It is one of the issues with choosing the cloud providers and taking their stack. They are hoping the cost of swapping once bought into their way is too costly to a competitor who can offer similar service cheaper. Lockin used to be considered bad but something changed with cloud providers and ops/developers don't seem to care as much anymore.

Maybe because pricing by, say Amazon, is published on their web site and therefore, the same for everyone ? Whereas before, when you were with one supplier, he could make specific price for you and leverage its position to make you pay more ? dunno...

I'd be very surprised if big users of AWS or Azure pay the rates advertised on the public web sites.

Right, nobody pays /more/ than the published prices.

And prospective users can look at the published prices, and see that historically they've gone down more than they've gone up (although obviously that trend could reverse).

So people think they're safe from the risk of Amazon quadrupling their bill over night.

Of course, vendor lock-in can have other negative effects, but apparently people aren't worried about them, or at least think AWS is no worse than the alternatives.

Well, if you aren't in the US there is forex risk - Azure certainly increased their prices in the aftermath of the Brexit vote decrease of GDP against the USD.

Doing any kind of business in non-USD currency is itself not a great move.

Like most large business, AWS has a sales department and sales engineers that behave like you expect.

Rates are absolutely negotiable.

Our AWS rep is nice and cheery. He'll come into our office twice a year and bring sales engineers to hear about our upcoming projects. There's one lead developer on our team who keeps imagining systems that use half a dozen AWS services for "big data". The AWS dudes always end up talking to him the most and they definitely bait him with various pitches and, of course, feed his ego. Good thing that he's so disorganized and delayed that he never has a chance to waste company money on all that bullshit.

Having negotiated both, AWS is negotiable within a range that is much tighter than the range for enterprise sales of Cisco, EMC, etc gear. (Or AWS has better negotiators, but I've never gotten a call "Hey, Qx is about to end and I need to hit my numbers, so is there anything we can pull forward" from an AWS rep.)

They could show everyone different prices (like plane tickets)

There are some open source implementations of parts of the APIs of cloud providers that might help someone a bit when trying to migrate. For example, Minio [1] [2] implements the AWS S3 v4 API.

[1]: https://news.ycombinator.com/item?id=12392081

[2]: https://minio.io/

We[1] have seen a fair number of requests for managed services as devs claim that "we don't have the time or skills to maintain these open source components" (quoting verbatim from a request on Intercom). I don't think this is about having open source substitutes in all the cases. Personally not a fan of how/where the build vs. buy debate is playing out here.

[1]: https://hasura.io

"we don't have the time or skills to maintain these open source components" translates to "we don't want to install a monitoring solution that restarts a service when it fails, or think about design in regard to component failure".

It's such a poor argument. I was a developer long before AWS appeared and I've used so many open sources packages that were profoundly reliable. In many cases it just takes a daemon restart. And while it's not exciting to set up some of that stuff, it's far more tolerable than writing a CloudFormation template.

I warn other developers at my company about this. When new projects spin up they're often very excited about using new Amazon services and will make any excuse to choose an AWS product over a stable open source solution. If I were a manager, I'd be very worried over the vendor lock-in.

I don't understand the preference for AWS over open source in many cases. Their services are "reliable", but they often have minute restrictions that will eventually bite you. You also end up having to pay for something you could get for free. Why use SNS/SQS when there are free pubsub/message buses out there? Most of the other devs justify this with the argument of not having to maintain the software themselves. "But RabbitMQ might crash! We don't have to worry about that with AWS!"

Anyway, I typically minimize the AWS services I use (S3, EC2, ECS) so I don't dread the day AWS blows up or, more likely, some VP or exec says we're moving to GCP/Azure because we got a better deal.

>Why use SNS/SQS when there are free pubsub/message buses out there?

Free is never really free. There's always a tradeoff in engineering time and money when you choose to run your own stack instead of paying to use a stable, well-established service. Oftentimes running your own will be cheaper overall, but you have to do that cost-benefit comparison for yourself.

You're also forgetting that if you set up something on your own you also have all the hardware concerns as well. You need to procure hosts, provision them properly, deploy them, monitor them, scale them, fix them. That infrastructure cost doesn't go to zero but it is significantly reduced using a cloud provider.

I'm not arguing against cloud platforms in general; just the irrational use of very specialized services they offer. I can run a containerized service that uses open source packages on any of the cloud computing platforms. Now if I used Athena, SQS/SNS, DynamoDB, ELB, Lambda, EC2 that would make me very nervous, and I see other devs designing these stacks all the time. I guess I shouldn't care as much, because I'm not going to be the one to migrate that when the company gets a better deal from another platform service.

> "But RabbitMQ might crash! We don't have to worry about that with AWS!"

I can confirm that not only can RabbitMQ get into an unusable state, it will do so extremely rapidly and with little warning unless you sit an engineer or two on it to monitor and manage the incoming/dead letter rates.

AWS provides a lot of features that are exclusive to their platform and can't be drop-in replaced on other providers like Azure of GCE. ELB, EFS, S3, ASGs, etc. They'd need to be replaced at the application level for other platforms. That could be a huge commitment for a decent sized system.

I don't know about ELB, EFS and ASG but:

- S3 has a public protocol and many 3rd party providers support it (OpenIO, Scality, Ceph, Minio, etc),

- EFS could be replaced with something like DRDB or GlusterFS, or DigitalOcean's block storage or Google Cloud's networked disks.

- ELB could be replaced easily with similar services from other providers [1] if you use Kubernetes (I don't know if all have a LoadBalancer type though)

I would be more concerned about firewall/vpc rules, because I have no idea how those could be migrated without risk of forgetting some. Lock-in seems not that high in the end though and even less so if you use an open source container orchestration stack because they abstract most of these things away.

[1] https://kubernetes.io/docs/tasks/access-application-cluster/...

One good way is to have automated tests which make sure that those rules actually work. What if all your AWS rules suddenly get deleted. How are you supposed to know if you have not forgotten any.

Terraform (https://www.terraform.io), which we use, is a neat way to abstract this configuration data. We keep the configuration files in git, and can do GitHub pull requests over our whole infrastructure and apply the configuration with confidence (to change the existing setup or re-create it from scratch). This works for multiple cloud providers and is great for security purposes (all changes are auditable, no configuration drift).

Heap has a great blog post on Terraform : https://heap.engineering/terraform-gotchas/

Essentially, a declarative configuration for infra is what you are getting at. You can take this further, using containers and orchestration tech, to abstract your application behind a declarative configuration making it infra agnostic (as it should be iMO). Obviously, not getting locked into any cloud provider services is a pre-requisite for this. Check out such an implementation here[1](full disclosure - I work here))

[1]: https://docs.hasura.io/0.14/ref/project-configuration-and-st...

It's amazing how the promise of "decentralized" internet has turned into centralized datacenters.

P2P networks, each computer being a "data store" on the internet, no one entity can control data, etc to modern day centralized cloud where a couple of players control so much.

There has been a cultural shift. In the early 2000s, the idea of storing your data somewhere else would have been weird. But now, people don't care about keeping their data on apple/google/etcs data centers.

I think it has to do with the fact that computer/internet illiterate people are now the majority whereas in the 90s/early 2000s, it was generally the computer literate on the internet.

I was pretty befuddled when my company IT switched from self hosted storage to commercial cloud accounts for incredibly sensitive info.

I think the reasoning was cloud accounts are easier for the masses than mapping a drive and accessing over VPN

Also someone else to blame when the sensitive info is exposed.