 As Joe already announced, I'm not Baltis or Oswald, but Chris Aprilib. I don't work for SBB, but I'm a redheader, but our colleague had to fly home yesterday to Switzerland. And I'm working actually with SBB for quite a long time now on OpenShift and other topics. So for more than a year, if I said no worries, I will step in and I will take the session here. So first of all, who is Swiss Railways? Clear, Swiss, they are in Switzerland and they do rail business, so they're on trains for goods as well as persons. And actually they are plus minus the only rail company you could say they have, monopoly there in Switzerland. And we are working with them on OpenShift for quite a while now. And actually I want to talk is about how they went to OpenShift or why they were thinking about OpenShift. And what were the steps which led them there? About Swiss Railways itself, a company has around 30,000 employees, around 2,000 of them in IT. They are as well a software development shop, so they have a few hundred software developers. They do a lot of custom development in-house as well. What I want to start with is actually a talk about DevOps in combination with provider management. So what SBB actually did or how they started a couple of years ago is that they introduced, I think it was around 10 years ago or something where they started to introduce so-called shared platforms where multiple applications and projects could put their applications on. Shared platforms for IBM WebSphere, for example, shared platforms for databases and so on and so on. So they built up these big shared platforms so that all the projects in SBB could put their applications there. There was one problem with these shared platforms which is the isolation between the applications. So it was a technical limitation which they could not really resolve network-wise, CPU-wise, that they could not really isolate the stuff from each other. And what they did then as a consequence is to introduce processes to mitigate these risks. So you have big change management processes. You have word templates which are used for the handover from artifacts from different stages to each other. So they really introduced a big process machinery, you could say, for change management and to mitigate these risks of applications affecting each other. And this as a consequence certainly broke up development and operations into different silos because in the middle you have this big heavyweight processes which just separate the two of them. As well, you had the interface between Dev and Ops was very technology specific. So for every technology you had on Dev and Ops teams. You had an Ops team for WebSphere, one for database, one for every technology. And what SBB did then is they said, okay, we are going to outsource some of the operations. So the infrastructure operations for example is outsourced, the platform operations is outsourced to any provider. And the impact of this is certainly that the gap between Dev and Ops even gets bigger because it's two different companies, probably two different, or I mean we have, we've talked with German in Switzerland, nobody else does, nobody else understands us if we have to talk English it's getting a bit tricky. So all these things are coming as well into play if you outsource things to a provider. And what they did then because the gap was so big, they said okay, we need to have an Ops team as well in SBB itself. So they call it operations management and what does operations management do? They sit between the provider Ops and the development and coordinate activities there. This is what these guys do. So you have another hop or another Ops which you're adding to the game here. And this is not enough certainly because usually you have multi-provider strategies. So you have multiple provider providing different pieces or operations for different pieces of your infrastructure. And so this is what happened as well. They had to manage different providers for each technology still you have an operations team. So it's not only the different companies you have to manage the different providers but as well per technology you have such operations teams. And I mean if they wanted to introduce a change which affected some backend systems and some front end systems, they had to orchestrate these changes across multiple different operations teams across multiple different companies even. And this can be very tricky. I mean usually when you release stuff you have dependencies, you have to do things as things in a certain sequence or in parallel and to coordinate these things across different companies can be really, really tricky. We're still not at the end because then providers start off shore, near shore or just shore certain parts of operations. So for example network operations was moved somewhere else and then you even had to talk to even more parts and companies and you had even more different languages and cultures involved in the operations of a single platform. So what's wrong here? Yes, you have a little bit of Dev and then you have Ops, Ops, Ops, Ops, Ops. Something is wrong here. So this is what they realized as well. I mean it kills your innovation in the end. You're very slow in releasing things and so on and what they actually did together with us of course or with Red Hat is to introduce OpenShift and they introduced OpenShift for on the one hand side development of applications and on the other hand for operations of applications as well. So OpenShift provides on the one hand side the isolation of applications from each other which allowed them to remove these heavyweight processes around and build so-called DevOps teams. The DevOps teams, they are responsible for an application end to end. So from the development over the whole staging into production and maintenance of the application they are end to end responsible for the applications and what they as well did, so they changed it a little bit so they introduced a horizontal split of responsibility. SBB itself is responsible for the application and its operations and the providers are responsible for operating the base platform, so OpenShift. You can still have multi-provider strategies so you can still have multiple providers providing you an OpenShift platform which you can use. As well certainly OpenShift brings a lot of benefits in automation of the operational tasks so operations is getting smaller and smaller that's the plan actually and one other big thing is that you do not have to have multiple different teams anymore for the different technologies because the interface between DevOps and OpenShift Ops is not about technology, it's not about I want to host a JEE server, I want to host an OJS. This is not important anymore because it's all containerized and it doesn't really, the technology itself doesn't really matter anymore so the interface is much, much simplified. So what SBB has right now, they run stuff on-premise, they run stuff in public cloud as well on OpenShift and this brings me to the use cases kind of, so one use case we are currently working on is the SBB mobile app. Actually it's one of the most popular apps in Switzerland. It's always under the top five ranked apps in Switzerland there is around, I think a million downloads or something and the back end of this app, this is probably the first use case is running on AWS. So everything customer facing will be running on AWS and other systems like backend systems are running on the internal cluster. This is one of the use cases we are currently implementing then the webshop is the next project which is coming. Actually we have identified around 15 projects which we are going to put to OpenShift by the end of the year, that's the plan and also they are currently defining their future technology stack. So they call it their cloud technology stack consisting of Spring Boot, then Redis database and so on, so they really define a set of technologies they want to use to build their next generation of applications and are kind of hardening these things on OpenShift now. That was it, thank you very much.