Platform-as-a-Service vs. Configuration Management
by Dan Razzell

Dan Razzell, June 7, 2012

[Dan Razzell has just joined ActiveState and already we've coerced him into blogging. The following analysis of configuraiton management tools vs. Platform-as-a-Service was written in the context of a lively (and ongoing) discussion sparked by the recent online debate between David Cramer and Randall Degges on the merits and weaknesses of both approaches. --TT]

I come from the "old" school which advocates declarative system configuration management tools such as Chef, Puppet, and cfEngine.

Such advocacy is necessary when the only alternative is reactively configuring each system according to need - as in fact I'm doing this very moment while setting up my Linux workstation. There is no xchat, so I have to manually install it. There is no Ruby, so I have to manually install it. I have to manually disable the Caps Lock key. A few days of this and I will have a desktop environment roughly like the one I want, and roughly similar to those of my colleagues, I hope. If the workstation blows up, I'll have to start over, and it's almost guaranteed that I won't get the same thing twice. And I can't transport a desirable configuration from one workstation to another, because it hasn't been abstracted away from its implementation on that particular machine.


It's common practice for sysadmins to do the same thing on servers, and therefore not know exactly what has been configured or how to recover from catastrophic system failure. I see it all the time. System configuration tools were developed in response to this, and they make excellent sense compared to ad hoc configuration.

With me so far? But if you've ever had to manage a fleet of systems using one of these tools, you'll know that it's still totally full of hair. The intention is to abstract away from system-specific detail, but the reality is that behind the scenes you're applying regexes to config files that were only ever intended for manual editing, whose syntax differs subtly from one platform to another (e.g. /bin/sh not being bash in Ubuntu), etc. So it's still a lot of work and complexity and expert knowledge and brittleness. The leverage you get out of these tools comes from abstraction and repeatability.

Stackato offers a significantly higher level of abstraction and perfect repeatability. I can understand that sysadmin types might do IaaS + Chef out of sheer familiarity, but all they need to do is run one trivial app deployment in Stackato and the value proposition becomes obvious.

Sysadmins are not obsolete

I'm not trying to say that there is no need for comprehensive sysadmin skills. If you're going to have an application stack, someone has to understand the complexity of the lower layers. But in many cases, you just want sufficient environment to run an application. Those layers end up being nearly invariant. Why invite the extra work and risk of opening them up to arbitrary configuration?

Yes, there are special cases where you really do need to delve into the complexities of how iptables is implemented, or routing policy, or JBoss tweaks, or whatever. The space of all possible system configuration is huge, and it's never going to become smaller. The whole point of good sysadmin is to make that configuration space tractable. You do it for the sake of your own sanity, if nothing else.

Subscribe to ActiveState Blogs by Email

Share this post:

About the Author: RSS

Dan has a background in language design, system administration, development, and network operations, with information security and identity management experience as well. He's worked with everything from supercomputers to embedded control systems. His past involvements include the Laboratory for Computational Intelligence, Parasun, Sun Microsystems and WestGrid.