Hacker News Reader

Comment by yudlejoza | Hacker News Reader

We've had chroot jails, freebsd jails, and a ton of other options in 1980/1990s. Then someone decided to create a landing-page with a lipstick, and an SV pitch, and viola, docker is the revolution!

We've had make, autotools, ssh-expect/pexpect, pxe-boot, not to mention, shell itself, and a ton of other options. Oh but a few folks decided to create landing pages with lipsticks, and SV pitches, and viola, we have Ansible, Terraform, Kubernetes, the whole IaC revolution!

The same folks who shitted on autotools all their life without investing time in learning it properly, now are willing to invest 10x more time, putting up with all the warts and bugs and crap documenation of neo-IaC, and all-in-all being carpet rag fanboys of the new tools.

View on HN

I agree with the assertion that the core "hard tech" in K8S, docker, Ansible, etc has been with us a long time, and some of us did indeed use it.

That said, knowing what to mix and match to create a "pattern that you can learn and everyone uses and learns too" does contribute value, its essentially parallel to the value provided by linux distros.

I can "docker pull" from many different distros, with lots of premade apps.

I think the lesson for the "hard technology" folks is when you solve a hard technical problem DO think about setting up and promoting high-level standards with sane defaults. You are the most knowledgable person(s) for your "hard tech problem", and thereby often in the best position to standardize the default pattern by which it can be used.

That can contribute as much or more value than the hard technical work itself.

EDIT: also, don't forget to publish and promote STANDARDS giving a well documented "if you don't have a reason not to, do it this way" path for integrating useful tools together. That's essentially what docker is/did, and even though it can be recreated in a 100 lines of bash (https://github.com/p8952/bocker) the branding led to ~100,000 developers publishing containers that are fairly easy for anyone else to understand and build from.

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.

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

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.

Thanks for the response! Good points and interesting perspective.

What happened was that folks realized that the technology isn't enough--you need to build communities around the technology.

Docker for example includes a bunch of features to help build a strong community of Docker users (image standards, tooling to make building & sharing images easy, public registries, etc.).

Yet Docker still doesn't implement 2FA, which means you can't trust the community. Software supply chain management is a often overlooked problem and Docker just contributes to it.

Two things:

All the other tools are more approachable and show the user more value quicker.

This is similar to all the Dropbox naysayers “I can just use (rsync|ftp|etc)”

You honestly believe the new generation of tools provides 0 value over their predecessors?

Reply on news.ycombinator.com