Hacker News Reader

> If $cloud_vendor doubled their prices tomorrow, what are you going to do ?

> If $cloud_vendor decided to kill-off a product tomorrow and replace it with another one with a different API, what are you going to do ?

Been using AWS for close to ~10 years now and I don't recall them doing anything remotely similar to above. Of course, they could potentially do it in the coming days. But going by their past behaviour I'd say it's a low probability event.

When the cloud/AWS was new these fears were indeed valid. But this line of reasoning is getting old and tiring; especially when it's not backed by even anecdotal evidence and is purely speculative-fear in nature.

I do know that Google, Twitter and others have pulled down some fairly popular APIs/products but please don't conflate that with GCP/AWS/cloud offerings.

For most of the startups it's not even a question of if cloud now. Early days (2010-2015ish) it used to be the case that engineers had to convince management about the advantages of cloud. Primarily because one had to mostly go hybrid as many of the services weren't in cloud yet (such as Route 53, RDS etc.,). It was a pain to maintain hybrid. Now it's possible to run 100% of tech stack in cloud. So it's the other way round; VCs and business folks will frown upon tech if they run on bare-metal/data-centre.

There was the time Google App Engine completely changed the pricing model. Although I guess that isn't technically GCP.

Should we infer zero off-cloud contingency plans, then?

Depends on factors such as business size, product life cycle stage etc.,

For a typical startup trying to figure out PMF and launch an MVP or figure out customer retention I'd be really surprised if off-cloud contingency is even on top-50 priority list.

But for someone with a proven business model with a good revenue stream cloud dependency or vendor lock-in or single-vendor-point of failure does indeed become an action item to be worked upon.

Or when a regulator requires setting up a DR site which they did for us back in 2015. We had no option but to set it up in a data-centre.

Or let's say someone like Mighty (1) whose product is sort of competitor to AWS's (2). They wouldn't want to go anywhere near AWS or any cloud for that matter. And last I heard they were indeed ordering their own physical server machines.

There are valid reasons to look for either hybrid or purely on-prem solutions as I listed a few above. But please don't forward "what if cost doubles" type of reasoning. All that said, I'd hypothesise not going full on cloud is an exception for a typical startup now a days.

(1) https://www.mightyapp.com (2) https://aws.amazon.com/workspaces/

If you take this attitude you should write all of your own tools, make your own hardware, not use any libraries (I might actually be able to make a case for this one).

I am most familiar with AWS, so all I can say is their prices have gone down over times, the availability has gone up, and the total number of services is amazing.

With other cloud vendors I think you might be at more risk of them shutting down services, but if they start doing that with out giving you multi-year notice it means they are going out of business.

> If you take this attitude you should write all of your own tools, make your own hardware, not use any libraries (I might actually be able to make a case for this one).

No. Just...no. There are more than the two possible positions, its not either "ignore technological dependencies completely and blindly give your balls to a single vendor" or "create everything yourself from the ground up". You can look at your stack and consider how vulnerable you are compared to how much you gain. Sometimes you will find that it's worth it going all in with one vendor, but it should be a conscious decision. Business have to consider their vulnerabilities all the time and it boils down to compromises and tradeoffs.

Exactly. If your $open_source is abandoned tomorrow, what are you going to do?...

Stay on the version that already works and provides the features you need? Fork it to add new features if needed? You don't need to constantly update software dependencies.

Fork it, and continue on...

Genuinely can't tell if this is sublime sarcasm or a straightforward argument.

> If $cloud_vendor doubled their prices tomorrow, what are you going to do ?

They can't do this because of reputational damage. No one would consider that provider for the next 5 years. It also wouldn't squeeze out as much as you'd think because medium size and larger accounts are all on long-term contracts, so they have time to migrate.

Google maps did that with their pricing and a lot of people changed api's.

Yes, it's a simpler change. But other serverless tech does exists on mostly the same dev language.

Additionally, price changes should be warned way upfront.