Do you remember the days when everyone had their own data center and setting up a server involving drawing up specs then putting in a PO then waiting for it to get delivered on a truck to be racked and formatted? AWS is magic and the price is entirely justified.

Yes and also i clearly remember in 2007 trying ec2 for first time and asking, is it production ready? Could we actually use this vs. building out a cage. And in 2007 the answer was no. Something about no external IP addresses or no load balancer possible. But yes that cage was expensive and the last cage I ever got. AWS is magic and amazing.

You’re basing your experience on AWS from 2007?

did you read what I wrote? It was just a nice little story about trying aws for the first time in 2007 and then never getting a cage again. It was PRO-aws.

There are also dedicated servers for a fraction of the price. The choice isn't AWS or own datacenter, there's a lot in between.

Under these circumstances, how is AWS lock-in and cost escalation any different from Oracle of the past?

Why would any startup shackle themselves to AWS or any cloud when it's not portable?

Lambdas, in particular, seem like the worst idea in the history of ideas. Once your org adopts them, how do you keep track of these mysterious, business-critical pieces of functionality? How do you ever plan to port them to something else? It seems like you become an Amazon customer forever.

I am incredibly skeptical of cloud at this point. If the other infrastructure and platform concerns of OS upgrades, patches, etc. were handled in an automated way, I'd strongly consider running Kubernetes on bare metal. Data centers and colocation all the way.

I'm eager for self-management of k8s, DBs, Redis, etc. to be automated with tooling. On-prem, but easy to maintain.

edit: wow, from +3 to 0 after an hour. I maintain that I articulated my opinion well in an unbiased way.

Lambdas, at least the JS ones, are Node.js based and not hard at all to migrate to an alternative cloud service. You can even use a framework that handles all the cloud-specific functionality for you and works across AWS, Azure, GCloud, etc: https://www.serverless.com/

The lock-in really comes from AWS-specific services. Redis, Mongo, etc will have the same API no matter where you're hosting them, so it's pretty trivial to point your client-side code to a different cloud-hosted Redis instance if you find AWS lacking there.

I agree and just want to add IAM to the list of AWS Lock In services. We provisions environments almost entirely using Config-as-code tools (packer, ansible, terraform) and generally have a good blueprint for what an environment looks like and the parts I’ve had the hardest time thinking about migrating to another cloud provider is all the IAM rules that magically give hosts/services the ability to talk to other services.

I'm not sure about GCP, but Azure does offer role-based access[1] which gives you similar resource authentication magic to what IAM provides. The definition formats[2] even look fairly close to their IAM equivalents.

It's used in combination with Azure Active Directory, so the modality isn't 1:1 with AWS. But Managed Identities[3] is a feature that's rolling out across Azure which simplifies the model a bit, since it negates the need to create service principles in AAD beforehand.

[1] https://docs.microsoft.com/en-us/azure/role-based-access-con...

[2] https://docs.microsoft.com/en-us/azure/role-based-access-con...

[3] https://docs.microsoft.com/en-us/azure/active-directory/mana...

GCP too provides role based access.

IAM is simply one of AWS's killer features. It's just a service that's so good it differentiates itself from the competition. Lock-in based on quality is not the sort of lock-in that I'm most worried about, because it's very clear what I'm getting in return for it. The alternative to using IAM to begin with would be to commit to work comparable in scope to that required to migrate away from it in the future.

Avoiding use of Lambda(example) is possible but for IAM?

> Why would any startup shackle themselves to AWS or any cloud when it's not portable?

Depending on the startup, that may make sense if it allows for fast iteration.

If a startup is trying to achieve product market fit, having a huge AWS bill is a good problem to have, since it means the product is actually successful.

If you're building on AWS properly, your usage scales with demand. So a huge bill should mean you have huge demand.

Only servers used for client requests. Dev and integration environments but esp data crunching can be a lot more expensive than serving web requests. And they're hard to keep cheap if you scaling is easy.

it’s not even slightly difficult to get a huge AWS bill. people do it on accident because they refuse to put in spend limits.

Do you realize how many software as a service vendors the average corporation is tied in to?

You’re always tied into your infrastructure once you have any type of scale. The pain of migration is huge.

I once worked with a company whose entire workflow was integrated with six or seven vendors through APIs.

Have you ever worked in the healthcare industry? The level of lock-in they have to their EMR/EHR would make you cry.

What's your alternative? Go on prem or build your own competing cloud provider? Probably not. The open markets have set the prices for cloud compute and storage resources.

I'd argue that the existence of cloud providers have only accelerated the growth of the tech industry and has in fact put more money in the pockets of tech workers and VCs than there would have been without the existence of an AWS/Azure/GCP/etc

Bare Metal is cheaper and more effective than running your startup on fumes just to offload your expenses on unsuspecting VCs.

I hear this a lot, but I rarely see any data or evidence to back this up.

The company I work for used to have most of its revenue come from VC-backed startups. Over time that changed as we courted more well-capitalized enterprises. If our VC-backed-startup customers all went bankrupt tomorrow, it would certainly hurt, but it wouldn't kill us, not by a long shot.

I would expect that to be even more true for a product like AWS, not less.

After working for a company that spends millions of VC money on AWS per year I can also say that infinite cloud scaling is a myth. We had all kinds of downtimes due to AWS over the years.

> We had all kinds of downtimes due to AWS over the years.

No, you just had downtime, full stop. Failures are inevitable, regardless of whose datacenter you're using. Failure-tolerant architecture design minimizes (or eliminates, if you're lucky) the downtime caused by failures. I'm not saying that's easy or necessarily appropriate depending on the stage of your company, but foisting responsibility onto AWS is missing the point.

I am not "foisting responsibility". There are fallbacks and fail safes in place to mitigate such issues but that's not my point. My point is that they sell us a dream of infinite scaling, all managed and no more problems, which just isn't the case. I know, it's naive to believe that in the first place but the marketing certainly goes into that direction and some proponents spin this story all the time. Would the alternative be better? Most certainly not, but it's still a question worth asking from time to time considering the extra money spent.

> Most certainly not, but it's still a question worth asking from time to time considering the extra money spent.

Esp if you are not vc backed and infra costs are already near the same order of magnitude as most of the dev team and are running into scaling issues…

I think you're maybe mixing up different things? "Infinite scaling" doesn't mean your app is failure-free and constantly available. In my experience AWS's scaling features work pretty well, as does their on-demand provisioning. But they have very little to do with tolerating infrastructure failures. That's up to you, regardless of whether you're developing on AWS or on hardware you own.

Let me provide an example. When we recreated a big Elasticsearch cluster, AWS ran out of available instance types in that AZ resulting in the cluster never going into a green state because a node was missing. This is not something you typically worry about when you choose a cloud provider. Your tone is a bit condescending tbh, you don't need to lecture me about the importance of a fault tolerant distributed system.

yeah, kayoone response was to the argument “AWS is more expensive but it scales”. In fact it’s not magic and you still have to manage it so worth looking at alternatives such as bare metal, especially at scale.