types.markdown

My basic point is that currently, configuration management code manifests as a giant, unverifiable pile of mud. The languages we use lack types and are weak at making non-runtime assertions. With the modicum of sanity that a proper module system and types can bring to the table, we would be considerably better off.

The entire model is broken. The rapid adoption of half-baked technologies like Docker shows how desperate people are for a better model that avoids this trouble in the first place. Sharing components between disparate processes on a system is a constant source of pain, and no amount of package management intelligence can fix that. Mutating systems in place is a good way to take things from one partially understood state to another, with no way back. Like security, you can't bolt configuration management on the side.

Rule #1: The best solution to a problem is not to have it.

Bake the notion of constructing immutable deployment artifacts into the system. Bake the notion of multiple systems in an ensemble into the system. Bake the notion of ensemble lifecycles, via state machines and events, into the system because these things need to be immutable but they sure aren't static. But whatever you do, don't waste time polishing the mutable, bolted on configuration management turd.

Super agree with @b in terms of don't waste time polishing the mutable, bolted on configuration management turd

But was thinking that docker could be one of the mechanisms (along with a stripped down minimal os like CoreOS) to get there Its not inherently immutable, but it could be used in an immutable way from what I can tell.

It seems that Docker is evolving to a component architecture where containers become like black boxes of functional goodness. It has Links (defined input/outputs) and attributes set via /etc/etcd and otherwise treat it as a black box with an API.

In the short therm the Containers / Lego components are made with "old school" service implementations like Nginx, tomcat, mysql, whatever. But they get constrained by explicit container APIs and not but a mud of config files, packages, etc.

The Docker linking model is strictly local and extremely primitive (that is primitive in the stone axe sense, not primitive in the you can build on it sense). This is not surprising as their networking story is nonexistent. Yes, it's a container (3 layers of container, actually), but that is the easiest part of this problem. Probably why it gets solved over and over, while the hard parts of networking and orchestration are consistently broken. Solaris Crossbow, which arrived 5 years after Zones is a good start on the problem and an indicator of just how difficult it is to do the networking properly. Some sort of conception mashup between Erlang supervision trees and Crossbow is a what I keep imagining.