Hacker News Reader

Comment by jconley | Hacker News Reader

This is why DevOps became a thing. It's complicated managing systems at scale. If you were using these tools and aren't at scale, well, that sucks.

Unplanned downtime is the main drawback to both hosting your own OS's and using leading edge tooling for your critical systems. It doesn't matter what the underlying system, stuff like this happens. This stuff is complicated. You will find major warts in every new system. Everything will break, often, leaving your users stranded. It takes a very long time for software to mature. [0]

That's why you see engineers with 15+ years of experience patiently waiting for new technologies to mature before putting them in place in our critical infrastructure. Sure, we'll play with them, but putting new tech in production that could easily make your entire system unavailable is too risky. Yes, three year old tech is new.

[0] http://www.joelonsoftware.com/articles/fog0000000017.html

View on HN

It takes a fair bit of experience before you can recognise the warning flags, though.

Most folks don't realise how simple their requirements are. Most folks need to put files on a server and start a process. What they don't need is a whole mass of rickety scaffolding and control plane infrastructure that gets them halfway (and only halfway) to running an in-house PaaS.

So having kicked the tyres on Docker and been appalled by the messy design and dreadful tool quality, I went back to using OS-native packages and isolating our microservices via (gasp) user IDs.

Judging by their product direction I suspect Docker's board want them to challenge VMware, which (rubbing my crystal ball) suggests to me that their future is a bloated and overcomplicated piece of Enterprise, targeted at companies who think you can buy devops.

Well container came out of slimming down VMs.

Meaning that rather than moving a whole OS from hardware to hardware, or spin them up or down as load required, you would spin up or down processes and their runtime requirements from a known functioning image.

Thus removing the overhead of the VMs hardware emulation and the need to run so many kernels.

The response from the VM world to containerization seems to be to push unikernels. Effectively going back to the DOS days where you have just the minimal kernel and userland, all living "happily" in the same (virtual) memory space.

Well, thats what cgroups and chroot is for, but then docker is just a fancy wrapper.....

As for performance, if its critical then get a real server, if you've got decent change management (ie ansible, puppet et al with no manual intervention) Then its no effort.

(seriously network boot, and vlans are your friend here.)

Couldn't agree more. This is the reason I haven't started to recommend Docker for production use yet to our clients. We are pretty happy with only having a single JAR deployments for all of the services, running with separate users that cannot access anything else than the service folder. I am considering using runC probably starting early next year, seeing the amount of problems with dockerd makes me nervous about introducing it to any team.

> This is why DevOps became a thing.

How do you define "DevOps"? Because configuration automation (e.g. cfengine) and deployment automation (e.g. Capistrano) were more or less widely known and (less widely) used before the word (portmanteau) was popularized.

> This is why DevOps became a thing.

Huh?

Reply on news.ycombinator.com