Five DevOps AntiPattern and How to Avoid Them
Almost every developer worked in a project or company that implemented DevOps or worked towards a DevOps strategy. Far too often, basic things are done wrong while implementing DevOps. This article explains five Antipatterns that happen when DevOps is approached the wrong way.
What is DevOps
DevOps is a combination of Development and Operations. The goal of DevOps is that a software team can develop and run their piece of software independently over the whole application lifecycle, as shown in the image below.
Contrary to the common belief that DevOps teams build extensive operations knowledge to run the application, they use services that allow them to manage the operation of their application. Those services are built to simplify application operations for a DevOps team and are made by specialists.
The Service Layer
Those Services are built on top of specific infrastructure or other software and provide a more accessible abstraction. A service can be a Database as a Service (DBaaS), a Platform as a Service (PaaS) that runs applications, etc. The following image shows how DevOps Teams consume Services from the Service Layer that simplify their work by providing out-of-the-box solutions to their problems.
The developers of the applications are further referenced as consumers because they consume the services. The developers of the service layer are further referenced as providers because they provide the services.
Antipattern 1: The Service Layer isn’t a Self-Service Layer.
Suppose a Service Layers needs its consumers to get in touch with someone or something. In that case, dependencies have been introduced that slow the development process down and waste the time of both consumers and providers because it can most likely be automated.
Fewer dependencies lead to higher productivity in a DevOps Team!
To be most efficient and to be able for the Service Layer to scale, it’s necessary to provide a Self-Service functionality throughout. That way, the consumers can consume a Service independently, without having any waiting times or dependencies to the providers.
Antipattern 2: Consumers need to know the technical details of a Service implementation to consume it.
Technical specifications of a particular service should never be necessary if people want to consume it. E.g. if new languages or frameworks are introduced, consumers need to know, the required knowledge within a DevOps Team increases. This increase makes people unproductive because they need to switch between their core stack and the additional languages and frameworks of the service layer. If configurations aren’t done quickly over a service interface, it requires a lot of technical knowledge.
Abstract the technical implementation to make your service easy to use! But abstract only irrelevant complexity to still provide important functionalities.
Consumers are developers of specific applications as well. They need to know the stack of their application and are experts in that stack. If they consume a service from the provider, the technical implementation must be irrelevant to them. Of course, they need to know the service and how it works, but the implementation details should never be relevant.
Antipattern 3: Your Service isn’t self-explanatory to the consumers.
If things aren’t self-explanatory, the service either isn’t used, or the consumers will contact the provider side to get the information they need. Reaching people is slowing the process down a lot. Time is wasted, and therefore, money is wasted.
Remember that consumers aren’t operations specialists!
To provide a better consumer experience, build your service self-explanatory. Either by creating a wizard that describes the steps necessary or providing a step-by-step guide built into the Service Interface. Also, listen to what your consumers are telling you. Feedback is key and a working feedback loop between consumers and providers is the backbone of a high-quality service layer.
Antipattern 4: Developers don’t know a service exists or can’t find it.
Marketing is key! As a provider, it’s your job to get the word out to the consumers about what you offer and how they can consume it. Provide a central, up-to-date overview of all the services that contain all the information consumers need. A great way to make new information also a self-service is by providing a subscription functionality that informs consumers about changes or new versions.
Blog posts are a great way to describe and introduce new services of a service layer and explain them a little more in-depth.
If your service isn’t known, it probably won’t be used.
Organize regular talks or small events if you have a large service layer to bring your consumers up to speed with the latest news and functionalities.
Antipattern 5: There’s no versioning in your service layer.
When no versioning is implemented, all the consumers must switch to a new version immediately when it’s out. This is neither stable nor safe. To provide a safe environment, make sure that old versions of the service layer are supported until all the consumers switch to a newer version. Once an old version isn’t used anymore, the provider can safely remove it.
If changes of services are made, always provide them in new versions by keeping the old ones alive!
Don’t force consumers to switch to newer versions immediately. This will cause them to do tasks that don’t provide added value to their application and will probably keep them from doing more important changes first.
Have a look at Semantic Versioning to learn how to use version numbers that provide a self-explaining structure and describe the implemented changes automatically. Semver.org describes it as:
“Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards compatible manner, and
- PATCH version when you make backwards compatible bug fixes.” — semver.org
Inadequate implementations of Service Layers can make things worse instead of better and can bring companies further away from the goal of a productive, high quality, and satisfied DevOps organization.
So if you are building a DevOps infrastructure, make sure your Service Layer…
- …is a Self-Service Layer.
- …provides functionality and is simple to use.
- …abstracts the technical details to the user.
- …is known amongst DevOps teams.
- …has a default configuration that fits most use cases but can be changed if necessary.
References / Sources
Automatisierte Kollaboration und Prozesse in der Softwareentwicklung - Wandel von…
2018 | OriginalPaper | Buchkapitel Im Gegensatz zum klassischen Verständnis einer rein funktionalen…
DevOps for Developers | Michael Hüttermann | Springer
DevOps for Developers delivers a practical, thorough introduction to approaches, processes, and tools to foster…
Continuous Delivery and DevOps: A Quickstart guide | Packt
Before we get into the meat of what continuous delivery (CD) and DevOps are all about, I would like to introduce you to…
Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers)
Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) | Nygard, Michael T. | ISBN…