DevOps is everywhere. And while it’s an interesting trend, it should be fitted to products, not the other way around. But some people don’t see it that way. I’m often asked questions such as: “Do you think we should start using Docker, or jump straight into Kubernetes?” Such questions are meaningless without even knowing what the product is about. All those fancy terms—cloud, Kubernetes, containers, configuration management, Infrastructure-as-Code—promise some improvement. But they are to DevOps just as telescopes are to astronomy. They may be useful, but they are not necessary. At its core, DevOps aims to close the gap between what the client ordered and what the development team has delivered. There is an emphasis on short release cycles, iterative approach to design, and automation of repetitive steps. What do you think is most important to bring those to reality? If you said “great communication,” you are right. The tools are all fine. But they are only worth the money invested in them when they improve communication. One aspect of communication is knowing what’s necessary to get the job done. And the job does not mean “code is committed to the repository.” Think of it rather as “the client saw the change in production and accepted it.” As soon as this first step is determined, and everybody knows what needs to happen, that’s the best time to write it down. Where? Well, I’m a huge advocate of maintaining a README.md. Each person on a team can always peek inside it and know the state of a project, and it’s a natural go-to for project newcomers. Automation, the next step after writing a README, is optional. It is, though, a natural outgrowth of documenting the process. And yes, automation is what often comes to mind when thinking about DevOps. Wait a minute…automation is optional when it comes to DevOps? Isn’t DevOps the department of the person who does deployments? What people usually understand under the “DevOps engineer” term is either a software reliability engineer, a platform engineer, or an operations automation engineer. These are all valid roles that enable practicing DevOps, but using the collective term “DevOps engineer” may be a bit ambiguous. So let’s take a closer look at DevOps itself.
DevOps explained
First, let me show you what DevOps isn’t:
It isn’t just a job title prefix It isn’t a team (but “Dev” and “Ops” are) It isn’t a technology It doesn’t mean “a system administrator who can code” It doesn’t mean “automating stuff” It doesn’t mean “there’s no operations team now”
Knowing this, you are now aware that you can’t simply “hire a DevOps engineer” or “create a DevOps team” in a company to make sure you’re future-proof. DevOps is akin to Agile development. Would you hire an Agile developer as such? Probably not. Either you develop product in an Agile way or you don’t. How then can DevOps be described? It’s a methodology. Or maybe a culture. Perhaps even a spirit. Doing a product according to DevOps principles means that everyone—be it developer, operations engineer, or product manager—shares a common vision, maintaining it via communication. To a lesser extent, it also means that everyone uses the same tools. These tools aren’t meant to help any single group of people. They are meant to push the product forward. Going with this concept requires a serious change of mindset, which is the main obstacle. Why is that? It’s because people have to step out of their comfort zone and start collaborating with people that have different competencies. Developers suddenly need to learn how the cloud works and start to deploy their own code. Operations people need to abandon manual setups and start coding. Everybody needs to learn new concepts. Everybody has new responsibilities. This isn’t easy, but with good communication and a common goal, it is quite achievable. This communication involves establishing a culture, setting up lightweight processes, and maintaining proper documentation.
DevOps automation is documentation
You probably never thought of it that way. But most of the tools commonly associated with DevOps are documentation tools:
Build scripts written for readability serve to document the build process Continuous integration pipelines document the integration process, from building single pieces to a whole product Continuous deployment pipelines go further by documenting how to deploy a product your client can use Configuration management files document the process of installation and configuration Infrastructure-as-code specs document the necessary infrastructure (quite formally, in fact!) Containers come with their own Dockerfiles that document how to build and configure a given microservice
All these fancy concepts do basically one thing: They help team members communicate better by documenting processes. These processes can then be run manually or be automated. What’s important is that every stakeholder in a project is able to follow them. Documenting your processes as code has one big advantage over usual instruction manuals. Code can be verified and behaves predictively. Given the same input, it produces the same output. With written instructions, you’ll have as many interpretations as there are readers. If you write ambiguous or vague documentation, the person that reads it will fill in the gaps. Point is, you have no control what goes into the gaps. It’s much simpler with code. Without concrete steps, the program will cease running. These concrete steps are one key aspect of DevOps communication.
DevOps communication: The only way to bright the gap between developement and operations
In the book The Phoenix Project we witness the problems of a recently promoted manager tasked with deploying a big project. As nobody knows what is happening, everybody is fighting fires without much progress. The book subtitle mentions that it’s a tale of DevOps. I agree with that. But what’s interesting is that throughout the course of the book, not a single new tool is introduced. Can you achieve a state of DevOps by improving communication alone? The protagonists of the book did it, so there’s hope for you too! Even though the protagonists’ approach may be considered “old school” (using actual paper cards instead of a proper bug tracking system), things begin to change for the better only once all the involved parties start to talk to each other. You may think it is only possible to improve collaboration between development and operations by creating better interfaces between them, like service-level agreements or incident backlogs. But the opposite is true. By tearing down the interfaces and introducing empathy and a common cause, you will have a team that works towards a common goal.
DevOps team structure: Who’s on a team?
Ideally, each product should only have one team: the product team. I was once on a development team where a common goal with other teams was absent. The development team wanted to push as many changes as possible. The validation team was tasked with preventing the introduction of defects. They had different managers and they were evaluated individually. The result? Development and Validation played ping-pong with defect reports. When Validation found a test that wouldn’t pass, Development was more interested in finding flaws in the test code itself than trying to make their own code free of bugs. The release cycle ballooned, of course, as there was enormous overhead required to properly fill the reports, the counter-reports, and so on. What most seemed to fail to recognize was that in terms of product, both teams should share a common goal and work together to achieve it. But the lack of proper cooperation and silo mentality made it very hard to notice.
Fighting waste is a joint effort
The lean production mindset that inspired The Manifesto for Agile Software Development (which in turn introduced us to DevOps) was about fighting waste. By waste, we mean everything that is not directly relevant to what the client’s ordered. Piled up work-in-progress is a waste. Every step of a process that does not clearly lead to release is a waste. But waste can only be seen from a high level. In the scope of one team, some procedures may seem essential. From the product perspective, though, they may well be useless. To figure out which efforts are wasted you have to join forces and consider the lifecycle of a shipped product. You also need to think from a client’s perspective. Is this feature something the client wanted? If not, you may as well skip it at this time. Are your processes simple and lean? Take a deeper look especially on those that cross team boundaries. Do you want to make sure the development of a product is as efficient as it can be? Invite an outsider to see how you work. A person that is not a part of your team will be able to ask insightful questions and spot new areas for improvement.
DevOps principles: Keep your CALM(S)
CALMS is a very accurate description of how one should practice DevOps:
Culture Automation Lean Measurement Sharing
Notice that it’s formed like a sandwich. The three middle values are more technical, whereas the outer ones relate to soft skills. But the basis of all culture is communication: We exchange our values and beliefs with other team members until we reach a consensus on how things should behave. Same goes with sharing. Sharing something basic like food doesn’t require communication. The gesture itself, however, can also be seen as an act of communication. “I care for you, so I share with you.” We don’t want to limit the scope only to verbal communication. Sharing ideas and tools, however, requires communication. How should we share them? Where are we to put them? Are they useful for every person on a team or just for a smaller group? If you focus only on the more technical aspects—Automation, Lean, and Measurement—you are missing the point of DevOps. What’s so good in having an automated deployment script that nobody ever uses beside author? If the script saves her some time then it might be justified. But imagine how much time could be saved if everyone shared this script. This says something about fighting waste!
DevOps brings business closer to development
Some say DevOps brings operations closer to development. This is true, but it’s not the whole truth. When done right, DevOps brings every unit closer. It allows business and clients to see what development is doing, almost in real time. This shorter feedback loop benefits all stakeholders. The work is generally more visible, and developers, too, can easily see how clients use the code they produce. With traditional deployment, you can wait several months before somebody notices bugs or missed requirements. With continuous deployment, everyone can react to any problems as they arise. Developers, operations, business, and clients can sit in one room and modify the working application according to current needs.
DevOps tools first? Think again
Of course, there’s a need for all the tools to make it possible. But no amount of tools can be a substitute for good communications and empathy within the company. I once observed a product where the build process was owned by one team, while the supplied code was owned by another. Problems with the build system were common. Developers were unsure how to use it. It was based on standard tools but they were customized to the point that every documentation available on the web proved useless. Everybody wanted to improve the situation, but there was no understanding between the two teams. This meant that both sides introduced new tools without consulting with the other side. This only widened the gap, instead of closing it. If you want to start a DevOps transformation within your organization, start with improving the way you communicate. Don’t simply assume a solution: Brainstorm with an open mind first. Then you might find that, for example, tooling support is insufficient for your needs. That’s when you can consider tweaking your current tools or introducing some new ones—otherwise you’ll likely be adding to the original problem.
The quickest way to establish DevOps? Better communication
In the introduction, I mentioned the question that clients often ask me: “Should I go with Docker or should I jump straight to Kubernetes?” After reading this article, you can see that such a question is best answered after doing some prep work—with a DevOps mindset. If you know your product team understands the benefits of DevOps for itself and for the client, the team and the client can start by setting their expectations. Then engineers can figure out the development and deployment model. Finally, you can determine which tools are needed. Once all the requirements are documented, technology choices are much easier to make. I am an advocate of all the great DevOps automation tools that make our work easier and more manageable. But our daily job is working with people. Let’s invest some time to improve on this aspect of DevOps best practices rather than getting another technology certificate. The Toptal Engineering Blog is a hub for in-depth development tutorials and new technology announcements created by professional software engineers in the Toptal network. You can read the original piece written by Piotr Gaczkowski here. Follow the Toptal Design Blog on Twitter and LinkedIn.
