Hacker News Reader

Comment by astrostl | Hacker News Reader

"Multi-cloud from the outset" is probably the single-worst generic cloud advice that I think anyone could be given. In professional cloud consulting the rule of thumb is to do one cloud with excellence until you even think about another one. And even that is really just kicking the conversational can, as both becoming excellent and actually needing multi-cloud combined is one-in-a-billion.

View on HN

That pretty much binds your hands since in our experience the one provider who can do “one cloud with excellence” is AWS.

(As an aside I also agree that multi cloud from the get go is a YAGNI violation. Just keep in the back of your mind “could we have an alternative to this?” when using your provider’s proprietary features.)

That generalizes to every kind of lock-in: have a viable escape plan, but only execute it if you need or it becomes cheap enough that it won't harm you.

Just having the plan is already expensive enough.

My experience is the opposite: AWS has more features on paper but most of them exist only to tick a checkbox. Azure has more integrations between their offerings, as well as Azure Active Directory, and Microsoft 365.

And Active Directory integrates horribly with everything outside Microsoft.

Azure Active Directory has both SAML and OpenID Connect endpoints… what’s missing?

We use it across many non-MS services without issues. Care to expand?

We’ve had reliability and availability problems esp with azure and also Google. less with AWS.

None are ideal.

Why do I want AD or Microsoft 365?

You personally? No idea. You probably don't. But many (most?) businesses use AD and Office and aren't particularly interested in migrating to alternative solutions.

Yes, Microsoft focuses on the customer (corporate IT), not the user.

This is how the iphone was able to nuke windows phones which were designed to meet the needs of IT

I mainly work in startups. None of them in recent memory have bothered with AD or Office. Okta and Google Workspaces take their place.

Those MS products have an “IBM mainframe” problem. New businesses won’t choose them.

That’s why I say “why do I want them?” If I was starting a new business I’d have no reason to use them.

O365 = teams, docs, outlook, etc. workspace tools

AD = identity, access, privileging, SSO

I know what they are. No company I’ve worked for recently used them.

In my mind they’re legacy business products.

Sure, most businesses use them, but I don’t necessarily believe that is a forever thing. At one point most businesses had mainframes.

Refuse reality at your own peril. These tools are actively used at scale across most enterprises, and likely will be for the majority of your career. More than 95 percent of Fortune 500 companies use Azure/O365.

How many Fortune 500 companies were founded in the SaaS era?

I'm going to guess that the 5% that don't use Azure/Office 365 represent newer entrants to the Fortune 500.

71% of Fortune 500 companies use mainframes [3], and yet they are considered a dead technology with essentially no future. Do you know anyone or anyone who knows anyone who learned how to develop on mainframes in college in the current millennium? It sure wasn't part of my CS curriculum!

Small businesses represent almost half of US economic activity [1] and represent 99.7% of firms with paid employees [2]

[1] https://advocacy.sba.gov/2019/01/30/small-businesses-generat...

[2] https://cdn.advocacy.sba.gov/wp-content/uploads/2021/12/0609...

[3] https://www.precisely.com/blog/mainframe/9-mainframe-statist...

Just to steel man your statement: You should strive for excellence in deployment with all providers (dabble) but have your initial core setup on one cloud (YAGNI principle) until when multicloud capacity is needed (at scale)

If you use generic enough services (container hosts, load balancers, VMs, object stores, even hosted SQL DBs, etc), then the multi-cloud journey is not that hard. The challenge comes when you have build a whole architecture on top of some AWS magic that simply does not have an easy alternative in the non-cloud world.

Who are you quoting? I said "multi-region from the outset" and later acknowledged that multi-cloud would probably be overkill.

This was exactly what I was thinking, its amazing what people read into, probably myself included.

Completely agree, though certain aspects, such as running on k8s or Docker might make it easier to switch if you ever decide to, versus say, being tightly coupled with many bespoke cloud products.

My philosophy is to make switching to a new cloud possible. It doesn't have to be easy. We just shouldn't nail our feet to the floor.

Or you could just deploy on metal, which will be cheaper and sufficient for vast majority of cases. Plus you can always migrate to VMs with relatively low hassle.

You always only need another one when everything has gone to shit, either from failure or cost from vendor-lock-in, so drinking your chosen providers Kool aid equals taking the reactive route and scrambling to rearchitect when the issues hit.

Multi-cloud is really not a big deal. Main nuisance is billing differences, followed by slight variations in e.g. Terraform config.

On top of which, startups often don't have that luxury; you have often need to ruthlessly prioritise your effort.

True. When Nextel was bootstrapping in the 90's, a VP said, "We have to buy gas for the car now. Later we'll buy the seat belts"

Totally agree. If the service you're providing is so important, build your system so it can fly on one engine or at least land safely. Multi-cloud is the equivalence of trying to transfer all of your passengers to a different aircraft mid-air.

Multi-cloud should only be for mission critical infrastructure. Very little infrastructure is mission critical. Most other use cases can be temporarily wallpapered over with an "Under maintenance" page unless there's a good reason otherwise.

Multi-cloud introduces more risk than it prevents. Which is why things like simulated failovers and BCP testing is constantly required.

Surely it would depend on the reliability demands of your product.

Reply on news.ycombinator.com