There are a few key concepts and practices that might be disruptive, at first, but are essential in the long run, when you are trying to adopt the DevOps model. Some of the changes are related to human behavior and the rest are technical.
DevOps means greater freedom for the individual to experiment and learn about different technologies. However, with this freedom comes additional responsibility. The range of problems you are expected to deal with grows, and so does the level of competence expected from you.
This can be overwhelming. Under the traditional model, the humans were split based upon the skill sets Under the DevOps model you might want to use a different approach. The application itself can be broken down into manageable microservices. Then a team, or an individual, can take responsibility for a particular microservice rather than the whole complex application.
Adoption of a microservice architecture is not necessary, but quite helpful if you are trying to adopt DevOps as a culture.
2. Continuous Integration
Quarterly release cycles and “scheduled” deployments slow down the thought processes. Ideas lose their charm, sitting on a to-do list, and humans lose enthusiasm. Central to the DevOps culture is the practice of continuous integration, or CI, where you push changes to a central repository and then a set of automated tests validates that the entire app works correctly, after the merge.
This works beautifully with microservice architecture. If a build fails, then you know that it is your particular microservice that was changed and you will turn your attention to that. If it were all a giant monolith, incremental updates would have triggered bugs in the remotest part of your code base making incremental updates an impractical idea.
3. Continuous Delivery
Integrating your changes with the existing code base is fine, but what about releasing it into production? Is it a bridge too far? While many insist that this is indeed reckless and unwise, you should look into Continuous Delivery options if they are well-suited for your application. Why push a giant update every quarter or every six months, when you can push new features incrementally.
This will give your product a competitive edge. While your competitors are waiting for their next release cycle you are rolling out new features to the users continuously.
If security and reliability is a concern, you can use the flexibility of source control to differentiate between the production-ready branch and the one that is on the bleeding edge. A good example this is the FreeBSD operating system, which offers its users STABLE, CURRENT and RELEASE branch and OpenSUSE rolling update model, Tumbleweed.
4. Observability and Debugging
The nastiest of the bugs are encountered in production, the ones that escape test cases and subtly hurt performance are the hardest to catch. The only way to monitor them is to make your code more observable. The proper DevOps team believes strongly in the value of observability.
Services like Amazon CloudWatch can be integrated into your applications to monitor and log the app’s state, in real-time. Besides real-time monitoring, aggregating time series data can also benefit the developers to better optimize for trends in usage pattern and user behavior.
Observability and Debugging ought to be first class citizens when it comes to DevOps.
Thinking to adopt the DevOps model? Find out guidance.