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.

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.