For a startup, it can work out like this: Start out on AWS/GCP/Azure in the initial phase when you want to optimize for velocity in terms of pushing out new functionality and services. When you start to require several message queues, different data stores, dynamic provisioning and high availability, you save a lot on setup and maintenance - the initial cost of getting your private own cloud up and running, and doing so stably, is not to be underestimated. Especially when you're still exploring and haven't figured out the best technologies for you long-term.

Then, at some point, that dynamic changes as you have a better understanding of your needs, the bills start to build up and the architecture is in less flux. You might also have a bigger team and can afford to start allocating more resources to operation. That is the point when it it might make sense to migrate over to self-managed.

Then at the same time, you have the scalability, which might be more of a key point for even larger organizations.

I think building somewhat cloud-agnostic to ease friction of provider migration is good, regardless, but do so pragmatically and look at the APIs from a service perspective.

Kubernetes? All the bigger providers have alternatives and you can run your own. Fargate? You're going to have to do some rewrites. MemoryStore? Just swap for your another Redis instance. BigTable? Highly GCP specific. etc.

Not saying there aren't a lot of companies who choose the wrong provider for the wrong reasons, but it can also be part of a conscious strategy. Also nobody got fired for IBM and so on.

> Then, at some point, that dynamic changes as you have a better understanding of your needs, the bills start to build up and the architecture is in less flux. You might also have a bigger team and can afford to start allocating more resources to operation. That is the point when it it might make sense to migrate over to self-managed.

I completely agree, and I had this discussion with my direct manager in the past. Yet, even if the potential savings are significant, managers might not be too keen on investing on switching your infrastructure. Running your own infrastructure is risky, and although top managers enjoy lower utility bills they don't enjoy the sight of having a greater risk of suffering downtime, specially if the downtime is self-inflicted and affects business-critical services.

So, if this transition doesn't go perfectly smoothly... The people signing for the migration to self-hosting services might be risking their whole career on a play that, at best, only brings some short-term operational cost savings. Does this justify a move whose best case scenario is equivalent to a AWS discount?

For sure, there are a lot of factors to consider here. For heavy workloads where you need solid I/O, the cost for the same performance on baremetal vs VMs on cloud can be >4x so you could even afford to have a duplicate setup on another network for redundancy and still be saving.

Moving workloads in-house does happen. But, in general, you're right. It's hard to advocate for a near-term expensive (in time and money) and at least somewhat risky (expect some nights and weekends crises) migration for possibly some longer term cost benefit (assuming you've accounted for all the costs). Which BTW neither you nor your manager may still be around to take credit for. And also BTW is at least somewhat counter to what companies are doing in general, for better or worse, and which execs will probably rightly see as a potential distraction from whatever the company is trying to accomplish.

Frankly the whole discussion mostly highlights that these are things you need to think about upfront before you're fully committed.

Back in the day, when I was part of a startup, the DB guy was all into making us write “provide agnostic” sql in case we ever wanted to switch to Mysql or Oracle. We were actually using Postgres. This was a nightmare.

Things started improving when we said ‘f-it we are not moving out of Postgres, let us at least use the best features of PG’

There is a similar problem when trying to use AWS with the constant thought about moving out of AWS at some point.

Yeah, this is a bit what I mean with doing it pragmatically - at least when you choose provider-specific services know that either 1) you have an idea of how you would migrate it or 2) it is a conscious decision to leverage a USP. By taking the provider-agnostic paradigm to the extreme, you have the least common denominator, getting none of the upsides.

> Start out on AWS/GCP/Azure in the initial phase when you want to optimize for velocity in terms of pushing out new functionality and services.

Have you ever done this? It's exorbitantly hard to migrate off of a cloud provider, and few ever do.

I agree that migrating off a cloud provider can be very hard. However, architecting your system with portability in mind can help a lot, as rumanator points out:

> I think building somewhat cloud-agnostic to ease friction of provider migration is good

Of course, that's not always an option if the system is already built, but it's definitely a good approach.

I have and It’s only hard if things aren’t dockerized imo. If everything is in something like cloud foundry it will be much harder.

If you don’t have heavy AD and policies in place even better.

+1 on containerization, and I would add that controlling your container orchestration service (particularly ingress and security) is another key factor. Whether someone uses Docker Swarm or Kubernetes, this setup enables anyone to redeploy their entire applications at a blink of an eye, regardless of which cloud service provider you use.

If your entire infra is dockerized, you are in the vast minority and should probably be discarded as an outlier.

> They aren't crazy or stupid, and as AWS is the world's leading cloud provider then it's highly doubtful that the decision is irrational and motivated by ignorance.

Part of the problem is that a huge proportion of the people I come across who chose AWS used this exact argument. Part of the problem with that argument is that none of the big guys are paying the list prices (unless they're not doing their jobs; I've seen the kind of discounts available once you get into even the few hundred k/month range and tell your account manager you're considering moving), and a lot of them also used the same line of thinking.

It pulls in a lot of people who pick AWS for all the wrong reasons.

> AWS might overcharge a lot, but truth of the matter is that for any sizeable corporation it's irrelevant if they spend 200€ or 400€ on their cloud infrastructure.

The ones I used to deal with used to be more like a 3x-10x cost difference on bills in the 10k-100k/month range. I agree with you that if the difference is ~200/month, then who cares. But a lot of much bigger companies burn money this way. Often because they started off with a 200/month difference, and then never made it a point to re-evaluate as their costs grew.

The difference isn't always that bad, but especially bandwidth hungry services are ridiculously expensive on AWS (to the point where if people really badly want to stay on AWS and spend a lot on bandwidth, a quick and dirty fix is to rent servers to use as caches in front of their AWS setup)

I'm not saying people shouldn't use AWS. But as you point out, the right usecase for AWS is when you don't mind the cost, and pick it for convenience, and there's the warm fuzzy feeling of knowing you can hire people "off the street" who knows how AWS works.

AWS is the luxury option. Sometimes you want the luxury option.

But it worries me how many startups build in ways that end up locking them into a provider that for some of them multiplies their per user cost by anything from 2x to 10x. When I evaluate startup pitches today, I often ask whether or not they have thought this through. It doesn't matter so much that they're on AWS - that might well be a fine choice. What matters is whether it was a conscious decision, and they've done at least a superficial attempt at modelling the costs both for AWS and some alternatives, rather than just picked it by default.

For any start-up that is expecting to work with enterprise customers there is no choice and has been this way for at least 3 years now but to support AWS. This doesn't mean you must use AWS (with Azure close second and GCP irrelevant essentially for most large non-tech customers) for your entire footprint, but you will need to have POP in most regions that the F500 works with strategically. Any enterprise tech founder that utters the word cloud should know this as table stakes to compete for the foreseeable future.

That absolutely makes sense. But you can achieve that by either being able to deploy the client specific bits to AWS for clients that absolutely insist, or by simply deploying proxies and picking and choosing on a per service basis whether or not it makes sense to deploy it to AWS or proxy it to your own infra.

Sure, but there's a fun catch with this strategy. I'm familiar with some companies that refuse to work with vendors that use AWS for production hosting of their footprint because it would be funding their competitor. There's no such thing as a company that contractually requires all of production in AWS though, in contrast, not even AWS.

wrt to aws, there's also the option of building out with serverless tech, which is a dramatic cost reduction (not paying for idle) and ideally scaled for usage to business model/revenue. cloud portability suffers but I've found for an ha setup, its a dramatic cost savings (10x) while getting traction for a service. I've seen that transformation bear out in many enterprise companies. As an example I built out https://awsapichanges.info and run it for less then a dollar month with fargate spot, s3, etc. Just saying ymmv depending on how you want to build/design your app's use of infra resources.

It really isn't a dramatic cost reduction for most people, as most people simply don't have sufficiently large difference between base load and peak. I love the concept of serverless, but I'm not seeing it as a cost savings measure for the most part, but as a simplification of architecture.

I basically agree...

However, I'd argue if you pick the right tools from the start you can leverage AWS relatively inexpensively... But that's hard without enough cloud knowledge in the industry yet, and consultants are (generally) terrible at this.

The main advantage is you can pay that crazy $200/month for a scalable database without paying $5,000+/month (burdened) for the guy that can build it and maintain it for you. A developer can handle connecting and writing code for clusters not easily than they can learn how to do scalable database -- and this is just an example, replace DBs with some other function you might hire a person or a team to do.

> However, I'd argue if you pick the right tools from the start you can leverage AWS relatively inexpensively... But that's hard without enough cloud knowledge in the industry yet, and consultants are (generally) terrible at this.

You'll have a hard time finding a AWS consultant that's specialized (or inclined) to help you set up your infrastructure so that you don't use or need to use AWS. Not only is there no need for that sort of service, it would actually kill the goose that lays their golden eggs.

Odds are that you could find consultants that are specialized in some other cloud service provider, and aren't experienced enough in AWS to be in a position to smoothly migrate services out of it.

I used to do that, and used to actively recommend customers not to use AWS in most cases, or to use hybrid setups, as while my billable hours tended to be higher for AWS setups, the demand is high enough that it's not worth making bad recommendations to milk a client vs. showing them that you can help them secure substantial savings.

Some setups we made cloud agnostic enough that when we finally got migrations approved we were able to do zero downtime migrations by splitting the setup between providers temporarily. That incidentally was the best way of getting people to migrate: You make the case for resilience and flexibility, then argue for a test run for a month or so, and then all it takes is for them to compare the bills.

I even several times made offers to migrate customers off AWS for a proportion of what I estimated they'd save over the next 3-6 months. None of them ever took me up on it when they realized just how much that'd add up to vs. the fixed time based offer I gave them but it was a useful sales tool to demonstrate that I was willing to stand behind my estimates. One customer slashed their hosting bill 90% by getting off AWS (they were bandwidth heavy, and we cut their bandwidth costs by 98%; AWS outbound transfer is ridiculous)..

[as I've said elsewhere, AWS has its uses, but keeping cost down is not one of them... Ironically one of the good uses for AWS is to keep the cost of a dedicated setup down: Being able to "spill" over onto AWS (or other cloud) instances in the case of unexpected events lets you operate far closer to the wire than you otherwise would dare on a dedicated environment, even if you rarely use the capability; doing so also allows for more easily spinning up additional test/dev environments etc]

The biggest reason I can see why you don't find more consultants offering those services, is that a surprising proportion of people hire consultants to give them backing to do what they already want done ("see, the AWS consultant says I was right to want to use this AWS service") rather than to genuinely give independent advice. If you're not comfortable being repeatedly told "yes, but here's why we'll be ignoring the professional advice we ostensibly hired you for" and being very careful about forcefully presenting opinions backed by evidence that don't match the hiring managers preconceptions, the pool of contracts rapidly shrinks.

I didn't say avoid AWS... I was more trying to point out that consultants and what not with certifications and "experience" are great at regurgitating information but often lack personal experience and result of their work months down the line. They suggest using tools based on their understanding, which is frequently with minimal hands-on experience... E.g. use a bunch of Dynamo DB tables with several indexes each to get serverless database.. ignoring concepts of duplicating data and leveraging hash/range, avoiding scans.. etc. (As an example)

You're assuming the organization/company does not do a lot of computation. If that's true, then yes, cost is not much of a factor. But in that case, a company could just rent a server at some ISP and be done with it.

In interesting cases, cost is _very_ significant. And it's not a 2x factor, IIRC it can easily be 10x.

> You're assuming the organization/company does not do a lot of computation.

I am assuming nothing. I personally had this very same debate with a program manager of a company whose bread and butter was doing a lot of computation. At the eyes of upper level management, arguing about spending 20€ or 100€ on a cloud service provider is a kin of debating which brand of detergent should the company buy. It's irrelevant.

> But in that case, a company could just rent a server at some ISP and be done with it.

That's where you get it all wrong. Hiring bare metal services does nothing to your ability to scale, either to meet demand or to develop/test/try out new services, nor does it help you use higher-level managed services. Everything you have to do or manage by yourself is a productivity hit, and that productivity hit is measured as a percentage of your entire payroll, which eclipses how much you pay to your cloud service provider.

100€ on cloud service is not "a lot of computation".

Computing itself is the cheap part, especially on spot instances. It's the outbound bandwidth that'll kill you

Ok, so s/computing/computing, storage and network I\/O/ . Same argument.

... although if it's outbound bandwidth - if you can take care of your compute, maybe it's possible to purchase outgoing bandwidth at an hourly resolution, rather than "whatever your wires can send us", and have your flexibility.