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 incurring financial losses due to unsustainable or unmanageable automation. Their approach is straightforward: old processes, well-known approaches, and hiring more people.
The approach of the second type of company is much riskier. They recognize that the world is changing, and companies need to change. Scaling your product effectively in our realities without automating processes is impossible.
The statistics show that more and more people are choosing to embrace automation rather than fight it: The DevOps market was valued at $10.9 bln in 2023 and could reach $63.4 bln by 2032.
Main question
Why do you think there has been an increase in the number of companies adopting the DevOps methodology to automate their processes?
Automation will always reduce operational costs while enhancing service delivery and quality of the end product. For any organization that wants to scale with fast iteration feedback, this is necessary in the current dynamic environment.
Adopting DevOps Approach (simplified):
Adopting 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 this?
Choosing the approach - how we are going to lead the transformation process. - Split the transformation scope into independent epic tasks and document it.
3. Iterative implementation phase
Extended list of addressed questions during pre-phase
The pre-phase is getting answers to 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 are we 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 are we? There are 5 levels of DevOps maturity. They are totally applicable to any business process, from sales to the mining industry.
Level 1. Initial/Ad-Hoc:
When we understand where we have the biggest losses, we'll first automate there. And then the initial automation has already been done: we have written scripts and handmade tools, we have accelerated specific processes, and 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 manufacturer for making nails/hammers/wheels. In the software industry, for example, your team uses Kubernetes for container orchestration and CI/CD tools like GitLab CI 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. For 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. 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 are 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. A managed state is used when you clearly know what you have deployed.
Infrastructure as Code (IaC) appears at this stage - 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 code set.
This stage also makes use of API technologies, which permit interaction between two software parts through a particular specification and interfacing system. Consider that a telephone has a weather service software system that stores daily weather data. The mobile weather application gets in touch with this service via the API and receives updates; thus, the application displays the weather for the day.
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 (CI), which means constantly automating and looking for ways to improve our work. And, of course, it's important to take full advantage of Self-Service Capabilities, which gives developers the tools to complete tasks independently without waiting for someone else to help them.
Measurements (How we are going to measure the results):
Google offers a DORA metric 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.
Deploying software to the production environment is a change. Therefore, we may consider it a change in 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 business language: How long does it take to apply the change?
3. Change Failure Rate:
The percentage of deployments causing a failure in production. The business may consider the percentage of failing changes against all changes
4. Time to Restore Service:
Time to Restore Service is the time it takes to recover from a bug in production. The less time, the better. It is the time needed to return to the state before change.
Afterword
From now on, armed with the knowledge of how to track the effect of actions, the company can assess the state of where it is, know what needs to be done, and what stage we are going to achieve
Automation is a natural process for any industry to standardize outcomes, streamline processes, and increase quality to business needs. Soon, the same processes will be created for genome reduction, AI development, molecular biology, or any other new branches of industry as they were for machinery and software/hardware engineering.
Hleb Skuratau
Juliya Moshkareva
Elizaveta Sokolova