Recently I was reading my favourite 9GAG series on the web and while surfing I
was hooked onto this quote :
” I am a SYSADMIN because FREAKING AWESOME is not an official job title.”
It’s been few months since I have joined new start-up Corseco [http://corsecotech.com] and on the day one itself I was given the task to design the entire flow from scratch including the backend architecture.
Initially, since our product was more in the POC kind of shape we started with Digital Ocean. 20$ /mon pricing “droplet” which has around 2 GB of Memory , 2 Core, 40 GB SSD, and bandwidth of 3TB.
But as my project grew bigger and bigger I was sure that I had to migrate it from Digital Ocean. And there are two reason(s) for the same :
– Being a startup we had a very small team and pile of task(s). Also, with the increasing size of our DB cluster and number of droplets with all the data inflow, I was sure that we had to be on our toes if we are managing this using DO[Digital Ocean].
Personally I like DO reason being it kind of gives me a bare-metal machine to play with. For a guy who wants to know how to setup the production based architecture DO, is heaven to be honest. But then again, DO has some drawbacks as well (and you can correct me if you feel that I am wrong here).
– Elasticity in terms of expansion. Well, I can expand the cores of my machine any time but in case I want to shrink my machine it’s a different TASK altogether. I’ll give a small use-case over here. Recently, we were testing our product VCA [Video Content Analysis] and big chunks of data was pouring in. As we wanted to do stress testing on the VCA tool we started 3 more VCA machines , due to which there was more inflow of data. Now since I was using a single 20$ /mon machine for the testing purpose I thought why not expand it to 40$ /mon and as soon as I did that! WHAM!
- They turn off your droplet when they are expanding! The lag is pretty significant if you are working on a real time scenario.
- No way to roll back changes.
Another point in non-flexibility is LOAD BALANCING. If you are using DO services you need to configure the HA Proxy and other services manually, right from the scratch!
One of the service that I need the most is use of CI auto deployment. I love Heroku for this! <3 [no pun intended]
So we currently use Travis-CI for auto deployment. To be honest I miss Heroku 🙁 at times for the auto-deploy part, especially for the staging server. Now in Digital Ocean, for this part again the manual intervention comes into the picture.
But one thing I particularly liked about Digital Ocean is the fact that it is easy to use and spinning up droplets is fast. After facing a bit of issues in the initial level of product development and deployment, I thought maybe it’s a good idea to shift the following to other service. Then I received a mail from Microsoft, stating their ISV partnership program. And after meeting their Sr. Evangelist Mr. Manish at their Gurgaon office, I was pretty convinced for migrating my architecture from DO -> MS [haha]
One of the core feature that Microsoft boasts about is their uptime [which is specifically mentioned in their SLA] that is, 99.99999999….% . To be honest, migration on Microsoft Azure was pretty easy.
Features like auto deployment hooks, CI environment, Auto-Scalable load balancers, traffic management, were enough to keep my faith in Azure alive after initial the week of testing.
Also easy DNS management along with custom test domains at _foo_your_domain.clouadpp.net is sort of a life saver for our UI team. They want to send the designs to client. Also, IP’s are not cool if you want to give demo to the client.
Coming to the pricing model of Azure. I don’t know why, personally I find it a bit on a higher side for large VM’s. Especially when compared to Digital Ocean but then again the flexibility that I get with the Azure is something worth mentioning.
Well I did a comparative study of Azure w.r.t to the DO, that I was using earlier and here are my findings. [for stress testing I used Locust.io to check whether or not the system goes down, general 500 error, resource busy etc.]
PRICING Azure : Bit On High Side for large VM’s but add on services are a plus. DO : Pocket Friendly 🙂
Scalability Azure : Easy to Scale DO : Manual Work
Elasticity Azure : High DO : Manual Work Involved
Migration Azure : Easy DO : Lots of Pooling and structurization involved
Ease of Management Azure : Great DO : Not So much 🙁
Resource Pooling Azure : Great DO : Average
I also made a test case with Locust IO comparing $20 machine and (A1 1 1.75 GiB 70 GB) instance of Azure. Surprisingly, A1 was able to handle the request pretty easily. I mean there the threshold I was getting was around 294 RPS with DO, and with Azure it was around 340 upto 0 error.
I’ll post some stats with fancy graphs in my next blog.
All in all, I would say Azure is something any budding startup with limited resource should try out as it decrease the pain of your Dev-Ops guy and also did I mention that they give free credits too!
That’s all for now. Till the next time. Adios!