Five DevOps AntiPattern and How to Avoid Them
By: Jasmin Fluri
Tags: Development, DevOps, Antipattern, Software Development, Service Design

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. Jasmin Fluri Follow May 10 · 5 min read

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.

DevOps Application Lifecycle — Plan, Develop, Build, Test, Release, Deploy, Monitor, Feedback — Iterations.

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 Service Layer provides Services to Software Development Teams —Software Development Teams can consume Services to be able to manage the whole Software Lifecycle.

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

Conclusion

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