Live data from Hacker News

Autoscaling for Digital Ocean?

news.ycombinator.com

21–30 of 45 posts

Re: Autoscaling for Digital Ocean?

#21

One thing to consider is that DO is really, really good at vertical scaling. You can have about 1 minute or less downtime on an instance (basically boot time) to restart it as a bigger instance (RAM/CPU) as long as you don't grow the HD at the same time. This is counter to most horizontal scaling strategies but it's really about the same. When you add more servers you're essentially just adding more CPUs and RAM via…

Using snapshot to create a new droplet and update some configuration files should be fast either. Probably, longer than 1 minute but not much, I guess.

Re: Autoscaling for Digital Ocean?

#22

At clanofthecloud.com (Gaming backend as a service), we needed to implement autoscaling for DO, in node.js. We used consul.io for service discovery. CPU load was used as the central metric, and each service instance would store it in consul.io. We then triggered the creation/destruction of instances with thresholds. In the end, we only used it for our sandbox environment, as the production env runs on bare metal (mor…

Thank you. I'll look at consul.io closer

Re: Autoscaling for Digital Ocean?

#23

One thing to consider is that DO is really, really good at vertical scaling. You can have about 1 minute or less downtime on an instance (basically boot time) to restart it as a bigger instance (RAM/CPU) as long as you don't grow the HD at the same time. This is counter to most horizontal scaling strategies but it's really about the same. When you add more servers you're essentially just adding more CPUs and RAM via…

That looks nice until it doesn't work. We regularly see 30 minute event processing when doing flexible upgrades of Droplets (and the same when scaling back down). It's not safe, since the resize isn't guaranteed to be fast and you have no way to abort it once it's started. Sounds good in theory, not reliable enough to use in practice.

Re: Autoscaling for Digital Ocean?

#25

My 2 cents: Build an independent autoscaling tool that abstracts over the differences between clouds because: 1. Even if DigitalOcean is the best cloud provider today -- I'm not saying it is or isn't -- the probability it is the best that will ever be is approximately zero. The landscape changes. Heterogeneity among cloud providers is increasing and anyway latency will always be a function of the physical location of…

Thanks.

Re: Autoscaling for Digital Ocean?

#26
post #9

It wasn't clear to me how to autoscale with DO either. That's why I ended up using Google Cloud Engine. It's not exactly cheaper than AWS, but the pricing model for discounts is WAY simpler at least. It also doesn't have the feature set AWS does, but it does have most of what you'll need like a load balancing service.

Ditto. If you need to autoscale you outgrew DO. On top of DO prices not dropping in 4 uears, I see little reason to use them. GCE has $5 instances now with big boy features.

Re: Autoscaling for Digital Ocean?

#27
post #23

One thing to consider is that DO is really, really good at vertical scaling. You can have about 1 minute or less downtime on an instance (basically boot time) to restart it as a bigger instance (RAM/CPU) as long as you don't grow the HD at the same time. This is counter to most horizontal scaling strategies but it's really about the same. When you add more servers you're essentially just adding more CPUs and RAM via…

That looks nice until it doesn't work. We regularly see 30 minute event processing when doing flexible upgrades of Droplets (and the same when scaling back down). It's not safe, since the resize isn't guaranteed to be fast and you have no way to abort it once it's started. Sounds good in theory, not reliable enough to use in practice.

Isn't this what the flexible IP is for?

You create a new droplet concurrently the one running and then flip the IP to point to the new droplet. No downtime.

Re: Autoscaling for Digital Ocean?

#30
post #23

Earlier quoted context omitted.

That looks nice until it doesn't work. We regularly see 30 minute event processing when doing flexible upgrades of Droplets (and the same when scaling back down). It's not safe, since the resize isn't guaranteed to be fast and you have no way to abort it once it's started. Sounds good in theory, not reliable enough to use in practice.

Isn't this what the flexible IP is for? You create a new droplet concurrently the one running and then flip the IP to point to the new droplet. No downtime.

You have to have the a server with the same configuration or a snapshot or provision a new one...
Post reply on HN