By
·
4 minute read
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 losing money 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 know that the world is changing, and companies need to change. 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 impossible.
The statistics show that more and more people are choosing to embrace automation rather than fight it: The 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. This is essential for any business looking to scale via fast iteration feedback in today's competitive landscape.
Automation is much simpler than it appears at first glance. The key is to explain how process automation works.
This article treats automation and DevOps as synonymous because automation is the heart of the DevOps methodology.
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 some scripts and handmade tools, we have accelerated something, 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 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. 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 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 phone's weather application "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, 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.