Smash Company Splash Image

June 6th, 2019

In Philosophy

1 Comment











If you enjoy this article, see the other most popular articles




















If you enjoy this article, see the other most popular articles




















If you enjoy this article, see the other most popular articles

Nils Meyer: there are advantages to containers, but fairly easy to get wrong

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

Here is a comment that Nils Meyer on LinkedIn, in response to something I said. I can agree that I would see some use to Docker/Kubernetes in a non-virtual world, the irony is that I’ve only seen Docker/Kubernetes used in virtual setups.

I would agree that using packer and treating the VM like a container (or rather a pod in Kubernetes Parlance) is the easier approach. It’s also somewhat bizarre that a tarball of multiple tarballs and shell scripts concatenated with “&&” are now considered the pinnacle of software packaging. EDIT: There is a lot to dislike about docker as a container runtime, the image format, the standard way to build images, use of outdated lowest common denominator technology (iptables anyone? And why oh why must we use IPv4 and NAT?), feature creep etc.. Containers are a neat idea but docker leaves a lot to be desired.

There are advantages to using containers, especially with an additional orchestration layer, especially when NOT running on virtualization (most container deployments probably are to VMs). It is very difficult to get there though and requires a lot more work on infrastructure so that’s not a step to be taken lightly. It’s also fairly easy to get wrong with disastrous consequences for security, very often I see people pull in containers and code from all manner of sources, and many of the “official” container images have known vulnerabilities.

For context, see my earlier essay, Docker Is The Dangerous Gamble Which We Will Regret.

[ [ UPDATE 2019-06-10 ] ]

Nils Meyer added a comment to this blog post, which I’m incorporating into the blog post itself:

To elaborate a bit on my remarks: Many organizations use containers and container orchestration without having a defined and valid use case and without the necessary skillset and manpower in house to manage a complex setup. It’s extremely easy to get up and running with containers, setting up Kubernetes is also extremely easy when you’re just using kops. There are of course hosted solutions as well. This can be very deceptive since you skip ahead on the learning curve.

A risk therein is that people don’t actually understand what they have built, especially when it’s mostly developers with little Linux background setting it up. There is a lot of technology involved that you should understand when running a complex setup: Networking, Routing, Network overlays, the Linux distributions you’re using, overlay filesystems as well as underlying filesystems, proxying, if you’re using a proprietary cloud you should have an understanding of how those components work as well.

The risk is that you’ll get a lot of rope to hang yourself with since re-use of components is very easy. For example, you can pull in a lot of stuff from docker hub and other container registries, but there is no quality assurance or curation there (like you would get with python core modules for example) – there was some recent research that found a lot of fixed security issues in “official” docker images simply because the underlying OS layer wasn’t updated.

So to do this properly you would end up building your own container images, which means a lot of duplicated effort. Since you often end up running different Linux distributions you’ll need to know how to manage those as well. You will need a CI/CD system for that. You’ll want your own container registry. You’ll want to run vulnerability scans on your containers and have alerting when an image is vulnerable.

Once you have a large orchestration layer it becomes more and more difficult to get things to run similarly on developers machines. You’ve already lost when developers run an OS that doesn’t natively support containers and most of your developers probably don’t run Linux.

You need to be able to debug a container build – this can be especially annoying with Dockerfiles due to the layered approach, if the list of commands you chained together with && \ fails you’ll have some trouble trying to fix it. This is of course true of other packaging systems to a certain degree as well. Wouldn’t it be great instead of having every command create a new layer to just create a layer explicitly (just like database transactions)?

If you’re in a strongly regulated business you’ll want to be able to audit what software in what version and under which license you’re running at any given time. That also means you need to keep old container images around but be able to prevent their use.

Once you have all this you can do some pretty cool things – for example you can run optimized builds of your software, you can use newer versions of libraries only where you need them instead of completely running a bleeding edge distro, you can achieve far better utilization with containers on given hardware, containers scale very fast, virtual machines suffer from some unique CPU bugs that aren’t as high impact with containers. Some of these benefits you’ll realize a lot easier by running on bare metal, but few do this.

All of this doesn’t even take into account the most difficult thing: Storing data. At a certain point you have to store data, and usually do to limitations in networking and storage systems this can’t be very elastic and it gets very difficult if you have certain requirements for durability.

Source



Check out my books:





RECENT COMMENTS

August 13, 2019 1:34 pm

From William Hatch on Docker is the dangerous gamble which we will regret

"No tool is every perfect, and you're certainly free to use whatever you want. But, I doubt very much the huge ..."

August 5, 2019 5:23 pm

From lawrence on Why does he want to throw his reputation away?

"DangerNorm, as to your last point, I was recently consulting with a startup that focused on the privacy of med..."

August 5, 2019 3:55 pm

From DangerNorm on Why does he want to throw his reputation away?

"This is tangential to the above point, but on the subject of mental health, I'll also take this chance to say ..."

August 5, 2019 3:51 pm

From DangerNorm on Why does he want to throw his reputation away?

"Your description of most people's response is correct, but I consider it to be a problem, rather than the corr..."

August 5, 2019 3:28 pm

From lawrence on Why does he want to throw his reputation away?

"DangerNorm, thank you for writing. I think you are missing the moral element here. You should understand the d..."

August 5, 2019 3:07 pm

From DangerNorm on Why does he want to throw his reputation away?

"It is true that a murderer is different from the flu virus in that murderers are moral agents and the flu viru..."

August 5, 2019 1:19 pm

From lawrence on Why does he want to throw his reputation away?

"ruurd, I'm not sure if you're responding to me or to DangerNorm, but this is true: "If you don’t get it the..."

August 5, 2019 1:09 pm

From ruurd on Why does he want to throw his reputation away?

"Oh yeah that argument. If you don't get it there is something wrong with you. Yeah right. I'll tell you what's..."

August 4, 2019 9:43 pm

From DangerNorm on Why does he want to throw his reputation away?

""Mass shootings are just not enough of a problem to be worth the attention given to it", is in fact an importa..."

July 28, 2019 2:48 pm

From anon on Appreciating the wisdom of Clay Shirky's comments regarding the early Web and how it would end

"I thought the article ended with a quote, but then I saw the last line: NO COMMENTS..."

July 24, 2019 11:56 pm

From lawrence on Mutable iterators are the work of the Devil

"Alex Miller, thank you. I should have said that I was writing the Clojure code so it might be easier for a Jav..."

July 23, 2019 6:42 pm

From Alex Miller on Mutable iterators are the work of the Devil

"This Clojure code may be serving a comparative purpose, but it's poorly written as Clojure code, and not what ..."

July 21, 2019 6:19 pm

From lawrence on Why is Meghan McCain famous?

"Lindsey, thank you for writing about Meghan McCain. As to her miscarriage, I am of two minds. Miscarriages are..."

July 21, 2019 6:02 pm

From lawrence on How I recovered from Lyme Disease: I fasted for two weeks, no food, just water

"Lindsey, thank you for writing. In fact, when I was a teenager, I went through a phase when I was very into wr..."

July 21, 2019 5:39 pm

From lindsey on How I recovered from Lyme Disease: I fasted for two weeks, no food, just water

"to be honest i was kind of hoping this would be a whole rhyme, with the first sentence and all. i'm glad you ..."

1 COMMENT

June 10, 2019
8:21 pm

By Sean Hull

Some great points. Especially the one about storage systems. A lot of micro services encourages breaking up your database, so that each service has its own. When you do that you have to put an API in front of it, so that all the other services can get at such data. You can see things getting hairy already.

What about network overhead? Longer code path? How do you do joins across different APIs? How do you backup multiple databases sitting behind different services at the same point in time. How do you restore them together?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>