In successful, long-lived software projects, developers continually refactor their code. That means that in addition to adding features and fixing bugs, they clean up the hidden structure of the software. That cleaning up leads to easier extensibility and maintainability—which ultimately lead to higher higher quality and productivity.
The alternative? Software becomes steadily more complicated, becomes harder and slower to change, and eventually must be replaced wholesale or scuttled.
That situation sounds familiar to many sysadmins in charge of production servers. You start with a clean deployment of 20 identical servers with a simple software load on each. Over time you apply patches to the systems. Then app updates. Then a partial web-app customization on half the systems—now you have two classes. Then a new storage driver on a different subset of systems—now you have four.
After a few more rounds of updates, patches, configurations, emergency fixes, accidental changes, cosmic-ray hits, and mistaken configurations by “the new guy,” you find yourself with a bunch of snowflakes. Each system is now unique, brittle, impossible to understand—and risky to change in any way.
Usually, the only answer is to burn it down and start over.
But what if Ops could refactor servers just as programmers refactor code?
Some common refactoring operations are:
- Finding commonalities in two different components, and pulling out the common part into a single reusable component.
- Breaking down a monolithic complex component into smaller, reusable pieces.
- Finding and eliminating components that are no longer used.
- Pushing functionality up or down the inheritance hierarchy, making it more or less broadly available.
rPath drives change from a flexible model for each system. And those models make it possible to refactor by:
- Finding commonalities—With a system component library (containing everything from whole operating systems down to individual packages), it’s easy to see that two system models are both using a similar config of the Squid proxy, and to change both to use a single reusable Squid component.
- Breaking down monoliths—It’s hard to see the pattern in a complex software assemblage because it’s not written down anywhere. Complex applications in rPath are modelled as Conary recipes, which use a powerful declarative language for system automation. When you see your database installer listed as a clean set of steps, it’s easy to break it down into (say) separate pieces to install MySQL, to configure it, and to preload it with your application data.
- Eliminating unused parts—Conary dependency handling automates this. You don’t have to do detective work to tell whether anyone is still using that old xinetd.conf—just let Conary drop it when it’s no longer needed.
- Pushing functionality up or down the hierarchy—Step 1 is to have a hierarchy in the first place. With rPath, you can model base systems that describe your common builds, then derive variants for specific purposes. Each variant, such as a JBoss system model, can focus on just the relevant parts (such as JBoss’s required dependencies and configurations), not on the common stuff (such as using the right version of OpenSSH).
The benefit is really the same in both domains. When you continually improve the underlying framework, you don’t have to raze everything and start over from scratch. That’s a bad way to maintain your house and a bad way to maintain software systems. Refactoring means better productivity and better quality.
