WwoeSsi
By:
WwoeSsi

DigitalOcean or Amazon AWS for autoscaling?

April 24, 2017 571 views
Scaling Ubuntu 16.04

Hey everybody.
I’m planning to setup a platform on which I will give space to professional travel writers to monetize their articles. Behind the scenes it should be supported by a forum. I did a lot of research and I have decided to go for a combination of Ghost and NodeBB as a start, and script my own needs from there. Since this is both NodeJS I think it should be possible to host it on one VPS with NodeJS and MongoDB (Mean stack) on Ubuntu 16.04. Before I start building, however, I want to make sure that I’m choosing the right architecture. It is very important that it is highly scalable. Also it should scale automatically because in the future articles might go viral which will result in traffic peaks, and in the nighttime the website may have way less visitors. I’m now deciding between DigitalOcean and Amazon AWS. Amazon AWS offers Elastic Beanstalk (https://aws.amazon.com/elasticbeanstalk) and AutoScaling (https://aws.amazon.com/autoscaling/). DigitalOcean offers an API and a few example scripts for automatic scaling, but they don’t really have a service for it.
What would you do if you were in my position? Which option is the cheapest? Are there other options?
Kind regards, Wijnand

5 Answers

Hi @WwoeSsi

If you want complete auto-scaling no matter if there is 1 user or 1000 users visiting the site at the same time, then I would probably recommend using AWS or Google Cloud.
It's a lot more pricey, of course, because they always need to ensure there's enough resources.

But you can setup a solid, scalable structure with DO. I would recommend using a load balancer and/or cache server (something like Varnish perhaps). Then you know your cost every month, but you should be able to serve several hundreds (easily scalable to thousands) of requests at the same time.

@WwoeSsi

DigitalOcean doesn't have built-in auto-scaling capabilities baked in to the service as of yet.

There are ways to auto-scale, but you'd be building in that functionality on your own using the API or setting up each aspect manually (which isn't really auto-scaling since it wouldn't be automatic).

If you're not willing or capable of building out that functionality, I would most likely recommend using a service that supports it, such as Amazon or GCP.

As @hansen mentions, it is possible to setup a very solid and scalable structure with DigitalOcean, but it's not as automatic as it would be elsewhere just yet. New features are being added, such as Block storage and Load Balancer services, but auto-scaling would be limited to use of the API.

...

That being said, the way it's currently managed with DigitalOcean, you can only scale CPU and RAM without having to shutdown an instance. If you choose to scale disk as well (disk that isn't block storage -- speaking of the disk on the Droplet), you have to shutdown.

If you scale CPU and RAM, you can scale up or down. If you scale the disk (again, not block storage), then there's no scaling down.

For the above reason, It's best to use Block Storage for storage over worrying about upgrading the actual physical/virtual disk of the Droplet.

@hansen @jtittle Thanks a lot for your feedback. I'm right now running this startup alone but as it expands I will be able to hire people for the back-end to make scaling as efficient and cheap as possible.

So my question is what would you do? Would you go for the more expensive AWS or GCP in the beginning? Or do you think it would quickly pay off to hire someone for doing scaling manually (and in the beginning do it myself, without any prior knowledge? It seems there's a lot of documentation out there).

Is GCP and AWS really that much more expensive?

  • @WwoeSsi What I would do - well, I would do the setup myself, but that's not the answer you are looking for :-)

    In your position I would probably recommend hiring someone to do it for you or try to get started with GCP/AWS yourself (which is still not two-clicks-and-you-are-running).

    As for price, GCP/AWS will charge you depending on load. DO charges you for whatever size droplet you've chosen.
    So they will scale, but become more pricey, whereas DO will become slower, but price is always the same.

@WwoeSsi

Having worked with GCP, Amazon, and SoftLayer/IBM over the past few years, I can say that the cost very well can be more expensive.

For example, when I was tinkering with SoftLayer, it was relatively easy to just deploy a configuration that'd easily cost me $10,000 a month if I had of been paying for it -- and that was 2x servers. Albeit, they were Quad-CPU, 1-2TB RAM, 16-24x Disks, and Dual/Redundant 10Gbps uplinks, but still -- easy to do. SoftLayer's API is a nightmare to work with though, so back to the others :-).

With DigitalOcean, you'd have to deploy quite a few Droplet's on accident to hit the $10,000/mo mark intentionally or on accident.

...

That said, example aside, what I would do before even choosing a provider is to map out what you think you need now, and if X, Y, Z growth goes as planned, what you should need in 6-12 months.

Why? I could tell you stay with DigitalOcean and you could, or I could tell you go with GCP and you could. But if neither can offer what you need now and should need in the future based on projected numbers and flow, you might be planning a large-scale migration from one to the next before you even get around to building out a platform to help you scale.

...

If you're current application state is development, figure out what you're going to need to push it in to production -- there's your base needs. When it comes to numbers, load testing will give you a general idea of what your application can take on X, Y, Z hardware (i.e. 2-12 CPU's, 2-16GB RAM, etc).

From there, you optimize your stack, retest with a new load test. Are your numbers better or worse? If better, see if there's anything else you can squeeze. If not, you know about what the max of your current hardware is and that's how you can go about scaling while keeping things affordable.

If you're numbers are worse, figure out what and re-optimize, then retest. Don't just throw hardware at something in hopes of making it better -- it won't always work.

...

Of course, you're also not limited to a single provider when it comes to scale. In fact, a properly ran structure would most likely scale beyond a single provider, or it should.

Relying on a single provider is like relying on a single data center when it comes to scale. You just don't do it. Too many factors at play and as the saying goes, don't put all your eggs in one basket.

...

If all this seems like it's too much to handle on your own, shoot me an e-mail, seriously. We can talk numbers, exchange ideas, go over what I would do with X, Y, Z, what I wouldn't do, etc. My e-mail is in my profile -- I'd be more than happy to discuss things with you. I've signed my fair share of NDA's in the past, so don't feel awkward if that happens to be the first thing you discuss with me :-).

@jtittle I emailed you thanks

Have another answer? Share your knowledge.