You’ve read it in the news. You’ve heard that your competitors are using it. You’ve seen it being described as the next best thing since sliced bread in the software delivery field. DevOps – the Holy grail of IT development and operation efficiency and culture, which promises to solve all of the problems that you have. You’re curious, you start reading about it, but as you step deeper in it, you find even more related buzzwords, like GitOps or DevSecOps. Let’s see whether they really are just buzzwords or something that may help you out, if used properly.
The term DevOps has been used and abused for the better part of the last decade. The general consensus is that it’s a compound of development (Dev) and operations (Ops), DevOps is the union of people, process, and technology to continually provide value to customers. And while the first part of the definition is quite obvious from the name of the term, the second part, which actually starts going into what is needed to adopt DevOps, is often bent or partly neglected in favor of too heavy focus on just the technology part (writing scripts and making pipelines sadly is not the full story of DevOpsing). More often than not it’s already much better than doing a lot of manual work. But when talking about DevOps, one cannot ignore the DevOps frameworks that have spun up over the years, with CALMS being quoted quite often.
CALMS in its essence is just an acronym made up of these words:
- Culture
- Automation
- Learning
- Measurement
- Sharing
They can be considered the key values, which DevOps is built on and each of them an essential part of true DevOps adoption.
Automation is a value which is the most easy to understand. Automating the infrastructure provisioning and software deployment saves time and reduces the potential for errors thus enabling rapid development cycles as well as consistent and repeatable outcomes. Well executed automation results in tidy version-controlled code and CI/CD pipelines that run the whole software deployment process automatically right from the code commit. Automation alone is a great way to start tearing down the wall between developers and operations.
But making changes might give a subjective sense of accomplishment. That’s why it is important to measure the outcomes. And in software development that can be anything from releases per day to bug numbers per week to the time it takes all the development tests to complete. Measuring objective indicators give a good idea about what is working and what is not for your organization and your employees.
The Lean pillar is all about reducing unnecessary tedious tasks (hence – automation) and focusing on the most important things first. A very important thing when talking about lean is the iterative approach to building something and validating the end result after one short iteration. It is commonly referred to as “fail-fast” as if the outcome is not what is expected and is considered more or less a failure, it did not take the team 3 months of pulling in the wrong direction and the time loss is minimal.
This fail-fast approach, however, must be supported by the organization. And it brings us to the Culture pillar. Great things might require multiple tries to perfect. And having this understanding within the teams and management reduces stress and builds an environment where new ideas are appreciated and failures are seen as a way to learn and grow professionally.
Sharing is also intertwined with the cultural part. Long gone are (or should be) the days where the the whole IT organization relied on a single person due to some specific knowledge that only he or she had. Tools, practices and knowledge should be shared to enable a more sustained organization without bottlenecks and faster growing competences.
As you see from even this brief description, all of the CALMS pillars are deeply connected, making DevOps significantly more than what what lies on the surface.
How the same mindset applies to a broader scope
It’s probably quite obvious, that most of these principles can be broadened and applied on a different scope. The DevOps term itself has been vastly improved and extended over the past few years with terms like DevSecOps. In essence it is more of a technical expansion of DevOps, emphasizing the importance of making security an integral and shared part of the whole IT development cycle. It further down breaks the old silos and enables a more holistic approach to security inside an IT organization. But while the tooling and competences might be extended, the core idea remains the same as with DevOps. Some of the ideas of DevOps are even transitioning into the business side of things with mechanisms like BizOps.
And while on the topic of scope, DevOps is not at all related to the public Cloud. While building automated infrastructure in the Cloud is very much targeted for quick releases and a significant automation infrastructure, the Cloud is definitely not a prerequisite to start adopting DevOps.
Is DevOps only for software engineering?
DevOps initially started out as a mindset of breaking the walls of software developers and system operators and that is obvious by looking at the name of DevOps. But what also needs to be mentioned, is that the traditional “operator” has evolved into a role that is more similar to a developer as well. Only not an application developer, but an infrastructure developer. It is a person, who has the right set of infrastructure skills and can define that infrastructure in code and automate the deployments, to have a consistent way of quickly provisioning environments based on the requirements that the application teams might have.
Of course this is of essential importance to companies that develop their software products and do numerous releases every day. But what about other companies? Companies that do not develop their own software, but who rely on large IT infrastructures and still have a lot of ongoing operational activities. DevOps practices can help with the daily activities as well. From a fully automated infrastructure provisioning or migration pipeline when a major upgrade is ahead, to a centralized configuration application for your network equipment, which in term will reduce the quality of changes, improve the availability metrics and reduce the overhead that the IT team has to deal with.
For one, the culture of knowledge sharing will improve the general awareness of the whole infrastructure, which previously might be siloed. Storing the configurations for network equipment, virtual server configurations and container manifests in your version controlled Git repository will make it easier for specialists wearing different hats to work on a common goal and actually broaden their view and allow them to look into what the other teams are working on.
Ensuring that your infrastructure is saved as code will make the code reuse easier, prevent multiple “versions” of a particular script being in circulation, ideally replace your existing functional scripts into more easily maintainable infrastructure-as-code manifests and allow to integrate everything into a single, easily usable infrastructure pipeline. And that, in a nutshell, is what you would consider GitOps.
Now GitOps, as you might have guessed from the title, is another item that we are keen to discuss. As described in the paragraphs below, it is focused mostly on infrastructure, and has little to do with software development. However, it shares a lot of the same principles of DevOps, and shows that it can be beneficial even when software development is not your (primary) business.
Managed DevOps Service
Now it’s probably apparent that advanced automation capabilities alone is not what enables DevOps. And because of that eyebrows often get raised when someone mentions DevOps-as-a-service as a solution for software companies who want to start out with DevOps, but don’t know how to start that. After all, culture and knowledge sharing are qualities that should be born from within the organization, right?
While providing the technological edge to our customers’ development teams brings significant value very quickly, we try to follow the CALMS framework and firmly believe that the cultural part brings the best value in the long run. This might seem to be harder to achieve with a managed services provider than with a set of internal teams, but our experience shows, that bringing in an external party to help with DevOps activities can greatly improve the development team’s awareness of the infrastructure architecture and allow them to adopt to more frequent software releases, which improves overall efficiency and acts as a stepping stone to embrace DevOps internally.
We truly believe that the cultural part of the CALMS framework brings the most value for a development organization in the long run. And yes, a consultant coming in and writing a couple of Ansible playbooks and building a few pipelines is arguably a “more packageable” service than spending time with the developers and system engineers to see where and how problems arise and working towards improving it. But to enable a better overall collaboration, the cultural part cannot be neglected.
The goal of such a service, in our view, is to enable a self-sustaining practice within a company and not be on the leash of your technology partner and then allow the customer to choose whether additional technical expertise is required to help out with the in-depth technological solutions (which, of course, is just as important).