With DevOps to a new level in the e-commerce business

In the past, it was usually a matter of implementing large shop systems with sometimes complex requirements. At the beginning of the project many requests were placed and the systems were implemented with great effort.

If there were changes to the system, that was regularly associated with a greater effort in terms of development, testing and going live.

In recent years, however, encouraged in part by the increasingly used agile approach, the market has demanded more and more that changes can be implemented with greater speed. Cloud providers such as Amazon Web Services (AWS), Microsoft Azure or Google Cloud Platform (GCP) take this into account with their offerings. Strategy in the e-commerce business is one thing, but the real battleground is in the area of software deployment and, in particular, speed-to-market while software quality requirements are increasing (see also:
https://blog.iese.fraunhofer.de/high-quality-short-time-to-market/
).

This market requirement – to be faster while improving quality – is where DevOps comes in, resolving this apparent paradox in the process.

DevOps brings a number of benefits that allow you to be faster and better than the competition:

But how can its basic idea be implemented in the company?

The first thing many would look for is the right tools. But unfortunately it requires much more than buying software tools. Telling development and system administration to work more closely together in the future doesn’t help any more than setting up a DevOps department and waiting for results.

DevOps is not a process or workflow, it’s a culture that needs to be established!

One possible approach to implementation is the CALMS model(short for Culture, Automation, Lean, Measurement and Sharing). The model was coined CAMS by the authors of the DevOps Cafe podcast Damon Edwards and John Willis (see also:
https://devopscafe.libsyn.com/webpage/category/podcasts
) and later supplemented by Jez Humble with the L.

The strength of this model is that it shows what DevOps is all about: people, processes, tools, in that exact order, with the greatest emphasis on people (Damon Edwards: “people over processes over tools”).

This is the cornerstone of DevOps. This is about how people and groups behave towards each other. In the past, there was a division between Development and Operations, which worked towards their own different goals.

This silo thinking must be broken down, all departments must work as one towards the common goal of deploying code safely and reliably and quickly.

The goal is to automate (and thus make repeatable) routine tasks (e.g. test automation, execution of deployments, or even code compilation). It is the starting point for problem solving and helps gain all the other benefits of DevOps. It allows development teams to focus on non-routine tasks with high variability.

Automation noticeably improves workflow and productivity of an organization.

To implement this, you need to establish a “toolchain” (e.g. Ansible, Git, Jenkins) that helps you implement the following key concepts:

• Infrastructure as Code
• continuous integration
• continuous delivery

Lean is the agile aspect in DevOps. The idea is to break the work down into small, manageable packages (code deployments to live systems should be small and frequent) and make incremental improvements that way.
One of the aims of automation is to keep as much as possible to a minimum so that the infrastructure is not unnecessarily complicated.
The principle can also be applied to team sizes, as larger teams find it harder to agree on anything.

Implementation examples:

• Minimization of “Work in Progress” (WIP)
• Reduction of waiting times and complexity
• Making work visible

It is necessary to define metrics and KPIs (Key Performance Indicators) to be able to check whether changes have led to an improvement. So it’s about monitoring and tracking the progress of various aspects of the DevOps environment.

Firstly, it is important to ensure that the measurements are carried out across the entire organisation and secondly, the metrics should be defined in such a way that cross-team goals are set, the achievement of which can then be measured. Furthermore, these metrics should be open and transparent to everyone in the organization.

Examples:

• MTTR (mean time to recovery)
• Cycle time
• Lead time
• Costs
• Proceeds
• Employee satisfaction

Sharing ideas and problems is the heart of collaboration and especially the heart of DevOps. Sharing is why there is such a big focus on openness and transparency in DevOps, and is also the feedback loop that enables continuous improvement.
People make mistakes and it is important to establish a culture where these mistakes can be shared openly without fear of disadvantage. Only in this way can an improvement be achieved.

Aspects here are:

• Transparency
• Visibility
• Knowledge transfer

These 5 components of the model are the core values in order to implement DevOps. They are the “why” behind the technologies for implementing DevOps and provide a blueprint for how the DevOps idea can be realized in an organization.