 So, good afternoon everybody. My name is, as mentioned, Marcel Kornegor. I will be telling about how to get started with DevOps today. At the end of my presentation, my colleague Elzbieta will also have a little presentation about the OPI. I'm from AT Computing, which is a Dutch company. We are specialists in Linux and open source technology. And I work there as a DevOps and cloud consultant. I'm not really a tech guy, so this morning I was already in the track and I was really inspired by all the technical things that happened with Ansible, Kubernetes and such. But I'm not really that into coding or other kind of operations from a sysadmin perspective. So, this talk will be less about the tech side and more about what is DevOps and how does it work within an organization and what should be considered when you want to get started with DevOps. So, that's a short introduction. And the next 45 minutes will be about DevOps. And before you get disappointed, 45 minutes to cover all that part of DevOps is by far not enough. There's really a lot to talk about. And I will mainly be scratching the surface of what DevOps is and what it has to offer. So hopefully it will be a nice overall view of what DevOps is, what it's made of and what you could make of it. So, let's start with a quote. DevOps is a very mysterious and powerful philosophy and its mystery is only exceeded by its power. I'm not sure if you know the movie but actually it needs to be adapted a bit because DevOps is not really mysterious. It's only really powerful and quite straightforward if you know the concept. So, what is DevOps actually? A lot of people online or even at conferences try to define DevOps like with a nice sentence or a phrase. But it's really hard because there's so much that involves DevOps. So, I'm not trying to define it within one sentence. Instead of I will try to explain what it's like constructed of. Because DevOps is a method that uses a lot of concepts and a lot of things from other methods. And the founding fathers of DevOps cherry picked from all that different methodologies and packed it together to have like a super positionized methodology. And the first system that's part of DevOps is the Toyota production system or TPS. And maybe you're familiar with this car. It is the Toyota, the car company. And actually back in 1948 one of the directors of Toyota came up with a system that's now called the Toyota production system in which he focused on three major topics. And that was Murray which is to overburden. It was Mura which is inconsistency and Mura which is waste. And what the Japanese did is to really specify what they meant with these three terms. And they made them measurable. So, they could actually improve their process and really make visible what they were improving and how effective their approach was. And eventually when they started to get better in it, production went better and Toyota became mainly because of the TPS, the largest car manufacturer in the world. And of course this inspired other car manufacturers like General Motors or maybe Ford to also investigate well how does Toyota do this? And one of the follow-ups is Lean which is based on the Toyota production system. And maybe you've heard of it. Lean is like a worldwide known standardized way of running a production facility. So, from now on as an IT professional when you step into your Prius or your Igo, please remember this, that the Toyota production system is really a smart way of making a production system. If we go back a little to IT, there's Agile and Scrum. And a lot of companies worldwide are for the development of their applications relying on the Agile and Scrum principles. So, also DevOps uses Agile and Scrum is compatible with Agile and Scrum. And the main goal of Agile is to improve the agility or the flexibility of organizations. In the old world a team could spend like a year developing a software application and when it's deployed it was like submit and pray. They had to see well does it function the way the customer expects it to and if it doesn't they had to fix it and it was really expensive and in the worst case there was a year of development down the drain. So, with Agile and with Scrum they say well let's chop up the development of an application into smaller parts that we can really manage and oversee. And finish that first before we start to increase the complexity or increase the functionality. So, in that way you avoid being like really putting a lot of money into a big and complex project without the result of a product that expects lives up to the expectations. So, this is in basis really great and is really popular. One other thing when we look at the way things run today is the way organizations are organized and they are siloed. So, in the main many cases you have some sort of organizational structure with different teams doing different things with all different responsibilities and they have to collaborate but that's not like really what they do from a natural perspective. And the reason of that is because every team has its own KPIs. So, every team manager gets a set of goals for the next year or the next month and his main goal is to reach that goal with his own team. So, if another team has different goals and needs to collaborate to achieve the goals it's not always the case that they work together to achieve the goals in collaboration. So, you have a lot of individual goals that not always make up to the overall goals of the company. So, in this way also the CIO of the company can actually be able to reach its targets, its KPIs. And then you can say, well, he has done a great job because he actually delivered what we agreed on. But with DevOps that's really complex because the developers and operations are in separate teams. So, they have different KPIs and well, the real world looks a bit more like this. We have the developers somewhere in the organization, can be multiple teams, can be one team. We have operations, those are somewhere completely different within the organization. We have quality assurance, we have product management, all separate teams, process management also in large companies. There are some sort of business relationships or service delivery management team, internal audit and lots of other stuff. And one thing that's missing is this. Between all the teams there are, well, they're not actually walls, it will be very inconvenient in an office, but some teams are even not allowed to talk to other teams because of KPI conflicts or because they say, well, the process within the company is to deliver it there and they need to pick it up. So, there's no transition, it's just like throwing it over the wall, good luck with it and that's it. So, that's really hard. Also, there is UX. They have a special place, but that has different reasons. And of course security and they have a slightly different kind of wall. So, with DevOps, this is not really going to work well because there's too much friction and too many conflicting agendas over the whole company. So, what to do about it? With DevOps, we must make a transition to what's called a value stream. And this is also something that DevOps did not event itself or itself, but it's also a principle of the Toyota production system, which says, well, a car is a finished product, so everything we do as a company has to add value to the steps for making the car. And that's also a big transition when you're going to start with DevOps that you have to look at IT application or IT platform as a service or a product. And everything you do on a daily basis needs to add some value in some way to the finished product. So, if you plot that back on the organization, it means that you no longer have like a vertical silo, but you get a horizontal line. So, from development to operations, even from business to operations, they all need to be aligned on the same product, on the same service to make from the ID that the customer said, well, I want a new application until Ops says, well, it is available, it's running for you, and you can use it. They all need to be on the same page. And with Agile and Scrum, you run into a problem. And that's because with Agile and Scrum, you mostly focus on the development part. So, if we look at the total value stream, which starts at the demand, somebody wants something, and ends after the lead time, which is the total time it takes from ID to delivery. With Agile and Scrum, you optimize the development part. So, from writing code to making it ready for deployment, but it's not actually deployed. It's like staged or you call the Ops guy and say, well, my package is right here, and good luck with it. So, there's still a bit of a wall left between development and operations when you're using Agile and Scrum. It's not like the whole value stream, it's only a part of the value stream. So, what about Ops? It's not part of Agile and Scrum. Maybe I should put it this way. What about Ops? Because that's actually where it's delivered, and that's actually what the customer experiences. It doesn't experience the code developer as written, no, it experiences the final product that's running in a production environment. So DevOps has all the things from development, which I called like Agile and Scrum. It has quality assurance to make sure that everything that is produced is complying with corporate standards, but it also incorporates operations, and therefore DevOps covers the whole value stream from beginning to the end. And that's really important when you're going to have a collaboration over the value stream that you have small compact teams with short lines and no walls between them. So, with this set, we now live in an era where some larger and smaller companies actually are really successful with DevOps, but in my experience, more companies are really curious about it, but still do not really do it. They started with Agile, they started with Scrum, but DevOps is more complex in a way or harder to implement. And that's mainly because DevOps really asks you to look different at things you do. So you have a different culture within the company that you need to make DevOps possible. And that means not only that as an engineer, you need to look different at what you do at a day. So from an ops perspective, we are all firefighters. If there is a major outage, we run with our water hoses and fire extinguishers and we make the fire stop. But we need really an engineering mindset where we start fire prevention. So we really look into the system and say, well, if we take this action, it will not be a major outage, but we can prevent it from happening. A simple example is a security certificate. Everybody who's in ops has had the experience that a certificate is expired and that always gives trouble. So you can replace the certificate with a valid one and that's it. But the next day, another certificate might expire. So from an engineering mindset, it would be better to design a system or to propose a system and build a system that in a way automatically restates the certificates. So those are two different mindsets. The one is a point solution and the other one is a structural solution. And you need that over the whole value stream. So the organization needs to think about making things better in a consistent and permanent way instead of firefighting. And that's really hard because if you have a siloed organization and you want to make it a value stream organization with a DevOps culture, there is some work to do. Not only from the technical perspective but also from management, from directors maybe, they need to understand that this is necessary to succeed with DevOps. Another part is blameless learning. And learning is an essential part of the DevOps cycle because every time something doesn't go the way you want it, it's actually experience that you can learn from to prevent it from happening again. So it's really compatible with the engineering mindset that you need to adapt to. And blameless also means that when you take an action and it leads to an outage that you do not get fired on the spot because you made a system go down. But your manager or director says, well, let's investigate what went wrong and let's learn from it so we can prevent it from happening again. And this is also really important to adapt to but also really hard because you need to accept that sometimes things fail and break. Then there's another thing and that has more to do with automating things. DevOps advocates that say, well, we can improve quality, we can speed up and we can bring down costs without any artifacts. So there's really amazing potential. But to do so, you need to automate because if you do everything by hand, you will not be very efficient. Well, we have seen some amazing automation tips and tricks this morning already from the other speakers. So there's a whole lot possible. But if you have a running production system, a legacy application, it might be really hard to get started with the automation. And speeding things up can be really difficult. If you have a green field, a continuous integration or continuous delivery pipeline can be built. But if you have an existing environment, it can be really hard. So that's really a challenge with DevOps. If you have your mindset ready, you have your blameless environment, your director is not hunting for you, you still have a challenge in the technical side. How am I going to speed things up? One trick is to embrace APIs. And APIs can help you also with legacy environments because if you have like a legacy system that's not really flexible, when you make a little layer around it, which actually is an API, you can automate and make it more flexible when it comes to communicating with it. And the legacy system can remain the same, but it does not stop you from making steps on other environments. So you're gaining a little flexibility and have less problems with the old environment. So APIs are really your friends in the case of a non-green field situation, which is almost the case in every company. So this is a really quick run-through, DevOps in 20 minutes, with some concepts and some background. And this is a really quick run-through as I already mentioned, there's a lot more to DevOps than I can cover in a presentation. And it also features things like the demo cycle, which you do plan, do, check, act loops. There's a lot of feedback involved to increase the learning capabilities. Also there are ways how you can embrace the changing and start small and scale up. One of the best practices is actually to have a small set of work that you can really oversee well and start there. And after that successful, really celebrate the success so that the company can see, well, we have done a DevOps experiment and it was really successful, and from that point scale it up. But it's really a lot to deal with in a short presentation. So I really encourage you to see online, there are a lot of great videos that go into more detail on specific subjects. The founders, Patrick Dubois, Gene Kim and Jesse Humble, and also John Willis have lots of postings, blog writings about what DevOps is, how the movement can be started, and some practical tips and tricks, how you can start DevOps because it's really hard to make it get started. So with the end of the introduction, it's now time to talk a little about open source because I suppose you came for it. As I mentioned, I'm not really a technical guy, so I will not dive into the open source too deep. I will mainly put it in perspective like how can you use a tool to help you with DevOps in a real life situation. So DevOps is possible without open source, but there are so many great open source software available you probably don't want to. We've seen it already this morning, it's like everything can be done with open source, so there's no reason you shouldn't embrace it at all. This is what I call mostly the DevOps pretzel, which covers like the whole software life cycle and every stage from development to operations and also the feedback towards the next version of the software. And I will now walk through every stage and have a quick look at what can you expect here and what should you consider. So from a creation perspective, a lot of this has been already mentioned this morning. It's all about writing code and designing your DevOps application. You would want to have smaller functionality, so not large monolithic applications like they were used to, but small flexible functionality units like microservices or loosely coupled application parts that can really interact quick and are also more like a Lego system where you have one brick that you can reuse for different types of buildings and where the brick itself is really well defined, so others can also use the brick that you have built. You see a lot of REST APIs, JAML, JSON templating here and it's all code, so I really suggest you use Git, which you probably will do, to make sure that you have version control and keep control over all your code. The next step is to verify what you have built and this morning I see ICD pipelines were covered. This is what you really want to embrace when you're going to do DevOps, automated testing. Make sure that every step you take is tested automatically and even with continuous delivery, one of the principles is that you first define the test criteria, so when is the light green and is the software functioning right and when is it red and should something be fixed and it's really on unit level, so you start at the lowest possible level of testing to make sure that you can automate everything towards production. When it comes to packaging, already we saw the Docker images, you can have various types of packages. It can be a container image, it can be a VM and there's lots of ways you can package your software to make it ready for deployment. Of course, containers are really interesting because of their flexibility and their lightweight and really fast, so when using containers, there's also a comparison metaphor which is called the pet versus kettle metaphor which says if you have a pet, which is like your cat or your dog or your goldfish, you put really a lot of effort into making it healthy and making it happy. So when it's ill, you visit the doctor and you're really doing your best to make it better. That's also the case with older applications, your legacy applications. If they get broken, you really try hard to make it work again. Kettle is different. It's like the cow's for a farmer. He treats them well, but if one gets sick, it's not like they go to the hospital with it and really make it better. They sooner will decide to give it a peaceful ending and proceed with another cow to make the production on par. And that's also what you do with containers. If a container does not work right, you just stop it and spin up a new container. Of course, when it keeps crashing, you have another problem, but you're not going to patch the container or troubleshoot the container. When it comes to releasing the software, this is also a part where you want to do a lot of automation. In various companies, there are release managers who have one specific task and that's to get software to be released. It's a lot of craftsmanship involved to make it all work and make it all happen. If you already have your pipeline in place, production is just another day at the office. It's not that special because it's already tested. All the lines are green, so if your production environment is comparable to the other environments or it is containerized, it should run and there should be no problem. Still, it might be a good idea to have a transition that's not like a Big Bang, but more a controlled way of releasing a new version. Two popular ways is a blue-green deployment, where you have your older environment, the blue environment. You build a green environment and it's like a parallel system. For instance, load balancing or traffic redirection, you start to use the green environment. When it all works well, you can start to decommission the blue environment. When there's a problem with the green environment that was not visible during testing, you can switch back to blue and run production on that system until you fixed the problem with the green environment. Another deployment or release way is the canary release. This comes really from the coal mines where they had a little bird in the cage. When there was a gas leak, they hoped the bird would die sooner than the people working in the mine. It works like a sentinel. It gave an early warning like, well, there is something wrong. You better run and get to safety. This principle is also done for releasing where you have only a small portion of your IT systems running the new version. You can have some users test it and see if it all works well and from that point on, scale it up until you have your new version on the old service running. Some tools that are really well for this purpose is VAMP. It's an open source tool and it gives you really good control about how you can make the canary scale up. Also, a vagrant and packer help to make good images that are comparable to your development or acceptation environments. You can make sure that if you are deploying it in production, all things will remain the way they were. Then, of course, if it's running in production, we have to make sure that we can manage the configuration of the system. Ansible, of course, is widely used. Also, puppet chef and salt are really good for the job and they can also, because they're based on templates, on automation, reduce a lot of handcraft work that's been done, well, like the last 30 years or so, where you have patch Monday and everybody is busy patching manually on various servers and you don't want that in a DevOps cycle. Then, of course, you need to monitor what's going on. If everything is green, you can say, well, I'm at rest. But with DevOps, you also use the monitoring data for continuous improvement. So it's not only to notify you when there's an error, but you also can see trends and analysis to speed up the learning and see, like, well, the CPU is not peaking at 100% right now. But if this trend continues, it might within a couple of months. So is there a process that's slowly eating more resources or maybe there's a memory leak in the program software? So monitoring is both for fire detection and also for fire prevention. And also, it's really smart to have some sort of data logging analysis. The ElkStack is much used for it. And it gives you a really, can give you a really good view of what's going on within your whole system so you can take it back to the development team in your team and see how you can improve your application further. And then there's, of course, the platform because DevOps, there's a lot of discussion about, well, if silos are not the way we should organize a company, how should the DevOps team be formed? Will you have, like, one big team with everybody in it because that would be convenient? Well, no, that's too big. So the possibility here is to have an application team which does everything which has to do with the application. And the other team is a platform team and they have to take care of the platform. And the alignment between the two is really essential. So the platform team has to think of their platform as a service or a product and really specify, well, if you have an application, how can you interact with the platform to make sure it's compatible? And the platform team can, in that case, independently work on the platform as long as it sticks to what they deliver to the application team. And it is a smart way. It all has its pros and cons, but this seems to be really a clear line between what an application team, a DevOps team does and what a platform team does. And from a platform perspective, there's also a lot of automation going on. So manually deploying a virtual machine is not the way you want it to do anymore. So as we already seen this morning with things like OpenShift, Kubernetes, and various cloud solutions, you can really scale up your platform and really make a great and robust production environment or have really a speedy development environment. So with the platform, I'm coming to the end of my part of the presentation. So I would like to ask my colleague, Elzmita, to the stage for a little update. Are there any questions at this moment? Not yet? Maybe yes? Sorry, let's say that you have 500 applications. Yes? So the question is if you have like 500 applications in a big company, how do you transform that to a DevOps organization? I would suggest that you start like a small project with people that already are enthusiastic about DevOps and bring them together and give them a small project that's big enough to make impact. So it's visible and it gives a benefit for the company, but it's small enough that it does not really interfere with the work that's going on on a daily basis. So in that case, you will have the visibility, but it's also manageable and not too big and too complex. Other questions? Yes? Can you compare DevOps to SRE, which is the Google site reliability engineering? In a way, you can. So DevOps and SRE are also compatible. So a lot of the SRE mindset is also the DevOps mindset. They're really on the same page. The difference is that DevOps more focuses on the application team and SRE is more on the platform side. So in a way, SRE is a way of Google to how they have built a platform operations team. So they really match up pretty well. Any other questions? Thank you. Okay. Hi, everyone. My name is Serge Bieta Godlebska. I work for LPI, which is a Linux professional institute. I'm responsible for Czech Republic, Slovakia, and Poland. Actually, it will be quite quick. I don't want this to make like a side speech or whatever. So actually, I only will show you a couple of slides which I think are relevant for those... I'm falling. Sorry. For those who know LPI, have you heard about LPI? Okay. Quite a good number. So just for you and for those who don't know, you wonder probably what LPI is doing here talking about DevOps. So there is a reason. Actually, you are right that LPI is known as for Linux certification. We develop exams and provide certification for Linux professionals traditionally for system administrators. That's right. But actually, as we try to follow the trends and DevOps has been a trend for more than a couple of years already. So as LPI, we wanted to follow this and we created an exam and a certification... which is a DevOps exam. It's for DevOps, actually, specialists. It's DevOps Tools Engineer Certification. It's quite new. It's on the market for a little bit more than one year. And here you can see... I think I might be here. So that's the traditional track, LP1, LP2, LP3 which are specializations for those security, mixed environment and virtualization. And on the left side, you have Linux Essentials, which is very, very basic fundamentals. LP1 is a very good basis for people taking Red Hat certification and a lot of Red Hat people, they say, it was really helpful to them to take LP1 or LP2 to better prepare for Red Hat certification because it's really Linux-focused. And here on the right side, you have DevOps Tools Engineer, which is totally like a part. It's not the same track as LP1. That's only one certification. And actually it covers a lot of DevOps Tools, which are recommended, let's say, by LPI and recommended after months of consultation with DevOps Specialists. So those tools are tools we recommend and we suggest to work successfully with DevOps. I will not talk about the details, but I really invite you to go on our website and to check the objectives. So you can see the tools we recommend. Many of them were mentioned here and probably will be mentioned in the track later on. And, yeah, let's just go quickly. You can go on LPA Wiki, you can go on the LPA blog, so we have just series of blogs or posts on the blog explaining different tools. So, yeah, that's mostly... Yeah, that's what I wanted to tell you. And also, LPA has been changing, so we started new certification. We will have new certification this year too. It's one, the name is BOSS, you will hear about this maybe soon if you are interested in LPI, let's say, stuff. So BOSS is for business people, business of open source, for non-technical people, but, for example, for human resources people, for all kind of managers who are not technicians but need to know about open source. And one new thing, this year, LPA is launching membership program. You are all invited, you don't have to have LPA certification, but it's kind of, it's a step to be like a Linux community under LPI. So if you're interested, please just check website, but we will be around with Marcel the whole day and we can talk about this and if you have any questions about DevOps and about LPI in general. That was quick. Okay, thank you very much. Any questions? We are here.