Scaling a Digital Ocean Vertically or Horizontally? (Newbie Here)
Scaling a DO Droplet Vertically or Horizontally?
Hey Guys, My first time posting here and not sure if this is the right place to ask as it doesn't directly pertain to any DevDojo products but it is about scaling.
I have been tinkering with Digital Ocean virtual servers for a couple of years and want to build out an application but I don't want to have to be the bottle neck when it comes to scaling.
I know with digital ocean you can just vertically scale a droplet but worry (one day) that one won't be enough.
I have had a look around briefly and the DO staff did send me some links about Kubernetes and terraform last year but it all seems a little intimidating to me.
I'm sure it won't be as bad as in my head it is but up until this point I tend to work on my own and having a little trouble embracing a team mentality so feeling a bit overwhelmed having to do everything from front-end to back-end and all in between.
Am I right in saying that the simplest version of horizontal scaling on DO is 2 droplets and a load balancer?
Also has anyone had experience with Digital Ocean's latest aquistion? - https://www.cloudways.com/en/#managelikepro
This might be the answer to my prayers but feel I might be giving up too much control to an automation...
Any contrustive replies are most welcome :)
Chris
Hi there,
Indeed, adding a second Droplet + a Load Balancer is a very solid way to go.
What I personally do is:
- Start with a single Droplet
- Once I've reached the limits, I would move the database to a separate server or a managed database cluster
- After that if I still need to scale, I would go for the second Droplet + Load Balancer solution
In this case, one thing that you need to consider are your sessions, as if you store your sessions on the Droplets directly, the user might see 2 different things depending on which Droplet the load balancer forwarded the traffic to.
To tackle this problem, you could go for a separate Redis server where you would store your sessions and cache so it could be shared between the Droplets.
An additional thing to consider is using an S3 storage so that if your users are uploading any files, you would not have to worry about replicating them from one Droplet to the other.
Here is a tutorial that I co-authored a couple of years ago that covers those concepts:
How to Set Up a Scalable Laravel 6 Application using Managed Databases and Object Storage
An alternative option is to go with the DigitalOcean App platform, that way it has the builtin load balancing and etc, and you could scale up with a click of a button.
Hope that this helps!
1
Hi Bobby :)
In this case, one thing that you need to consider are your sessions, as if you store your sessions on the Droplets directly, the user might see 2 different things depending on which Droplet the load balancer forwarded the traffic to.
I Noticed that when setting up load balancers you can have 'sitcky sessions' where the user is always taken to a specific droplet. Is that similar to what you mentioned about having a redis server. I appreciate its not quite the same.
An additional thing to consider is using an S3 storage so that if your users are uploading any files, you would not have to worry about replicating them from one Droplet to the other.
Also I would like to keep all the products under one roof (DO) this is for ease of use and I haven't yet used an S3 bucket but I believe they are very flexible?
I was thinking of using DO spaces for my file storage. Is there any advantage or drawback in this compared to S3??
Many Thanks
Chris Canham
Hey!
About the sticky sessions, this might help but if for any reason the LB forwards the user to the incorrect server, then the user will lose their session. So it is best to have a separate cache server rather than relying solely on the LB.
You can also use the same redis instance as your caching server so that the cache is also shared between the web servers.
Regarding the DigitalOcean S3 storage, yes, their Spaces product is quite good and it should be sufficient!
1