Also, when something breaks, you are responsible. If you put it in AWS like everyone else and it breaks, then its their problem not yours. We will still implement workarounds and fixes when it happens, but we are not responsible. Basic enterprise rules these days is to always pay someone else to be responsible.
Actually nothing new here, this was the same in the pre-cloud era where everyone in enterprises prefer big names(ibm, microsoft, oracle, ecc) to pass the responsibility to them in case of failures ... aka "nobody get fired because of buying IBM"
And the big name companies always refuse to take responsibility, and have worse reliability metrics than the lean alternatives...
but somehow that is never a problem.
The only metric that's important is the CTO's bonus
When everyone is suffering because AWS is having its bi-yearly 8 hour outage, the CTO isn't blamed, bonus all round, and maybe the AWS sales team takes him for an apology lunch
When the CTO is up for 1500 days straight then has a 2 hour downtime when nobody else does, the CTO is blamed, no bonus, and more likely to get fired
Reality matters less than perception.
This fired of some warning bells in my head. Is the data available to actually make a verifiable claim regarding those reliability metrics like you are.
Microsoft and Oracle were on the vanguard of suing people that published metrics about them into bankruptcy... So, do you trust the metrics they publish?
IBM is older, and it's incredibly well documented how mainframes are more expensive to run than normal servers.
Unless you put someone on retainer to be responsible, which you can do cheaper than to keep your AWS setup from breaking...
(I do that for people; my AWS using customers consistently end up needing more help)
The point isn't cost, it's dodging responsibility.
You can dodge responsibility equally well by outsourcing to people who'll run your bare metal setup for you. We exist from small consultancies like mine to huge multinationals.
> then its their problem not yours
this is the main advantage of cloud, no one cares if the site/service/app is down as long as it's someone else's fault and responsibility.
I don’t know. Hours into the recent AWS outrage (when it was already being covered by mainstream news) everyone at work was running around with their hair on fire trying to figure out how to get our services back up. I even saw a 700 person Teams meeting.
It's always your problem. The difference is, if you control things, you can fix it, work around it, resolve it.
If not, you're at the mercy of others.