 Welcome everybody, quick question to begin with, who's here because the title implies eating chocolate? Okay, those of you are right, but we hope you're now happy that the title wasn't eating your own dog food. So please help yourself get a bar of chocolate, Swiss chocolate, pass it over to the neighbour, and sharing is caring. So welcome again to our presentation about the Swisscom internal application cloud and how we as a DevOps team became customers of it and why and how that's a question to begin. So this is the outline, quickly we're going to talk about ourselves who's talking to you right now, then give some business context, talk about a problem we faced two years ago, then introduce the Swisscom internal application cloud and talk about our journey and our learnings from it. So my name is Roman, I work as a DevOps engineer at Swisscom, I joined the company six years ago and I'm currently working as same team as Fabian. So welcome everybody also from my side, my name is Fabian, so I work as DevOps engineer, the same team as Roman. So I'm mostly engaged in the fields of cloud automation and recently discovering my passion for developing microservices for Spring Boot. First of all, I briefly outlined the business context in which we operate and how this context has recently changed. So we've been running an enterprise service bus for a couple of years now. That means we were focused on aggregate composing orchestration of data and services from our Swisscom back ends and we create easy to use web service for our internal customers, for example mobile apps or front ends. And both models are the classical way of following a waterfall approach, technical requirements came to us from somewhere in the Swisscom. So fortunately things are changing and I guess like many other companies we've been taking different transformation steps, meaning we are operating as a DevOps team, we're following agile values and principles and also important our business model is changing. That means we are less focused on solutions, but more on digital products, which means we try to find a demand and creating more generic solutions. So we are pretty active in the field of voice of IP and messaging. So it's not that black and white, we're in a transition phase, the ESB is still there, but we're focusing on our new business. So in addition to our changing business context, we were facing different technical issues. So as you can see over there, over time a monolith gets rusty. So the same happened to us. We have a tightly coupled software stack containing of a ESB software, a message broker and underlying caching system. And there was a particular use case which was designed just for a small amount of workload. Pretty expensive in terms of caching and messaging. But over time this use case became the one with the heaviest workload. And the whole monolith was getting unstable with the poor performance and we spent a lot of time with troubleshooting and fighting those issues. And so we asked ourselves what to do. On the one hand we don't want to lose the customer and the particular use case, but on the other hand we were pretty annoyed having such an unstable system. So scale out and up was not possible because of technical restriction. So we asked ourselves what to do. We knew that there are concepts and technologies out there which could be pretty helpful for us. For example, applying or separating our concerns with a microservice architecture or so applying the 12-factor app to reduce the amount of troubleshooting and infrastructure tasks. So we knew that stuff, but we don't know how to get started and how to face these technical issues and where to run our new business. So at the same time the Swisscom internal application cloud came up and we asked ourselves is this the right place to run our services on it. Exactly. So in the same time we weren't the only ones looking for such a platform as a service. And in fact in 2016 Swisscom launched a public offering of its own cloud foundry based platform as a service. And then in 2017 it launched an internal version of it called the internal application cloud or in short IAPC. With some services, not too many, just a few ones with high quality and they were thoroughly maintained. So that's the baseline and there are some extensions to it, some custom services for Swisscom. For example an identity service to query LDAP or a smart messaging suite to send texts through an API. Or a handy implementation that assists you in managing connectivity requests to outside of the cloud, to the legacy system, to platforms outside the cloud within Swisscom. So as of today in just 20 months the Swisscom internal application cloud became home of more than 900 orgs in cloud foundry speak, 6,000 applications and more than 2,000 users. The numbers on the graph don't matter that much. It just shows the usage, the consumption just knows one direction, it's increasing every month. And one noteworthy number in my opinion is that currently there are more than 7 terabytes of memory allocated by all applications running in that application cloud. But that doesn't surprise as Swisscom has a cloud journey, a cloud migration in its strategy. So it enforces or strongly encourages DevOps teams to migrate their workload, their applications from bare metal to in the best case to a platform or if that doesn't apply to a container or else infrastructure as a service. We decided that our monolith can be split up in multiple microservices and we want to go for the platform as a service approach. So the last two years in our opinion could be divided in two phases. We had an exploration phase and an exploitation phase. In the exploration phase we got acquainted with cloud concepts, 12 factor apps and stuff like that. We discovered the Swisscom internal services we could use. So in our monolithic application we had to maintain and manage our service by ourselves. We had to have our own implementation and we thought in one particular case where we wanted to have time to live for a document that's exactly what a service like Redis or MongoDB can offer us in the cloud. So drop the old implementation, use the cloud service. And third thing is to completely rebuild our CI-CD setup. From the monolithic approach we had maybe a day, maybe even a weeks until a code change was in production. And nowadays with that new CI-CD pipeline setup we're down to five minutes. A code change is checked in, tested, deployed to test, integration tested or acceptance tested and then deployed to production. But we still control when exactly that change would go live. So the rollout is still done manually with the blue-green setup. So the exploitation phase is more about moving the heavy workload from the monolith to the microservices without impacting any customers. So there's a concept out there from Martin Fowler called the strangler pattern. So we have no idea that we are compliant with this concept. It was more the logical way to do that migration. So this pattern says there's no way to migrate the monolith into microservices at once. So you have to follow three steps, which means you have to duplicate the functionality from your monolith as microservice. And then you move the related workload from your monolith to your microservices and then the third step you can remove the functionality, the particular functionality. You have to do it over and over again until there's no workload left on your monolith and you can phase out your old system and infrastructure. So in our case we had a web server, a reverse proxy with a rewrite engine in place and we have defined and specified every single migration step. That means there were several input parameters like the resource path and there was even soap actions, users and different stuff. So we created revised rules to move particular workloads to new microservices and we were able to do stuff like canary releasing, moving 1%, 10% to our microservice. So we were able to drive some migration and so in our opinion our customers were not having no problems because we were able even to switch back the traffic and that was a very, very good thing. So having the engine X in place, so after a while we realized, okay, for Cloud Foundry there's also an engine X build pack and so we decided it would be good to move the whole workload to Cloud Foundry using the engine X build pack so we can use the configuration out of the box and having the workload over there means in the next step we can apply more cloud-native technology like Spring Cloud Gateway or we are ready now for something like a service match. So we are pretty happy that we are seeing that the service match topic with Istio is in the spotlight here at this conference. So we are ready, so we are waiting for something like that. In our case we also had to put the monitoring on top of our traffic management because we want to see what's going on. That means we are converting the traffic into metrics in the Prometheus and the Grafana system. So we have different metrics, HTTP codes, response size, response time, everything like that into our time series database and so we were able to see how our migration is going on and we kept monitoring the whole stuff. So here's a screenshot from Grafana which is running on Cloud Foundry as well which shows just a single migration step for a REST resource. So we have started to specify the migration step. We have moved those resources to our microservices at the first day. We have started first with 1% and then with 50% and we've checked for a full day, does it look good and even if there are any customer complaints and after the day we move 100% to our microservices. And this is just one example, one migration step. We do it over and over again and move the workload to our microservices. So another important topic was, of course, we're having the old infrastructure running on bar metal and we're having our microservices and after a while we see having more and more microservice even the complexity and the cloud increases and we were looking for something, in our case, a Zipkin which helped us to model our complexity and having an overview that's going on with our microservice infrastructure and furthermore we were able to follow requests with IDs and see in detail what's happening and how we can troubleshoot the whole stuff. So in particular for the Zipkin UI we were looking for something that was not available in our marketplace. So remember we are cloud users, we're not the cloud team so we're consuming stuff from the marketplace and for us it was some kind of life saver those extension points from Cloud Foundry. So having build pegs, creating your own build pegs, having Docker images, having user defined services was for us very important to set functionality which was important for us but it's not available to have in place. Next we would like to spot some points out which we think are very important for our migration and maybe are also important for someone who's doing similar things. Yeah, of course, consumers first. I mean our consumers they don't care if the request is handled as a microservice or as a monolith, they don't care. So it's our business to make sure that there's no impact for them. So with applying the strangler pattern we were able to do it in very little steps and of course we talked to our customers and are keeping them in the loop but we want to be on the driver's seat, we want to move the workload, if necessary so there's one very important step we thought of our customers and do it the agile way in small steps. Focusing on our business means, as you can see here, it's just an overview of our tech stack having in place before our cloud migration and the important point here is we were responsible for every piece of software which is shown here. We were responsible for troubleshooting, for optimising, for tweaking, it was our business to do it good. And having the cloud or cloud foundry in place as a first phase it means there's another layer, another complexity, but we see when we're using standard services and community stuff in the third step when moving the monolith away as a container there's almost nothing left that we're responsible for. There's just the spring boot application and our code that's our business and we are responsible for that. Everything else, the services is placed at our cloud team and that was very valuable that we can focus on our main business. Scalability, our monolith wasn't scalable. With microservices we knew we could scale but we still had to figure out when or based on which metric we want to scale. So we introduced metrics and kept them monitored in Prometheus and Grafana. Then because we don't have something like an auto-scaler in place yet, we have to manually scale out or in. So that's one point we learned. The other thing is by removing code, unused code we implemented six years ago that nobody ever used. We could still free up resources and hopefully in the future when new features come we can implement them directly. We know they are used and we see if there's heavy use on it we can scale appropriately. The third thing is in our opinion it's important to use the right tools or the right framework for the job. We think in our case spring, spring boot, spring cloud was the perfect framework for our problems. We're still fascinated to see how easily cloud foundry, spring and external services like RabbitMQ work together. So in Westime, check which framework is the right for a job and benefit from it. So our journey continues. It's not yet over. There are still things to do of course. The ESB is still there but we're waiting for a container as a service offering available within Swisscom. If it's there we can bundle and ship the remaining functionality from our monolith as a container as a service platform. And if it's done, so there's almost nothing left... I'm sorry. The slide was missing. So when we're able to ship the remaining part as a container to container platform there's nothing left and we can remove the whole network infrastructure stuff and the certificate and the VMs and everything which is on bare metal. We can just remove having the stuff on cloud foundry and the container system. Furthermore, we want to embrace features like the autoscaler to be more efficient with our resources and last there are security features or we are waiting for something which is available for our security needs for CretHub so we are in touch with our cloud team and as soon as possible we want to integrate CretHub in our setup. So first, thank you for your attention and also a big thanks to our cloud team which brought the cloud foundry platform to us which allowed us to redesign our stack and to be ready for the new business. So thank you very much. Questions? Thank you. Can you elaborate a bit on the remaining stuff that don't fit cloud foundry yet and needs to be bundled into a container that's not 12-factor compliant can elaborate a bit on your last slide? This one? Yeah, first line. The remaining parts they don't fit into cloud foundry that's why you bundled as container can you detail a bit why they don't fit into cloud foundry? Yeah, you're right. It's an option. We can think about in our case it's a Mule ESB we could try to run it as a container or as a build pack with a Java build pack on cloud foundry but there are still some additional processes which are connected to this ESB so maybe it's easier to us to have a container and attach additional services for monitoring which are pretty close to this functionality but you're right, the Docker functionality is there but in our case we feel more comfortable to have it a container run time for our ESB. Good. Then okay, thank you again and if you have any further questions just come by we're still here.