 Hello all, I'm Faisal Kather. I'm a specialist essay in the sales team that manages this account. I specialize in OpenShift and related red hat technologies. I'm Kubernetes and OpenShift certified. I closely worked with Lance Preston, the infrastructure architect from BOKF, in setting up the different OpenShift clusters until production environment. On these clusters, IBM Cloud Pack for automation with its final product is hosted. I closely worked with him, helping him navigate through all the challenges with the infrastructure and provided the necessary enablement to help him complete this effort. Working together, we managed to tackle all the roadblocks and have led to this great success story for the bank and red hat. I'll hand it over to Lance to share his experience. Hello, my name is Lance Preston. I am an infrastructure architect with the BOK Financial Corporation, which is headquartered in Tulsa, Oklahoma. I'm here today to talk about banking app modernization via the IBM Cloud Pack for automation on the OpenShift container platform. We started our app modernization journey basically in the fall of 2019 when we began planning to replace our legacy file net platform. I believe I'm sharing that information on screen now. I'll talk about what our legacy platform looked like here in just a minute. But basically, at that time, what we needed was a solution that was going to be supported for the foreseeable future, as well as being more easily scalable and that could support the needs of our business, which included adding some additional products within that content management platform provided by IBM. So in the fall of 2019 is when we really began talking seriously with IBM and Red Hat about building out a new environment for our content management platform. And it was at that time that they suggested that instead of using the... just upgrading the components in our legacy platform that we look at going with containers and Kubernetes and specifically, the OpenShift platform. So I'll talk a little bit about what our legacy environment looked like. So we basically had the IBM FileNet P8 platform, which was version 5.2. We were running the IBM Content Navigator kind of separately as a front-end to FileNet for our users to access the documents and the content within FileNet. This was all running within the WebSphere application server network deployment edition, version 7.0 and 8.5. We had a combination of both, and these were connecting to an Oracle database that was clustered within PowerHA. All of these were running on our IBM Power8 hardware, running the AIX7.2 operating system. So I will kind of show you what that looked like from a visual perspective here. I'm not sure if I can get that any larger. There we go. So basically, so all of these are AIXL powers in our IBM Power platform, our Oracle database, that these L-Pars, which are the content platform engine, which is where the majority of the content is served up, and it is stored on our network-tap storage platform on-site. This is all on-premise, by the way. And then the content navigator applications, which were load balanced and would front-end the content platform engine applications. We also have kind of a legacy piece that's called the application engine, which is used by a couple of other lines of business. So all of these are, so the AE servers, the application engines were running WebSphere, Network Deployment Edition, version 7.0. The CPE servers were WebSphere, ND8.5, and the content navigator was also WebSphere, ND8.5. These are all separate AIXL powers in our on-prem Power 8 environment. So growing this and expanding this is a little bit of a chore. We can obviously add additional resources to each of these servers as needed, but if we need to stand up another server to scale out the environment, that's obviously a lot of work. We have to build another AIXL power. We have to install WebSphere. We have to join that into the existing cluster and get the applications deployed to that. So the solution that we came up with, with IBM and Red Hat, was to deploy what we consider our modern environment, which is basically the IBM CloudTact for Automation. So we are currently at release on the redhat.0.3.6.2 for the CloudTact for Automation platform. That is running in a Red Hat OpenShift 4.6 environment on our on-prem VMware vSphere 7 platform. So these, all of our Red Hat OpenShift nodes are just essentially Red Hat Linux core OS VMs running in our on-prem VMware platform. We have the IBM CloudTact for Automation deployed to that environment. We are still running the content platform engine, which is the IBM FileNet P8 product, but it is the later version. It's version 5.5. It also is still front-ended by the IBM Content Navigator, which they refer to as the BAN application within the CloudTact for Automation. But these are now running WebSphere Liberty within the containers, within this application. So here's kind of a visual of what that looks like. Well, and we all also, all of these environments are still connecting to an Oracle database on-prem that still resides in our AIX platform in the IBM Power 8 hardware. So this now looks like this essentially. So we have our on-prem VMware cluster, which is a couple of dozen servers, at least in our production environment. And those VMs are our Red Hat core OS nodes. We've got the three master nodes. We currently have four worker nodes that are all running Red Hat 4.6.16, I believe is the version we're currently at. These are all on-prem VM data source in our VMware environment on our enterprise stand. We have a management node that is used to deploy the applications, right? That's where we run the OC or the kube control, you know, command line interface for the cluster. We do also use the OpenShift GUI for management of that cluster from time to time. But a lot of the tasks that we do, we do command line through this management node. This all is still front-ended through our on-premise load balancer appliances. And then all of the cloud pack for automation applications, those containers and pods, right? They reside within this cluster, right? They run on various nodes within this cluster. And then the persistent storage for those applications, as well as our content within the FileNet platform, is still on our NAS platform, right? Our network attached storage. And then those environments still connect to our on-prem Oracle database instances, which are clustered together in a PowerHA environment and running on our AIX72 platform. And again, this is all on-premise. So it took us quite a while to actually get to this point to get this environment stood up. There was a pretty steep learning curve from our perspective to be able to get this environment in place. But we did receive a lot of help from both Red Hat and from IBM. Red Hat specifically on getting the OpenShift cluster stood up and working, and any problems we had with that. And then, of course, IBM with the cloud pack for automation packages that we got deployed. We struggled with it a little bit, but we were able to overcome any issues or difficulties that we had with assistance from both of Red Hat and IBM and have a test dev cluster stood up, as well as a production and a disaster recovery cluster stood up. This image is depicting our production cluster. But now that we have this in place and now that it's stood up, right, scaling out these applications is much easier, right? We can just scale up the deployment and immediately have additional instances of the application that are serving our customers, as well as upgrading the cluster itself is relatively straightforward. It's a very simple process. And then upgrading the cloud pack for automation packages themselves, that bundle, it's a much easier process than the legacy platform, right? When we used to have to do an upgrade for FileNet or for Content Navigator, that was pretty much an entire weekend, right? Several employees working together for the majority of a weekend, which is when we could take the downtime for the application to have it offline for hours or half a day at a time in order to do the upgrades and test it out and make sure everything was working before we went back into production Monday morning. Now that upgrade process, right, can occur basically within a couple of hours at most, generally less than an hour, and it can be done with the applications online, right? We just deploy the new application, apply a new configuration file, right, a YAML file, and the upgrade kind of happens by itself in the background with the old version of the application still available until the new application is fully deployed and those containers come online and it's just like flipping a switch. And then backing it back out is just as simple, right? So much easier in the new environment than the legacy platform. I can't really speak to the performance of the new environment yet but while we do have this production environment built out, we are still in the process of loading content and data to the FileNet platform to serve to our customers. So they currently are still using the legacy platform, but as we migrate that content to the new platform and make that available, more users will eventually cut over to this new platform and we will have a much better idea at the point of load and the performance that the new environment can provide. We're optimistic, we don't have any reason to believe that the new environment won't perform as well as, if not better, than the legacy platform, but we have yet to have any concrete data on that. That's basically what I wanted to present to you. So thank you for your time. I appreciate you paying attention. I hope you find this information useful. Have a great day. Thank you. Thank you, Lance, for sharing this wonderful insight on this topic and thank you all for listening. Lance, myself and my associates are available to take any questions in the chat.