DevOps veteran Chris Bytaert, who pioneered DevOpsDays, shares his experience and his findings will surprise you.
Ten years ago, we suddenly took a trip. We brought together some of our good friends in Ghent (Belgium) to discuss Agile, open-source, and early cloud computing experiences. In 2009, John Allspow and Paul Hammond gave a talk at Velocity on "10+ Deployments a Day: Dev and Ops Collaboration at Flickr" (and a recording of this talk is worth watching). After seeing this talk, Patrick Debois decided to found DevOpsDays.
Is it true that the DevOps world has changed a lot over these 10 years? I have been attending DevOpsDays events since the inception of the conference, and during that time I have gained significant experience. In this post, I will share 10 tutorials that might also be helpful to you.
1. There is no such thing as a DevOps engineer
Many teams have a person with the title of “DevOps Engineer”, and not all specialists like this title. This profession name gives the false impression that DevOps is a job that can be done by one person. More often than not, a DevOps engineer is a Linux engineer who, with some luck, can solve automation problems. When recruiters start looking for a DevOps engineer, job seekers should ask themselves the right questions: “What does the company really want from the job seeker? Are they looking for an assembly engineer? Senora who understands non-functional requirements? A specialist in the operations department, capable of dealing with automation or someone else? " Most often, companies are looking for a specialist who will distract the rest of the employees from not meeting the practical principles and requirements of Agile.
In organizations with large DevOps departments, as a rule, no one is involved in DevOps. The word "DevOps" only speaks of separation from the rest of the team, and the applicant can get a good salary and learn new skills at work, but he will not "do DevOps".
2. DevOps teams don't exist
We've often said in the past that the goal of DevOps is to eliminate confusion between different teams. In particular, between developers and employees of the operational departments. However, recently we have encountered a new phenomenon - the emergence of many DevOps teams.
Building a DevOps team sounds like a new practice, but there are obvious contradictions here. In one organization, this team will deal with development tools, in another, it is literally a wall between the development team and the operations specialists. The problem is that this wall creates confusion, frustration and reduces the level of useful interaction. The team that is called "DevOps" at best solves a variety of problems and has some responsibility for the services with which they work. Usually professional teams prefer not to have the word "DevOps" in their name.
In my experience, having the word “DevOps” in a team name is likely to hinder the achievement of the desired results.
3. DevOps projects do not exist
All projects are finite. You develop, deploy your solution, and move on. Also, over the past 10 years, there has been talk that DevOps is continuous improvement, and continuous improvement is endless. In turn, the result of your projects are long-running services, and the service implies the sequence "Development -> Deployment -> Health support"
It’s only after we look at services outside of projects that we can see aspects that are easily forgotten: non-functional requirements. Non-functional requirements include functionality that does not fit into specific behavior. These requirements also determine our assessment of the system's performance. These requirements often include aspects that are classified as DevOps: reliability, usability, maintainability, and scalability. All of these characteristics are important for achieving business results.
When working with short-term projects, there is a risk that you will not pay enough attention to this work. When you move on to the next project, you will no longer think about the non-functional requirements of the previous one, since you will take up new challenges, and the rest of the problems will no longer bother you. In turn, when managing a service, you really get into the work, and it is in your best interest to polish everything so that everything runs smoothly.
4. DevOps tools don't exist
While many vendors will try to sell you a variety of tools, including one that will solve all your problems, DevOps is not about tools. DevOps is about people and their interactions. Some tools really help people collaborate. Often times, tools can help people from different backgrounds share the same terminology and ecosystems. Yet just as often, tools get in the way of effective communication.
A tool-based culture can isolate people rather than help them interact. The fact is that people become obsessed with their toolchain and move away from those who do not use it. While certain tools can be very useful from a technical point of view, a number of new tools (conventionally referred to as DevOps) have widened the rift between different groups. For example, I often hear the phrase “this works in my container”. Developers use this phrase to indicate that "their" work is done. Containers by themselves do not solve the interoperability problems associated with running applications efficiently. We cannot allow tools to distance us from each other.
5. There is no certification in DevOps
No multiple choice test can confirm that you are capable of effectively interacting with colleagues. Organizations offering certification may have incredible technical expertise (and even effective communication), but certification cannot show that someone is good at DevOps.
Unfortunately, management teams require certifications in an area that is difficult to certify. Be educated in your favorite software and hardware, and explore the cloud. Study at a local university, read books from which you can learn a lot, in particular, books by Deming , Forsgren , Humble and many others... But don't expect to be the best at DevOps once you get certified. Interacting with colleagues is much more important.
6. DevOps pipeline doesn't exist
"Has DevOps already worked?" "The DevOps pipeline is working." "The DevOps pipeline is broken." Whenever I hear these statements, I’m surprised that we came up with this terminology. Did we rebrand the deployment pipeline, or is it that in some companies DevOps teams are working on this infrastructure? Or maybe it is because developers are calling operating team if the pipeline is broken?
Despite the immense importance of CI / CD technologies, I am skeptical about the use of the term "DevOps pipeline". If the development pipeline breaks, then the operations team is to blame. Developers don't think about the pipeline while they write tests. The concept itself is also misleading. Pipelines are created for each service or application separately, rather than across the entire DevOps domain. By creating generic pipelines, we run the risk of increasing the gap between teams, and this is not at all the goal of DevOps.
I recommend using a technique I've seen in hundreds of organizations around the world: refer to each individual pipeline as an Application X pipeline. This terminology will make it easier to know which application is having problems when testing, deploying, or upgrading. We will also know which team will be working on the fixes in Appendix X (possibly with the help of friends from the operations team).
7. DevOps has no standards
The hardest of the thousands of DevOps stories is standardization. In the same way that we cannot certify people, there is no one size fits all standard in DevOps. Every organization has its own path, and these paths can be very different. There is no magic recipe that lists the tools and describes the methods for creating automation flows that will suddenly become DevOps in your organization.
The standard in DevOps means that you apply a specific methodology that will allow your organization to start collaborating and move away from office politics.It should also improve the quality of work, increase morale and allow you to achieve better results with fewer disruptions.
DevOps should be understood as a set of practices similar to the methodologyITIL . Remember that the L in ITIL stands for Library. And this library should be taken not as a guide to action, but as a list of best practices, from which you need to choose the most applicable for you. ITIL was hated precisely because of unsuccessful implementations, in which the library was used precisely as a step-by-step instruction. Standardization in DevOps will lead to the same results.
8. There is no such thing as DevSecOps
We started DevOpsDays in 2009 and this conference was open to everyone. Of course, initially it was an event for developers and employees of operational teams, but everyone came to us: database administrators, testers, business analysts, financiers, and, of course, security specialists. Back in 2012, we spoke at OWASP meetings talking about what we did. We joked that the “S” in DevOps stands for security, just like the “S” in HTTPS.
DevOps is about security at its core. I have found that CD principles are best suited to security teams. CD is a security requirement: you must be able to deploy at any time, this will give you the ability to deploy and implement the updates required by business or security concerns.
On the one hand, it's sad that we have to come up with words to include people in charge of security. On the other hand, it's good that we discussed this again. Basically, there is no difference between DevSecOps and DevOps. Safety has always been a part of development and operations. I can use the term DevSecOps for this, but it's better to just use the term DevOps.
9. You can't take and switch to DevOps
Have you ever met a company that makes a statement like “We are doing a DevOps project in the fourth quarter of this year, and next year we will move to DevOps completely”, which really succeeded? So I have not met.
Software delivery never stops, technology always changes, it always needs support, and (ideally) the approach and attitude towards DevOps should remain the same. Once you refine your delivery approach, you will want to improve further. Not because all the functionality of your application has been implemented or because the ecosystem in which it lives has stopped developing. You will want to continue to develop because the quality of your work is growing exponentially, and at the same time the quality of life is growing. DevOps will continue to evolve even after some task gets the Completed status.
10. There is such a thing as Dev-oops
Unfortunately, many people do not understand the importance of collaboration. They build walls between teams, believe that tools are more important than practices, require certification of everything and everyone. They also believe that all 9 previous statements are incorrect. And these people will forever struggle to succeed in what I call Dev-Oops.
DevOps is about thinking tools and team separation are more important than true DevOps principles that can improve your work. Let's strive to do DevOps, not DevOops.
the main objective
We have been running DevOpsDays for 10 years, and during this time thousands of people have learned a lot of interesting things from each other in an easy and open environment. Some of the concepts that I find conflicting with the goals of DevOps and agile are popular. Focus on getting your services to help your company and don't stop learning. And it's not about copying tools and implementing them in your organization. It's about focusing on continuous improvement in every way.
Learn more about how to get a high-profile profession from scratch or Level Up in skills and salary by taking SkillFactory's paid online courses:
- DevOps course (12 months)
More courses
- - (8 )
- UX- (9 )
- Web- (7 )
- Machine Learning (12 )
- Data Science (12 )
- (9 )
- «Python -» (9 )