Comment by friend-monoid | Hacker News Reader

Comment by friend-monoid | Hacker News Reader

* If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write.

* We have a whole lot of HTTP services in a range of languages. Managing them all with fat binaries would be a chore - the author would have to give me a way to set port and listen address, and I have to keep track of every way to set a port. With a net namespace and clever iptables routing, docker can do that for me.

* sometimes, I have to deploy and insecure app. Usually, it's a badly configured memcache or similar. With net namespaces, I can make sure only a certain server has access to that service, and that the service cannot ruin my host server.

* Its possible for me to namespace everything myself with unshare(1) and "ip netns" and cgroups and chroot and iptables... but that would consume all my available time. Docker can do that for me.

* When you reach more then 20 or so services to keep track of, you need tools to help you out.

* load balancing. Luckily, I don't have to deal with extreme network loads which would require hand-made solutions, but just pushing up that number a little to do ad-hoc load balance makes things a lot easier.

> * If my colleagues don't have to understand how do deploy applications properly, their work is simplified greatly. If I can just take their work, put it in a container, no matter the language or style, my work is greatly simplified. I don't have to worry about how to handle crashes, infinite loops, or other bad code they write.

Of course you do, you just moved the logic into the "orchestration" and "management" layer. You still need to write the code to correctly handle it. Throwing K8S at it is putting lipstick on a pig. It is still a pig.

> * We have a whole lot of HTTP services in a range of languages. Managing them all with fat binaries would be a chore - the author would have to give me a way to set port and listen address, and I have to keep track of every way to set a port. With a net namespace and clever iptables routing, docker can do that for me.

Nope, you wrote a set of rules and as long as everyone adheres to those rules things kind of work ( in a clever way ). Of course if you had the same kind of rules written and followed in any other method, you would arrive at the exactly the same place. In fact, you probably would arrive at a better place because you would stop thinking that your application works because of some clever namespace and iptables thing.

> * sometimes, I have to deploy and insecure app. Usually, it's a badly configured memcache or similar. With net namespaces, I can make sure only a certain server has access to that service, and that the service cannot ruin my host server.

You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container.

> load balancing. Luckily, I don't have to deal with extreme network loads which would require hand-made solutions, but just pushing up that number a little to do ad-hoc load balance makes things a lot easier

The time to build a template and instrumentation for your haproxy/nginx/varnish layer is when you don't have enough traffic and enough complexities.

> You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container.

I can guarantee it pretty well on my RHEL and CentOS systems, SELinux prevents containers from accessing things they shouldn’t just like it prevents Apache from dumping /etc/passwd.

"I can guarantee it pretty well on my RHEL and CentOS systems"

Slashdot tried that with CentOS and failed miserably. I have my doubts regarding your guarantee.

Link? I want to see what they actually tried.

I think that the main point was that docker skills are transferable, i.e. you can expect a new hire to be productive in less time. Too many companies still have in-house build/deploy systems that are probably great for their purpose but don't offer valuable experience that would be usable outside that company.

In my observation, Docker skills is a modern day ability to type "make", without being able to actually write a Makefile or debug a Makefile.

Your observation is incorrect.

Yes. Each time you start a container, you are basically saying “make clean” as well.

Except that people who write software to be put in containers cannot write that Makefile to save their life so for something that should be a ten line dependency they manage to build entire Linux, entire X and all unneeded tool chains.

Writing a dockerfile successfully is maybe that. But learning to make a dockerfile should take someone a day to figure out. What the entire movement is about is creating an ecosystem around a common standard for dev ops.

I use Makefiles for creating docker files there is an advantage to docker from fat binaries. Both tools exist for a reason, used both wisely you can save time and effort.

If a company has existing in-house systems that are working well, why should they care about "valuable experience that would be usable outside the company"? Unless you think it's their responsibility to train people so those people can then leave and take the benefit of that training to some other, possibly competing, business?

Companies don't have a moral responsibility to do that, but it's a smart retention strategy. If good devs feel like they're learning useless non transferable skills, they'll be more likely to leave for the sake of their career. If they feel like the business is investing in them, they'll be more likely to stay.

Resume Driven Development can be just as bad for everyone involved.

That's a slanted take. Skills and experience that are only useful inside of one specific company are more likely to be less meaningful and effective (almost by definition).

Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing.

Of course, there is a balance here. Sometimes frustrating tasks must be done. In that case, ideally the end goal is sufficiently motivating.

Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing.

Right, but to those people, whether you use Docker or Kubernetes or custom scripting or a unicorn whose horn magically creates new instances when you need them is mostly just an implementation detail. It's no more interesting than exactly which compiler or DB you use; these are just tools, means to an end. If the differences are significant for your use case, sure, you evaluate and choose accordingly, but then you use the tools to get on with the job. The deep, interesting stuff is almost always in what you can build once you're into that territory.

This is definitely true for many people.

However, I do think it's likely there are some fundamental principles at play that make tool 1 better than tool 2 in specific contexts, and I think it is valuable and interesting to explore that.

Perhaps we are getting into the scientist vs. engineer mindset. I would guess, though, that the best engineers undoubtedly have some scientific curiousity helping them excel in their craft.

I think the conflict can be that engineers know what they're interested in, scratching their own itch, but that's not always aligned with what's best for the company. The balance is finding both.

One extreme is that I see companies hold on to toxic employees because they're brilliant, even if they are bad for the company long term.

(it does look like we're saying the same thing) Catering to a developer's whim as a retention strategy is not going to end well for anybody. In an ideal situation it can be mutually beneficial (that's what good management is--but that's not only relevant to your tech stack), in the worst case the developer leaves and there's new hotness from 3 years ago that doesn't work very well and nobody wants to touch.

The company may not care about building skills for employees that are transferable elsewhere (though good companies do), but they do care about being able to hire people with skills that are applicable to their systems.

While a very large company can get away with building a custom in-house ecosystem that takes months for a new employee to come up to speed on, most companies find it more palatable to use industry standard products/systems that a new employee is already familiar with and can come up to speed on quickly.

The company may not care about building skills for employees that are transferable elsewhere (though good companies do), but they do care about being able to hire people with skills that are applicable to their systems.

Of course, but who would you rather hire, someone with solid fundamentals who can get up to speed quickly with anything, or someone who job-hops to use the latest buzzword library/framework/language that may have a useful lifetime of just a few years or even less? Given an either/or decision with other things being equal, I would almost always prefer to hire the former, and then use whatever tools worked best for the job regardless of whether they were built in-house or imported. A job-hopping resume full of trendy buzzwords is a big red flag for me.

While a very large company can get away with building a custom in-house ecosystem that takes months for a new employee to come up to speed on

This argument gets made all the time in discussions about frameworks, but I just don't see it. In my entire programming career, I have yet to encounter this hypothetical nightmare architecture that takes months before you can become productive and has no useful documentation or examples even though the entire application is built around it. (YMMV, obviously.)

Being able to get up to speed quickly on a new framework or library is an essential skill for a working professional developer. Whether that is the latest shiny Web World buzzword or something internal in your new employer's environment makes little difference, as long as the internal design is also sensible and reasonably documented -- and if it's not, you have much bigger problems than who you're thinking about hiring next.

It pushes thinking up to the app/middleware stack and away from server instances.

The odds are you are running on VMs in AWS, GCS, Azure or even DO. If that's the case, why on earth is your building block not a VM?

No idea. I’m not advocating that position.

There are enterprise use cases where docker makes sense if the app support people are less impossible to deal with than the SAs. But you don’t have that issue in cloud.

* Multiple machines are a larger attack surface and a larger surface area to get things wrong.

* Overhead. It might be getting smaller but it's certainly still there. Not just the application but all the OS services that are duplicated are extremely wasteful when you're billed for your resources directly.

* Your vendor distributes applications as docker containers.

* Your developers are building and testing in docker.

* Clustered resources are dead simple with swarm. It can obviously be done with VMs but it's work.

* Devs and sysadmins alike enjoy using off-the-shelf services that are maintained by someone else.

I can run a dozen containers on my laptop a lot more easily than I can run a dozen VMs.

> You may be able to guarantee this with a VM but you certainly cannot guarantee it with a container.

Don't group all container implementations into one category. You could certainly use FreeBSD Jails and Illumos Zones for isolating apps.

Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they?

The most secure isolation is provided with physical separation. Second best is VMs. Containers are a distant third.

> Those solutions still allow the host and all the other containers to be compromised through a kernel exploit, though, can't they?

If I keep my boxes up to date I only need to worry about zero day kernel exploits. So if someone comes along and uses a zero day kernel exploit to escape my FreeBSD jail then they were going to get on the box anyway, because any attacker using a zero day is highly skilled and highly targeted.

> The most secure isolation is provided with physical separation. Second best is VMs. Containers are a distant third.

While I agree that physical isolation is the safest, I don't think it's so cut and dry between containers and VMs. Virtual machines have significantly more attack surface than either Jails or Zones, think of all the emulated devices.

"Virtual machines have significantly more attack surface than either Jails or Zones, think of all the emulated devices."

Nothing prevents you from using jails or zones in your VM.

> Nothing prevents you from using jails or zones in your VM.

I get that but that's no longer VMs vs containers, Thats VM plus container vs container.

> Second best is VMs. Containers are a distant third.

I will grant you that containers are harder to isolate since it's same problem as isolating individual processes. But there isn't really a meaningful difference between a kernel exploit and a hypervisor exploit.

Attack surface of a minimal hypervisor is way smaller than that of an entire kernel.

Take a look at Clear Containers (despite the name, actually using VMs) and their qemu-lite minimal machine type.

What makes you say that? VM's get exploited as well http://venom.crowdstrike.com so what makes you think VM's are better than e.g. zones?

You argument seems to be "why use Docker when you can do all of these things by hand?". It's kind of the Devops corollary of "why use Java when you could write everything in C?".

No, my argument is "if you are using docker without understanding what you are doing, you are not only not solving your problem but complicating your stack"

Don't get me wrong I love people doing this. It makes my skills in uncomplicating needlessly complicated systems extremely valuable.

clearly you never had to reengineer some crappy code whilst making the current live system operate.

Docker nowadays at least for me is essential for encapsulating st

Extra scenarios:

* Not all our libraries are available in the same ecosystem. We need to mix JVM with C++ with a sprinkle of Python [via jep].

* We run a lot of small variations over the same code base. We'd rather not wait to re-deploy 99% of a fat binary for each run.

Another good point is that Docker's layered filesystem allows for caching that greatly benefits the use case you're describing.

We have an old .net app we pushed to servers via zip files, and the sheer size of the zip ended up being a burden after many deployments. Docker's caching and "docker prune" make things a lot easier.

This argument appears to be: when the application is crap, putting it in a container lets me deal with it without getting my hands dirty.

This is probably true, but it isn't good.

Why is it not good? It is in line with the robustness / Worse-is-Better ethos, and importantly, it lets you get on with delivering business value, which is what we're supposed to be doing. (At least in a business context. If you want to rewrite code to perfection on weekends, for fun, so do I, I am all for that, but that's almost never what my employer needs.)

"Why is it not good?"

Because it still allows the base problem of crap coding practice to proliferate.

and don't forget that crap code == insecure code.

but nobody have to worry about it. just start a container the last guy left. /sarcasm

> and don't forget that crap code == insecure code.

I don't think I believe that equality is nearly as neat you'd hope. Unless we're willing to call all code crap code, a lot of projects with well-respected code and development practices have had serious zero days, and we've also found that sandboxing software is highly effective. Insecure code in a secure, well-written sandbox can get you a secure deployment, and you probably want to have your "good" code in a well-written sandbox anyway.

zero days and the privilege escalation are a luxury.

bad code is often plaged with injection/sql injection. Which sandbox does an absolute NOTHING to protect you from. After all, it is all within the expected side effects of your code.

What does this have to do with Docker then?

because a flawed argument in defense of containers is that it is safer, since it's harder to escalate priviledges.

my point is that false sense of security makes it even easier for an attacker to use readily available privileges in the badly coded application.

Spot on. Both fat binaries and containers very often translate in: "Nobody here cares about security. We deploy opaque blobs that will be unmaintained."

This seems to be the main point of the article to me. If your language's toolchain makes it easy to make sufficiently* self-contained 'fat binaries' (like Go or Java), then Docker doesn't add much. If it doesn't, like Ruby or Python, then Docker is very useful.

* 'sufficiently' is doing a lot of work here. Go binaries might still need libc; Java tars-of-jars (or fat jars, if you're confused) still need a JVM, which needs a handful of shared libraries. But those things are relatively stable, generally backward-compatible, and one single big thing (libc or JVM), so it's fairly easy to manage having multiple versions installed anyway. More than zero work? Yes. Less work than managing a Kubernetes or Docker installation? Also yes.

Reply on news.ycombinator.com