Julien Pivotto
Transcript
So I will give you a talk about DevOps, but my guess is that for many of you, all of this stuff won't be new, maybe some of them, but a lot of people are already doing it, so without knowing the name, without wanting to just say, oh, I'm doing DevOps stuff, no, you just do it, and that's really great. So where am I?
So my name is Jean-Pierre Vautour, I am a consultant at Inuit.
I defend the open source software since 2004. And since I started working, I've always been a DevOps evangelist and believer.
And you can find me on Twitter and GitHub also. So InWits, let's make a small introduction. So InWits is a Belgian company, but we are in four different countries, Belgium, the Netherlands, Ukraine, and Czech Republic. And we are 50 people. We have customers from all Europe. And we do both development and operation of open source softwares. We have a lot of customers including small, large enterprises, banks, so we see a lot of different structures, a lot of different IT people, a lot of different customer from all the different areas you can see. But let's go back to what we are here for, so DevOps.
Yeah, what is DevOps? Did you hear about it? Probably yes. It means a lot of things to a lot of people, a lot of different things.
And I will try to show you what is our vision, the vision of the people that have created the movement.
So let's go with a traditional dev shop, which we are in an agile conference, so I might expect that this is no longer the case already in your different companies. At least I hope for you. But in traditional dev shops, Friday, 5 p.m. It was a turbo, put this code life, no. Because we are on national TV in 20 minutes. So the other, and that's, That still happens in a lot of different environments and even in some agile environments when you develop your product, but when it's developed, when your code is maybe tested, it's ready, but the final step is just not doable like that. It's just too complicated. And on the other side,
You have the operators. Yeah, they ask, okay, what are the dependencies, the databases? They ask a lot of different questions that are relevant for them, but that a lot of developers just didn't know about, they didn't think about, because yeah, it works on their machine. What GDK do they need to use? Well, the GDK on their machine is just working. And then after a tight dance in production, everything explodes. And no one has any idea of why. Why it's not working, why it's not reachable. And they start to do finger pointing, like, okay, this is because of the ops team. They did not put the monitoring on that stuff. And the devs say, okay, yeah, so it's not our deal. And then the operators say, okay, we didn't know that we needed to monitor that. SQL database or that really is a database. So what is really happening behind the scenes?
So what are the different people paid for? So the devs and the ops.
What are the objectives of each one?
Well, the developers are paid to make new features. On the other side, the operators are paid to get more stability so that the application is always stable.
The developers want to make new releases. They want to achieve their goals to implement new features. While the ops take care about the availability of the apps. So the application must be available 7 of 7, 24 hour and 24 hour.
The developer needs to be able to respond to changes, like in the Azure Manifesto. So they want to be able to quickly develop, to quickly test. But on the other side, the operators, they do care about security. So they just don't want you to go to the database and to update your own dump or to do anything like that.
They are working in different silos and they don't speak to each other. So what's happening is that they have different goals. They don't want the same stuff at that moment and it's a bit
It's, you cannot understand that because what is the goal of both of them is that they get paid and they just put the application in production and that it works. But if you're agile, if you are agile in only one silo, if only the developers are agile and it stops there, then you have a problem. You will have problems.
But if we take a closer look, then the developers, they also do sysadmin work because they test their product, they do some database work, they do small deployments on their laptop. And the ops, they also do some kind of development. So maybe they do some batch of Python scripting, do some infrastructure as code, they do some monitoring scripts, so they are not so... It's still different jobs, but they kind of do sometimes the same stuff. But the reality is that IT is evolving.
You get more velocity.
There are some buzzwords like the cloud, the containers. All of that is changing a lot. You have volatile environments. You can have 10 VMs today, 20 tomorrow.
You need to be scalable. There is a global market now, so you don't have only users from 9 to 5. You have users at any moment of the day, of the night, that are coming from any countries. So you need to take care about availability. And there is no space for the old teams, for the people that work in their side, and I do not care of the rest.
So that is what DevOps is. It's just getting the developers and the operators working together. It's nothing more than that. It's going back to the basis and just put everyone in the same group and
There is a lot of people that have been thinking and doing that for like more than 10 years. They were just doing it on their company. And then they decided that they needed to spread the word to everyone. None would know about that, about what they are doing, because fundamentally, IT was broken. There were a lot of silos all around the world, and in every company, it was just not working. So they decided to make a first conference in 2009 in Ghent. And this year, in 2014, there was the five-year of DevOps Days. So it was a conference with, there were 60 people at the beginning, but then there will be dozens of events, including one in Paris in 2013. And people came and they just shared their experience. They make some experiments. And the DevOps days were like that. So in the morning you get conferences with speakers that come from a lot of different backgrounds. And in the afternoon you get open spaces. What you get is what you bring. So if you want to participate in an open space, you just go, you discuss. And then if you don't want it, then you can just go out. And it means that people need to be involved. Because if you are not involved, then you just spend your money in the conferences, maybe by sleeping or doing anything else. But in the afternoon, if you don't participate, you will just sit on a chair and just do nothing. And that will be very boring. So DevOps Days is also about involving people. And there are some big companies that also They organize their own DevOps, they are private even, because they have a large team, they have maybe 200 people that work together and they want to improve the workflow, so they They don't want to be part of an external DevOps because they already have a lot of different people with a lot of problems. And what they wanted is just be able to talk without having leaks, so they can speak freely about the real problems, talking about servers, about the real business. If you were in the banking world, for example, you cannot speak about what you want. So some big companies did that. They have their internal DevOps days, and it works pretty well. So DevOps is a cultural and professional movement. So the both aspects are important. So it's not only about professionals, it's not only about the culture, it's really the both worlds.
So, the ROPSIS is split in four main different topics. First of all, the culture, the automation, the measurement, and the sharing.
And that's what John Willis and Damon Ewers wrote down on the DevOps Cafe. So because at the beginning they were just speaking about DevOps, but there is no clear definition. Everyone just came by and explained its own stuff, but at a certain moment they needed kind of a definition or an explanation so they can Get more people involved, more people interested. But what can DevOps bring you?
Well, the first, it will bring you a faster time to market, which is really important, which is really a key value. But also some reliability of your infrastructure that you don't have when you are not aware of what's happening. So it will get you a clear view of what's happening and when. And it will also bring you some trust between the different people that are working on your projects.
But let's go first for the cultural part.
So a traditional IT company will still have that. And a lot of companies have that because of legacy or because it needs to be like that, so they have different silos. In this silo, you have the developers, then the operators, and then you might have other silos like the QA team or the test team or the monitoring team even, and you can still have more silos. And the problem with the silos is that people cannot talk between the different silos because they are in a team and sometimes they need to talk with the manager first. But it's not like that that it will work. It's not the way IT works. So the first thing you will need to do, or it will not be done in one day, of course, but you need to burn the silos. And why do you need to burn the silos? Because you only want one team. One team that will have people that have different skills. So developments, integration, testing, infrastructure, monitoring, all of that needs to be in just one team. And why do we want only one team? Because we want a team with only one goal. Helping the business.
that the people need to understand that they have the same interest in having the application up and running and getting new features in production as soon as possible. So they can get paid by the company and the company can just sell his products and so earn money to pay the developers and the operators and all the other person in the teams. So that's the goal of the team is just helping the business. How do you do that?
Well first you will need to enable the communication.
It means no closed offices. Well, ideally, you will mix open spaces and offices, but people need to sit together to be able to just take their two feet and just go to someone else asking a question. But you also need to do stand-ups. If you are in the agile world, then you already know that. But what is different here is that you need to involve your operational people in this meetup, in this stand-up, because they need to know what's happening, what's coming. If you are planning to develop a new feature that will imply a new database or that you will make 10 times more reading into your database, then the operational people need to know that in front.
People need to communicate using mails, chat, any other stuff, because we are in a world where a lot of teams are spread all around the world, like you have developers in one country and then testers in another country, maybe the QA team in a third country, and then it's really like hell to do the communication.
What brings you to the last point. One language to hold them all. Because, yeah, sometimes I go to a customer and then, yeah, all the documentation is in Dutch and I don't speak a word in Dutch. What can possibly happen then? So you need one language. If you, even in the informal,
Even in the mails, for example, because a mail can be forwarded. You need to insist that people always speak the same language. A world where a lot of teams are spread all around the world, like you have developers in one country and then testers in another country, maybe the QA team in a third country, and then it's really become like a hell to do the communication. What brings you to the last point?
One language to hold them all. Because, yeah, sometimes I go to a customer and then, yeah, all the documentation is in Dutch and I don't speak a word in Dutch. What can possibly happen then? So you need one language. If you, even in the informal, even in the mails, for example, because the mail can be forwarded, you need to insist that people always speak the same language.
And then you need to build the trust.
So now you have people that communicate, you have operation people involved in the different stand-ups, but you will need to build the trust. So you will need to do experimentation. When there is a success, you will need to measure it. The same for the failures. You need to automate all the things that we will see later. And that will come up with some kind of trust between people because the operators will know upfront that the developers know what they are doing and the developers know that the operators don't want the same thing as them. So they need just, well, to play together.
Because when you are alone, you can still play a lot, but when you have two different people, then you have more ideas, more creativity, and you can take different approaches. Sorry, what are you doing this like that? I would preferably do it in another way. Why are you taking that database? I would prefer to use that one because it will best fit our requirements in stability and stuff like that.
It's also more fun and more comprehension between the different people. Because if you only see the other, if you only see the operators when there is a problem, or if the developers only see the manager when there is a problem, then you only have conflicts with your team. But if you start playing together, making experimentation, then you will also be more comprehensive and get more empathy between the different people. And that will allow you to build trust between people.
Then you need to share the responsibility. So who is responsible for that application? Oh, but it's the ops guys because they do the monitoring, but who is responsible for the monitoring? Oh, but that monitoring, we were thinking that it was, no, everyone is responsible. If you see a problem, you just say, okay, I think at last place we have a problem and you, You put maybe everyone on call if it's needed. And I say, everyone is just everyone, even the managers. Why do you want to put the managers on call? Well, it's easy.
If it gets rigged up every night at 3 p.m. Because there is a problem of infrastructure, or if every hour you get an SMS because this is a false positive, then things will move.
You know the phenomenon of alert fatigue is when you get a lot of mail for your alerting system that are just nothing because it's not impacting the production. What you need to do is to involve everyone. So if you involve the managers, then they will help you to fix the problems. They will put you some time to do that.
There will be less finger pointing also because you will not try to figure out, oh, who did that? Yeah, who do I need to blame? No, you will just fix the different issues.
But you can only do that if you give access to people. So you don't want to block people. They just need to be able to do what they need to do.
So if someone needs to be able to read some logs, then just give it access to the logs. It does not mean that anyone needs to have access to the production database, no. But if you need something and that's relevant, then you should be able to just do it without asking permission. Because do you let a blind person paint your home? So if a developer will deploy a big application in my environment, I want to know that he can, he know what he's doing, he know what impact it will be, and that it will get a view of his application because yeah, there is a lot of different problems in the infrastructure that you can see before they happen. And if people don't have access to the information, then they just cannot, they just can't do anything relevant for you.
Another concept of agilis, the definition of done. Yeah, but what is the definition of done?
A software project is not done until your last end user is dead. There will always be maintenance, there will always be security fixes. So you cannot just say, okay, the project is done now. No, because there are still people that are using it and they might need your help on that.
So the definition of DOM is a bit different here.
So that was all the cultural part. There are a lot of other stuff there, but I will stop at that point and attack the second way. So the automation, which is something that is well known in the Agile world, but it's not, it's worth it to just get a review of that. So what do we want to do?
All the things.
You want to have builds and a reproducible build, just not a developer that runs make or anything and that ships a binary to a server or even by mail.
You need to have a build on a build server that anyone can see, anyone can see the logs, anyone can see the artifacts. And the build needs to be robust.
And it must be done on the environment that will look like the production.
Because if you build with JDK 8 or JDK 7 and the production is another version, then it will probably break.
And if you have that build that is reproducible, then you have no work. Oh, it works on my machine. I don't know. You may be wrong in production because I don't know how you deployed it, but for me it works. So it's your problem. The test also needs to be automated as far as possible. So you can gain trust into your own code. And the deployment also needs to be automated. There are a lot of tools to do that, to do the deployment, the testing and stuff like that in an automated way so that anyone can see the logs, anyone can see the process you use, and all the team can be involved in writing new tests, writing new deploy features. But to do that,
you need to get more confident with your code. That's why you want to automate your builds. That's why you want testing. That's why you want a lot of difference. That's just to get more confident in your code that you are not afraid to put it in production because you will know that it will not break anything because you have enough tests.
So the test automation, what can you test? Well, you can do style check, syntax check, regression tests, compatibility tests, LNRM, Cucumber, test-driven development. So you have different approaches to do the testing. And the more testing you will do, the more mature your testing will be, then the more confident you will be. to just deploy the more often possible.
So DevOps implies continuous delivery.
But for some people, continuous delivery implies DevOps. It's not my case, but for some people, DevOps is just continuous delivery. So if you do continuous delivery, then you are just doing DevOps. And they completely forgot the cultural part that we really like about DevOps.
Then the next question, how many can deploy today? Well, I would say it's not a contest. It's not because you deploy 10 times a day that you do it right. So it's not a contest, but yeah, it's something that matters.
So you have multiple principles that will allow you to do that.
So the first one is a continuous integration. So everyone works in the same branch, in the same git branch. You merge as soon as possible, and then you run the test, you deploy the code into an infrastructure development environment, you test it, you do performance tests, integration tests, upgrade tests.
And that environment, that development environment you will be the continuous integration on, should be the same as the production environment, ideally. And that will bring you some more confidence that you will say, okay, I have at least tested my code once. And then you can do one step. Step further, once you have integrated your test into a special environment, then you can deliver it or deploy it. So the continuous delivery and continuous deployment, it's not the same stuff, I will show you the difference, but it is the next step. It's just, now I have automated a lot of different stuff and now I will just deploy that, deliver that. The first step is the delivery. The delivery means that when you commit, you have a build, you have an artifact, you have a way to deploy what you just pushed. And that code is always in a good state because if the integration test has failed, then you did not make that build. So if there is a build, then it's in a good state. I could deploy it in production. You can have features flagged, like in the previous conference, we have features that only us see. It's the same stuff here, so that you get feature flags. So you know that... If the build is deployed in production, then it will not have that feature because it's too new. If the build is deployed in production, it will not set up a database, for example, because it's not ready yet, but it is already in the code. So we only have one code. We don't split the code between development, master, and a lot of different branches that just bring confusions. When you have a different branch, then you have a different product, or you already have a big update. But most of the time, you should only have one branch and do baby steps and do small commits. And in the continuous delivery, yeah, human action is needed to deploy. Is that not mean that someone need to SSH the servers to update the application, but it means that the jobs will stop. It will not go to the point of deploy it, because that's the job of the continuous deployment. And at that case, It's exactly the same as the delivery event. In this case, you know that your code will be working. You have tested it. It did not break your different environments. And you can just deploy it without downtime and do silent upgrades so you don't even notice that it has been upgraded. And at that point you don't have any human intervention anymore. But that requires that you already have some major testing infrastructure and that you trust your tests.
But once you get to that point, then it's just the end of the continuous delivery. Because a developer knows that if he pushes his code and then whenever later it's in production. Well, whenever is the time of a different test.
How does it reflect in reality? Well, you get pipelines. In this case, it's Jenkins pipelines. It will run a lot of different jobs, but you will get feedback on what's happening. You will get graphs. You will be more confident of the different tests. You are launching. And the pipelines allow you to, instead of having one big blow job, one big blow job, then you just have small ones that contains the smile checks, the style checks, the syntax checks, and then at the end, you just get a build with maybe a button or something like that, you just need to press.
So you need to run. You need first to do the integration on a development platform. And then you can train yourself to do deployment on a UATV infrastructure, so human acceptance testing environment. So in that case, you will bring people a place where they will always see the latest working commit of their product.
And once it has been deployed to UAT, you can do the delivery to production, which means that at that point, you may consider that putting in production is maybe a business decision, because when do I need to deliver that feature? Maybe it's only next week, so I will not deliver to production. No, I will not press the button. But you know that the code has already been deployed in UAT first.
and then you get the promotion. So first, you click a button, so to promote your build, to see, okay, this build is valid, it works on UAT, so I want it in production, and then you get more confident in your code. The UAT did not break since maybe six months, and you say, okay, we are ready now, and you remove that button.
So the code will go into the development environment and in the UAT when you can still have some acceptance test. And then you can just have the code deployed in production.
But what is the rule about deployments? Well, if it hurts, if it's difficult, if it takes time, if it's, yeah, do it more often. So you can improve yourself continuously, you can be more efficient. So if it's difficult to deploy, Then learn to do that with less outages. When you look at the big websites, Facebook, Amazon, they are not done each time they deploy something. So you need to learn and to do it more often and more often and more often.
But then you have also the problem of the infrastructure. And there is a concept called infrastructure as code, which means that you consider infrastructure just as a piece of software. So you put your infrastructure under version control. So you can have the history. You can amend it. You can see what would change that stuff. So if it's difficult to deploy, then learn to do that with less outages. When you look at the big website, Facebook, Amazon, they are not done each time they deploy something. So you need to learn and to do it more often and more often and more often.
But then you have also the problem of the infrastructure. And there is a concept called infrastructure as code, which means that you consider infrastructure just as a piece of software. So you put your infrastructure under version control. So you can have the history, you can amend it, you can see what would change that stuff.
And you can deploy the monitoring, the backup, the application from the same location. So you know that if there is a website, then there is an Achilles check for that website, for example.
But it does not mean that it's a bash scripting. It's not a bash script in a Git repository. You know, it's something like Puppet, like Chef, like a real system that will be able to respond to the changes in your environment, that will be able to do some reports of what has changed and why it has changed.
But in that case, then, yeah, your prep code, your chef code, yeah, it's code. So it must be deployed. And it does not. It does not mean that you can just write your private code, you commit and push it directly into production. No, it needs to be tested also. So you also need to apply that to the different environment. Remember the UAT, the development environment. So first of all, you will have a small evolution in your code between the different environments. And the second stuff is that at that point, you will have the environment that will be the same. And you can also do the promotion and the delivery because maybe you first want to test the latest changes in the MySQL database to see the performances in the UAT before you push them in production. But when you will push the button to have that in production, you will know the impact of that.
So it's the same path as a product. So in that case, the operation people can follow the same rules as the developers.
And then you have orchestration because who wants to go by hand restarting all the HTTPD servers, for example? You need something more, you need something more powerful than that. No one wants to connect to 20 servers one after each other. So you have tools like mcollective and Cibble that can do that for you.
Also the configuration of the DB of the different commands, you can just orchestrate that.
And let's speak about the third part, which is the measurement. And one concept that is very well known in the Kanban and Agile world and the Scrum is measurement, the feedback.
Feedback, do I really need to say more about that? It just means that you will get information. You will get information as soon as possible.
The second part is the matrix. So you will collect tons of matrix, you will build dashboards, you will learn for your logs, which is very important because every application has logs, but how many of them are really collected and
how many of them do you make dashboards to see when something is wrong? The log is often the first location where you want to look at. And if the server is completely down, you just don't want to say, oh, I cannot see the logs because the server is down. No, it makes no sense. So you would not want to have some kind of a log server that will collect everything and you will learn for all of that. And that is valid for every platform, like in the previous talk. You need to monitor your development environment. It does not mean that you should get a SMS at 3 a.m. Because the development environment is down. No, but it means that if there is a problem, you should see it as soon as possible. And if you can see it before it goes in production, then it's really, really good. And when you see the troubles early, then you are more correct. Because fixing a problem in development is less racing than fixing it in production.
And it also allows you to measure your progress. Because if you only do the performances in UAT, or if you only measure the performances in your development environment, in your production environment, then you will miss information. If you see that starting, yeah, this is the last build in production, I see that I have a problem with my CPU usage, then you will not know which commit did produce that. But if you already did the checks in the development environment, you will know exactly when the commit was introduced and what's the problem.
You can also observe the side effects before they arrive in production. So all of that is very important, is that you just don't want to monitor the production because then you are missing the goal of the monitoring, which is to prevent the problems. So you can even start with the development If you see that at a certain moment the build takes two times more, then you have a problem already there and you can directly blame the different changes to see what happened exactly.
If you see your code coverage is going down, you see that you have a problem also. So you need to get metrics from everywhere. And then you will monitor the runtime, which is what you always do. You monitor the disk usage, the CPU, the I.O., the memory.
But you also want to monitor the middleware. So there is not only the array. They will not only define their product. It's not enough to just try to connect to TCP to the port 80 of a website to see if it's up and running. No, you want to check the response time, the users, but also the queues, the API calls, the connections. And you need to implement in your application something that the application really does. If you are building a calculator, you should be able to check if it can do calculations. If you are building a website where a user can log in, you should be able to monitor that a user can effectively log in. And not only check if you see the first page, because there might be a SQL problem with the user table that you won't see in the first place.
So you want to test what the application is really doing. And also have your lawyer between that.
But that takes time because, yeah, the more you will monitor, the more false positives you will get. And that's a lot of work to just find the balance between what you need to really get as information and what is not relevant, how to fix your different checks. Because sometimes you have a network problem and what you get is a disk space problem. And then you first need to get the right alerts. There are a lot of tools to do that that can just look what happens and what are the downside of that.
We need to measure everything. So it does not only mean the IT part. You also want to monitor how much do you deploy, how many commits you are doing maybe, or how many tickets you are fixing, the command queues, the length, so you want to keep track of that. You also want to know, yeah, okay, my work in progress. Oh, was it yesterday? Or was it two days ago? Oh, is my work evolving? And then you start building graphs. This is still a low version of Logstash, but
you get graphics, which means that you have a view on it. You just don't collect data and then forget about it. No, you are actually using them. If you're a big company, then it's even more important to be able to show.
To show, okay, look, we have a problem there because we have a lot of 500 errors in our Apache server. Let's try to find what happened.
Because sometimes, yeah, you will get problems that you will believe that there is no impact, but something bigger is hiding there.
So you collect the matrix, you collect your rocks, but then you need to do something with them.
So you need to get the business values out of that. So it's, yeah, you can always get a lot of metrics, but if no one makes sense for the business, then the managers, they will just don't care about them. So you will need to find out what is relevant. If you want to go after the number of paying users on your platform, just do it because it's important. It will show you the health of the company. If you want to share the dashboards between the developments, the management and the operation people, you need to have common values that speaks to everyone.
Of course, the management people don't need to have access to all of the metrics. But still, they should be able to talk with you about, okay, look, we've got a problem at that moment. So if you have a screen or a dashboard that's, and if the manager comes by and he sees that, oh, the number of users that pray, is done by 10%. Oh, is that possible? And then you tell it, yeah, but it's because the platforms get slow, the people don't come back. And then the manager will know that there is a problem and they will have to fix it, to find time to fix it. What's happening? What's going on, guys? So that's why you want to share the dashboard so that when there is a problem, when something is wrong, everyone knows it.
And then you will learn for your matrix. So when did they happen? When, what's happening? And you can use them.
You can use them, you can analyze them. You can prevent the failures. So if you figure out that each week, You have 1% of disk space less than you can know, okay, in five weeks I will need to, I will have a problem, so I can actually know to prevent that.
You can correlate failures. You have tools, notably drawn from, let's see, that allow you to just, when there is a problem, an anomaly in a graph, to just know how many graph is, if the same anomaly at that moment. So if the CPU usage is high, and at the same time, I see that the metrics of my database are always high, then I get a step further, and I already get the information that will help me to do my postmortem, so my recos analysis. Because I will know that, okay, the problem was not actually the CPU, but it was the... at that moment. So you have metrics, but don't just look at one metric, because a problem should impact several metrics. And you need to know which one went in the wrong direction first, which one caused the other ones.
And that's from the development to the position.
That's what for the measurement. So having metrics, K metrics that have business values and also that can help the people to find what is wrong. And the last part is sharing.
So you want to talk about your experience. You want to use maybe open source software just so you don't do the work alone because if you are in the telco business or in the bank business, then you don't care if you share your Jenkins job to test, I don't know which, it doesn't matter, but you need to share with other companies because yeah, you are not paid to do Jenkins stuff, but if you can get a receipt that are already used by someone else and it will facilitate your job also. And when you have some code that someone else could reuse, just do it. So other people can improve it and they can just add more features that you might need one day. So when you can publish something that other people will reuse, just do it. Share your experience because the IT world is big, but if anyone plays in its own room, then we are not advancing. And yeah, I just share my experience with you. And as a conclusion, I will tell you what DevOps is not, because DevOps is about patterns and anti-patterns. And DevOps is not, the first thing is,
DevOps, it's not about tools. Tools, they matter. Yeah, it's really important to have tools because if you don't have them, if you just talk about The way of doing things, you are not advancing, but that's not the goal of DevOps. It's not, yeah, you could call some tools DevOps tools, but it's not the point of DevOps. It's really about the culture, the automation, and the measurement, and the sharing part.
The second theme is DevOps is not adding a new team. It's not adding a new person that will do DevOps stuff. No, because in that case, that person or that team will become the bottleneck, or even worse, you will get just a new silo. And that's not what you want. You don't want a new silo called DevOps, because then you will get the new troubles again. And if you have a super reward that can do everything in your infrastructure, then it will one day be your problem. What you want is to improve the experience and the knowledge of the whole team, instead of just one person that will just do all the job and clean all the mess.
Like everyone is responsible, everyone cleans its own mess. So if you do something wrong, you will just correct it by yourself and don't depend on others. Because in the DevOps world, super heroes are not welcome. We don't want people to be able to fix it and the day is sick, nothing is working anymore. That's not what we want.
Which implies that DevOps is not a job title. DevOps is not just one person, it's not, yeah, there are some, Piper that you could call full stack developers in that expression. But DevOps is not a job title. If someone asks you if you are a DevOps, then you should probably answer no.
Because DevOps is not that. Well, if you consider that DevOps is the continuation integration, the continuous delivery part, then yeah. But it's not the case. DevOps is more than that. You are not a culture, no. So you are not a DevOps.
DevOps is not a methodology, so it's not against Kanban, it's not against Scrum, it's not against all of that. DevOps, you still need to manage your projects. DevOps will not fix that problem for you. So you still need to be agile, you still need to use Kanban, you still need to use the methodology you were using before. And it's the same as in Kanban. In that point of DevOps, yeah, you need to make it work for you.
Because DevOps is a journey, it's a cliche,
You cannot one day come to your boss and say, okay, let's break all the silos. Yeah, let's do DevOps stuff now. It's over. No, it will not work. It will take time and time and more time to get to the point when you have no silo and your application is continuously deployed. take a lot of time to convince people, to show them, to demonstrate them, to bring new tools.
To bring the new culture. So that is a journey, a real journey that takes years in bigger organizations.
Okay, so that's all. There is a lot of readings about that, so I have put some URLs there. There's also the Phoenix project book.
And in this location, in this venue, in April, there will be Dead of Days Paris again, two years after the first one, when you will be able to meet other people that face the same problems.
So I encourage you, if you are interested, to just come to these days and to discuss with the DevOps community.
Okay.
Thank you. You can still meet me. I am still there.