I remember a world where you had to manually connect to a physical machine then copy and paste DLLs around tp deploy stuff. A batch script (that occasionally wo

I remember a world where you had to manually connect to a physical machine then copy and paste DLLs around tp deploy stuff. A batch script (that occasionally worked) was great innovation when it came to deployment. Not that long ago I worked with a company where it took persuasion to stop the madness of manually deploying to "the cloud" from an IDE at night when the traffic was slower. Kubernetes is borderline painful, because it's specific, you need to learn it, you'll get burnt a bunch of times and unlike a VM you can't connect and reboot. And it has this tendency like Javascript to have breaking changes every 9 months. But if you're doing anything at some scale, it's also pretty good once it's set. If you don't, and what you're looking for is simplicity, go for one of the functions / lambda / heroku alternatives. Yes, lock-in, but also not that much if you abstain from leaning into the proprietary too much. Which brings me to that > Kubernetes has also created a powerful lock-in effect What? Isn't lock-in to kubernetes the same lock-in you have with your programming language, databases and largely architecture decisions? I mean if you're using one of these cloud resources sure, but generally when just relying on the orchestration, it actually provides the opposite.