DevOps is not a particular skillset. It is a business culture that affects how teams are organized and how software is delivered and operated at scale. Learn what this culture shift entails in this post.
Anti-culture: typical siloed team divisions
“DevOps” as a word points to merging development and operations. Old siloed team divisions into “development”, “operations”, “quality assurance”, and so on, have been shown to work poorly and slowly. The reason for this is inter-team friction caused by no one team “owning” the entire process. Operators find it hard to work with a piece of software if they do not know how (and why) it works. Or rather, what to do when it doesn’t. And developers may not understand why their code seems fine on their own machines, but fail to work when deployed to the cloud. When problems occur, the last thing you need is more friction between the people that ought to fix it.
Conway’s law describes that organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations
. If your teams are in silos, that’s bad news. But when teams are merged and they share responsibilities, we get away from these inefficient silos. Engineers are no longer working in isolation, but instead toward a common goal. Because nobody can say that something is somebody else’s problem anymore, everything just goes smoother.
DevOps culture: sharing
Sharing reigns supreme in a DevOps world. Knowledge, responsibilities, tasks… all of it. When skilled engineers talk to each other, the old broken and inefficient silos are torn down. Many software engineers have more than one skill. Some have run servers at home or for an organization, like a local sports team, or a blog. Many have dabbled a bit in front-end development. Some love automation, both of their homes, and of their software build environments. In cross-cutting teams, skills such as these get to grow. Not only is this good for business, because more people can take on other tasks than the silo approach would allow, but also for individuals. Engineering is a creative job, and job satisfaction tends to go up for creatives when they get to pursue their interests. Job satisfaction pays off tremendously for businesses, as skilled people are hard to both find and replace.
Sharing requires working together. Whether this is via meetings, Slack, Trello, or whatever is up to your team. Do what works for you. And use whatever tools you need. The point is to remove friction and to get everyone on the same page.
Remember to share with outsiders, too! DevOps is fairly new, and your team benefits from learning what others are doing. Build a local community and host events. Getting people talking and sharing is so important to foster development of good DevOps culture.
DevOps culture: automation
Think about how developers treat their programs. They do not bugfix programs while the programs are running. They prepare a new version, shut down the old, and replace with the new. Throwing out what did not work is how they have always done it. And going back to a previous version is easy, since all the code is version-controlled.
On the other hand, operators tended to be system administrators, administering systems by upgrading them constantly. There is nothing wrong with that approach: it is what you had to do before virtualization came around. Ordering and installing new hardware took weeks! But these days, when creating a new cloud server takes a few minutes, new possibilities have arrived.
How developers have always worked with programs can now be used for how to operate servers. Old versions are thrown out and replaced with new ones. Entire server sets have versions, so it is easy to go back and forth. Configuration is also stored in versions.
Done right, automation makes it possible to spin up an entire parallel cloud infrastructure. By doing that, bugs found in production can be fixed in isolation. And once they are, replacing the broken version in production is no more dramatic than any other change. Imagine asking a systems administrator in the nineties to create a whole parallel data center just to troubleshoot an issue!
Some tools obviously come in handy here. Terraform manages infrastructure, Kubernetes container deployment. Consul stores and distributes configuration values, Vault does the same for secrets. Ansible can help automate management tasks.
The main driver behind automation is laziness. Because engineers are creatives, they rarely enjoy doing boring busywork. Letting them to automate away the boring tasks to focus on the important is great for DevOps culture. And for productivity. Of course.
DevOps culture: monitoring
You can’t understand what you don’t observe. This makes monitoring a crucial part of any operational task. Three types of monitoring are important:
- metrics shows how your systems are doing;
- logging shows what your systems are doing; and
- tracing shows how your systems are interacting.
Many different tools are needed here. That is because each type works with different data. Metrics are time-series, where a value (such as CPU usage) is tracked over time. Logging from applications is text, hopefully with some structure. And tracing is a set of related records in a database. The tools that we typically recommend in this space are Prometheus for metrics, ElasticSearch for logs, and Jaeger for tracing.
A culture of monitoring comes naturally when everybody works toward the common goal. In a silo, a developer does not have to know how the code behaves when it is deployed. In a DevOps team, that information is front and center and informs all future development.
Summary
Transitioning to a DevOps culture unifies your team, and makes it deliver software more efficiently. It stimulates engineers and makes better use of their entire skill sets. Automation makes fixing bugs much less scary, and monitoring systems makes it easier to identify where more effort is needed.
Since 2011, Elastisys has helped many customers adopt a DevOps culture and see these gains first-hand. If you want us to help you too, don’t hesitate to contact us.
