The concept of DevOps dates back to 2009, yet it remains a hot topic. Everybody wants a DevOps engineer in their company. People talk about DevOps practices and implement them into their processes. Still, many developers, when engaged in private conversation, say that DevOps does not work, does not help, and makes their job more complicated and even annoying.
Is there a reason why DevOps keeps proving its efficiency in some companies, while becoming a nuisance in others? Let’s dive into the issue and find out.
Contents
- What makes DevOps tick
- Top 10 common mistakes of practicing DevOps
- Using Scrum as the micromanaging tool
- Not using the united runtime environment
- Testing only “the happy path” and “the clean data”
- Overtesting
- Making the DevOps engineer a bottleneck
- Introducing “DevOps” without implementing Agile
- Ignoring the security
- Making your teams work on different goals
- Working with the generic tools only
- Making DevOps a routine without a purpose
- The biggest mistake - not utilizing DevOps
What makes DevOps tick
To discover why DevOps does work, let us explore the cases where it does not. It is easy to find many opinions about DevOps inefficiency, including these:
When you read these opinions, you always find one common point: “What we work with is not DevOps, but an imitation.” This often happens when managers treat DevOps as a universal guide or even a ritual with no substance, rather than the philosophy or set of practices needed to be adjusted for different tasks.
Every story about failed DevOps implementation usually involves decisions, where management does not really know what DevOps is or its goals before they start introducing it to the company’s software development workflow.
This means we need a clear understanding of what DevOps is before finding out why it does not work in some cases. In BellSoft, we like the definition of Donovan Brown, a Partner program manager at the Azure CTO incubations team at Microsoft and a speaker at our own JRush conference. Donovan says that DevOps is the union of people, processes, and products to enable a continuous delivery of value to end-users. And the emphasis on “continuous” and “value” is the essential part.
When working on implementing DevOps practices, managers sometimes forget the end goal, which is to deliver a valuable product. It all goes downhill from there. Developers lose themselves in the endless cycle of updates and software releases that do not make the customers happy. With every new version, the product devolves.
So if there is one thing you take away from this article, it should be this 一 remember the end goal and implement the practices with this goal in mind! There is no single universal approach to DevOps that will work for every company. Invent your own processes, do not stick to the formal guidelines. Be creative, and always remember to bring a valuable product to your customers.
Let us discuss the common mistakes developers still make in 2021 when implementing DevOps. Or contact our engineers and let them share their experience of DevOps in the world of Java development.
Top 10 common mistakes of practicing DevOps
Using Scrum as the micromanaging tool
Scrum is an excellent practice for automation, one of the most important aspects of a successful DevOps routine. And yet, administrators tend to use it as the micromanaging tool, implementing only some values of Scrum while ignoring the others. Remember these values are not only Commitment and Focus, but also Openness, Respect, and Courage, and they only work together!
If your Daily Scrum (which should be a 15 minute event) turns into an hour-long meeting, you are doing something wrong. If someone outside the Dev team decides who should work on which tasks, it is not Scrum. If Sprint reviews do not lead to future adaptations, then they are useless.
If you only utilize Scrum to put your team into time brackets, you better avoid working with it at all.
Not using the united runtime environment
“It worked on my computer” is a phrase no one wants to hear, and to avoid hearing it, consider utilizing a unified runtime that works great on desktops, servers, clouds, embedded devices, and so on. This decision will immediately help in dealing with security, deployment, and testing issues.
Furthermore, as the DevOps practices include a lot of testing and may require different kinds of deploying, including Github, repositories, and others, using unified runtime helps organize the smooth workflow. Applying security patches also becomes much easier.
Last, but not least, runtime like Liberica JDK has many additional advantages, like convenient control application and utilities to create better containers, microservices, and native images.
To find out more about our unified runtime environment please download the white paper on Liberica JDK.
Testing only “the happy path” and “the clean data”
When you test your app functioning only the way it is supposed to work, you are in for some trouble in the near future. Spend some time to try every possible way the user can interact with your software, because you can never predict their actions.
Also, remember, it is likely your software will have to work with “dirty data” generated by some script and should be able to handle it.
Overtesting
The other side of the coin is that you can overtest. Indeed, it is nice to be overprotected, but time and resources are not infinite. A good approach for testing software is to figure out how much failure is tolerable in your system and work towards reaching that point. Of course, it depends on what kind of software you develop. In our case, we build Java runtime, so we cannot afford to leave a vulnerability because it will influence other people’s work. That is why our testing is done with a goal to reach top-notch security. And depending on the kind of software you create, think about important parts and test them to reach that tolerable level of failure. If you over-test, you risk losing the momentum the DevOps approach is trying to achieve.
Making the DevOps engineer a bottleneck
One of the goals of DevOps is to eliminate the bottleneck between code commitment and deployment, accelerating software delivery speed. But in case you just put a person in charge, name him or her “a DevOps” and ask to control the workflow manually, you are just adding another bottleneck to those already existing. The goal is to build a bridge between Engineering and Operations, not a wall with a small gate.
If you do not automate the processes, your “DevOps guys” will only make it worse. And there are a lot of cases when good specialists were hired with the right goal in mind but faced challenges, when they tried to change the workflow. They met resistance from the management, who wanted a faster release cycle and nothing else. The result was a disaster.
Introducing “DevOps” without implementing Agile
DevOps allows bringing development and operations teams together to ensure continuous delivery. Agile is based on collaboration between customers and the development team to build a high-quality product. Although these approaches are focused on different aspects of production, they can work towards the common goal of speed and quality of releases.
When you try to put out the bad product faster, you still get a bad product. And DevOps practices will only ensure it stays bad. You need to create good software before you try to ship it.
So do not implement DevOps before your product actually works.
Ignoring the security
Security is one of the most important selling points on the market, and DevOps is the right tool to reach it. New vulnerabilities are discovered constantly, and the modern way to deal with them are regular updates of your software, reliable support, and security patches. According to DevOps Institute, DevSecOps is a crucial trend with a must-have percentage vote of 56 percent in the automation tool category.
If you do not work on the security of your apps and user data, you will surely make the front pages, just not in the way you would like.
Making your teams work on different goals
The issue of the internal competition between different teams in one company does not only happen in the software development industry, but is especially common in it. The goal of DevOps is to link Operations and Development, but when one division is tasked with reaching one goal and the other one with another, you cannot expect them to work together.
You have to build an evaluation system where you motivate teams and people to communicate and collaborate to reach the same objectives. Suppose Operations are awarded only for releasing a product as fast as possible, but Developers are simultaneously punished when they do not have time to implement many features. How can you not make these teams enemies?
Working with the generic tools only
It is tempting to try to copy other people’s successful approaches when planning your DevOps strategy. “If it works for them, then surely it will work for me as well, right?”
Sorry, but no.
Remember, one of the common principles of DevOps work is “Experimentation is extremely important, resulting in challenging questions and continuous improvement.” That also means that you need to spend some time choosing the tools that fit your own tasks and requirements, your people, and your plans, not a generic “ideal DevOps strategy.”
It is easy to fall into the trap of working with the “default” tools. For example, in many large companies, every Software Development Kit used in development must be approved by management before it even appears in the list of choices. Please do not settle for that! Find the utilities and practices you know will help, and make sure they are used not only for prototyping, but for actual production. Your developers and managers will thank you later.
Making DevOps a routine without a purpose
People do not like innovations, especially in their workflow, because “if it ain’t broke, don’t fix it.” The problem is, even when new methods are introduced and become a part of the routine, they can become just another formality or a ritual without a purpose.
DevOps practices can also fall into this trap. To avoid it, remember:
- You need to know what your goal is and how you want to reach it with DevOps;
- The team members need to understand these goals as well. Explain all the changes as much as needed, listen to the feedback, make some adjustments if it does not work;
- Encourage communication between the teams;
- Focus on automating the processes, tools, and testing;
- Remember, tools are nothing without DevOps practices.
If you ignore these steps, you may find your software development team imitating the DevOps approach without actually benefiting from it.
The biggest mistake 一 not utilizing DevOps
There are challenges in introducing the DevOps philosophy into your company, including those described earlier. However, that does not mean you should not do it because your competitors are doing it. When implemented the right way, DevOps becomes a working tool that can revolutionize your software development, shorten development cycles, increase deployment frequency, code efficiency, and help you reach your goals. The DevOps statistics of 2021 show that this approach is not just alive and kicking, it also keeps opening new possibilities for software developers worldwide.
So learn to respect and love DevOps to make it love you back!
The article was inspired by presentations made by Donovan Brown and Heidi Waterhouse at JRush in September, where they explained how to boost DevOps practices and enhance CI/CD pipeline at a company. Head over to the JRush page to listen to full presentations.
