 Well, hello everybody, wow, so good to be here at the OpenShift Commons in San Francisco. And thanks for the really amazing talk so far. It's always interesting to hear other people's views on the technologies you're using yourself. So thanks a lot. Next we are going to talk about OpenShift. Yeah, no kidding. To be more precise, we're going to talk about the software engineering model that's in use at ELISA and how OpenShift enables us to implement it in practice. First, shortly about ourselves. My name is Severi Haverla, the guy on the left. And the fine gentleman next to me are Niklas Tamskanen and Jesse Haka. And all of us three, we work at the DevOps team in ELISA. What we do, among other duties, our task is to keep OpenShift up and running, but also support the development teams so that they have a kind of a pleasant journey with putting their applications running in containers and OpenShifts. I guess there might be some people among you who are not from Finland. Yes, so I guess it's a good time to introduce ELISA to you. So, yes, sir. Okay, so what is ELISA? ELISA is Telecommunications, ICT and Digital Service Company and a market reader in Finland. And during our 135-year history, we have always been enthusiastic about utilizing new technologies and ways of working. We now serve over 2.8 million customers in Finland, Estonia and internationally. And back in the days, we were just a typical telecommunications company, but nowadays we are much more than that. We are working in business units called software services, which is mainly focusing on digital services. And one of our biggest services is called ELISA Viihide, which is kind of entertainment system where you can train movies and watch live TV channels. All right. And then just a few words about DeFiCode and more importantly about the collaboration between ELISA and DeFiCode. So, Severi and I work at DeFiCode. DeFiCode is a leading DevOps house in the Nordics. We have almost 200 professionals in the Nordic countries. And what we do is that we enable organizations to reach the fullest potential in today's digital world. And with ELISA already being leading telco and forerunner in digital services, it has been truly been a joint effort doing these great services together. And we work together in areas like DevOps or Design and UX. And we have done so for almost a decade. And we also organized multiple cutting-edge events together, such as the DevOps 2017, which was held last year in Helsinki, or the Design System Conference, which was organized just lately also in Helsinki. And what we aim to do as an organization is to learn from each other and do and build great stuff together. But enough about that, let's move on to the topic of the day which is going to start by introducing the software engineering model at ELISA, which is a model that describes how software direction and software development should be done at ELISA. And it comes to around three points. First of all, we need a platform. We need a platform that can run those services and the development of those services. And we need that platform to be fast, efficient and flexible. So I guess you could say that it needs to be software-driven. So let's call it software-driven cloud. And when we have that platform, we want that development of those services should be done on that platform and it should be easy and automated. And when it's easy and automated, that leads to faster learning, faster development with smaller iterations, meaning faster time to production and less errors. And more importantly, it enables the developers to feel that they're getting stuff done because that's very important when you're developing something that you can actually get stuff done. And finally, we want to shift the end-user experience to the teams themselves, meaning that the product in production should produce meaningful metrics to the development team so they can take action and develop the product in the way that the business sees it. And another thing is that the development team should have easy access to production, meaning that the pipeline from the Git commit to the production is fully automated and every developer has access to it. And the next essay is going to tell you more about the software-driven cloud history. Okay. So 2016, we started to contribute to Kubernetes and we are doing also that nowadays. But so we had separate Kubernetes clusters for every team, but we saw that it didn't work quite well because we didn't have enough kubeski-led people in-house. So we started looking for something else and we decided to use OpenShift for everybody. 2017, we had one OpenShift cluster for everybody, but soon we saw again that it is not maybe the perfect solution. We had problems with stability of that cluster. And when we had only one cluster, it was not good situation at all. So 2018, we had nowadays two products and clusters and two development clusters for everybody. And because we have two OpenShift products and clusters, we need some kind of way to load performance traffic between these. I have seen that someone uses here DNS-based solution, but we think that it is not maybe the perfect solution because we want that we have application failover capabilities. And we can archive that with load balancer. So we have decided that we have load balancer in front of these clusters and how we are updating this load balancer. We have in-house made solution for that and it basically means that it is installed for every cluster and it is listening load changes in OpenShift and then it is updating that load balancer configuration automatically. And it means that, for instance, if you want to create new application for DC-1 cluster, you can do that and then the load balancer will just make the traffic for DC-1 cluster. And this our solution is available in GitHub, so if you are interested, you can take a look how it is made and how it works. And our next target is to get more projects to production. All right, so how do we get those projects into production? Well, as we see it, we have to get the developers engaged. Well, how do we get that done? So it's actually really simple. We just use the force. We burn all the silly VMs to the ground and just force them to use the containers and put them running on OpenShift. Let's have a quick life demo of this. So everybody in the audience, please stand up. Yeah, that's what I thought. You can sit down if you did it. So forcing people to do uncomfortable things, it doesn't really work out that well. So that wasn't the way to go. What we actually did is that we took a pilot project. So enter Elisa Vihde. So as you've heard, it's an entertainment service. You can watch live TV, rent movies and stuff like that. And so back in spring 2017, Elisa Vihde was starting a new project. They were having like a full renovation on their video rental service. And we thought that that's the perfect opportunity to us to implement the software engineering model in practice and also use OpenShift to do it. So what we did is that we sat down with the development teams just to see how they were producing software at that point. And we saw that they were using Jenkins as their primary CI CD solution. And how they were deploying into production. They had these VMs that they were deploying the software using Ansible. And they weren't really familiar with containers or container orchestration platforms and such. And in general, I guess they were interested about OpenShift but also quite a few people were a bit skeptical as well. So as all of you know, developing with containers and putting the production running on top of them, it's a whole different game. And for that reason, we wanted to start out with something that's familiar to the development team. So we took Jenkins and we put Jenkins running on OpenShift. And we integrated the CI CD pipelines with OpenShift using the OpenShift Jenkins plugin. And bit by bit, the development teams, they got a bit more interested about the platform and kind of saw what it's capable of. But also when we were doing it, the complexity grew quite fast. We wanted to add different kinds of functionalities to the pipelines and such. So in order to keep everything maintainable and also keeping the pipelines readable, we decided to create our own shared Jenkins library on top of the already existing OpenShift Jenkins plugin. Next, Niklas is going to talk a bit more about the shared library. So why we created this library? Well, the OpenShift did not provide support for things that we wanted to do out of the box. Neither did OpenShift Jenkins plugin. So we built out a library on top of the Jenkins plugin. And we introduced multiple features like multiple production cluster deployments, meaning that the Jenkins pipeline will deploy application to both of the production cluster that we have. We also had Canary deployments introduced into the library so that the developer has easy access to that, integration test and environment setups, goat analysis. And one of the most important features of the pipeline is that it's able to do preview environments. We deploy every branch of the application directly into OpenShift and the dev environment. Going to demo that in a bit, but first let's go over to the demos. And the first demo that I'm going to show you is that how easy it is for the developer to get started on a new project in our environment. So here I am in one of the dev clusters. I'm logged in using single sign-on with Elisa credentials. Everyone has these credentials already. Everyone can log in into the cluster and create the new project. I've selected Jenkins from the catalog. This is an Red Hat provided Jenkins with some modifications and I'm deploying it here. And before the Jenkins container starts, it's going to boot up an init container in front of the Jenkins. And this init container is going to ask the developer a few questions about the plugin configurations in Jenkins so that I don't have to write any guides on how to do the configurations. The developer just simply will ignore them and not use this platform at all. But with using this wizard here, that this cool wizard that tells what to do actually, I can engage the developer easily into the development in top of OpenShift. So I have some features here like GitHub single sign-on. I can add admin users here, organizations from the GitHub. And in the moment, the Jenkins is going to start with the configurations that the developer just put in. I have also here set up the Jenkins slave images so that the developer really has a fast start using OpenShift. We also integrated the library that we talked about into the Jenkins. And this way, he or she can just copy paste the pipeline example to the Jenkins and right away can deploy stuff into OpenShift. And this all takes about 15 minutes. And the next demo is about the preview environments. Before I start the demo, I'm just going to tell you that I have a small app here that says greetings from the Spring Boot. And I want to change that application's background to red. So let's go and see how do I do that. So here's the app. Here's the pipeline that builds it in Jenkins that I set up previously. Here it is in OpenShift deployed by the pipeline. And what I'm now going to do is I'm going to check out a new branch. And I'm going to modify the code so that the background is going to be red. And here we go. Git commit and then push. And now it's in GitHub or Git. And going to the Jenkins, it should have received the web hook. Yes, there it is. It received web hook from the GitHub. Please start building this branch. And what now happens is that the pipeline is going to build the infrastructure that it's requiring to the OpenShift. So here I am. It's already being deployed. And you notice that it has a hello word dash red so that it has the app name dash branch in it. And if we go to the shared library here, this is one of the template files of the library. This is a root object template file. And what the pipeline does is that it substitutes these variables on the template file with the variables from the pipeline. And if I now get the root from the OpenShift, and this root here was created by the pipeline using this template as a basis. So this way the developer really doesn't even have to know about OpenShift objects. And if I now fast forward the build and change the URL from the master branch to the red branch, I have a red background. And I think that if you were fast enough, you saw that I only used the git here. Everything else was fully automated. The OpenShift was automated. The Jenkins build was automated. Only thing that I did was a simple git checkout and git commit and git push. And this really enables the developer to have a very fast start with OpenShift and start hacking about stuff. And if you think about UX designer, he or she can now change the layout and just do a simple git push and it will end up in OpenShift. And they can share the root with the product owner or business owner immediately. So they don't have to set up the dev environment into their own laptop. All right, so of course all of this, it wasn't just a walk in the park. We had some challenges as well. Maybe the first one is that keeping the development teams engaged with the CI CD practices and with OpenShift. It's actually quite challenging. Our initial plan was to provide really good support in the beginning and then kind of slowly allow the development teams to take full ownership of all their pipelines and kind of fade into the background and let them handle their stuff. Well, it didn't really work out that well. Quite soon we realized that we were providing too good of a support as the developers actually fully relied on us on all their CI CD OpenShift-related needs. So lessons learned. You really have to try to find the balance on between supporting the teams but still kind of allowing them to make their own mistakes and so that they actually take full ownership of their stuff. But then again, it's also really important to have kind of a smooth learning curve with the platform. Of course this depends on the people. Some people are more interested about new things but some people don't really like to change the ways they are working. So if you are already a bit skeptical about the platform and you have a bad first impression, you start blaming all the problems on the platform itself. So that's what happened a few times. OpenShift was blamed for many of the bugs that were actually code-related. Lastly, creating Jenkins shared libraries it's not always that fun actually. It's sometimes really hard to test them. The development is quite slow and stuff like that but these are things you can actually live with and kind of mitigate as well. So next is the fun stuff. Yeah, during our time with OpenShift so far has proven that it can handle the workloads that we throw at it and maybe a little bit good the one day the Elisabeth project lead came to us and is it really so that when the pipeline finishes the stuff is in production? Yes it is. And they deployed accidentally to the production already. And we are eager to see how the platform evolves even further. Okay, thanks everybody.