> Preventing this from happening requires a clued-in CTO and equivalent senior level leadership

Most CTOs (and increasingly M2s and M3s) I've met are what I call "box architects". You know the ones who love drawing boxes, moving one box inside another box, drawing a line between 2 boxes or changing a unidirectional arrow into a bidirectional one, then declaring the hard part is done and now we need any random engineer to implement that or "Is there an AWS service that does that? I just don't see the value in us doing it in house".

A "super optimized tools" is just a box that you swap for another box and the "minor changes" will be just a couple of arrows than need to change or another box to swap for another box. You get them to feel good about doing architect stuff plus the 10x reduction in the bill. They can always replace that box with another box later after all.

> Preventing this from happening requires a clued-in CTO and equivalent senior level leadership who can defend against such 'attack' methods and knows the difference between, for instance, paying a monthly recurring cost to host a Linux/KVM virtual machine and paying for some totally 'cloud' SaAs.

And the reality is eventually you'll get a clueless one, and everything will revert to the mean.

And the mean is heavily influenced by marketing propaganda.

You are missing the timeline factor here.

2016 - lets use EC2, its just VM, we can move off

2018 - I see you are hosting your own PostgreSQL in EC2, you can use our managed solution

2020 - you are already using 18 our services (note, at this point you might still be using non-vendor products, like VMs, managed DB, and so on), why not use our IAM instead of rolling out your own auth.

2024 - you are now deeply locked, lets add more lock-in, why don't you use this tool to optimize your costs (welcome DynamoDB)

At this point, no one would ever question next tool from salesman. Because engineers see that company doesnt have strategy to move to another cloud, why should they reject this new tool?

also consider the people who are involved, a lot of times after 2 years you have totally new people in your team, they won't have context and constraints you had in the past when deciding to buy "just VM", they see it as "we already use AWS"

I had many conversations with a former boss about the Azure sales team. They would come in, say they can do it cheaper, simpler and better — he was immediately convinced.

I would do a calculation based on their public price plan and come up with a 5-10x price compared to the bare metal OVH solution that perfectly fit our use case. I would then ask the sales team where I made a mistake in my calculation and hear nothing back.

A few months later, they would come back with the same pitch and the whole process would repeat...

You'd be wrong to laugh at them, because different cars of the same general size can indeed vary 50% or more in fuel efficiency. It's fair to be skeptical of promises of huge savings, and question why your counterparty would benefit from giving you those savings, but sometimes there's a good reason.

They're probably not wrong, if they're talking about hypermiling a Prius

> Do people actually take claims like that from glorified salesmen seriously?

People who know the tech, no

Non-technical middle management types, yes. It produces revenue when done aggressively enough, google "solarwinds sales people" for many anecdotal examples of extreme persistence. Not that I agree with it.

I save 75% on electricity vs diesel

AWS has been (blatantly) using Microsoft method of making their way in. Redis, Elasticsearch, whatnot, all follow the same procedure: 1. Here is a managed service. 2. Here is a fork of the managed service where we manage the server (you don't see) with 15% off in price/credits. Easier backups with clicks etc. 3. We are dropping support of managed-X, move to our fork. 4. Due to the market conditions, our forked service is now 50% more expensive. 5. Ah also, you cannot export/download your backups because they are in proprietary format. 6. Locked-in.