Operational Stability is one of the main concerns in organizations. Especially some larger organization struggle to get a more stable IT landscape. Too often it’s political discussions that are preventing them from doing something about it. Organizations that have DevOps teams in place can just smile because they are enabled to be in control of their entire delivery chain from development to production. Read about what DevOps teams do in order to be real DevOps and why they’re smiling all day long.
DevOps Practice 1: Develop Loosely Coupled Services.
Disorders inside a highly coupled system can and will at some point in time affect or worse take down an entire system. Think of a system of many services that is build in a way where all services are called in a sequence, one by one. They heavily depend on each other and one of those services is not responding or is having a timeout, the effect can be tremendous. What I’ve seen very often is that we take the effect and try to figure out the cause so we can fix “Something”.
Don’t take the effect and make it the cause.
It’s like robbing a bank because a new law was made up.
I was once part of a project where we had lots of C++ files that were over 2000 lines of code long. This application was doing so many different things that there was not One Single Developer who understood all of its responsibilities. Whenever we made a change we introduced a new bug. This project was demanding – we were scared because of the massive amount of dependencies it had. Instead of spending time fixing those applications we must consider to find out the real cause of a complex and error-prone application. One solution to avoid services affecting other services is it to build loosely coupled services that are less prone due to instabilities in the overall system. DevOps people love Microservices because they are so handy and so easy to integrate into Continuous Delivery Pipelines. Here is a great blog post that explains Microservices
DevOps Practice 2: Release Small Changes
Big and clumsy monolithic applications are often very hard to manage. Releasing a small change often requires a full regression test which is time consuming and expensive. It’s like piloting the Queen Mary 2, one of the worlds biggest cruise ships through the canals of Amsterdam. I would prefer a speedboat unless you’re seeking for entertainment like monolithic applications provide developers.
Imagine how much more stable your whole IT system could be when you can release only a very small change into production. Let’s say Continuous Deployment is the way you work in your organization and every commit will be released automatically. In case of a bug you do exactly the same thing, you commit a hotfix. A regression test that is part of the pipeline only takes some minutes because your change is inside a service that has only one single responsibility and ergo is very small itself and easy to test.
Small changes in small services can cause problems like big changes in big applications. But small changes are easier and faster to manage and to hotfix than big changes. Choose the speedboat and manage to get your change out as fast and stable as possible.
DevOps Practice 3: Monitor the System
Knowing what’s going on improves a team’s capability to react early and to avoid incidences. Imagine you can see all anomalies in your overall system in realtime like an increasing response time from one of your services. You will be able to react immediately. You will be able to find out what’s going wrong before customers will notice it.
The last couples of months I was so lucky to be the driver for monitoring our IT landscape with AppDynamics. And I can say that it helped us almost immediately to avoid serious problems. We created a custom dashboard that shows any kind of data that gives info about our operational stability with lamps, graphs and numbers. After some weeks we collected all errors and warning that didn’t result in an alarm that is sent out to Operations and analyzed them with the objective to improve the operational stability over time.
It’s great, motivating and fun to monitor what’s going on and to feel real control over our IT landscape.
Conclusion
DevOps is much more than only these three practices, of course. Continuous Delivery, where we automate anything from development to production ready state is another practice that in my opinion should come from itself. In order to become responsible of running our own services in production and at the same time separate duties for security and quality reasons, automation is an obvious step to go. If you not yet have implemented a DevOps culture please read my article about how to start today: 9½ Simple Steps On How To Start With DevOps Today
