A conversation about the business value of DevOps

At Wise, we love friendly chats over coffee in our office kitchen. This morning routine always helps to tune up for a productive day and usually is accompanied by discussions on some trending topics. One day we had a small talk about the connection between DevOps and business, and this blog post is a continuation of that conversation. We decided to discuss the value DevOps can bring to business, and no one understands it better at Wise than our DevOps engineer Ihor Mozil.

Ihor has 12 years of background in system administration and now 5,5 years working as a DevOps engineer. Ihor’s ability to dive deeply into the problem and learn fast fascinates our team. His persistence helped him grow in his domain in immense steps. Ihor's tech knowledge is very broad, and his major expertise includes CI/CD pipelines, infrastructure, and system security. Also, among other Wisers, he is known for his hobby – Ihor constructs racing drones and flies them as well. He is a mentor at Wise Engineering School, takes an active part in our Tech Talks, and never gets tired of talking about his hobby.

This interview is not about building drones, which requires great system thinking by the way. Yet it will help you see how DevOps can help you fly your business better. Or, better to say, faster.

Specifying the nature of DevOps

Q. What system administration didn't give you that you headed towards DevOps eventually?

I. Automation would be the most critical, I suppose. When working as a system administrator, I always looked for opportunities to automate my work. All the repetitive tasks were eating up most of my time, and I always wanted to spare more of this resource for more complex issues. So I intuitively started to automate some processes already in system administration, and then the transfer to DevOps was very logical.

The ability to minimize human errors is the second reason. No matter how attentive or scrupulous you are, in routine processes that are complex, at the same time, the machine performs better, and the risk of an error is minimized.

Q. During the five years, did you get the moment that helped you reconsider the DevOps model? And what was it?

I. In fact, reconsideration and reevaluation are happening all the time, because, as a DevOps engineer, you get new experience continuously working with different projects. Within some projects, you have all the freedom to try new technologies and see their potential in practice. Some projects have extensive legacy parts that give you a lot of restrictions. Still, it makes you think twice harder and make up a working solution from all the minuses you have. This allows you to reconsider the overall process and introduce approaches that simplify complex issues or make these complex issues convenient for other people that work with you in a team.

I can't say this is a process of constant reconsideration of the DevOps approaches, but with time you get to see a more broad picture of how DevOps work influences business development, that’s for sure.

Q. Are there any myths or misinterpretations of DevOps you’d like to dispel?

I. The key idea to keep in mind is that DevOps is about the adoption of methods, best practices, and processes, and it is continuous in its nature. Thus, the first misinterpretation of DevOps I would address is that it's not about the tools your team uses. You can not say that by introducing a particular service, you’d have the DevOps processes arranged. This is not how it works.

DevOps strategy is based on setting up effective collaboration between people responsible for creating software and people whose work is to maintain it. Hence, a major task of a DevOps engineer is to streamline this process to help a business achieve goals faster.

“DevOps engineers are an integral part of the engineering team. Not a separate unit that works in a vacuum.”

Another important aspect is that DevOps engineers are an integral part of the engineering team. Not a separate unit that works in a vacuum. Only if DevOps engineers work closely with all the development team, they understand all the tech context and if they have a high-level business roadmap for at least a year, DevOps specialists can be most effective. If working separately, they can bring only more headaches to a project.

And finally, this comes from what I’ve mentioned above, one should never underestimate the soft skills a DevOps engineer should possess. Communication is vital in DevOps. I always speak of it during the DevOps mentorship program at Wise School. If you can not clearly communicate the value the change brings to the overall development process and the business, this change will never get approved and never happen eventually.

Last but not least, the DevOps methodology has a business focus at its core. And this is critical to understanding both for business owners and engineers themselves. All the optimizations that are about to be introduced face a particular business challenge, and help achieve business goals from both short- and long-term perspectives.

Business value driven by the DevOps team

Q. Let’s focus on this part – the business value that the DevOps model brings. If you had to think of one core thing, what would it be?

I. Faster time to market. This is the key task behind DevOps above anything else. Or better to say, everything that a DevOps engineer or a DevOps team strives to achieve is to make sure the software the engineering team builds is delivered to the customers ASAP and the management immediately starts to receive data on how it is performing.

“The specific appeal of DevOps is that business no longer has to trade speed for product stability, and vice versa.”

Hence, speeding up time to market should be at the core of any task a DevOps engineer receives and the key aspect a DevOps specialist should focus on when introducing any changes and optimizations. Most importantly, this applies to all – startups, more mature companies, and enterprises. By building a new product or modifying and improving the existing one, the main task is to bring this product or product updates to end-users as quickly as possible, at the same time not neglecting its stability, security, and quality. The specific appeal of DevOps is that business no longer has to trade speed for product stability, and vice versa.

Q. So there are multiple components of DevOps work that lead to shortening time to market. Can you name them more specifically?

I. First of all, DevOps creates and automates a pipeline of software shipping to a customer.

A specific pipeline is created that launches automatic tests after each commit, then automatically or manually deploys these changes to where they belong, assigns QAs to test them and sends it for product owner review, and, finally, deploys them to production. Exactly how long it takes for this process to complete defines time-to-market speed. DevOps engineers’ major task is to speed up this process as much as possible. Gone are the days when deploys were happening once in a quarter. Today engineering teams need to be able to deploy changes to production multiple times a week, if not a day or hour.

The other aspects that are in the DevOps competence and influence the business maneuverability include:

• Standardization and virtualizing infrastructure assets (servers, databases, testing environments).
• Monitoring and measuring system performance and health, minimizing downtimes.
• Fostering tighter collaboration between all tech teams and sharing resources across tech departments.
• Smooth integration and automation of low-value processes.
• Eliminating ineffective processes and cost optimization.

Q. What are the major business risks DevOps work should address?

1. Losing market competition

DevOps culture allows businesses, first of all, to win a race with competitors and get more market share in the long run. Because if several companies are operating in the same market, and one of them have all the processes streamlined, and the others need weeks or months to introduce changes, it’s clear who will end up as number one.

2. Lack of relevant analytics

Working on the crossing between technology and business, DevOps engineers can set up custom analytics that helps business stakeholders keep flexibility in business decisions and base them on data rather than predictions. Because with a streamlined software delivery pipeline, your customers get access to your product or its new functionality before the competitors, and as a decision-maker, you need to start gathering data faster and adjust the business roadmap accordingly.

3. System vulnerability

DevOps engineer analyzes the project for vulnerabilities and suggests the relevant permissions policy for everyone involved in product development. Personally, I practice forbidding access to everything right from the start and, then, granting only those access levels required for efficient work. No more, no less.

4. Lost profit

During the periods when your product or its parts were not available for customers, you lose money, and a business analyst will help you count the exact amount in no time. The efficient work of a DevOps engineer ensures that downtimes are minimized, and if any incidents happen, the work is done to prevent them in the future.

5. Lost opportunity

This is about system autoscaling and downscaling. In today's dynamic environment, you should be sure that if any load increase to your system happens, it can handle it, and once it is over, downscale back so you would not spend extra. Imagine that some celebrity shared a link to your website, and it went down due to the user high load. Would you get such a chance any time soon? Don’t think so.

Underestimated aspects of DevOps work

Q. You’ve mentioned previously the importance of communication between DevOps and the tech departments. How can it be arranged and how it may impact the overall teamwork?

For a DevOps engineer, offering a single solution and stating that this is the only solution and this is what we'll do is a faulty approach at its core. Setting up DevOps processes is about communication and finding win-win solutions for all teams, offices, and departments. Everyone involved.

If as a DevOps engineer, you work with multiple tech teams, you can gather all the tech leads to discuss the solution you are offering. Depending on the project or company size, the form of how you’d communicate will vary. In small teams, creating an RFC document would be good practice. It can contain a short problem description, its technical resolution, architecture, and possible solution. DevOps can share it in a communication channel, ask all counterparts to review the suggested solution and add their comments if this solution is relevant or what aspects are not taken into account. Then in the communication that comes after it, the win-win solution is born – a solution that would address a specific problem and specific business goals.

“Setting up DevOps processes is about communication and finding win-win solutions for all teams, offices, and departments.”

If the team is bigger the idea of communicating details remains the same, only a more complex document is created, based on it a meeting is set up where all the counterparts decide: what we are doing, why we are doing it, what are the benefits, what project part require modifications to get it implemented.

In situations when an incident happens, DevOps engineers’ soft skills matter the most. In such situations, it is critical not to find people to blame but to make sure all the aspects are examined, and all the necessary work is done so this won’t repeat in the future.

Overall, improved communication across tech teams that can be initiated by implementing the DevOps model leads to more motivated engineers and more productive teamwork. Moreover, the time that a DevOps engineer saves for the development team struggling with any routine inefficient processes can now be used to innovate and helps to take things off the engineering team’s plate.

Q. How can a business ensure that key information on DevOps settings is well-preserved and transferred when DevOps engineer rotation takes place?

I. This is a very extensive and urgent topic. I’ve made some notes on it for my future speech at Wise Tech Talks. But I’ll try to expalin briefly here.

Knowledge-sharing is a big and important aspect that DevOps methodology drives. DevOps engineer makes sure the project documentation, first of all, is written. This does not mean every single move should be described in detail. No. The documentation describes the project specifics on a higher level. So that every engineer that joins the project after reading it would understand how the system works, what system components are interdependent, how they communicate with each other, and that’s all. A good practice is when project documentation contains information on why particular approaches or technologies were not chosen, and why.

When the change in the DevOps team is taking place, Infrastructure as a code is one of the greatest practices that ensure the knowledge is transferred from one specialist to another efficiently. The process of managing and provisioning software infrastructure through code ensures that no settings are made manually. DevOps engineer writes code and via API of some cloud sets up infrastructure and its configurations, and develops the whole CI/CD process through code. When new engineers onboard a project, if they have efficient tech expertise, they will understand how everything works.

Because a DevOps engineer collaborates across tech teams and finds common ground for sharing knowledge, this specialist can also initiate some regular tech discussions, updates meetings, TWIL (This week I learned) initiatives, or other forms of knowledge sharing. The management team, then, can turn this initiative into some corporate training programs and help the company embrace the knowledge-sharing environment on a more global level.

New horizons for DevOps

Q. What are the biggest challenges DevOps engineers face today?

That depends on the project, I suppose. I’d speak of the projects I’ve been part of recently.

More and more these days, I come across tech problems that, at first, look very complex. And to solve them properly, you need to dive into business specifics. Such solutions usually require a lot of preparational work, examining similar cases, and finding unique solutions for the specific context by combining approaches that other teams already implemented. So the main challenge, DevOps tasks can not be divided from a business perspective and require a business context that is not always provided from the start.

As we’ve spoken already, DevOps practices can drive a lot of changes. The biggest challenge is to be able to communicate their value to the management and for the latter to understand how all these processes are interconnected. So, openness and efficient communication on different company levels are challenging. I am lucky to work with teams where I can initiate a lot of improvements, and it motivates me a lot.

“DevOps specialists become the ones who think about multiple aspects even if not asked to do it directly.”

Also, cool DevOps engineers do a lot of volunteer work today. What I mean is that dynamic teams that deal with startup projects can not afford to hire multiple specialists responsible for some deep tech expertise. Such people as DevSecOps engineers, site reliability engineers, FinOps experts, and more. DevOps specialists in such teams become the ones who think about multiple aspects even if not asked to do it directly. Because a DevOps engineer sees how the system operates as a whole and understands its weak and strong sides better. This results in a high workload for DevOps engineers and requires great stress resistance.

Q. Where is it all heading? Are there any trends that you observe?

With the numerous new DevOps branches such as DevSecOps, FinOps, GitOps, and others, more and more engineers will dive into narrow expertise. I see both benefits and disadvantages here. I still believe a good DevOps engineer should know a bit from everywhere and have some things that make up most of the tech expertise.

Another trend is the standardization of DevOps practices, frameworks, and approaches. I believe this is the major trend I observe these days. And Kubernetes plays the major role here. Of course, there won’t be a one-size-fits-all approach developed, but DevOps work will get more systematic and consistent across projects.

One more tendency that is changing the way businesses launch tech products is the emergence of low-code solutions that allow businesses to create tech products without hiring an engineering team. This applies only to some cases. But still, the rise of low-code solutions influences the market, and the way tech businesses start their journeys. What I mean, is that not every team should worry about the DevOps model from the start. This also helps companies to test business hypotheses faster, and this is great.

I also believe that no matter what the future holds for tech businesses, DevOps will continue to become more and more connected with a business perspective and, thus, will pivot a lot. The great thing about DevOps is that its maneuverability allows you to fly those routes that you thought were out of reach before. You just need the right team on board.