 Hi, and a very warm welcome here at KubeCon in Valencia. It is overwhelming to be here. After this very long time of only virtual events due to COVID, it is so great to be here in person and to actually meet people. Before we start, I would like to briefly introduce ourselves. So please welcome my dear colleagues, Peter, one of our lead experts, and Jens, one of our excellent DevOps engineers. My name is Sabine, and I'm a product manager at Mercedes-Benz Tech Innovation. Thank you. So if you hear Mercedes-Benz and you see the Mercedes-Benz Star, you might think about things such as luxury, lifestyle, great quality, and of course cars. And still, we are not at any kind of car conference here. So you might be wondering, what is a car manufacturer doing on main stage at KubeCon? Now, the answer is, as Mercedes-Benz Tech Innovation, we don't build cars. We create software and thus play a decisive role in shaping the digital future of mobility. We are a subsidiary company to Mercedes-Benz, and we were formerly known as Daimler TSS. So just in case, you want to check for our commit history. Our headquarters is based in Ulm. Now, who of you has ever heard of Ulm? Oh, oh, okay, that's more than I have expected. I thought hardly anyone, but I'm pretty sure that most of you know Stuttgart, which is famous again for cars, for Swaybians, and for Mao'l-Taschen, the yummy answer to Ravioli. And I'm very sure you all know Munich, which is famous for great beer, Lederhosen, and of course, the Oktoberfest. So if you take the German Autobahn from Stuttgart to Munich, you will drive by Ulm. And although Ulm is not that famous and not that big, it is hosting something really great. It is hometown of the currently highest church tower of the world. Now, why am I telling you this? Because one message I would like to bring to you today is, you don't have to be very big and you don't have to be very famous to be able to host something that is really great and worth to talk about. And this is the case for us. So last autumn, we had Priyanka visiting us, and we told her our story about the last seven years and us and Kubernetes. And I have to say, she was as impressed about us as we were about her and the whole CNCF. And therefore, we have decided to share our story with you today as well. We will let you know from where did we start, what did we do, and what do we have now. I would say, Peter, let the story begin. Thank you, Savina. So why did we build our own cloud-native ecosystem? Why did we build our own cloud-native Ulmo Münster? To understand that, we have to take a look back to the life of a software engineer at Mercedes-Benz in, let's say, 2014. And yeah, it was quite different. It was a kind of different age of IT. We were caught in a classical enterprise IT. Not everything was bad, but it was built with a different mission. It was optimized for cost and not for speed. It was optimized for governance and not for developer experience or innovation. I will give you a few examples. So ordering of a VM or a firewall experience often took weeks. We had a very narrow corridor of software tools, frameworks, middleware that we were allowed to use. And most of it was closed source. Open source was forbidden if not explicitly allowed. And maybe the worst, death and ops were strictly separated. Deployments often were done manually based on a description and change tickets. And that really caused a lot of pain, I can tell you. And yeah, it led to a situation where, on the one hand, our dev teams, they tried to be as agile as possible. They had pressure from the business to deliver features. And yeah, they built their increments, their product increments. But then they often failed to deploy them to production. And that was the setting where some guys from one of our competence groups and all they said together to make our life a bit better. Jens, you joined them pretty early. How did we build our own momentum? So every building needs a strong foundation. Ours was a young team of developers. We wanted to modernize the world of IT operations in our company, starting with a Greenfield approach. We did not care about the enterprise way of running IT. In 2015, we analyzed the options for modern microservice orchestration and chose the new toolkit on the block, Kubernetes. Soon after, we started with a single shared cluster running Kubernetes 0.9 already in production. And for the applications we hosted, deployment velocity was yet unheard of in the company. If you visited the Mercedes-Benz car configurator website like five or six years ago, parts of it have already been hosted on Kubernetes and deployed with a CI CD pipeline. All this in times when even startups did talk about Docker. And the keynote audience in here was like the very first five or six rows. During the first days, we soon realized the single shared cluster will not fit our needs. So we compared the alternatives for Kubernetes fleet management, but there was no vendor distribution out there at the time fitting our requirements. On the other hand, we had engineers within that knowledge. We understood the tech and decided to create our own solution instead and cloud management system. We built it based upon 100% free and open source software, both developed and operated by the same DevOps team. And soon realized the benefits. Something's broken. Instead of worrying about licensing issues and sending in support requests, we enjoy the four freedoms of open source. Not only are we able to run the code, but we also deeply dig into reading it and modifying it if we see need. And of course, we shared back our improvements. During the first days, we still lacked the formal contribution process in our company. So we had to send in patches during our spare time with private mail addresses. But eventually, this was resolved. In the year 2021, Mercedes-Benz, the car manufacturer, ranked under the top 20 companies worldwide contributing to Kubernetes. Remember, we still contributed a Stimler TSS back then if you check the commit history. Today, we are part of the cluster API provider OpenStack Maintainer team. And right now donate cluster API statements to the community. A customer once asked me, now the application is completed. Who will I send this Docker image to so you can run it? And he was pretty puzzled when I replied back, well, you build it, you run it. There's an API for that. You can it. You will have to do it on your own. This was uncommon in a world of ticket operations. Instead, we went first, even automation only. As the blood from brew and with us, the number of applications we hosted, the number of changes just started to pressure surrounding the IT process is still stuck in those enterprise days, driven by Excel sheets, handled with manual tickets. But the cloud approach spread among the IT in the company from getting a firewall clearance to internet exposure, from managed databases to our company internal led script service for retrieving certificates, all of this radius lead times and deploying a new application from month to days, or even minutes. As the OIMA Minster, even after completion, always seems an everlasting construction site for our iterations. We are too constantly renewing our setup, reinventing core technology, following the newest upstream development by joining in community efforts like cluster API management of the Kubernetes fleets. We are able to add amazing new features all the time by reducing the amount of internal code and improving quality. Right now, we roll out Kubernetes 1.23, always balancing out enterprise requirements for stability and developers' needs for breeding edge technology. And of course, we support our app teams all the way on their way to Cloud Native to keep up with the pace. If you're interested in our experiences in not only renewing our infrastructure all the time and following the newest upstream development, but also driving upstream, be sure to join my colleagues Tobias and Sean's talk on first day afternoon in the operations track. So Peter, where are we now? So at the moment, we're running more than 900 Kubernetes clusters worldwide, 24 by 7, all on premises. But we are moving to public clouds at the moment. And yeah, cluster API is a perfect match for doing that. We do have five platform teams, which are steadily growing. And yeah, we started with Kubernetes as a service. But we soon realized that this is not enough. So we had to reduce the cognitive load of our DevOps teams. So we added logging and monitoring as a service, as well as databases as a service. We do have a team which is offering a container security service. And we do have teams which are doing golden passes. That means a kind of preconfigured solution for Mercedes-Benz-specific challenges like the integration of our identity and access management systems. And so now there's just a hand chart for doing that. Most of what we are doing is open source or inner source. Inner source is a kind of open source within the scope of a company. And we are supporting our platforms in a community approach. That means instead of this first level, second level, tickets, stuff, we're just doing, yeah, we have slack like communities, channels, where the application development teams, they can directly contact our platform teams and they can solve problems if there are. And it's much more, we are also helping our dev teams in there with Kubernetes-specific topics or cloud-native-specific topics. And we also can see that application teams are helping each other, which is pretty cool. And I think this really is one of the success factors of our platform. But we've reached much more than that. So we were part of the movement in our whole company from this classic enterprise idea I showed you towards a cloud-native mindset. And it's pretty cool to see that now the ability to run it and DevOps are common practices for us for years. And of course, our Kubernetes clusters are provisioned on the fly. And we do have APIs for firewall experiences. Yeah, but there's even one more thing to add. Some guys from this first, from this first movement or from this first team, they moved on and they did lobbying for open source within the company. And this led to our Mercedes-Benz force manifesto, which I think is pretty cool and we're getting pretty good feedback on it. It basically states a prefer open source strategy. So from open source not allowed to prefer open source, pretty good. And it also is a clear commitment, also from our management, from our CIO to contribute to open source and to play an active role in open source communities. I think it's pretty cool. It's on the web. You can read it if you want to. You can also use it. It's under a Creative Commons license. So feel free to check it out and use it if you want to. Sabine, what else did we learn? To sum our story up, we have learned a lot of the last seven years. One of our main success factors was we simply started, we were brave, we took heart. We started small and thought big and that worked really well for us. From our end user perspective, we can say you will learn so much from using open source technology and the CNCF landscape is a great guide to let you know what is out there and what is good to use. As an end user, you are a valuable part of the community and you can contribute in many different ways. And we would like to encourage you to actually do so. And last, Kubernetes still is hard. Therefore, don't leave your DevOps software and developer teams on their own. Support them on their journey to Cloud Native. Talking about journey, if you are ever close to Ulm, just make sure to stop and visit the Ulmer Münster. And of course, if you want to, you can also visit us at one of our fast growing locations we would love to invite you and have you there. We will be around at KubeCon for the next couple of days together with some of our colleagues. Just look out for the T-shirts. And we would love to talk to you and get in touch with you, exchange knowledge, exchange experience. So if you want to, feel free to talk to us. Thank you very much. Enjoy KubeCon and talk to you later.