 I'm Alan Flour from HCL. I'm joined by Thomas Davos. We're here to show you something quite interesting today. This is the first time you would have seen this in our industry. We're at an event called CubeCon. And it's easy to think that in the world of container orchestration platforms, Kubernetes is the only platform that counts. In fact, there are two significant container orchestration platforms in our industry. Kubernetes and Cloud Foundry. How many people here have ever heard of a project called Cloud Foundry? A lot of people. What's happened in our industry over the last two or three years is the gravitational pull towards Kubernetes has been overwhelming. It is now the de facto orchestration platform. An open-shift, of course, is the market's most dominant containerisation platform today. What we're going to show you now is fully automated migration from Cloud Foundry to open-shift. If there is one request that we've heard more than anything else in our industry over the last two years, it's from Cloud Foundry users who are desperate to leave a stagnating legacy platform and move all of their workloads to open-shift. You may be familiar with products like Pivotal Cloud Foundry. You may have heard of products like VMware Tanzu. You may be an IBM Bluemix or Cloud Foundry user. These are all commercial distributions of Cloud Foundry. So what we've built is a fully automated journey to take you away from Cloud Foundry to open-shift. We're announcing today at this show support for all of the major commercial Cloud Foundry implementations, Pivotal Cloud Foundry, VMware Tanzu, and so on, but we also support migration to open-shift from any other Kubernetes platform. This is fully automated, no human intervention migration, which we are going to demo to you. You're going to see a demo where we migrate stateful as well as stateless production workloads from a live Cloud Foundry platform. It's running in our lab today in Dallas, and we're going to show you how we move from Cloud Foundry to open-shift. The open-shift instance we're using is running on Google. This is a fully automated journey. We automate absolutely everything. You only have to make three clicks and we do the work for you. We do complete vulnerability scanning, so we're checking for the consistency and the security of any workloads that come across to open-shift. This is a fully automated journey. The best thing I can say to you is rather than me talk about it, we're going to show you this. It is so straightforward. Thomas, if you'd like to join me and maybe take over and maybe just describe what we're going to show, I think. No, not yet. Now you can hear me. Are we awake? Perfect. That's good. Thank you, Alan, so much for the introduction over here. I would like to demonstrate over here live how we can migrate a Cloud Foundry workload onto open-shift. This is the demo setup I have over here for you. We have the Kubernetes migration platform, KMP, deployed on GCP, first and foremost. We have KMP tags with a couple of agents deployed on a VM, and the purpose of those agents is to keep connectivity going with, in this case, TAS, like Alan was saying in Dallas, into our cloud-native labs. On the right-hand side, you see the target, which is open-shift. I'm going to bring up now a drawing application, which is running on TAS. I'm going to try to move the workload and the data onto open-shift. I can't see this very well. This is the Kubernetes migration platform. I have currently defined two agents, as I earlier said. The first one is the open-shift one, and you can see here the endpoint. The endpoint is connected to open-shift. It does the automatic discovery over here. I also have an endpoint configured here connected to VMware Tanzu. You can see I have over here one application deployed. This is a Spring Boot application. It has a back-end or managed service of my SQL. This is the drawing application I was talking about, and hopefully I will try to bring in my creative skills over here and do some drawing over here. It's a bit more difficult with this mouse, but okay. Hello, KubeCon. Let's try. Anyone else has better artistic skills than myself? I think we get it. All right, okay, perfect, that's good. This is kind of the application. I am storing the state of this fantastic drawing into my SQL. Next, I need to kind of go to my Kubernetes migration platform. I am going to define a plan, and a plan is nothing more than defining what do I migrate from and to. Over here, I give it a friendly name, OpenShift Commons, and I want to migrate all the applications deployed into the default space. In this case, there's only one application to OpenShift. I have my plan created, and the next thing I need to do is just simply click on Migrate. So now the migration has started. The intelligence behind the Kubernetes migration platform has started. What are we doing over here? We are first and foremost discovering what applications we have running. In this case, one application, this is a drawing application. We are getting all the artifacts, we are getting all the binaries, and we are downloading this into a central place. From here, we are creating a new docker file in order to create a container image. The container image is currently being created in the background. Once that has been created, we will store it in Docker Hub. The reason we are storing this in Docker Hub is because we need to create, as well, a set of manifest files to deploy into OpenShift. We are creating those manifest files from the ground up with a reference to the new container image that we have created. We also have discovered that we have a MySQL database. This is a little bit more trickier. We need a request from Client Foundry the endpoint of that managed service. We have discovered that we have a MySQL database. We also have support for Postgres. We also have support for Redis at this moment in time. Once we know what type of database we have, we get all the metadata, database tables. We get also the data out of it. We store it again into a central place. Now we have all the artifacts. Now we can start recreating this in OpenShift. We are having a sync module that syncs the data between that central place into Kubernetes. We have created a new instance into a namespace on Kubernetes, in this case, on OpenShift. Migration is currently happening. The other thing that we are doing is creating a number of Kubernetes manifest files. We are trying to match the storage, networking, endpoints, egress, DNS, all these kind of good things onto OpenShift. We have a lot of intelligence built in there in order to map whatever was there deployed into Client Foundry and also in OpenShift. I suspect that this migration will take about three minutes. The same kind of automatic migration we do as well for Kubernetes or any commercial Kubernetes platform onto OpenShift. Whilst this is running, are there any questions? No? Okay, let's see. There's one question here. Left-hand side at the rear. Tell me? Sorry, I can't hear you very well. We're just migrating the binary. We're getting all the artifacts, the JAR files, the WAR files, whatever has been deployed. We are recreating the original container that was been running into Client Foundry and are we creating a new container in which we store this in Docker Hub and not the source code. We're going to have to migrate the source code manually if that's what you would like to do. I guess that goes into your normal software engineering process anyway. It's completed. Here you can see after three minutes and 19 seconds the migration has been completed successfully. The only proof in the putting over here now is that we go to my OpenShift cluster and see if this one actually happened successfully. Let me open this one. Yes, indeed, I do have now a drawing app deployed into a namespace. Let me have a look at the endpoint over here. Here you go. Application fully migrated, automated in three minutes and 19 seconds. Thank you. It's encrypted into a central repository. That's right. We are here in the coming three days as well at KubeCon. We are at Boot G1 as part of HGL, so if you have any more questions either for the Client Foundry 2 Kubernetes migration or you have further questions around any commercial kind of Kubernetes migration onto OpenShift, we are more than welcome to show this more in detail or if you have more detailed questions, feel free to come over. Thank you so much.