A bird’s eye view on the world of DevOps
DevOps is a concept that can be really hard to wrangle — there is a wealth of overlapping and conflicting definitions. So, what are we talking about when we talk about DevOps? Let’s find out!
I entered the world of DevOps recently by joining Polar Squad, a DevOps consultancy, after five years of developing applications in the fields of machine learning and web development. As a newcomer, I was surprised to learn that no one seemed to have a clear, agreed-upon definition of what DevOps is about. So, I embarked on this journey of trying to understand how people perceived DevOps.
My process was simple: I interviewed a dozen of my colleagues at Polar Squad about all things DevOps, and conceptualized DevOps based on those discussions.
So here it is; my current perception of what DevOps is all about. I hope it clarifies how DevOps can help software teams, and how the DevOps movement can contribute to organizations of all sizes.
What topics should come to mind when we think of DevOps?
The first topic is agility. Traditionally, with humans and animals, agility is defined as the ability to rapidly change the position of the entire body with speed and accuracy. The original meaning of the term “Agile” was in that sense for organizations, so that they can rapidly adapt to customer demand in a very precise way, without accumulating technical debt. For DevOps, it’s also about the agility in which software is developed, deployed, maintained and monitored. This is more important than ever in the fast-evolving landscape of technology.
Communication is another important aspect of DevOps. Development teams and operations teams work with different toolsets, but they need to collaborate to build the product. This requires communication, and communication is often problematic. As a result, the work done by DevOps consultants often involves changing the way developers and operators communicate — by improving processes, but also by helping them shape the social makeup of their organization.
A natural consequence of DevOps is automation. It is one of the key methods of creating value; companies want to improve the level of automation of their infrastructure, and they believe that for this, they need a DevOps consultant or engineer. It’s mostly true, in the sense that when we do our job right, that’s the result; better infrastructure and more automation. But automation tools like Docker, Kubernetes, Helm, Terraform, CI/CD pipelines, etc. are not everything. Working smart instead of hard is the core of what we do concretely when we do DevOps, and the tools just enable us to do so.
DevOps isn’t about automation.
Automation is just the natural result of DevOps.— Tatu Seppä-Lassila, Co-founder of Polar Squad
Also, a word of warning: DevOps does come with its share of buzzwords. “Cloud”, “Agile”, “DevOps”, “microservices”, “containers” etc. are sometimes terms not used in their intended original meanings, but as a selling point to attract technologists and investors. So it’s worth your while to achieve a shared understanding of the concepts involved in a given project; to understand, but also to explain, so that everybody is on the same page.
How do we explain the difference between DevOps and the more classical, pure operations role?
The operations team’s role is often restricted to the implementation of the infrastructure supporting the product, in a similar way that the development team’s role is often restricted to building the applications involved in the product, with a certain level of communication and automation between the two teams. But DevOps is about improving the collaboration between those teams by working on where the problems are, regardless of whether those problems are on the infrastructure side or not.
For example, if certain parameters of the application should differ between environments (URLs between services, API keys, credentials, etc.), a DevOps engineer would recommend that the developers make these parameters injectable at the application level and that the values of those parameters should be handled by those dealing with the different environments, i.e. the operations team. The DevOps engineer would then work on where the problem is to achieve such a result, but how exactly depends on the situation. So the difference would be in what a DevOps engineer vs an operator tries to do, but not always in how they do it.
DevOps is a philosophy about how to do things.
You can even do DevOps in the kitchen if you want.— Teemu Korpela, Co-founder of Polar Squad
While working in operations is often a technical skill that system administrators develop, DevOps is about a mentality of problem-solving: the technical skills are learned to enable solving the specific kinds of problems in the tech industry, but in theory, this mentality could be applied anywhere.
What do we consider a red flag that would indicate a team should improve how they implement the philosophy behind DevOps?
- Struggling with the software release cycle. The moment when developers release new updates is the moment where the development team and the operations team interact the most, so problems at this level are usually best handled using a DevOps mentality.
- Poor choice of technologies. There’s no single technology that -has- to be used, but there’s a common set of problems that most tech organizations encounter, and it is common to see those problems solved with certain technologies. When those technologies are not present (version control, CI/CD pipelines, etc.) or poorly used, it’s usually not a good sign.
- Rigidity in the workflow. A very rigid workflow is often a symptom of things that have been hidden under the rug for too long. For instance, technical debt being managed by an intricate manual workaround, managing an error-prone and yet-to-be-automated process with a long and regular (and dull) meeting, etc.
- Silos. They are not bad in themselves (see here for a great detailed explanation about what we should think when it comes to silos). But they tend to restrict communication, so when important communication channels are siloed away, it’s usually a very bad sign.
- Delegating a big chunk of the software delivery process to an external partner. If you can’t oversee the whole software delivery process, you basically have a blind spot for errors, which makes finding or resolving them extremely difficult. If you wait for your customers to point out the errors, it’s already too late.
All things considered, we still don’t have a universal definition of DevOps, but hopefully, this article shed some light on all the kinds of things it is. I’m having a blast working at Polar Squad, which is self-proclaiming itself as the best DevOps company (and thus far, I agree 100%!). Get in touch with Polar Squad to discuss how we can help you implement the various aspects of DevOps to your benefit!