February 25, 2013 at 17:0012 antipatterns of DevOps
- Transfer
From the translator. Continuing the series of translations about DevOps, this time I want to talk about how to DO NOT. We came across this every time something new comes up, like agile. There are cargo cults, hear speeches that we are special and we have everything wrong and so on. So let's try to avoid this in the case of DevOps.
So you want to become DevOps? Ok, but before you start, let's take a look at some things you shouldn't do.
In the good old days, we simply called them “bad ideas”, but diplomacy and political correctness appeared, the “brainstorming” went away and the “idea shower” appeared, and with it the word “anti-patterns”.
If the "pattern" is the right way, then in essence the "anti-pattern" is wrong - and therefore, to prevent you from going the wrong way, we have compiled this list (with a little help from the DevOps community).
Not really. It's a philosophy. This is a way of thinking. DevOps is supported by processes and tools. DevOps, according to Gene Kim , is based on 3 basic principles, known as the “Three Ways”.
The first way emphasizes the performance of the entire system - the value stream.
The second way is to reduce and speed up the feedback loop.
The third way is to create a culture that promotes ongoing learning and understanding.
( Read more about this in the translation of the article “11 Things You Need to Know About DevOps,” Part 2 and 1 )
If you ask this question, then you are probably working on some kind of agile process. Not bad. You have a software development process that follows DevOps values, but Agile does not mean that you have implemented DevOps.
DevOps transfers agile values to the administration department, allowing you to streamline the flow of tasks for administrators and letting this stream go further to the client, turning tasks into value for the end user.
CIO: "I want to upgrade to DevOps over the next year."
MGR: “Already done, we changed the signs on the doors of the departments this morning. We are so cool that now we have 2 DevOps teams. ”
Well super easy. And I'm sure you now have a lot of DevOps engineers. If you're lucky, they can sit next to you at dinner.
Go on. I beg you very much. Already? Well done! You have implemented DevOps. In fact, what you just did is create another silo. Now you got yourself another team that you need to try to integrate into the current process. Another team surrounded by walls that need to be broken. Maybe you should go back, rebrand and create 3 DevOps teams and become super cool?
DevOps does not mean that it is necessary to pull out several people from development and administration and pack them in a new team. You must accept and implement. Pour the development team into the administration team or vice versa. You need to completely destroy the barriers / walls / guards between the teams and form them into a single whole with common goals and responsibilities.
More details here
DevOps. This is a word that begins with "Dev." This means that development becomes more important because development comes first ... problems?
DevMgr - “Uh, we are doing DevOps right now. My guys have to learn how to work for production. ”
OpsMgr - “Uh ... alright. So who will be developing the code? “
The word DevOps is smart. It is derivative. This means that it is a combination of two words, in order to form a new word that gives a new meaning. It even has some effectiveness. This does not mean that we took the word operations and replaced it with the word development. So why don't you try and accept DevOps that way?
DevOps requires both groups to use their key skills. And they shared what should be common for collaboration. Find out what needs to be studied for improvement. This does not mean retraining. This does not mean cross-functional (however, this can be a positive side effect). This means providing feedback and transparency in order to improve.
If you think DevOps is just a buzzword, then you are probably using the “clouds” incorrectly. DevOps is like a medal to get.
DevOps is more than just a cool word. It's a state of mind. You must accept his values, you must help others to accept his values, and you must constantly improve yourself and help others improve in order to be successful. Once you drop all your ambition and start working together, you can make people think that “DevOps” can actually sound cool.
DevOps is like voodoo. In general, you get your team of developers and administrators working together. They smoke something and then sacrifice a chicken. Once you have done this, your organization will never be the same. You will be able to deliver software faster than ever before. The configuration will be self-managing. Your deployment tools will become intelligent. Your development and administration teams know harmony.
Get it ... DevOps is hard work! For most, this requires a cultural change! This is one of the most difficult things you have ever tried to achieve. For experienced developers and administrators with whom you are trying to do this, it will be the same as standing upside down. Do not try to do this in one night, otherwise fail.
Not! Hell no and no again. It shakes you with anger that you have to read it ...
Let me clarify 2 things.
DevOps is not development driven .
DevOps is not managed by administration.
If you want a development environment, well, go and create one. Just do not call it DevOps. Therefore, it is not.
Take a look at this article as an example .
“At DevOps, programmers are programmers.” - Exactly!
“In the same way, in DevOps, admins are admins.” - We're ready!
“Traditionally, the tasks of delivering software to a combat server are the responsibility of the administrators or development team.”
Wait a minute ...
“Administrators create deployment strategies to minimize downtime and provide stability through flexibility and responsiveness.”
Yes, we are back on familiar tracks ... and now bam!
Release Management through Development - WTF? The situation is getting worse:
“Release management through development takes a different path and considers how deployment can be done as often and as easily as possible. However, these deployments do not necessarily take place in production ... From the point of view of the process, continuous delivery has two big requirements: firstly, the process itself must be sustainable outside the development. This means that it must be stable, like any process that a traditional administration team can translate. "
Not. No. Non. Nej. Na Nee. Nein.
Development-driven can be a process. These are simply not DevOps. Replacing administrators with an automated deployment process is nonsense. Please do not try to repeat this at home!
Yes you are, yes you are my clever girl! But you are not so special that you cannot become DevOps. I bet you are the best developer there, the speed of your code is faster than the speed of light, and when other programmers see it, they cry with joy. Not? So, you are the most amazing Ops on the planet. If Chuck Norris were the administrator, he would be you. However, you and your organization do not have a single factor that will not allow you to implement DevOps. So let it happen to you!
Opscode's Jesse Robbins has some good tips for getting started:
Also useful for reading.
Well why are you hiring them? That is why - they are amazing! If you don’t think so, then you need to take a close look inside yourself, and then go and discover the real hidden talents in your team.
Someone told me recently that they could not do DevOps, because "they have the wrong developers and administrators ...". Is that they have developers who can not write code? I thought to myself: “My company has bad developers - people who do not know how to program, they work HR and marketing!”
DevOps promotes collaboration between development and administration. This cooperation should be developed at the policy level of the whole company.
And do not say that the “wrong” people work for you. You just don’t know how to cook them. Fight this.
OK, genius. You talked about ***. So what? We all do it. But now you want your admin guys to get out of bed at 2 a.m. to clean up what they know nothing about. They are admins, not “cleaners,” like Michael Clayton. To wait until an error occurs during deployment to start the interaction between developers and administrators is a complete crap.
It's too late for this problem ... but maybe not for the next one. You have a team of developers and admins who communicate (or swear at 2am) with each other, but at least they talk. Keep the dialogue constant. Get a retrospective overview of what happened and how you can fix it in the future. If you encounter this situation, then try to maintain a dialogue between the teams. Open communication channels between developers and administrators as early as possible. And then hope is not lost!
So you want to become DevOps? Ok, but before you start, let's take a look at some things you shouldn't do.
In the good old days, we simply called them “bad ideas”, but diplomacy and political correctness appeared, the “brainstorming” went away and the “idea shower” appeared, and with it the word “anti-patterns”.
If the "pattern" is the right way, then in essence the "anti-pattern" is wrong - and therefore, to prevent you from going the wrong way, we have compiled this list (with a little help from the DevOps community).
1. DevOps is a process
Not really. It's a philosophy. This is a way of thinking. DevOps is supported by processes and tools. DevOps, according to Gene Kim , is based on 3 basic principles, known as the “Three Ways”.
The first way emphasizes the performance of the entire system - the value stream.
The second way is to reduce and speed up the feedback loop.
The third way is to create a culture that promotes ongoing learning and understanding.
( Read more about this in the translation of the article “11 Things You Need to Know About DevOps,” Part 2 and 1 )
2. Agile is the same as DevOps?
If you ask this question, then you are probably working on some kind of agile process. Not bad. You have a software development process that follows DevOps values, but Agile does not mean that you have implemented DevOps.
DevOps transfers agile values to the administration department, allowing you to streamline the flow of tasks for administrators and letting this stream go further to the client, turning tasks into value for the end user.
3. Rename your team of admins / developers / anyone to DevOps
CIO: "I want to upgrade to DevOps over the next year."
MGR: “Already done, we changed the signs on the doors of the departments this morning. We are so cool that now we have 2 DevOps teams. ”
Well super easy. And I'm sure you now have a lot of DevOps engineers. If you're lucky, they can sit next to you at dinner.
4. Run a separate DevOps command
Go on. I beg you very much. Already? Well done! You have implemented DevOps. In fact, what you just did is create another silo. Now you got yourself another team that you need to try to integrate into the current process. Another team surrounded by walls that need to be broken. Maybe you should go back, rebrand and create 3 DevOps teams and become super cool?
DevOps does not mean that it is necessary to pull out several people from development and administration and pack them in a new team. You must accept and implement. Pour the development team into the administration team or vice versa. You need to completely destroy the barriers / walls / guards between the teams and form them into a single whole with common goals and responsibilities.
More details here
4. Hostile takeover
DevOps. This is a word that begins with "Dev." This means that development becomes more important because development comes first ... problems?
DevMgr - “Uh, we are doing DevOps right now. My guys have to learn how to work for production. ”
OpsMgr - “Uh ... alright. So who will be developing the code? “
The word DevOps is smart. It is derivative. This means that it is a combination of two words, in order to form a new word that gives a new meaning. It even has some effectiveness. This does not mean that we took the word operations and replaced it with the word development. So why don't you try and accept DevOps that way?
DevOps requires both groups to use their key skills. And they shared what should be common for collaboration. Find out what needs to be studied for improvement. This does not mean retraining. This does not mean cross-functional (however, this can be a positive side effect). This means providing feedback and transparency in order to improve.
6. DevOps is another buzzword
If you think DevOps is just a buzzword, then you are probably using the “clouds” incorrectly. DevOps is like a medal to get.
DevOps is more than just a cool word. It's a state of mind. You must accept his values, you must help others to accept his values, and you must constantly improve yourself and help others improve in order to be successful. Once you drop all your ambition and start working together, you can make people think that “DevOps” can actually sound cool.
7. Selling DevOps as a Silver Bullet
DevOps is like voodoo. In general, you get your team of developers and administrators working together. They smoke something and then sacrifice a chicken. Once you have done this, your organization will never be the same. You will be able to deliver software faster than ever before. The configuration will be self-managing. Your deployment tools will become intelligent. Your development and administration teams know harmony.
Get it ... DevOps is hard work! For most, this requires a cultural change! This is one of the most difficult things you have ever tried to achieve. For experienced developers and administrators with whom you are trying to do this, it will be the same as standing upside down. Do not try to do this in one night, otherwise fail.
8. DevOps means developers manage battle servers
Not! Hell no and no again. It shakes you with anger that you have to read it ...
9. DevOps is development-driven release management
Let me clarify 2 things.
DevOps is not development driven .
DevOps is not managed by administration.
If you want a development environment, well, go and create one. Just do not call it DevOps. Therefore, it is not.
Take a look at this article as an example .
“At DevOps, programmers are programmers.” - Exactly!
“In the same way, in DevOps, admins are admins.” - We're ready!
“Traditionally, the tasks of delivering software to a combat server are the responsibility of the administrators or development team.”
Wait a minute ...
“Administrators create deployment strategies to minimize downtime and provide stability through flexibility and responsiveness.”
Yes, we are back on familiar tracks ... and now bam!
Release Management through Development - WTF? The situation is getting worse:
“Release management through development takes a different path and considers how deployment can be done as often and as easily as possible. However, these deployments do not necessarily take place in production ... From the point of view of the process, continuous delivery has two big requirements: firstly, the process itself must be sustainable outside the development. This means that it must be stable, like any process that a traditional administration team can translate. "
Not. No. Non. Nej. Na Nee. Nein.
Development-driven can be a process. These are simply not DevOps. Replacing administrators with an automated deployment process is nonsense. Please do not try to repeat this at home!
10. We Can't Make DevOps - We Are Unique
Yes you are, yes you are my clever girl! But you are not so special that you cannot become DevOps. I bet you are the best developer there, the speed of your code is faster than the speed of light, and when other programmers see it, they cry with joy. Not? So, you are the most amazing Ops on the planet. If Chuck Norris were the administrator, he would be you. However, you and your organization do not have a single factor that will not allow you to implement DevOps. So let it happen to you!
Opscode's Jesse Robbins has some good tips for getting started:
- Start Small - Build Trust
- Create Champions
- Build trust
- Celebrate success
- Invent traditions
Also useful for reading.
11. We Can't Make DevOps - We Have Poor Employees
Well why are you hiring them? That is why - they are amazing! If you don’t think so, then you need to take a close look inside yourself, and then go and discover the real hidden talents in your team.
Someone told me recently that they could not do DevOps, because "they have the wrong developers and administrators ...". Is that they have developers who can not write code? I thought to myself: “My company has bad developers - people who do not know how to program, they work HR and marketing!”
DevOps promotes collaboration between development and administration. This cooperation should be developed at the policy level of the whole company.
And do not say that the “wrong” people work for you. You just don’t know how to cook them. Fight this.
12 Collaboration when r *** o hit the fan
OK, genius. You talked about ***. So what? We all do it. But now you want your admin guys to get out of bed at 2 a.m. to clean up what they know nothing about. They are admins, not “cleaners,” like Michael Clayton. To wait until an error occurs during deployment to start the interaction between developers and administrators is a complete crap.
It's too late for this problem ... but maybe not for the next one. You have a team of developers and admins who communicate (or swear at 2am) with each other, but at least they talk. Keep the dialogue constant. Get a retrospective overview of what happened and how you can fix it in the future. If you encounter this situation, then try to maintain a dialogue between the teams. Open communication channels between developers and administrators as early as possible. And then hope is not lost!