Welcome!

@DevOpsSummit Authors: Zakia Bouachraoui, Liz McMillan, Yeshim Deniz, Pat Romanski, Elizabeth White

Related Topics: @DevOpsSummit, Linux Containers, Containers Expo Blog, SDN Journal

@DevOpsSummit: Blog Post

Keep CALMS and Release More By @TrevParsons | @DevOpsSummit [#DevOps]

How to Keep CALMS and Release More!

How to Keep CALMS and Release More

DevOps is fundamentally changing.

It is no longer considered a fad by those working with the latest development tools. Now, DevOps emphasizes people and processes as much as the cool tools, and there are many different approaches to bringing them together.

If you Google search for "DevOps flow," you will find lots of flow diagrams and methodologies. While each one highlights different priorities and names, they all have the same general themes.

  1. Start with people
  2. Bring in automation
  3. Stay lean
  4. Measure everything
  5. Share

This strategy is called the CALMS approach.

Keep CALMS and Release more

CALMS vs ITSM?
CALMS grew out of the need to bridge the gap between ITSM principles and DevOps. The challenge faced by those familiar with ITSM, who might view as an alternative to DevOps, is understanding where they differ. If the differences are not immediately obvious when viewing the ITSM documentation examples, they will be as you explore the general concepts of the methodology.

The CALMS acronym will help illustrate these different methodologies at a quick glance, and as you observe culture is the first point, it quickly becomes clear that a side-by-side comparison is not possible.

ITSM is generally focused on documentation, change control, and repeatability, where DevOps is focused on people who drive results. With ITSM, repeatability is a main component, but the structure and processes are not primary objectives.

What Does CALMS Stand For?
Culture

Culture is not something you implement; it is the natural environment that houses the entire development team. Entire means all the developers, QA, AND operations. In this eco-system of people and tools, the culture is necessary to remove barriers and facilitate collaboration to hit team objectives.

There is nothing fluffy about culture.

Culture plays a major role in the success of the business so getting it right is important. In the case of DevOps where red tape, time spent on needless activities, and with the silos of responsibilities, bad culture hinders goal completion and company objectives.

Automation
Once you have culture in place you can focus on automation. This is not just creating scripts for infrastructure or using Selenium for functional testing.

Automation is the idea that you should program everything.

Find a way to lead all new initiatives with automation and then think about automation constantly to help scale.

Lean
As you build automation you also have to remember to be lean.

Running lean means keeping everything to a minimum.

Tools, meetings, and even sprints should all be kept lean. This also is often part of the culture, when you are a minimalist, and every tool, and process you select has a purpose.

It also applies to your teams.

You must keep teams to an effective size to avoid diminishing returns from too many cooks in the kitchen. If the application complexity warrants larger teams, then break them into sub groups, as many large organizations have done.

Measurement
Measurement is the glue that keeps it all together. When you are a lean organization automating everything, you can lose the ability to remember and document it all. Naysayers of DevOps can quickly point to this challenge as being a reason to avoid DevOps, and they are not wrong.

If a team does not have visibility into everything, something will eventually go horribly wrong.

When measurement is implemented correctly this should not happen. If you measure everything and think in terms of reporting on your development team and processes, you will have the ability to analyze and correlate all processes, tools, and production data together.

However, this cannot be done in the traditional spreadsheet style system. In the minimalist organization, you do not have time to inventory everything, which is prone to human error anyway.

Measurement has to happen using more advanced tools for data collection, like a log analysis platform. One that goes beyond event monitoring and reporting, and can push insights to you. This way you can avoid thinking about pulling information on regular tasks or maintenance, and can delegate the effort to the platform. Once you know what you regularly need to observe, you can build a dashboard that (in a glance) tells you everything you need to know.

Sharing
With all this data, you need to disseminate what is learned, what went wrong, and how to correct.

The benefit of breaking down the walls between developers and operations is the information flow becomes bi-directional, and you avoid the concept of "throwing things over the fence". However, this is worthless if information is not shared proactively.

Sharing is not just reporting facts, it is regular exchanging of ideas across teams.

Developers can suggest QA and operations try new tools to improve production quality, and operations can suggest functionality that helps back-end management.

Use CALMS for Loose Direction, not GPS
All DevOps flows similar to CALMS serve the same general function, which is to be used as a guide, and not a definitive answer.

What is unique with the CALMS description of DevOps is the emphasis on culture.

Culture is not easy, nor straight forward. It takes time to mold unless you have the luxury of hiring all awesome people. Sometimes it is awkward to start, but eventually becomes habit.

Because CALMS is a guide, not an answer, you must remember that it will not be perfect.

I personally believe CALMS is missing an R and an I. CRIALMS, (which sounds like something from World of Warcraft). Results and iterations are also incredibly important. Both, like the above, are culture and directives in parallel.

By nature if you are results driven, you will be analytical, and your results will come faster with leaner operations that collaborate well. In order to execute with the this framework, you need to evaluate your progress on small fast chunks; iterations.

This exercise is important not because CALMS should, or should not, be a standard we throw around like candy, but because when new movements come along (like DevOps) there needs to be a path from the hype to the practice. CALMS helps those who have lived operations and those who do not know what operations even is, but realize they have to work with them.

More Stories By Trevor Parsons

Trevor Parsons is Chief Scientist and Co-founder of Logentries. Trevor has over 10 years experience in enterprise software and, in particular, has specialized in developing enterprise monitoring and performance tools for distributed systems. He is also a research fellow at the Performance Engineering Lab Research Group and was formerly a Scientist at the IBM Center for Advanced Studies. Trevor holds a PhD from University College Dublin, Ireland.

@DevOpsSummit Stories
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more business becomes digital the more stakeholders are interested in this data including how it relates to business. Some of these people have never used a monitoring tool before. They have a question on their mind like "How is my application doing" but no idea how to get a proper answer.
Hackers took three days to identify and exploit a known vulnerability in Equifax’s web applications. I will share new data that reveals why three days (at most) is the new normal for DevSecOps teams to move new business /security requirements from design into production. This session aims to enlighten DevOps teams, security and development professionals by sharing results from the 4th annual State of the Software Supply Chain Report -- a blend of public and proprietary data with expert research and analysis.Attendees can join this session to better understand how DevSecOps teams are applying lessons from W. Edwards Deming (circa 1982), Malcolm Goldrath (circa 1984) and Gene Kim (circa 2013) to improve their ability to respond to new business requirements and cyber risks.
DXWorldEXPO LLC announced today that Nutanix has been named "Platinum Sponsor" of CloudEXPO | DevOpsSUMMIT | DXWorldEXPO New York, which will take place November 12-13, 2018 in New York City. Nutanix makes infrastructure invisible, elevating IT to focus on the applications and services that power their business. The Nutanix Enterprise Cloud Platform blends web-scale engineering and consumer-grade design to natively converge server, storage, virtualization and networking into a resilient, software-defined solution with rich machine intelligence.
So the dumpster is on fire. Again. The site's down. Your boss's face is an ever-deepening purple. And you begin debating whether you should join the #incident channel or call an ambulance to deal with his impending stroke. Yes, we know this is a developer's fault. There's plenty of time for blame later. Postmortems have a macabre name because they were once intended to be Viking-like funerals for someone's job. But we're civilized now. Sort of. So we call them post-incident reviews. Fires are never going to stop. We're human. We miss bugs. Or we fat finger a command - deleting dozens of servers and bringing down S3 in US-EAST-1 for hours - effectively halting the internet. These things happen.
The digital transformation is real! To adapt, IT professionals need to transform their own skillset to become more multi-dimensional by gaining both depth and breadth of a wide variety of knowledge and competencies. Historically, while IT has been built on a foundation of specialty (or "I" shaped) silos, the DevOps principle of "shifting left" is opening up opportunities for developers, operational staff, security and others to grow their skills portfolio, advance their careers and become "T"-shaped.