* When you have invoicing setup, the above shouldn't happen. You need to keep a payment method in good standing, but you have something like 10 days to pay your bill. -- They do a little bit more vetting (KYC) on the invoice path, and that effectively gets you out of dodge.
* Without paying for premium support, there's effectively no support.
I think if someone didn't pay their bill on time, you might shut off their service too, wouldn't you?
"Oh hey, it looks like $customer suddenly started a bunch of coinminers on their account at 10x their usual usage rate. Perfectly fine. Let them rack up a months billing in a weekend; why not?"
A hypothetical but not unheard of scenario in which immediate shutdown might be warranted.
It's a rough world and different providers have optimised for different threat models. AWS wants to keep customers hooked; GCP wants to prevent abuse, Digital Ocean wants to show it's as capable as anyone else.
If you can afford it, you build resilient multicloud infrastructure. If you can't yet do that; at the very least ensure that you have off-site backups of critical data. Cloud providers are not magic; they can fail in bizarre ways that are difficult to remedy. If you value your company you will ensure that your eggs are replicated to more than one basket and you will test your failover operations regularly. Having every deploy include failing over from one provider to another may or may not fit your comfort level; but it can be done.
> A hypothetical but not unheard of scenario in which immediate shutdown might be warranted.
Not without warning, no. It is possible that the customer intended to start a CPU-intensive process and fully intended to pay for it.
Send a warning first with a specific description of the "suspicious activity" and give the customer a chance to do something about it. Don't just pull the plug with no warning.
There's a degree of complexity that comes with multi-cloud that's ill-suited for most early stage companies. Especially in the age of "serverless" that has folks thinking they don't need people to worry about infrastructure.
My point is that the calculus has more to it than just money. The prudent response, of course, is to do as you described. Have a plan for your provider to go away.
Offsite backups and the necessary config management to bring up similar infra in another region/provider is likely sufficient for most.
> There's a degree of complexity that comes with multi-cloud that's ill-suited for most early stage companies. Especially in the age of "serverless" that has folks thinking they don't need people to worry about infrastructure.
Perhaps we'll start seeing a new crop of post-mortems from the "fail fast" type of startups failing due to cloud over-dependency issues. They're (presumably rare) edge cases, but easily fatal to an early enough startup.
> There's a degree of complexity that comes with multi-cloud that's ill-suited for most early stage companies. Especially in the age of "serverless" that has folks thinking they don't need people to worry about infrastructure.
I just heard a dozen founders sit up and think "Market Opportunity" in glowing letters.
CockroachDB has a strong offering.
But multi-cloud need not be complicated in implementation.
A few ansible scripts and some fancy footwork with static filesystem synchronization and you too can be moving services from place to place with a clear chain of data custody.
Everything I have runs in kubernetes. The only difficulty I have to deal with is figuring out how to deploy a kubernetes cluster in each provider.
From there, I write a single piece of orchestration that will drop my app stack in any cloud provider. I'm using a custom piece of software and event-driving automation to handle the creation and migration of services.
Migrating data across providers is hard as kubernetes doesn't have snapshots yet.
There are already a lot of startups in this space doing exactly the kind of thing that I just described. Most aim to provide a CD platform for k8s.
For an early startup, though, I would think it's not necessary to be "fully" multi-cloud.
Rather, it would likely be enough to have a cloud-agnostic infrastructure with replication to a warm (or even mostly-cold to save on cost) standby at the alternate provider with a manual failover mechanism.
Most folks overestimate their need for availability and lack a willingness to accept risk. There are distinct benefits that come with avoiding "HA" setups. Namely simplicity and speed.
> Most folks overestimate their need for availability and lack a willingness to accept risk.
I disagree. More specifically, I think, instead, many [1] folks just don't make that assessment/estimate in the first place.
They just follow what they perceive to be industry best practices. In many ways, this is more about social proof than a cargo cult, even though the results can resemble the latter, such as elsewhere in this thread with a comment complaining they had a "resilient" setup in a single cloud that was shut down by the provider.
> There are distinct benefits that come with avoiding "HA" setups. Namely simplicity and speed.
Indeed, and, perhaps more importantly, being possible at all, given time ("speed") and money ("if you can afford it").
The same could be said of "scalability" setups, which can overlap in functionality (though I would argue that in cases of overlap the dual functionality makes the cost more likely to be worth it).
None of this is to say, though that "HA" is synonymous with "business continuity". It's much like the conceptual difference between RAID and backups, and even that's not always well understood.
[1] I won't go so far as to say "most" because that would be a made up statistic on my part
Agreed for the most part. Availability for very many is a binary operation. They either do none of it or all of it.
A clever man once said, "you own your availability".
An exercise in BC planning can really pay off. If infra is code, and it and the data are backed up reasonably well, then a good MTTR can obviate the need for a lot of HA complexity.
> Availability for very many is a binary operation. They either do none of it or all of it.
I assume I'm missing some meaning here, particularly since the premise of much of the discussion in the thread is that there can be high availability at one layer, but it can rendered irrelevant by a SPoF at another (especially when the "layer" is the provider of all of ones infrastructure).
Do you consider that a version of "none"? Or are you pointing out that, despite the middle ground under discussion, the "binary" approach is more common, if not more sensible?
The binary approach is that it either isn't considered or people opt in for all of it without consideration for what is actually needed. The Google SRE book goes into this at length. For each service, they define SLOs and make a considered decision about how to meet them.
Oh, so what you're saying is that they're no considering the notion that there may be a medium-availability (for lack of a better term) solution, which could be perfectly adequate/appropriate?
Yes, there is or they wouldn't turn it off. Companies aren't in the habit of trying not to take your money for services without a pretty damn good reason.
And if it was that critical it should have support and a SLA contract, and you know, backups.
Right. Because big companies never ever do anything unjustified. Particularly when they put automatic processes in place with no humans in the loop, because we all know that computers never make mistakes.
