CALMS Is DevOps for Cloud Engineering

LONDON — “I like definitions. Definitions help us create common vocabularies.” That’s how Matty Stratton kicked off his DevOpsDays London keynote. The director of developer relations for Aiven pointed out, however, it took a couple years for the tech industry to settle around a definition for DevOps, which Donovan Brown nailed down as the union of people, process and products. Still, the term DevOps isn’t very inclusive of all the silos it’s breaking down, which has led to portmanteaus like DevSecOps, AIops and beyond.

In comes cloud engineering, which, Stratton contends, applies standard software engineering practices and tools across application development, infrastructure and compliance — usually just the first — pursuant to leveraging the cloud effectively. His talk offered how to combine the basics of DevOps’ CALMS — culture, automation, lean, measurement, and sharing — with the foundation of cloud engineering — build, deploy, manage — all with a cloud native mindset. Let’s dive into his breakdown now.

Keep CALMS and Carry On.

This is what CALMS stands for, and why each word in the acronym matters:

• Culture: “Why we’re here,” Stratton explained, paraphrasing Simon Sinek and emphasizing that everyone needs to understand the purpose of a DevOps transformation. He quoted Ngmoco’s Lloyd Taylor who said, “You can’t directly change culture. But you can change behavior, and behavior becomes culture.” This comes down to the importance of psychological safety, which on then can enable “DevOps for Dummies” author Emily Freeman’s definition of DevOps: collaboration, ownership and learning. This all creates a safe space for continuous improvement.
• Automation: What most people think about when they hear of DevOps. “This is the fun part, the tools,” which Stratton is why automation takes the least convincing to gain DevOps buy-in. After all, automation is what gets rid of the boring, repetitive engineering tasks.
• Lean: This later addition by Jez Humble dives into value stream mapping, elimination of waste and bottlenecks, and assessing progress over time relative to business strategy.
• Measurement: A true offshoot of agile and even the scientific method, you can’t improve what you can’t measure. This M was solidified by Google’s DORA metrics of lead time for changes, deployment frequency, time to restore, and change failure rate.
• Sharing: Stratton dubs this as one of the hardest. “People feel, especially at an executive level, things are on a need-to-know basis,” he explained. “The reality is the list of things that are need to know are smaller than we think.” Cross-functional transparency is what differentiates elite teams from DevOps in name only.

“DevOps is not just automation or Kubernetes,” Stratton emphasized. DevOps from the start was not very prescriptive which is when folks started selling magic solutions. But, he warned, “You can’t buy DevOps but I can definitely sell it to you,” with consultancies abound propagating their own secret sauce.

DevOps success all comes down to communication, which is why he advocates for combining CALMS with the emergent practice of cloud engineering to put everyone in the same direction.

Also Read: Google Says You Might Be Doing DORA Metrics Wrong

Build the DevOps Way

So far DevOps has been most likely applied to development and operations teams — it’s in the name. But if it doesn’t factor in governance, security and finance, to mention a few important siloes, an organizational DevOps transformation can only go so far. Stratton offers cloud engineering as a way to apply those standard software engineering practices and tools across the whole software development lifecycle, folding application development, infrastructure and compliance into build, deploy and manage.

👁 We use cloud resources to build infrastructure platforms upon which we deploy cloud applications, which we manage with policies

Basically, in a DevOps way of cloud engineering, Stratton explained in a follow-up conversation, “We use cloud resources to build infrastructure platforms upon which we deploy cloud applications, which we manage with policies.” So how does that new cloud native build stage work?

“The build part of cloud engineering is about creating the services and the infrastructures that provide what our customers need,” Stratton explained.  Stratton cited James Governor in pointing out how everyone is in a race to the bottom to create their own Heroku, when they aren’t in fact platform-as-a-service companies.

“A lot of orgs, we want to create things because it’s fun,” explained Stratton, with government agencies and the biggest companies “building tools that don’t exist to retain great engineers. It’s never your most important thing,” and then, he continued, “your side project doesn’t get the funding and attention.”

Now, if you apply CALMS to this build stage, it one-ups everything.

You guide culture with a focus on building differentiators, creating a common developer experience, and driving empathy. A lack of empathy, Stratton explains, comes from a lack of understanding. The build-driven automation zeros in on reusable components, leveraging ecosystems, and creating rationally crafted pipelines, avoiding bespoke implementations. Building with lean software development practices comes with a focus on increasing value, driving efficiency, and reviewing for continuous improvement.

new little song:

“The Re-Org Rag (I’m My Own VP)” pic.twitter.com/NLB4dtpD8s

— Forrest is at #GoogleCloudNext (@forrestbrazeal) October 4, 2022

How to Deploy CALMS-ly.

“Deployment processes that take too long or require too many minimal steps can absolutely block us from getting new features to customers or resolving service issues,” Stratton said. This is why he argues it is essential to deploy the same way, every time. And enforce it by applying continuous delivery practices to infrastructure, too — because otherwise, he says, humans make exceptions.

“When you have an exception process, everything becomes an exception,” he continued. “It’s a common practice to apply CI/CD to application development but not infrastructure.” He continued, “when we pick these same principles with our infrastructure that means our new updated infrastructure resources meet our quality controls and help us understand that we know what changed.”

Deploying the same way every time, Stratton further explained, includes quality and security checks. Make sure infrastructure is part of the application. You should even automate checklists, he says.

“The wonderful and frustrating thing about computers is they are jerks. So when we have a process that a person has to approve, people do favors for each other sometimes,” which is why Stratton advocates for enforcing the same thing, all the time. Which makes it easier to measure everything with ample visibility.

In a deploy culture, he says, “It doesn’t count until it’s in prod.” The deploy culture embraces iterative deployment, breaking a larger application into much smaller parts , and enables continuous improvement

Just remember that the measurements will be different depending on the org. “It’s not about speed — it is the ability to move at the speed that’s appropriate for what your business needs to drive value,” Stratton said. Only then can the sharing be grounded in everyone having a clear answer to: What’s changed?

Manage Cloud Engineering with Policy as Code

Stratton kicked off the third pillar of his CALMS cloud engineering with another pedantic exploration. DevOps is all about shifting left, but that isn’t typically explained well. “We want to shift the attention to the left, not the workload,” he reminded DevOpsDays London.

The manage side of cloud engineering comes down to creating this level of visibility across a development and deployment cycle, with a common vocabulary that connects to business objectives. At this stage, Stratton explains that security is everyone’s job, not just shifting that responsibility on new shoulders.

Cloud engineering aims to put controls and process in place to enable, enhance and automate as much as possible, especially around security and compliance, taking the blame away from the individual. “Treat policies as code and it gives security visibility no matter where they sit in an org,” Stratton said. “Security is everyone’s responsibility,” he reiterated. And security and quality are so closely linked, however, only the latter is considered early on.

Guardrails are actually very powerful culture influences, he explained, allowing everyone to be more confident in their deployment and management, increasing a common understanding across disciplines, he explained.

So how do you manage automation in a cloud native way? “Computers can’t lie,” he said. They also can’t be persuaded to approve something without the proper processes and checks in place. This way, policy goes from vague to understood across siloes, in a common, standardized, codified checklist.

Lean management then focuses on ways to determine continuous improvements. With cloud engineering, you’re able to express lean’s value stream changes in a codified way.

Then, the manage stage of measurement brings visibility into the current, executable policy — with metrics both tech and business understand. This includes a current state of compliance, with an understanding of where policy and value collide.

Then, by embracing a shared vocabulary, enforced by policy as code, it “helps us utilize success patterns and helps us share the learning,” Stratton said.