Engineers who job hop don't care, but they leave their orgs paying Amazon forever.

I'm doing this right now, but I know a boondoggle when I see one.

Management needs to act, and locking yourself in, if it’s the only choice, go for it.

In the case of IT, composing across clouds is pretty common because it solves problems. Note I am not talking about brokerage or constant migration or other such nonsense. I’m talking about treating your clouds as a portfolio where you have levels of investment for particular reasons, and can make long run decisions about upping or lowering investment in. You compose across them. Salesforce for CRM, AWS for my front end apps, Google for my analytics, Azure and O365 for internal apps, whatever. It’s reality.

Forcing everything on one cloud, boy I donno. For an SMB, sure.

My point is, don’t tell me how tasty and good for me the shit sandwich I am forced to eat is. Users of EPIC hate it, that’s a market opportunity.

Netflix for example has a metric ton of OSS they’ve built to ensure smooth global operations even though they for a long time ran exclusively on AWS, and have now gone multi-cloud. I wonder why that is? Could it be that running a large service efficiently requires more than clicking some boxes and swiping a credit card?

Apple also is multi cloud and has been investing heavily in Kubernetes talent. I wonder why that is?

Handing developers the keys to the use any managed cloud service without regard to quality or price and especially when they don’t know what they’re doing operationally, hurts my go to market and risk posture when

- I get hit by hacks because they didn’t understand the security posture of the service

- I get hit by bugs that they didn’t know existed But thought that cloud magically makes software bug free

- The solution doesn’t perform or scale because the developers didn’t understand the nuances of a particular cloud’s networking or storage abstraction

- I have 15 different ways deploys of solving the same problem and nothing coordinated

- I have outages due to poor AZ or region planning

Now look, I think it’s great to avoid undifferentiated heavy lifting. I wasn’t implying that I was racking and stacking , or managing my own artisanally installed Kubernetes clusters, I have one that is automated from one of the many solutions out there.

This is purely about choosing the abstractions that I run my business on. I would rather use open and composable abstractions than proprietary dead ends... UNLESS it’s a throw away experiment or skunkworks and even then I’d be skeptical.

Tell me what staff I am saving by running a database on a Kubernetes cluster vs. RDS or Cloud SQL? I still maybe need a DBA. I still need to have someone keep an eye on upgrades , availability, and Performance across the fleet (which aren’t necessarily automagical). I still am responsible for the overall security posture.

We aren’t talking about racking and stacking servers and switches here, we are talking about administrator to server or administrator to developer ratios. And while you certainly can have a terrible ratio with Kubernetes (it’s early days) you also can get that down to a very respectable number with good practices and modern tools + abstractions.

As an aside, monolithic EMR/EHR systems are the bane of most health systems’ existence and the vendors like Cerner and EPIC know they have to change (to various degrees) or they will be changed by the market.

Multi cloud undoubtedly saves me money and risk because (a) there is no large company in existence outside of AWS, Google and Microsoft that won’t be multi cloud due to M&A and risk posture (b) I can use the right tools for the job in the particular cloud if they do have a unique offering (c) I can play them off each other when prices and quality suffer. (D) I can use the OSS that is driving the industry rather than using expensive knock offs (looking at you Kinesis!)

This belief that you can pick one outsourcing vendor and you’ll be better sticking with it for all your needs until the end of time is the height of arrogant naivety and has been historically disproven. But every generation needs to learn the hard way.

I've been in companies that used managed service and running database on premises. As long as you used some kind of configuration management software and deployed tools like barman and repmgr, there wasn't any operational work. Only exception was a hardware failure, but that doesn't happen often and when it happens you spin a new machine and invoke few commands (these tools mentioned make it really easy) and are back in business. You also have more control over how replication and failover is set up (so it's tuned to your use case) or have ability to use all available postgres extensions. The only "good" thing about RDS is that management can't pressure you to do some things. For example you can say there must be a downtime to upgrade the database and there's not much that can be done about it.

You might run into performance issues, where you might need a DBA, but RDS doesn't solve this, that part is still exactly the same, and RDS gives you less control.

BTW: I also noticed that AWS really makes things so RDS service feels less attractive. For example if you want to create a serverless postgresql, I don't think you can do it from UI. I was only able to do it from cloudformation, the only version available is 10.7. If you allow instance to be put to sleep it requires 30 minutes to spin up, and AWS Gateway has 29s (yes 29s) maximum timeout, that can't be increased.

I think AWS wants to discourage use of postgres, and encourages everyone to use DynamoDB (which doesn't have 1:1 equivalent outside of AWS). I'm wondering if it's due to introduction of logical replication in version 10. The biggest asset of most businesses is the data, and not being able to get it out without a lengthy downtime might be the reason to keep businesses from moving.