DEV Community

chis0m
chis0m

Posted on

C.A.L.M.S - The DevOps Core Values

CALMS is an acronym for Culture, Automation, Lean, Measurement, and Sharing. These are the foundational values of DevOps practice. Below are some thoughts on them:

Culture

  1. Culture is a major factor in DevOps because it is the primary human factor.
  2. Notwithstanding technology, the core of our problem is related to people and their behavior.
  3. If we have a bad culture, other aspects of DevOps will only enhance and magnify our bad culture.

Automation

  1. Automation/CI/CD only helps to accelerate and enhance the benefits of DevOps as a whole. It doesn't correct human problems.
  2. Here we use CI Toolchains, Test Frameworks, Artifactories, Cloud services

Lean

  1. Simply, lean means creating more value for customers with fewer resources. The aim is to reduce waste.
  2. You should learn to have Minimum Viable Products. Every feature doesn't have to come fully grown...

a. Implement the basics, then from user feedbacks and other necessary inputs, mature the feature
b. Many times the developers' consent should be consulted in modifying and maturing a feature.

3.Every feature should also be broken down into basic stories so that it can be...

a. Easily built, monitored, and tagged
b. Easily isolate failures
c. Easily tested
d. Easily digested when pushed into the pipeline

Measurement
1.In DevOps, progress must be tracked.
2.Some Metrics that can be tracked are...

a. User satisfaction and feedback
b. MTTR: Mean Time To Recovery - The time it takes for our
c. system to be fully working after a downtime
d. MTBT: Mean Time Between Failures - The average time
between two downtimes
e. Income
f. Cost
g. Deployment Frequency
h. Release Frequency
Note: Working software successfully delivered by sound systems is the primary measure of progress.

Sharing
1.This basically has to do with communication. Transparency and openness are key here.
2.The Operations and Developers should be able to communicate with utmost good faith.
3.developer should always communicate his architecture with the Team Lead(and team if necessary), PM(Product Manager if need be) before implementing his task. To avoid repeating the task and to reduce WIP(Work in Progress) time
4.Costly faults should be communicated to the team lead or escalated(if need be) to find the best possible ways to mitigate such.

Top comments (0)