I use DO pretty often and I hope they have some cool new offerings in the future. Maybe really simple load balancing?
I use DO pretty often and I hope they have some cool new offerings in the future. Maybe really simple load balancing?
I think "There's no way to increase storage space without major down-time" is the most important one. One hour of downtime is no good for production.
[1] https://www.digitalocean.com/community/questions/where-can-i... (Kamal Nasser February 13, 2014)
and
https://digitalocean.uservoice.com/forums/136585-digitalocea...
I don't think the time behind the scenes will ever be zero so I'd rather 100% be guaranteed not to lose my IP address. Spin up a new VM and assign prod-new the IP of prod-old similar to how you might do it with AWS Elastic IP
- Get a new pair of droplets in front of your current droplet to load balance the traffic (HAProxy, Nginx, you name it). Point the NS records to those :)
+ Why two? Well, you can't afford downtime so there we go.
- Get a new droplet and manually clone the initial one, i.e. copy over config and assets. Add this second droplet to the LB pool for your site/app.
+ Manual work? Well, again you can't afford downtime so you'll need to put some man-hours on this.
- Now you can shut down the initial droplet and image it while the second one gets the traffic coming from the LB.
Eventually you'd want to separate functionality on different servers, so try to also plan that in advance. Also bear in mind that each 512MB costs like $5/mo, that makes this solution work for $20/mo, how cool is that?
I agree there's room for improvement on DO's service, but there's nothing that a good architect can't work around.
Anything I say would be a shot in the dark, but I'm interested on your point of view about this one. Caching? Write on two servers? In the second case do you setup a cluster or you just load balance it with a third device/service?
1. Most people don't go with two writes to a relational database (like MySQL). Syncing is hard, and when it is done, it loses its relational features. 2. Common set up is one mysql write server, scaling it up to fit your traffic, and automatically syncing it with additional servers where SELECT statements only will be made. A random read server is selected if there are multiple to choose from. 3. This also means that in the application, doing a write and immediate read on what you just wrote won't work, so you have to code your application around that. 4. In you app you separate your connections for the reads and writes.
Now, in terms of making changes to the write server is what I'm trying to figure out. Perhaps there's a way to make upgrades on one of the slaves (the reads), then automatically make that slave the master and the master a slave? Not sure, I'm reading a MySQL book (The MySQL Bible) right now that I hope will point me in the right direction.