Puppet and Chef Rock. Doh. What about all these shell scripts ?!
Alex Honor /
Incorporating a next generation CM tool like Puppet or Chef into your application or system operations is a great way to throw control around your key administrative processes.
Of course, to make the move to a new CM tool, you need to adapt your current processes into the paradigm defined by the new CM tool. There is an upfront cost to retool (and sometimes to rethink) but later on the rewards will come in the form of great time savings and consistency.
Seems like an easy argument. Why can’t everybody just start working that way?
If you are in a startup or a greenfield environment, it is just as simple as deciding to work that way and then individually learning some new skills.
In an enterprise or legacy environment, it is not so simple. A lot of things can get in the way and the difficulty becomes apparent when you consider that you are asking an organization to make some pretty big changes:
- It’s something new: It’s a new tool and a new process.
- It changes the way people work: There’s a new methodology on how one manages change through a CM process and how teams will work together.
- Skill base not there yet: The CM model and implementation languages needs to be institutionalized across the organization.
- It’s a strategic technology choice: To pick a CM tool or not to pick a CM tool isn’t just which one you choose (eg, puppet vs chef). It’s about committing to a new way of working and designing how infrastructure and operations are managed.
Moving to a next generation CM tool like Chef or Puppet is big decision and in organizations already at scale it usually can’t be done whole hog in one mammoth step. I’ve seen all too often where organizations realize that the move to CM is a more complicated task than they thought and subsequently procrastinate.
So what are some blocking and tackling moves you can use to make progress?
Begin by asking the question, how are these activities being done right now?
I bet you’ll find that most activities are handled by shell scripts of various sorts: old ones, well written ones, hokey rickety hairballs, true works of art. You’ll see a huge continuum of quality and style. You’ll also find lots of people very comfortable creating automation using shell scripts. Many of those people have built comfortable careers on those skills.
This brings me to the next question, how do you get these people involved in your movement to drive CM? Ultimately, it is these people that will own and manage a CM-based environment so you need their participation. It might be obvious by this point but I think someone should consider how they can incorporate the work of the script writers. How long will it take to build up expertise for a new solution anyway? How can one bridge between the old and new paradigms?
The pragmatic answer is to start with what got you there. Start with the scripts but figure out a way to cleanly plug them in to a CM management paradigm. Plan for the two styles of automation (procedural scripting vs CM). Big enterprises can’t throw out all the old and bring in the new in one shot. From political, project management, education, and technology points of view, it’s got to be staged.
To facilitate this pragmatic move towards full CM, script writers need:
- A clean consistent interface. Make integration easy.
- Modularity so new stuff can be swapped/plugged in later.
- Familiar environment. It must be nice for shell scripters
- Easy distribution. Make it easy for a shell scripter to hand off a tool for a CM user (or anybody else for that matter)
Having these capabilities drives the early collaboration that is critical to the success of later CM projects. From the shell scripter’s point of view, these capabilities put some sanity, convention and a bit of a framework around how scripting is done.
I know this mismatch between the old shell script way and the new CM way all too well. I’ve had to tackle this problem in several large enterprises. After a while, a solution pattern emerged.
Since I think this is an important problem that the DevOps community needs to address, I created a GitHub project to document the pattern and provide a reference implementation. The project is called rerun. It’s extremely simple but I think it drives home the point. I’m looking forward to the feedback and hearing from others who have found themselves in similar situations.
For more explanation of the ideas behind this, see the “Why rerun?” page.
That's very well said. All those scripts which being used for years has passed through many improvement cycles and people are familiar with them. These should be building stones for any new change.