Lifted from LWN [Posted February 10, 2018 by jake] -- In ACMQueue magazine, Bridget Kromhout writes about containers and why they are not the solution to every problem. The article is subtitled: "Complex socio-technical systems are hard; film at 11."
Don't get me wrong—containers are delightful! But let's be real: we're unlikely to solve the vast majority of problems in a given organization via the judicious application of kernel features. If you have contention between your ops team and your dev team(s)—and maybe they're all facing off with some ill-considered DevOps silo inexplicably stuck between them—then cgroups and namespaces won't have a prayer of solving that. Development teams love the idea of shipping their dependencies bundled with their apps, imagining limitless portability. Someone in security is weeping for the unpatched CVEs, but feature velocity is so desirable that security's pleas go unheard. Platform operators are happy (well, less surly) knowing they can upgrade the underlying infrastructure without affecting the dependencies for any applications, until they realize the heavyweight app containers shipping a full operating system aren't being maintained at all.
The original article is found at Containers Will Not Fix Your Broken Culture (and Other Hard Truths) -- Complex socio-technical systems are hard; film at 11.
My current role revolves around automating the build of solutions: operating systems, the networking, the virtualization, the storage and the apps running on top. And not just home grown software modules. So the above quote struck a chord. And is reinforced by another paragraph in the article:
Being able to reproduce a build allows for separation of concerns. We want this to be effective and yet not introduce unnecessary barriers. The proverbial wall of confusion is all too real, built on the tension between having incentive to ship changes and being rewarded for stability. Building just the right abstractions that empower independent teams is worth taking the time to iterate on (and, no, nobody gets it right immediately, because "right" will evolve over time).
While on the subject of containers, there was another recent LWN reference: Containers from user space in which Jonathan Corbet writes about Jessie Frazelle's talk at linux.conf.au 2018. The article reminds me that Seccomp, Apparmour and SELinux are important tools for enhancing the 'compartmentalization' of containers.
Containers, when used by developers for publishing their apps and dependencies, could be defined as a form of packaging. This definition segues into an article linked from Planet Debian which is called futures of distributions where the author makes reference to the issue:
The granularity at which software is built has fundamentally changed. It's now typical for hundreds of small libraries to be used by any application, often pegged to specific versions. Language-specific tools manage all the resulting complexity automatically, but distributions can't muster the manpower to package a fraction of this stuff.2018/02/19 - even after saying all that, pre-built containers are here to stay: OpenFaaS -- you can package anything as a serverless function - from Node.js to Golang to CSharp, even binaries like ffmpeg or ImageMagick. I read somewhere that serverless is just something you can't ssh into. So there is a wall be built between those who build the underlying infrastructure and those who put the window dressing on. And is confirmed by OpenFaaS moto:
Our core values are: developer first, operational simplicity and community centricNot saying serverless is good, bad, or ugly, but someone has a Curated list of resources related to serverless architectures and the Serverless Framework.