31–40 of 45 posts
You can either use VM snapshots or our metadata service (cloud-init compatible) to provision new instances automatically. We also have an API, but you don't need it for autoscaling.
We're a European cloud provider (based in the Netherlands) and don't have PoPs in the US though.
"AWS costs almost twice more than analogous DO servers, but AWS has way more features." When you us AWS you are paying for more than just a cheap VPS, which essentially is all DO is. It's comparing fast food to a fancy steak house. You can get meat at both, but at one side its microwaved. Not to say DO isn't great, it gets the job done and provides a valued service, but your money gets you what your money gets you.
It's really hard to find scenarios where AWS isn't ridiculously overpriced.
Consider that Digital Ocean is also an expensive alternative, but I deploy caching proxies for some clients who for various reasons insist on using AWS on DO because you can save lots by deploying droplets on DO to cache rather than pay AWS bandwidth costs for all your traffic, for example (you serve more than 1-2TB a month out of AWS you can start saving money that way).
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…
isn't that true for any CP store in any "cloud" provider?
Sounds like a fun project (and totally doable)! :) If I were you, I'd make heavy use of ansible, or something similar, for provisioning: 1) folks are familiar with it 2) could make it cross-platform more easily 3) well, no reinventing the wheel. For example, Ansible has ec2 module http://docs.ansible.com/ansible/ec2_module.html where you describe an instance and the number of them that should be running. So if you ha…
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.
A lot of the time when people want auto-scaling, the thing that strikes me is that most of them wouldn't have needed auto-scaling if they picked a cheaper provider to beging with. Often they could pick a dedicated provider, spin up 3 times as much capacity and still pay less.
I do not believe that a price difference of 100% would be enough to make such a project interesting. Why not build something like this for dedicated boxes from hetzner, ovh ... I don't have a clue how much harder this would be, but a price difference of about 300% looks much more interesting.
That said, one of the reasons to use providers like Hetzner and OVH is that as I've pointed out elsewhere, the price difference is so large that most people who "need" auto-scaling at places like AWS would pay less if they just ordered 2x to 3x as much capacity at a place like Hetzner and left it on 24/7.
Very few people have loads that are genuinely spiky enough to save enough from auto-scaling to make up for the massive cost difference.
It would allow you to add nodes with the packages that you need extremely easy. In one or two hours a cron could be made that adds and removes nodes as needed.
It is not a magic bullet solution but it fixes 80% of the problem with 20% of the effort.
It would allow you to add nodes with the packages that you need extremely easy. In one or two hours a cron could be made that adds and removes nodes as needed.
It is not a magic bullet solution but it fixes 80% of the problem with 20% of the effort.
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…
> you should expect a few "surprises" if you're running consul.io on Digital Ocean, heartbeats are delayed quite often (depends on datacenters), which makes failure detection hard isn't that true for any CP store in any "cloud" provider?
As I said, we've deployed our production environment on bare metal (in reaction to this exact problem...)
The cloudhero CLI can be a very good option for this. https://cloudhero.io/cli/ (pip install hero) It would allow you to add nodes with the packages that you need extremely easy. In one or two hours a cron could be made that adds and removes nodes as needed. It is not a magic bullet solution but it fixes 80% of the problem with 20% of the effort.
Basically, my docker cluster starts from 3 nodes and as the cluster gets filled with containers I automatically add new nodes on Digital Ocean to increase the cluster capacity.
Our team worked a day to make it happen but we got excellent support from the team.