 Hi, here are many people here. I would like to tell you a little bit about how OpenShift keeps you flying, how OpenShift helps us at Luft-under-technik. But first of all, I'd like to introduce myself. My name is Torsten Pohl. I work for Luft-under-technik and I'm the architect for the Aviata platform. And I'm also a product owner for the Aviata core services. And if you'd like to contact me, please feel free to drop me a line at torsten.avieta.io. Just to give you a little context about Luft-under-technik. Luft-under-technik is the daughter company of the Luft-under-airline that some of you might know. And we are the leading independent provider of aircraft maintenance repair and overall services. That means we will walk up to over 2,000 aircraft any day and check it. Overall more than 1,000 aircraft components. This can be tiny walls to flight computers worth tens of thousands of dollars. And we've got more than 110,000 different components in stock for your replacement. There will be 26,000 employees working for you to deliver parts to more than 2,000 aircraft that are under exclusive contract. And we've also got some great stuff to create and upgrade VIP aircrafts. So if any one of you has got a spare 747 lying around, feel free to contact me after the show. I said the word Avieta, which is a made up word from Avatars and Avieta because it's a digital twin of the aircraft. This is our first purely digital product that we created. And it is an open modular and neutral platform to collect everything we know about an aircraft. So open modular and neutral should mean we would like to open it to everyone who has got something interesting to do in the aviation context and the customers can choose which of the components they want to have. And as Lufthansa Technik has always been an independent provider, we would like to be neutral. So we will be offering our services, but if you've got a better one, you should be able to put it on our platform as well. Just to give you an idea what you can do in aviation with digital products is I will show you a little prediction use case and I will talk about an igniter plug. An igniter plug inside an aircraft engine, you will always notice that this is an aircraft engine. These are the small red dots down there. The engineers told me that they would be there. It's a little bit similar to the igniters that you have in your car. They will spark and ignite fuel. But differently to the igniters of your car, an aircraft engine has a constant flow of fuel that will be ignited once and then will flow all the time. At another time in the flight process, these igniters will spark. And this is when you're flying through bad weather because you don't want the engine to go out then. And it's really hard to get the engine going midair again. So they will be sparking all the time and we've got two of them because top one priority in aviation is safety. And for priority two, safety again, we have said, okay, we want to have them both operational all the time. And as you can see, they are really inside the aircraft engine, so it's hard to check them and so on. And they are also like the igniters of your car, discard items. So you would throw them away after you use them, but they are a little bit more expensive like thousands of dollars piece. So for safety reasons, again, we decided, okay, we have no idea how often they spark and they will have a guaranteed lifetime of, I would say, one million sparks just for simplification. We say, okay, after this and that many flights, we will replace them anyway. So when we replace those things, we will throw them away. I already said, and we found out, okay, they look so good. They are kind of new and we found out that they could be used easily five or up to 10 times of the amount. So as I said, there's no counter for the igniters, but when you got all the data together, you know how often is this engine started and how long did the pilot fly in anti-icing mode. And this is a prediction use case I like because I can explain it. So sparks per minute times the minutes it is on that will count the sparks. So okay, so we can without sacrificing any safety and still using a really good safety margin, we can replace the igniters only if we needed this will save quite a lot of money. Especially if you're thinking about two or four engines per aircraft, two of these igniters per engine times 300, 400 aircraft. I found out that I will be short on time. So I won't be telling you anything about brakes. But if you're interested, find me at the beers. I would like to talk about OpenShift. I'm thinking some of you might be interested in it. And I even got two of the OpenShift ones and I got a little disclaimer before that. I would say I will be over-extra-rating a little bit. So don't take everything I say and still feel comfortable to get on planes when you're flying home. So I looked on the technique. We've got two kinds of IT and this is the classic IT. I don't like the word because it sounds kind of negative and I don't mean it negative at all. If you find a better word, there will be beers to tell me about that. As a classic, I feel it. Okay, so with the IT that supports the business, how do we create software? We will do a project and then there will be developers and people who will do stuff. And then the project ends and the software needs to be working after that. So it needs to last. And so what did we think about? We said, okay, we want some standardization and we invented something. We call the Lift on the Technic platform. This is one EAP server that we customized a little bit and it would be deployed classically inside a VM. We also said, okay, we want some standard architecture that can solve most of the problems. We want standardized CI CD so any change can be done by almost anyone. We want the source code and we want to have some regulation on the source code and we want some code analysis and therefore we can get the software running by a few people for whom all these deployments look roughly the same. And those guys, they fell in love with OpenShift and why did they do it? Because when we were working on the VM side of things and introduced the OpenShift way, we were able to lift and shift almost everything. So we also already got this EAP that is commonly we create a new base image that has the same modifications and they get stuff for free. They will get first of all, no more server drift. Server drift is something I would say. I ordered the Dev Machine in February and the production in December after that and stuff has evolved after that and the Dev Machine never got patched and they are somehow different and also I have throughout the project I've done something on the Dev Machine. I forgot about it and stuff breaks on production. I don't like that. Another thing we were doing rolling deployments manually with LVMs as well but that requires someone to be there to go on the load balancer and switch stuff and say, okay, boot up the new server and then switch over again and hopefully they will be doing anything right and they've got automation and so on but with OpenShift that comes for free. Another thing, the self-healing features with the liveness and readiness probes. Most of the instructions for the operations team I've read say if this happens, first of all, restart the server. If that doesn't work, restart the VM and if that doesn't work, run and cry for help. So the first two things OpenShift can do for you, I'm sure there will be an Ansible plugin for running and crying for help as well. And the IT also like the scalability. So scalability is not the major problem for us because the business is going steady most of the time. But still there are projects who will have the need for more power during at some point in time and then they will idle most of the time because they will order a specific set of VMs. I was talking about the Aviator project. This is a digital business case, so IT kind of is the business and software is also created differently. We would be creating software and adapting squads that would be there all the time and the product might emerge or disappear during time because they work out or they don't work out and we've got a plus. There are almost no legacy systems. So over there there are product owners, the guys with the crowns on their head and the happy developers. They also love the OpenShift platform. Why do they do it? They have their primary focus is being fast. They don't have to wait for anything because they can spin up what they want inside the OpenShift cluster. They also want to be open. They would like to say, okay, if some project comes over, then they can join us in our infrastructure if they need to. We also want to be flexible. We want to try something out then go back or do canary deployments or so. But at least we want to deploy as often as we can and there's no presentation complete without saying DevOps. We have developers sitting over at our place and they hate to be woken up at night. So they like the self-healing piece and one thing for Vita that's important. I would like it to be cloud neutral and OpenShift gives us an installation layer towards the cloud products. And of course for us it's also important to be scalable but we are working with airlines and B2B so we are not talking about scaling in the evening when everyone wants to watch a video but rather whether these use cases are needed or not needed so much. So to give you an idea how does A Vita's infrastructure look like, we decided we only want one OpenShift cluster for dev, test and production. This one will be running inside the Azure cloud. If you want to talk about Azure cloud, someone has talked about beer. We will throw in some cloud services mostly data stores. Just a word of advice if you want to be cloud neutral, be very careful with cloud services and think about what you are using. And we will add some infrastructure as a service so we will run VMs and spin them up with Ansible and put the big data and Kafka stuff on that. One thing I would like to be talking a little bit about is the way how we do it. And I've created two approaches. The one I would call the visit approach. And on the visit approach I am the developer and I'm coding all the time and I like my code and I would like to commit it, push it to repository. And then there will be a box around me and I've got my responsibility. And then the wizard will come around. Let's call him Jonas. So this wizard around here will be giving me templates and scaffolding stuff so I have got an idea how to create my code that it works with all the magic that will come later. I would like to have it built and that wizard has put in magic and optimization and so on and created all the build stuff we've heard about these approaches here already. And then there will be unicorns that will try and deploy stuff to the OpenShift cluster and the rabbit will come out of the hat. I've got no idea if that works in English. But so everything is outside my box. I'm not responsible for that and if something breaks down in production it's most likely the wizard's fault. So this is a... I'm making a little bit fun but I think this approach is really valid because the good thing about it is you can take the developers, they work in this sphere they are used to and you still got processes that will recreate the same environments and so on. So this is really valuable to have it. On the other hand, we've got the autonomous approach. Still the developer is coding all the time and there will also be some templates but the developer still is also responsible for creating and updating those templates. Surprise, the developer is also responsible for working on the build pipelines and they will also be deploying this stuff to the OpenShift cluster. And as this is OpenShift, there is still magic going on. And one other thing, I think you have visited this never late. He arrived at this exact time. He means to. So this is really helpful to have someone to enable teams and so on but I think the whole thing is about the responsibility that you have. So the developer is responsible for everything and he has to have knowledge about everything. So this is kind of the flip side of things. It's easy to say okay everyone needs to be responsible for everything but they have to have the knowledge and they will have to accept the responsibility for that. So these are the two approaches I think that we are using for different use cases and I think they've got both their valid reasons why we use it and they've got the, they are both right. One thing I would like to give to you is some opinionated advice. So this is my opinion. I would advise you to find your mode or your modes of operation but stay flexible inside there. So if you put the developers too much into their cage, they will stay there and on the other hand if you give them too much flexibility they might be doing stuff you don't want them to have. But one thing is the people you have to give them knowledge if you want them to take responsibility and you should encourage that responsibility and with every Spider-Man knows with great power comes great responsibility so be careful if you're giving them the power they need to accept that they have got the responsibility to do it. And one thing, keep an eye on the current development. You will all be going to the Red Hat Summit and there will be tons of stuff going on. Be careful and stay focused because this is too much. You cannot try out everything and find out what will help you with your problems. So in essence get a visit, get some developers, get some product owners and you will find unicorns peace and happiness all over the place. So thank you for listening. I think the Aviator story will be continued and maybe you find a presentation on day two of OpenShift and if you would like to vote for us for the Innovator of the Year Award feel free to get out your phones now. And one thing that's more important to me we are creating a platform for anything aviation related so if you've got a nice use case, good ideas come to us you are invited to our platform and then we take off.