DevOps implementations vary greatly from organization to organization, but they all share the same intent. Two very solid explanations of DevOps by Microsoft and Amazon provide excellent illustrations of what DevOps should be: uniting historically siloed development and operations teams to efficiently deliver applications and services through shared practices and tools.
The idea of DevOps sounds magnificent in theory. In practice, however, it can be a lot like mixing oil and water because both sides think and work in very different ways:
- Developers solve long-term problems by creating solutions with code; they’re all about automation and they don’t want to touch a project once it’s complete. They also generally lack an understanding of real-time operations and behavior.
- Operations people, on the other hand, have a more hands-on and manual-oriented perspective. Although they work with scripts to accomplish their tasks, they generally lack advanced software development skills and don’t always know what automation is even possible.
Consequently, DevOps is the uniting of two forces that don’t understand each other that well, and communication between the two is often weak. A healthy feedback loop would certainly help to bridge the gap, but sadly, this is also almost universally nonexistent in most organizations, especially large enterprises with complex systems. As a developer, I’ve witnessed this too many times.
What most DevOps teams really need is a good technical therapist to bring both sides together. In some organizations, this task is being taken on by a newly established role, a Site Reliability Engineer or SRE, who bridges the skills gap between operations and development by being either a really strong ops guy with the ability to code automation, or a developer who is sympathetic to ops and concentrates on coding for automation and reliability instead of working on features. But until that profession is ubiquitous, there are several ways that developers in DevOps cultures can step up to improve the level of communication between the two sides. Here are three examples:
- Improve Application Logging and Metrics
Logging and metrics provide a picture of what an application is doing at any given moment. Errors should be logged when they occur, and metrics should capture activities as they occur. But most of the time, these logs and metrics are too generic; consequently, applications run in the dark. When problems arise, operations engineers use their skillsets to read and decipher the application behavior from the logs. But without sufficient ability to look within the application, they often are required to rely on tribal knowledge, making production issues very difficult to solve.
Developers can help to ease this burden in several ways, including the use of formatted logs with lightweight DevOps standard templates; middleware, interceptors and other methods for automatic capturing of necessary information; and tools such as Kibana and Splunk to consume and enable powerful query and analytics capabilities. All sorts of events can be captured to make the operations engineers’ lives a little easier.
- Enrich the “Configuration as Code” Practice
Configuration as Code is a DevOps practice where application configuration code is stored within the source code repository, allowing developers to better manage the configuration.
Most of the time, configuration ends up existing in simple and inconsistent text files that are copied and pasted all over the place if they are documented at all. It’s never easy to test configuration done in this manner. Adding to the mess, the requirements needed for deployment evolve over time, and older configuration files are not often updated to reflect this.
A solution to this problem is for developers to create and promote the use of configuration templates that are understood by both the development and operations sides. This enables much better management of all phases of the application lifecycle. With the use of templates, configuration can be updated without needing to rebuild an application.
One caveat to note: Application code (including application configuration files) should exist in isolation, so be sure to separate the application code from the configuration code. Don’t lump the configuration code within the application code. An application should only be developed with itself in mind — how it’s deployed is up to the configuration side.
- Ensure that DevOps Issues are Tracked in the Backlog
Too often, once an application is developed and released to production, developers move on to the next sprint and leave any issues for the operations people to solve. But if DevOps is a true team, a mixing of two sides into one, shouldn’t developers be involved in all phases of the effort?
DevOps must be a two-way street. Developers must become more responsible for what they have made and work hand in hand with operations in owning how the application behaves in production. It’s also critically important that the problems experienced by operations engineers be captured and tracked in the agile backlog and made a part of the sprint cycle, including things like changes to log messages, the log types being used, deployment issues, and more. This means bringing the operations team into the larger agile team and adding their needs into the product backlog to be taken care of during subsequent sprints.
One Big Happy Family?
Developers on a DevOps team should not see these measures as additional workload, but as a means to a more efficient workload for all. The importance of the feedback loop between development and operations cannot be overstated. Try to have active dialogue between both sides with healthy suggestions for how to make each other’s lives easier. In the end, this helps DevOps live up to its original purpose of uniting both silos to deliver applications and services more quickly and efficiently.
AIM Consulting has a broad understanding of DevOps and a history of implementing it in a wide variety and size of organizations. Take advantage of our DevOps assessment and roadmap offering to learn the advantages of building a robust DevOps practice in your enterprise.
