For enquiries call:
+1-469-442-0620
When someone asks me to explain what DevOps is about, I usually do this using the different letters of the acronym CALMS.
Culture is the foundation of DevOps. If you omit culture, you're only doing some symptoms of DevOps (like using a whiteboard, working in timeboxes, and doing daily standup meetings won't make you an Agile team).
Culture is about the people, self-organized teams, T-shaped profiles, and tearing down the wall between Development and Operations. A DevOps team takes end-to-end responsibility for an application or system: "you build it, you run it".
If your organization has always been working in a command-and-control style, then the first thing to do is to instill a culture of team empowerment. And don’t underestimate this: this will probably take years to change.
This is where a lot of focus goes and can be considered as the easiest to obtain. The heart of DevOps is the CI/CD pipeline: the continuous flow process that is triggered upon check-in of new versions of code. Continuous integration was already known in eXtreme Programming. In a DevOps context, the continuous delivery/deployment makes the story complete. To make your CI/CD pipeline work at its full capacity, you have to consider everything as code:
But automation is also about closing the feedback loop: getting observations and metrics from the running systems fed back into your team’s product backlog.
DevOps is not about moving big chunks of changes to production, but instead, moving to a constant flow of small and easier-to-control changes. Flow, as in Kanban: limited work in progress, small batches. And moving to production does not automatically mean: "going live". If there is a dependency with other code that is not yet ready, you can still disable your code via feature toggling until everything is ready to be activated.
This is crucial to improving: define metrics on your process. How good are things going in your organization? Where is room for improvement? And apply the typical Plan-Do-Check-Act/Adjust approach to gradually improve your way of working.
DevOps teams take full responsibility for their system. But this does not mean that they have to reinvent the wheel over and over again. They learn from their peers.
There are plenty of resources on the internet - blogs, pictures, slide decks, and videos - that explain DevOps using this CALMS acronym. So by now, this acronym has become common sense for anyone searching for a definition of DevOps. Or hasn't it…?
I recently discussed with a colleague who is a certified SAFe® Program Consultant and trainer. According to this colleague, SAFe® doesn’t talk about CALMS but about CALMR instead. She wanted to be sure we tell the same story and don’t confuse the people we train and coach. I am not going to give a full explanation of SAFe's definition of Devops; you can read it yourself on the SAFe® site (more specifically on this page www.scaledagileframework.com/devops).
This discussion made me wonder: if a large part of the world talks about CALMS to define the principles of DevOps, then why does SAFe® talk about CALMR, and what is the difference? And why do they call it "SAFe® DevOps"? So I did some investigation, and this is what I found.
In all honesty, whether you speak about CALMS or CALMR, in the end, both are equal, or better, equivalent. Let me explain why.
In the CALMS acronym, the S stands for sharing. Sharing of knowledge, of experiences. Call it communities, chapters, and guilds if you are more into how Spotify works.
I deliberately don't call it "the Spotify model" because there is no Spotify Model (says Marcin Floryan, a Spotify chapter lead in this presentation: https://www.infoq.com/presentations/spotify-culture-stc).
In "SAFe® DevOps", sharing is a part of the Culture. People work in teams. But teams together form a release train. So, these teams will not only need to align planning-wise, but they will also inspect and adapt during the IP sprint. And they learn continuously. OK, fair point. But sharing clearly is there in both definitions.
So, what about the recovery aspect of SAFe® DevOps? Is it a part of the CALMS acronym too? In my opinion, yes, of course, divided over other aspects. The first thing that the SAFe® site tells about Recovery is the "Stop the line mentality".
Now, that is a Lean principle. Mary Poppendieck (Lean Software Development) mentions this in her presentations: "The greatest productivity comes from not tolerating defects. Create ways to detect defects the moment they occur” (see slide deck https://accu.org/content/conf2007/Poppendieck-Stop_the_Line_Quality.pdf ).
The other parts, Planning for and rehearsing failure and Building the environment and capability to fix forward and roll back, are typically automation aspects. Plan for and rehearse failure talks about the chaos monkey.
The Simian Army is a bunch of tools and concepts that will create chaos in your ecosystem: kill processes, slow down processing, etc. Chaos engineering is really great, but most likely not the first thing you will implement (even though it is a very good enabler for resilience). More information on the Simian Army can be found on the Blog of Netflix. (https://medium.com/netflix-techblog/the-netflix-simian-army-16e57fbab116).
Fix forward or roll back: these are the capabilities of your CI/CD pipeline, the heart of your automation efforts in DevOps. Your Continuous deployment should allow you to roll back changes. Or do canary releases: for certain changes, you don't go full park all the way but deploy on a very limited set of servers/containers as a try-out and roll back if "the canary dies".
I could not find any explanation on the internet why SAFe® talks about SAFe® DevOps. The only thing I can think of is that they want to stress how DevOps culture, principles, and practices seamlessly integrate with SAFe®. Similarly, SAFe® talks about SAFe® ScrumXP, where the good practices of Scrum and eXtreme Programming help to deliver good quality software every iteration and every program increment, not only on the team level but integrated with the other teams of the Agile Release Train.
As far as the difference between CALMS and CALMR is concerned: they both cover the same ideas. In my humble opinion, the difference between CALMS and CALMR could be a matter of focus: maybe the initial focus of CALMS was to stress the importance of sharing knowledge, whereas the CALMR stresses more the need to be able to roll back a failing change. The bottom line, CALMS and CALMR may not be entirely equal, but they are definitely equivalent.
| Name | Date | Fee | Know more |
|---|
