Tumblr just ate my long blog post, so here’s a short one.

I like immutable systems.  They are the future.

Perhaps this is a weird coming from someone who wrote a major automation system primarily used in not following this methodology?  Let’s rationalize this.

In large updates, I’ve seen the optimizations you have to take to make sure you don’t catch your package mirror on fire, or the slowness and unreliability of operating on the open internet.  This exists, you can optimize around it, but if you could make your deployment just go “click”, I think you’d want to do it.

I don’t believe in the bugbear of configuration drift, but I do believe the only way to be absolutely certain is to smite a system entirely.  And the only way to ensure you are not attached to it and can rebuild in an emergency is if you feel no fear in doing this.

Ironically, I DO prefer the idea that descriptions of automation can be written in bash, because in such descriptions (packer or docker files), there is no need for loops, if statements, or other things in bash that suck - just package installs and the like.   Most developers probably don’t have to learn an automation system that way, and they can write baby-bash just like you’d type in at a shell.  Easy enough.

And the security team, if using an overlay system (like Docker), can deploy base OS configuration, and they can use Dockerfiles to build on top of that.

Caveat - I think images must come from a build system.  Using anybody’s canned images as a baseline is reckless.  I was actually at a startup that this nailed many years ago (rPath), but unfortunately it was mired in a custom package system.  But they had a cool image builder, that could do local image builds for EC2 and VMware, without needing to spin up cloud instances.  Which I like a lot about Docker as compared to say, Packer.

But yeah, config management?  Where it going if I say bash is ok?  The future of configuration management systems is in deploying cloud infrastructure that will later run immutable systems via an API level.

The need for orchestration systems to do version flips is somewhat the last remaining need for them in immutable systems territory.  I’m looking for cloud/virt providers to eventually provide continuous deployment APIs like flip(instance_group, load_balancer_id, version1, version2).  

To keep up, I view orchestration systems as needing to embrace workflow, merging with build systems, producing images, and perhaps attempting to provide those higher “cluster level” APIs prior to clouds more natively doing this.

Ultimately the plumbing for a version flip is something we can all standardize.  It would be possible to write a book showing idiomatic ways for all cloud providers and most Docker “cloud” systems, in all of the 3 major config systems, in I think about 50 pages.  .  One of the very best examples was a 1-page Docker flip shown by Jesse Keating somewhere in the middle of this talk.  I think somebody should probably do this – most people’s infrastructure follows the same pattern.

I don’t believe people aren’t ready for this.  There are easy steps.  First, make sure all data on your system can be externalized - use RDS or Cassandra.  Keep your logs off system.  Use something like logstash or Splunk.  Monitor externally.   Get to rolling updates with your classic automation.  Now just swap your classic automation out for an image build, that reproduces the configuration of your classic automation. You’re done.

So yeah, there’s me in the corner, losing my religion.

Config tools still have a place - in building the automated systems that allow folks to focus on business logic, but I think there are going to move down-stack to doing things like automating OpenStack.  The longer term future is about cloud/virt systems like this provisioning themselves, but they are still yet a bit too complicated in the way they are going about it, but I feel it’s coming. 

While PaaS has not become a reality for everyone, I think the idea of advancing your deployment between two versions as a “cloud API” on a cloud/virt provider are going to be a reality, to where this just becomes a given, and immutable is going to feel more and more natural over time.   

There are easy steps to start getting there now.

So yeah, are people going to be writing in config tools a bit less?  Yes.  But they will still exist under the clouds.  Ultimately in the end it means more time for everyone to focus on business logic versus thinking about deployments, so I’m a fan of that.

To me, coding was always about making ideas real, not about the coding itself. I’m cool.

Have I’ve said too much?  I’ve said enough.