[bob1029]

I sometimes wonder how many of us are running infrastructure across multiple nodes in support of an application that can practically be ran on a single instance.

For us, having production go down for 2~5 minutes while we spin up a prior VM snapshot is totally acceptable for our customers. I have a hard time believing this RTO does not exceed what would be meaningfully required for most businesses (i.e. actual $$$ impact vs someone's paranoid fantasies).

I totally concur on your 10x point. If you find your engineering staff arguing over containerization technologies or multi-cloud event-driven virtual actor architectures, you are probably wasting a lot of time. I would state that simply making the arbitrary decision to use containers is a massive mistake. All that overhead and complexity for what? You better have a damn good reason. Maintaining a typical Dev/QA/Staging/Prod stack is not sufficient justification. Unless you seriously fucked something up, your software should be able to be cloned+built+deployed+started in a few lines of powershell, et. al. What is stopping you from running this script on 4 servers or writing a little tool to do it from a web interface every time you click a button? Oh right, can't write your own CI/CD tools when there are so many on the market. So it goes. Down the rabbit hole and to the right.

For those who can handle a 2-5 minute RTO, and have business application performance requirements that can be addressed by a single 32+ core server, there is no reason you should be screwing around with anything beyond your basic language+framework tooling, SQLite, source control, and project management tools. This is an engineering paradise if your constraints allow for it. I would never squander this opportunity with shiny bullshit.

[dcolkitt]

> I would state that simply making the arbitrary decision to use containers is a massive mistake. All that overhead and complexity for what?

What complexity? I've been hacking a small Node app in my dev environment for the past few weeks. Decided to stand it up in prod. It took me literally 10 minutes to setup the Dockerfile, build the image and deploy it to the server.

Later this week, I'll probably throw it onto a GKE cluster. It will take maybe 15 minutes to write and test the Kubernetes YAML. (It will also save 50%+ on the hosting costs, since self-healing means I'll be able to put it on GCE preemptible nodes.)

[bob1029]

When I refer to complexity there are dimensions aside from time to prod. You also have to consider the added risk of introducing all of these additional vendors and codepaths into your application stack. For some, this is not a concern at all. For others, myself included, there are practical concerns regarding minimizing attack profile for the types of applications we need to deliver.

I really enjoy being able to tell our clients (finance industry) that our software is entirely on first-party Microsoft dependencies. It makes dealing with audits so much easier. We have clients that will scan our servers and bug us about specific DLLs that show up on the various enterprisey security scanning tools. We got hit with an audit on one of our 3rd party DLLs and had to spend a week rewriting for a compliant implementation. This kind of thing can kill us at our scale, so we don't even risk it.

There will be those who rally against writing everything in house, but there are some serious advantages to it, especially if/when your team actually gets good at doing it. We can crank out a fairly complex dashboard in 1-2 hours using Blazor and our existing platform services. Add in another 5-10 minutes for a code review, 5 minutes for a build, and then its in all required environments within 2-3 more minutes (total). All of this managed via a system that is part of our application's codebase. So, you can certainly get some fun numbers going either way you attack the puzzle. Difference is - In my case, if I want to make a very nuanced change to the behavior of a build/deploy/hosting item, I could quickly locate the code and make the required adjustments. If you need Kubernetes to do something magical that its not quite prepared for yet, you could spend a long time screwing around fruitlessly.

[dcolkitt]

Thanks for the response! Good points and interesting perspective.