Early on you probably don't need it for the load but for handling recovery if an application server goes down.
Prior to now if you wanted to run a passable production environment for a small application you'd probably do something like a single persistent store behind 2 application servers fronted by an nginx to balance load across the two.
Doing that requires nginx config and finding an off the shelf package for handling healthchecks and automated removal of failed items from the nginx load balance rotation. Now DO will do that for you at slightly above the cost of you rolling it yourself but with the benefit of being (probably) more reliable and requiring near-zero time investment.
Edit: Other threads have pointed out that keepalive on the VM works for recovery on single compute instances. Seems likely that this is for DO's larger client who need recovery and multiple computes with load balanced across said compute surface.
My question is if any of DO users want this today? If so, I am interested in knowing their use case (what kind of app requires a load balancer and nothing else). I don't want some imaginative work load, I want to a real example. For example, I cannot use it for my wp installs because the db does not scale without some work.
For the LB I use haproxy server only, which has it's own healthcheck.
How do you deal with a availability zone failure of a cloud provider?
We use it for both production, and staging, though we do offload our database to Google Cloud.
On DO we host our application servers (frontend and backend), as well as our caching, search and monitoring services. These are all load balanced behind Haproxy.
EDIT: This is coming from someone who works at MSFT and gets a bit of Azure for free. To me it's all about using the right tool for the job.
But Azure is very pricy if you want to use it just for VMs.
Sometimes we use it as a cost-cutting do-it-yourself CDN in front of AWS for clients that insist on S3 for storage (and again where we can't just cache everything in Europe for latency reasons). For bandwidth heavy applications, you can pay for significant numbers of Droplets from the AWS bandwidth savings alone.
Lack of load balancers have meant resorting to DNS based failover and hoping clients handle short TTLs (it works reasonably well, but with occasional issues), but the cost reductions are sufficient to make that a worthwhile tradeoff for many clients.
Don't get me wrong, I am just wondering if digital ocean wants to be AWS.
I think we can make the generous assumption that you've profiled and decided that compute is the problem and not static pages or DB. If that were the case, why would you not use DO load balancing?
> I am just wondering if digital ocean wants to be AWS.
No, they want to be better than AWS. They absolutely want that AWS $$$. Selling to devs who create "MVPs" and prototypes might pay the bills for now but if they are going to grow into their valuation they need larger clients. Seems likely that large clients wanted load balancing.
When you attach a load balancer, in AWS, it uses ELB; in DO it spins up an HAProxy instance. There are likely advantages to having parity between the stacks, having the load balancer higher in the stack.
For me somehow, the load balancer nevers puts a server back again in rotation even though ssh and http directly access works. Need to boot up the ec2 and then it comes back in rotation.
Source: spent a several days in December cost modelling a few services for a client, was surprised by the result
I mean granted I've only done rough guesstimates for some toy applications for myself and some friends and family, so I could be totally off base here.
Nah. I pay monthly, include monthly pricing. I can probably set up an nginx/varnish instance faster than I can calculate the monthly cost when you're billing by the hour.
One thing that is nice is the automatic failover (of the routing stack) when a VM or datacenter goes down.
Essentially what I'm after is Digitalocean's load balancing per-domain rather than per-infrastructure
If it was my own stuff I'd just do it myself, work can afford the premium if it includes a support team when things break