 Hello, my name is Joseph Meyer. I'm an electronics engineer and cloud architect at the company Rode in Schwartz, a German Munich located company. I am an OKD user since 2018 together with my team. And this is a story how we came from OKD to OpenShift in three years. We had started a digital transformation program in spring 2018. And the goal was to get the skills in my company to build up digital business. And one of the first goals was to create an MVP of a cloud product for a trade show that happened in autumn 2018. That's only five months after the start of the program. And this was very tough for us because we had experience with Docker but not with Kubernetes. And it was clear to us that we wanted to do that on Kubernetes. And the first task was this MVP was to provide Kubernetes clusters, two ones, one on-premises for our developers because we have the policy in my company that no source code ever has to be available in the public cloud. So we had to create a cluster on-premises for our developers so they can access the source code and do builds for their artifacts. And the second cluster should be in the public cloud so our customers can access them because we don't serve our software from our on-premises cluster to the internet. We have separate clusters for that. That was the goal and the first task and the race started. We had a few requirements for that. At least there were three very important ones. The first one was don't pay any license fees for the Kubernetes distribution because we started with our digital business and we didn't want to have a burden of license fees on them. And the motto was let the business grow first. That was the most important requirement in the beginning for us. The second one was the system must be stable. That's obvious, but we learned that it's not so easy to achieve. And the distribution should take care about everything that you don't want to mess around normally with networking with storage and a few more things. We learned a lot about that. It's a hard way that it's not easy to maintain those things if you have to. Also, if you look back, it's one of the biggest and most important requirements you should take into account if you choose Kubernetes distribution also. The third requirement was that we would like to have the same stack on-premises and in the public cloud and the same user experience so that our developers don't have to switch around in their minds with the usage of the tooling or the independence of if they use the on-premise cluster or the public cloud cluster. We wanted to have a look and feel that's the same everywhere. Then we went into an evaluation phase. Five months is very tough, so we rushed through that very fast. First, we tried the obvious. We used vanilla Kubernetes to create our first clusters on-head, take care about everything on our own storage, networking, usability was disastrous in the beginning. We gave up very soon. That was not the way we wanted to work because it was our company that we were searching for something better. We tried out several community-driven Kubernetes distributions. We didn't want to name them, but we had mixed experiences. We had problems with stability. I remember one tool that had an automatic installer for clusters and every second installation failed because of bugs. User experience was not so good on the others. We had no good feeling that we are on the right track. It was a very tough time for us. During the evaluation phase, it was a pure coincidence that we attended a sales presentation for OpenShift because OpenShift violated our most important requirement that we don't want to spend money for our Kubernetes cluster. You remember, we did not want to have a burden of license fees on our digital business, but it sounded very good. What we heard here, the salesman did a very good job in this presentation. He told us that there is a free community-driven edition of OpenShift called OKT. This is something we never heard about during our research. It was awesome because on the paper, it was free. It was a turnkey solution, very similar or at least almost the same as OpenShift regarding the features. It took care about storage network, had a nice UI at that time and great DevTools took care about builds. Everything was integrated very good in the web UI. It was great for our developers. We also got very good feedback from them. The third one was said, OKT3, we could install it everywhere on-premise, on our vSphere clusters and in the public cloud in Azure. It was very easy to get clusters running. We had lots of configuration options. We had Ansible out of the box coming with OKT that did the installation. It was great. We tried it out. We used it for our MVP in the end and we successfully developed our MVP on the Trajo running on OKT. Management was very happy with us and it was a cool time. It was very stressful, but we learned lots of new things during this phase. A year later, in 2019, we delivered even more cloud products. We were the heroes because we enabled all of them with a great distribution. In 2019, everything was cool. With OKT, we were very happy. We didn't regret that we chose it. Also in 2019, we improved and automated our cloud ecosystem because for the MVP, we have taken lots of shortcuts and workarounds because we were not so experienced with Kubernetes and the next goal was to automate everything. We found lots of tools that helped us a lot in this phase. Ansible, we had experience with that before. I found Terraform. That's an absolutely great tool for creating infrastructure with different providers. It's available for vSphere, Azure, AWS for everything you can imagine. We used Terraform to create the infrastructure and Ansible to install and configure OKT. Then we created the ICD pipelines. I liked a lot that OpenShift had great support for Jenkins or has great support for Jenkins. Everything is tightly integrated in the web UI. That's nice. Also, we created our first self-service portal. That's a tool running on our cluster that provides our developers simple wizards in a web user interface where you fill out a few fields and get tasks done on the cluster like setting up a CICD environment with Jenkins, with the proper secrets, everything completely automatically set up. People liked that. Yes, it was very cool. We learned a lot at this time. In the beginning months, we learned that the last release of OKT 3 occurred in autumn 2018. No new version came out. At that time, OpenShift 4 in the beginning of 2019, I think OpenShift 4 was released, but no OKT 4 was available. All over the completely year, no OKT 4 was inside. This was a problem for us because more and more tools did not work on OKT 3 because the Bonitz version, I think it was 1.11, got 2.0 for lots of tools and we had to wisely choose which tools we use. This was manageable, but we were waiting for something new for OKT 4 and it did not come, so we started to learn what is blocking the release of OKT 4. Myself, I tried OKT 4 Alpha in November 2019. I remember that because I had a colleague of mine who was a master of our DNS server and he spent Saturday evening or Saturday night together with me in a Skype session to set up everything we need for OKT 4. He helped me debugging the first steps and in the end it worked. I saw a web UI, I was so happy. I remember that this web UI was so much advanced over that we already laughed with OKT 3. It was so much better but it was not easy to get there. I had to do lots of mental steps hacking around in the Linux console to find problems, why the installation failed and it was an alpha, it was OK. It worked on vSphere, very good. If it ran, it ran very pretty good. I dove deeper into development. I found this OpenShift DEF channel on Slack and I also found out that there is an OKT working group. At first I thought this is a closed club of Red Hat employees but learned very fast that everyone who wants to help can attend this working group. So I did. The goal was to help do my best what I can do to bring OKT 4 live. That's what I did in 2020. I started helping with OKT 4. I created a few fixes for the installer for Azure. For example, because Azure at this time was not supported by OKT at all. There were a few problems with Fedora Chorus that is used in OKT in comparison to Red Hat Chorus that is used in OpenShift. There were a few problems with that. No big ones, but this was my first attempt to create pull requests to the OKT 4 community. My first PR was so big because I also patched Terraform code and it was far too big and Badi Brutkovsky, one of the main supporters of OKT was refusing it. He used some nice words. I don't remember. I was sad that it was refused but he told me it was too big to understand that I created a much smaller PR and this one was accepted then and Azure was available for OKT. This was my first steps. I did lots of testing at that time. I built up a homelab at home with the Horizon PC and 16 cores. I never used them to that level but I wanted to be sure that I'm not blocked by anything. I did lots of testing. I also organized vSphere license. There is some trial. It's not a trial. It's called VMware User Group. I don't remember exactly the product name. It's available for 150 euros. It's very affordable. I did all of that because I wanted to get OKT for life. I reported lots of bugs. I fixed several of them. Not all bugs are so complicated to solve. I found out. This was the time where our team learned much about the insights of OKT for that we can use the mechanics to solve almost any task we wanted to achieve. It's a great thing. I also did something that may sound a little bit crazy but I created a t-shirt for the working group video meetings. I always attended them regularly. The idea was to increase the release pressure. If everyone always sees this OKT 40A on my shirt, it's what's not so. It was more a funny idea. I promised to not change the shirt before the release. It has been made, but it took a few months. I have to admit that I changed the shirt in between. I never told that to anybody. Finally, OKT 4 was released in July 2020. It was very great because we had already prepared OKT 4 clusters on premises. We installed everything and only were waiting for the GA signal. A few months before, I discovered ARGA CD. That's a tool for GitOps. I found out that with OKT 4, it's very easy to configure things with GitOps because there are operators everywhere. You can use custom resources. That's a configuration method of operators with GitOps. This is also great. You have everything in Git. No scripts running once and developers are changing configuration and nobody knows afterwards who has changed what because everything is in the cluster. Git is a single source of truth. That's nice with ARGO. Especially in combination with OKT 4. We changed our service portal to use GitOps because of that. We also migrated all on-premises apps from OKT 3 to OKT 4. We had to change the routes and other few things. The DNS name for OKT 4 contains a part that is called apps in the URL. That's a little bit annoying, but we had to change that for all our apps. In the end, it worked. Since July 2020, we upgraded OKT 4 on-premises very often. It almost always worked great. Between OpenShift 4.6 and 4.7, there were a few hiccups, but we could always fix it or find workarounds together with the community around them. Since 2018, we attracted many of our developers to start a Kubernetes journey on create a digital business on our Kubernetes platform. That's great. I counted last week that we had onboarded more than 50 projects, not only playgrounds, but real projects on our OKT clusters. It's available for more than 2,000 developers in my company. It's running very stable, but we are moving more and more business-critical applications to our OKT clusters. We have a big manufacturing site to be more precise that also wants to use Kubernetes and cloud services. That's why we decided to invest at this time in commercial support because we have digital business running. We have lots of interest in my company. We have business-critical applications and we always say that this should be the time to invest in commercial support and we did that a few weeks ago. We started creating an arrow cluster. That's the abbreviation for Azure Red Hat OpenShift on Azure for our public cloud cluster. That's the customer-facing one. On-premise, we invested in OpenShift or there is also a... What was the name of that? OKE, OpenShift Kubernetes Engine. It's not OKT, it's OKE. Don't ask me why I say something so similar. OKE is a version. It's OpenShift. In fact, you have support, but not for everything and we are not using all the features of OpenShift at the moment for all our environments and because of that, we chose OKE for some clusters and OpenShift is then the full-fledged version for the services we need full support. For the moment, we are very happy with this decision and to conclude what I told you in this presentation, I am absolutely thankful to have OKT during our journey. It helped us tremendously to launch our digital business. In our opinion, OKT is a great door opener for OpenShift and enterprises because you can have OpenShift with zero risk to start your digital business. You have the same user experience. A few things are different regarding upgrades because in OKT, you only have a rolling distribution. This means that if something is fixed, it won't get backports. It's always going forward. In OpenShift, you have several stable or forced channels. But if you don't need that and in the beginning, you don't need that to be honest, then it's a fair deal to don't pay any fees and you have a full-fledged, great Kubernetes distribution. I congratulate Red Hat for the decision to have a community version of OpenShift in the programme because, as I said, I think it's an epic door opener for their main product, OpenShift. I have to say thank you to everybody from the OKT community and Red Hat who helped us in the last years that we came to this point. Special thanks go to Wadim Rutkowski, Christian Glombeck and Diane Muller. They always were very helpful. Wadim seems to be online 24-7 on Slack. Without these guys, we would not have managed the first steps with OKT for and thank you all. This was our journey. It took us three years. Now we are absolutely experienced in Kubernetes. I can compile some modules on my own. We know the insights of OKT and Kubernetes very good. We help in the community in several projects. Thank you for watching. If you have questions, I am available in the chat. That's a wrap.