
Multi-Cloud Is a Trap - tylertreat
https://bravenewgeek.com/multi-cloud-is-a-trap/
======
sgt101
“Lock-in” comes because others depend on the benefit from your services, not
because you’re completely in control."

\- this is hopelessly naïve. Lock-in occurs when you no longer can generate
the capex to resolve the opex drain that a vendor squeezing you has created.
If any vendor realises that you can raise the capex to get off them then they
will raise the opex demand to the point of financial viability to maximise
their returns and to ensure future returns (because by doing this they
underline their control)

Vendors can't help doing this, it's natural. Also it's their duty to their
shareholders.

Our responsibility is to NEVER get into this situation.

~~~
dsr_
Small companies are terrible at working together, even when it's in their best
interests.

Can any single customer smaller than the US government get a policy change at
Amazon by threatening to walk away?

~~~
dfsegoat
I'd put Netflix up there as a first candidate...

~~~
rbanffy
Are they still a pure AWS house? I'd expect that, at their scale, they'd have
boxes and VMs everywhere the round-trip time justifies.

~~~
testvox
They use AWS for everything except content delivery which is handled by their
Open Connect content delivery system that they built and operate.
[https://openconnect.netflix.com/en/](https://openconnect.netflix.com/en/)

~~~
rbanffy
Interesting. For a moment I thought they would aggressively optimize encoding
for frame cost but then I realized that's probably a rounding error compared
to their costs in storage and co-located infrastructure.

------
Spooky23
There are some good arguments about the technical complexity of using multiple
clouds. But the author seems to be naive about the power of competition, or
more appropriately, the problems associated with having no competitive
pressure on vendors. #1 priority of any business should be to have as few
sole-source suppliers as possible.

It seems cleaner to go all-in on AWS/Azure/Google/Your Datacenter/something
else. But the reality is, if you have a significant spend, and are dependent
on one vendor, you are truly fucked. You won't get good terms, you won't get
good pricing.

This industry goes through this cycle again and again. 30 years ago, people
bet the business on Oracle/Informix/DB2/Sybase. Oracle is the king of that
hill, and we all know the stories about how great they are to work with. 10
years ago we started with Office 365 and it's predecessor. Ask a big Office
365 customer how their subscription renewal process went.

Cloud is no different. Unless you can tell your AWS rep to go fuck himself and
move workload elsewhere quickly, you are giving up valuable leverage.

~~~
PopeDotNinja
Don't forget that it's easy to get killed on bandwidth costs when you suck
your data out of one cloud and into another. Also, you have to be big enough
to justify the spending money on engineers to make you multi-cloud, as you'll
be implementing many features yourself, which takes a bunch of time.

------
dec0dedab0de
I think many people coming up these days never really felt the effects of
Vendor Lock-in. Everything is either an open enough standard or dominated so
thoroughly by one player that there is no option anyway. I remember my printer
not working, and saving my report that I wrote in MS Works on a floppy disk. I
assumed that the computers at school would be able to read it. They had Word
Perfect, and MS Word, I mean one was the _same_ vendor, and it still didn't
work. That was over 20 years ago, but I still cringe whenever I see someone
using any kind of closed standard.

The idea of starting out with a single provider until you actually have things
working is probably a good idea. But, I'm surprised that more companies with a
certain level of steady traffic don't run their own hardware and spillover to
the cloud for spikes.

~~~
titanix2
Open standards doesn’t magically solve compatibility issues for very complex
software: I remember ODT files having their layout completely messed up when
opening them with a different version of Open Office. And this was minor
version changes, not major ones. I had way less problem with modern variant of
MS Word. That being said, I’m all for open formats.

~~~
dec0dedab0de
_Open standards doesn’t magically solve compatibility issues for very complex
software: I remember ODT files having their layout completely messed up when
opening them with a different version of Open Office. And this was minor
version changes, not major ones. I had way less problem with modern variant of
MS Word. That being said, I’m all for open formats._

Absolutely. The major difference is that one is a technical challenge, and the
other was a marketing decision.

------
api
Multi-Cloud isn't a trap any more than any other practice is a trap. Any
practice is a trap if it takes away from your core mission too much or
requires resources you don't have. I call such things "engineering
bikeshedding" \-- solving _some other problem_ instead of your core problem.

I think doing multi-cloud for something "normal" and mundane is probably over-
engineering. If you want to avoid vendor lock-in just avoid using the most
proprietary features of your cloud vendor, or use them in ways that would not
be terribly hard to port later (e.g. it's not hard to swap something else out
for S3). Yes your DC or cloud provider will have issues every once in a while,
but in the grand scheme of things it won't matter unless your service is one
that demands damn near 100% uptime as a strict requirement.

Multi-cloud makes sense when you need near-100% reliability. There are few
things where reliability requirements are this stringent. It can also make
sense when you need a great deal of geographic diversity or portability.

~~~
randoramax
It's hard to migrate data off of S3: once you drop petabytes in there, moving
to another service will cost you a lot of cash.

~~~
manigandham
Migrating petabytes will always cost lots of money, no way around it.

------
SoulMan
My company is was full on into GCP and after a year of terrible support
management suddenly decides to go all in into Azure. We use every managed
service from GCP including BigQuery which is nearly impossible to find a
replacement of in Azure. Appengine needs to be converted to Azure Kubernetis
Service. So its not a technical decision completely, just that company signed
a bigger deal with Microsoft and wants to pay a single bill. Based on feedback
from other teams company feels Azure support is way more professional when it
comes to production outage. Now all of 3 years work sing Google services needs
to be re-written in "cloud agnostic" way.

------
hardwaresofton
For those that avoid the "cloud-native" hype, this is one of the reasons you
should -- while this article rails against multi-cloud, as other posters have
noted, it's important for preventing lock-in and keeping competition alive and
prices down between providers.

I'll go one step further in saying that it's an inevitable future. The
likelihood that one cloud will have the best price, best components, best
qualities for every use-case is just not very likely. People _will_ trade
complexity for price eventually, once the price gets big enough.

The good news is, kubernetes is fast appearing to be the winner of the race
for a multi-cloud substrate. The bad news is, kubernetes is complex (IMO
necessarily so), so it takes quite a bit of investment and mindful practice to
learn.

I just thought of it, but you know what would be nice, if people started
posting their AWS/cloud provider costs.

~~~
falcolas
Don't worry, they're doing everything they can to lock down Kubernetes as
well. EKS, GKE, AKS... and the managers look at this and go "it's a managed
service, we don't need to pay an engineer, buy it!"

Of course, the whole "not needing engineers" bit is a lie of the highest
magnitude, but the marketing was really well done.

~~~
hardwaresofton
Could you expand on this? what do you mean by locking it down? EKS, GKE, AKS,
and OKS (Oracle has their own now) and IBM's CKE are all wins to me. While I
personally don't think people should be trying to tune Kubernetes into heroku
(IMO you should build a layer _on top_ of kubernetes for that), people are
trying and succeeding in making it way easier to run applications on it.

Dumb managers are gonna do dumb stuff no matter what, but judging by how the
widespread use of AWS did not in fact mean hiring _less_ developers, it just
changed the kind you needed to hire. I feel like the job posting just changed
from sysadmin to sysadmin (for actual in-company computer management) + devops
(for tech-side server management)?

That said, I'm also kind of waiting for the other shoe to drop on Kubernetes,
it just seems too good to be true (minus the complexity of learning it of
course). Well, thinking about it, I use gmail so maybe I traded my privacy in
small part for this.

------
dim0r
Multi-Cloud can be hard to do right and there are plenty of traps along the
way. It sure doesn't make sense to go that way just for Disaster Recovery,
unless you need to be prepared for the unlikely event that Amazon or Google
will suddenly get wiped out of the planet.

That said, going Multi-Cloud is indeed unavoidable in a growing number of
settings. So, instead of looking at it as a source of troubles, it can be
leveraged as a way to extract the best features out of each provider, to avoid
lock-in wherever it makes business sense and to minimize costs by distributing
workloads accordingly. That introduces new issues regarding access control,
cost analysis, auditing and governance which are best managed by a Multi-Cloud
Management Platform.

If you're looking for such a tool check out [https://mist.io](https://mist.io)

It's an open source CMP that supports most popular public & private clouds, as
well as Hypervisors and container hosts. It takes care of provisioning,
monitoring, RBAC, cost analysis and automation/orchestration. It can also be
used to deploy Kubernetes clusters on any supported cloud.

Disclaimer: I'm one of the founders.

~~~
jarfil
There, open source, that's the key point to avoid lock-in.

There is no problem with going with any single provider, as long as you "can"
replicate any functionality you're using. You may never actually replicate it,
but that ability is what makes me trust a provider... because even if they
fail, I know it won't be too much of a problem.

------
pritambarhate
This is a naive point of view. Cloud providers can and do raise prices when it
aligns with their objectives. Especially Google has the history of doing this.
Make a very strong product, offer it very cheap and then when all the
competition has died, raise the prices. Google Maps is one recent example.

------
QuinnyPig
Excellent, excellent point. This is a drum I'm starting to beat more and more
as companies start viewing multi-cloud as some sort of ridiculous best
practice.

------
stevehiehn
My understanding is that some institutions i.e. banks, governments etc. have
requirements to leverage multiple public clouds.

~~~
sapphire_tomb
Yep, at least in the UK. If you want to leverage the cloud as a bank, then
there are regulatory requirements to go Multi-cloud - it's not a choice.

~~~
easytiger
Out of interest, do you know more about those requirements?

~~~
stevehiehn
Sorry I don't. I've just heard that these requirements exist.

------
mathattack
I’ve found virtually every vendor I deal with starts abusing their power until
they receive an RFP that lets them know they’re in competition. The cloud
salespeople I’ve met are no different.

------
slap_shot
Do people honestly do this? If they do, do they not take advantage of the
platforms' services or do they rewrite all their code to the use each cloud's
specific service (e.g. Kinesis vs Pub/Sub)? Or are they use using compute
resource and running the services themselves? If it's the latter, isn't that
as close you need to get to get to prevent vendor lock in? Deploy your code on
any cloud and you're going...

~~~
a-saleh
Does partial on-premise count?

In my previous work, some of our clients wanted to self-host our saas service.
We allowed this by migrating our infrastructure on top of kubernetes
(previously it was tightly coupled with aws). For some technical reasons, some
of the services were still hosted, i.e. even for customers that had on-premise
deployment, we provided access to our saas mobile-application build-service.

------
a-saleh
Does using both internal openstack as well as aws externally count as multi-
cloud?

~~~
peterwwillis
That's "on-prem & cloud", definitly not multi-cloud. You're only in the cloud
when there's multiple datacenters providing high-availability scaling
services.

