Pre-word Since 1785, when William Cartwright invented and formally patented the first power loom, we have...
Since 1785, when William Cartwright invented and formally patented the first power loom, we have been hearing the word “automation” at every turn. Nowadays we encounter automation everywhere: at home, in stores, and of course at work.
At a certain stage of company life, the question arises - how to grow further, extensively or intensively. Usually, this begins to concern a company in the middle stage. And this is where companies fall into two types. The first ones avoid the word, and the key point is the fear of messing up everything they have built losing money spent on automation and due to unsustainable or unmanageable automation. Their approach is pretty straightforward: old processes, well-known approaches, just hire more people.
The approach of the second type of company is much riskier. They are well aware that the world is changing and companies need to change with it. For them, People are the new gold, but with their own goals, fears, intentions, and abilities. Therefore, Increasing headcount leads to increasing points of failure. Scaling your product effectively in our realities without automating processes is simply not possible.
The statistics show that more and more people are choosing to embrace automation rather than fight it: DevOps market reached $10.9 billion in 2023 and is expected to reach $63.4 billion by 2032.
Main question
Why are more and more companies adopting DevOps methodology to automate their processes?
The answer lies in DevOps' ability to streamline operations, reduce operational costs, and improve product quality-essential for any business looking to scale via the fast iteration feedback in today's competitive landscape.
Automation is much simpler than it looks like at the first glance. The key is to let people know how the automation of processes works.
This article treats automation and DevOps as synonymous because automation is the heart of the DevOps methodology.
Approach (simplified):
The adoption of DevOps methodology (or automation) sustainably differs from greenfield and already existing projects. But it always starts from the business needs. The short flow chart for any automation transformations is:
1. The pre-phase
- What are we changing?
Identification of building blocks e.g. services, 3rd parties. - Where are we?
Depicting baseline. - Where are we going to be?
Drawing out the target where we going to be.
2. Planning phase
- How are we going to achieve?
Choosing the approach - how we going to lead the transformation process. - Split the transformation scope into independent epic tasks and documenting it.
3. Iterative implementation phase
Extended list of addressed questions during pre-phase
The pre-phase is getting answers for the questions:
- What business goal are we trying to achieve?
- What is the affected scope of people and enterprise processes?
- Where are we right now?
- What are the requirements?
- What are the constraints?
- What is the scope of work and terms?
- How we are going to measure the results?
The Measurements and State can address the bolded bullet points, the rest addressed questions and implementation flow will be the topics for the other articles.
State (Where are we right now?):
Where we are? There are 5 levels of DevOps maturity. But they are totally applicable at any of the business processes, from sales to the mining industry.
Level 1 Initial/Ad-Hoc:
When we understand where we have the biggest losses, the first thing we'll do is automate there. And then the initial automation has already been done: we have written some script, handmade tools, we have accelerated something, now we need to put this whole thing on centralized rails.
Level 2 Repeatable:
In order to achieve the second level, we need additional tools. Tools that will allow us to reproduce our automation, which will be uniform and repeatable for everyone. From the industry perspective it is like establishing the manufacture for making nails/hammers/wheels. In the software industry, for example, your team uses Kubernetes for container orchestration, CI/CD tools like GitLabCI or Bitbucket for code builds and deploys.
Level 3 Defined:
Now we have a repeatable process, but it is not fully standardized, and differs across the teams. Business example - one brigade mines ore with huge rocks, and the other provides fine-grained material. So the processing steps that we have defined in the business process start to be included in a single standardized form in our automation. That is, the assembly has taken place, the artifact with the code is automatically loaded, and then, just as automatically, the testing begins.
Level 4 Managed:
Non software industries familiar with this as a technological card or flow chart. The software business process is unified for all developers and preferably for all components of the product in order to get certainty and non-repeatability in the end. But if someone goes to change something, we will get divergence, i.e. deviation from the specified state. For these purposes, a managed state is used, when you clearly know what you have deployed at that moment .
At this stage, Infrastructure as Code (IaC) appears - a model, the basis of cloud computing and an integral part of DevOps. Infrastructure as code allows you to manage virtual machines at the program level. This eliminates the need for manual configuration and updates to individual hardware components. A single operator can deploy and manage one or 1,000 machines using the same set of code.
This phase also utilizes API mechanisms, which allow two software components to communicate with each other using a set of definitions and protocols. For example, a weather service software system contains daily weather data. The weather application on the phone "communicates" with this system through the API and displays daily weather updates on the phone.
Level 5 Optimized: The final level is optimization. Here we are fully immersed in DevOps practices, individualized for specific to your product. Operate with Continuous Improvement, meaning constantly automating and looking for ways to make our work better. And of course, it's important to take full advantage of Self-Service Capabilities, which is all about giving developers the tools to complete tasks on their own without waiting for someone else to help them.
Measurements (How we are going to measure the results):
There is a DORA metrics offered by Google for the DevOps methodology. We can simplify and generalize their suggestions.
1. Deployment Frequency:
It answers the question - how often does your team successfully release to production? The more often the better.
Deploy software to production environment is a change, therefore we may consider it as Change Frequency.
2. Lead Time for Changes:
How long does it take to go from commit to master to release to production - is that the change time? The shorter the better. We may translate it into a business language - How long it takes to apply the change.
3. Change Failure Rate:
The percentage of deployments causing a failure in production. The business may consider as the percent of failing changes against all changes
4. Time to Restore Service:
Time to Restore Service - how long it takes to recover from a bug in production. The less the better. The time needed to return to the state before change.
Afterword
From now, armed with the knowledge how to track the effect of actions, the company can assess the state of where it is, know what to need to be drow out, and what stage we are going to achieve
Automation is a natural process for any industry to standardize outcomes, streamline processes, and increase quality in accordance with business needs. The same processes will be created soon for genome reduction, AI development, molecular biology, or any other new branches of industry as it was for machinery and software/hardware engineering.