SOLID is a mnemonic acronym for five basic principles of object-oriented design, originally coined by “Uncle Bob” Martin. From Wikipedia: “The principles when applied together intend to make it more likely that a programmer will create a system that is easy to maintain and extend over time.” While SOLID is designed to help guide developers, these principles can be very much applied to operations as well.
Single Responsibility (SRP)
A server should have only a single responsibility.
When first starting out, it’s common practice to run web server, the app server, and the database server on a single host. While that may be an accepted practice for development (though, I would argue against it even then), your applications will become more complex in time and the tangled mess of servers will become a nightmare to administer.
Each server should have a single purpose. By separating responsibilities, your servers are easier to care for, your metrics are easier to parse, your infrastructure audits go much more quickly, and service disruptions can be greatly minimized.
Capacity planning is an absolute must for reducing infrastructure costs. Proper planning requires clear and well-defined metrics. Virtualize parts of your infrastructure where performance will not be degraded to minimize expenses.
Servers should be open for extension, but closed for modification.
Once a server is provisioned, it should remain in the intended state until it is decommissioned. A server can be modified to correct errors, but adding new services or changing the functionality of a service means that a new server should be provisioned.
Adding new services to a server breaks the closed nature of the system, consequently increasing complexity and the time it takes to recover from failure.
Liskov Substitution (LSP)
Servers in an infrastructure should be replaceable with instances of similar types without altering the correctness of that infrastructure.
Servers are a disposable commodity. Never rely on providers to always have 100% uptime and never assume a server that exists today will be there tomorrow. Your application should not rely on a specific provider. It should not rely on a service that is only offered by one provider. Data that can’t be recreated must be backed up in a vendor-independent manner.
Knowledge should never be held by a single individual. The person responsible for a particular piece of infrastructure should document any and all information they have about it. Everyone on your team should be able to sub in for anyone else. They may not immediately know to resolve issues, but they should know where and how to find the necessary information.
Interface Segregation (ISP)
Many client specific tools are better than one general purpose interface.
Give your infrastructure the UNIX Philosophy treatment. The tools you use should do one thing and do it well. Your configuration management tool should only manage configurations. Your server provisioning tool should only provision servers. Your metric collection tool should only collect metrics.
Monolithic services force you to modify your processes to fit the service. Instead, use tools with single purposes and modify them to fit your processes.
Dependency Inversion (DIP)
Depend upon abstractions. Do not depend upon concretions.
Having your developers worrying about the underlying infrastructure is a needless and potentially dangerous distraction. Developers should not concern themselves with how much storage or memory a given system has. That doesn’t mean your developers should not understand or ignore the performance implications of their design decisions, but provisioning or configuring the systems they use should not be on their mind.
Provide your developers with a platform upon which they may deploy their applications; be it Heroku, Cloud Foundry, or even something home-rolled. Implement a simple interface with which they can deploy their applications and make the deployment process across multiple languages and data stores as uniform as possible.
In smaller organizations where cost is a much greater concern, following these principals does pose a greater challenge, but it is not impossible. Never assume your organization will always remain small. Growing will be so much easier in the long run. Likewise, if you simply don’t have enough time or people to implement one or more of these principles, make it a goal to work toward while focusing on the principals you can implement.
Like all ideals, meeting them completely is hard. Our common goal shouldn’t be “good enough”; we should shoot for the stars and sacrifice whenever we must.
2012/03/21 - Added "In Practice" section
It’s the summer of 2001. The sun is burning hot in the midday sky, the grass a most beautiful emerald green, and I just found my first love. It is a brown 1983 Buick Regal sedan with bench seats, a vinyl top, AM and FM radio, enough fake wood to re-panel a basement rec room, and shocks so
worn amazing you’d have thought you were sailing a ship across a sea of clouds. In other words, this is one serious Chick Magnet.
I have intense social anxiety.
I feel extreme discomfort when I am in a situation where I may have to interact with other people: grocery shopping; driving in traffic; going to the movies; even talking on the phone. My heart races, my hands get sweaty, and my head starts pounding. I can do pretty well with people or places I have known for a long time, but I am awful with new people and new situations.
The state of monitoring solutions has been on my mind for a while. Today, the
#monitoringsucks hash tag became a trend on my local Twitter feed. I’ve been working on my own monitoring app as of late, so I was inspired to put to words what my definition of the ideal solution should look like.
Programming is a science dressed up as art, because most of us don’t understand the physics of software, and it’s rarely if ever taught. The physics of software is not algorithms, data structures, languages and abstractions. These are just tools we make, use, throw away. The real physics of software is the physics of people.
I recently became the caretaker of a Chef server that sits behind a firewall, inaccessible to all but the nodes that require access. Even though it’s locked down, I still need to be able to administer it. My tool of choice is
knife, the command-line utility used to interact with Chef.
My wife is a writer. She considers herself the aspiring variety, but I disagree. Anyone who can actually sit down and puts words to paper (digital or otherwise) is certainly a bonafide writer in my eyes. Writing is hard - really hard, and I respect the hell out of anyone who tries their hand at it.
Never, ever, write in a vacuum. Show your work to people: friends, colleagues, reviewers. Check with your publisher to see how they want to handle this, but get feedback early, and get it often.
Tiered support is a methodology commonly practiced by any institution that proffers customer service. When a customer calls in, they’re connected to a tech who can offer basic advice. If that tech cannot resolve the issue, the customer’s call is transferred to the next tier of techs that know more than the last. Rinse, repeat, until the customer is passed on to the tech that eventually solves the problem.
This is a horrible practice, and I know you already agree with me.
I know what you’re thinking: “Of course it’s money. Everyone likes money.” But it’s more complex than that. Just a wee bit more, not rocket-surgery complex.
Say you start a business. You make it far enough that you need people to do some of the work for you. Great! Now, there are two paths you can take, each with a wildly divergent outcome.