[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.