Having laid out the headache that administrators face, we should talk about where some of the nightmare is coming from. We have automation tools like Chef, Ansible, and Puppet, but no theory regarding their usage. Developers and architects have codified common solutions to common problems into design patterns. I haven’t really seen this applied to administration. This might be because of the technical limitations, but now that we have the tools I thought we should investigate the idea of defining Administrative Design Patterns. Especially since I’ve seen some administrative bad habits starting to creep into development.
So what is a Design Pattern? In software development and architecture, we often run into common problems, and over the years we’ve defined some common solutions. Let’s briefly examine the concept with an example. Event Driven would be such a design pattern. The problem is that applications or parts of an application do not know when work is ready for them. Let’s use a real-world scenario. Let’s say that you have an application that processes some data and writes the results to a database. Other applications need this data. How do they know when the data is ready? A crude solution would be to have those applications regularly check for updates. But this would mean that waiting applications would have to be idle while they regularly check. They would also have to regularly connect to the database, which would load the database. What if the downstream systems could be notified when their data is ready? This idea of notifying a system when an event, such as updating the database, has occurred is the foundation of the Event Driven design pattern. We call it a design pattern because it defines a solution abstracted away from how to implement it. A design pattern is a theory about how best to solve a problem. The job of developers and architects is to figure out to use software to make the theory an implementation.
But this is basic computer science. With the growing adaption of DevOps, administrators repeatedly find themselves solving the same general problems. Things like, how to deploy applications, how to configure them, monitor for failures, responding to faults, etc. We have some crude design patterns, like Disaster Recovery, but this isn’t a very well-explored area. In this series we’ll explore some proposed administrative design patterns.