How to Use Kubernetes to Orchestrate Managed File Transfers (MFT) within a Hybrid IT Environment

Hello, everyone. I'm Lauren Tancini, the moderator of today's webinar. I'd like to welcome you to the first Stonebranch webinar of the year, where we will be focusing on orchestrating secure managed viral transfer within a hybrid IT environment with Kubernetes. In this webinar, we will introduce real time hybrid IT automation, cover what is hybrid IT, challenges with deploying applications within a hybrid IT environment. We'll do a quick demo, a summary of what we've learned, and then we'll open it up for questions. Now, I'd like to introduce Nils Buer and Colin Cocksedge. Great, thanks, Lauren. So before Nils dives into the details of the demo about managing file transfers within a hybrid IT environment, I'd like to take a few minutes to overview Universal Automation Center as an orchestration platform and set the scene for some of the challenges faced by organizations like yours in today's hybrid IT environments. So the UAC platform provides a number of capabilities for orchestrating processes across hybrid IT environments, including your on premise cloud, containerized applications, microservices, etcetera. So analytics and visibility within the platform, there's a command center style display that brings together an automation view for all of the applications and platforms that UAC orchestrates on your behalf. Event driven automation provides the ability to automate these processes in real time. Workflow automation orchestration provides visual capabilities for designing workflows that can span across any environment. And this is done with a low code, no code drag and drop capabilities and really helps you connect the dots between any number of applications or platforms across the different components of the environments that you're running. DevOps teams, data analytics, people running a number of different processes are becoming more savvy in the terms of automation. There's a lot of demand for having access directly to provide their own automation capabilities. And we refer to these people as citizen automators, so not your traditional users of workload automation, but they are teams that need capabilities to leverage automation to make themselves more productive. And we provide a number of upstream integrations that allow end users to kick off and view the status of workflow directly from within tools that they're using for other business process, things like ServiceNow, maybe Teams, whatever capabilities you're using there, there's ways and methods of integrating in so that people can kick off workloads and monitor those within those environments, and maybe even provide approvals for processes that their employees are attempting to request. So infrastructure and service automation. So, you know, work automation or the orchestration of hybrid IT is not just about running the workload processes anymore. There's really also a need to manage the infrastructure, particularly now, as you know, all of the infrastructure is infrastructure as code. It's very easy for users to be able to configure environments, but they need to be able to manage that, see the status of things, start and stop containers, services, various other things within there, and that's covered with the infrastructure and service automation components. And to support our main topic of today's discussion, you know, managing your data pipeline. So making sure that the data gets where it needs to be, that it's synchronized across the different environments, particularly as a lot of the cloud based and containerized environments are transient in nature. So they spun up, they do a task, they disappear. There's a need to get data to and from those applications in a seamless way. And this is the bulk of what we're going to be talking about today in terms of Nils is going to be demonstrating some techniques and a scenario of how that might work in your environment. So to support our activity in orchestrating all those environments, there are a number of components that we provide or capabilities within the tool. So, you know, managing jobs and workloads, fairly straightforward. That's work automation. You know, we've all been doing that for a number of years. Managing the cloud applications and environments, I talked about that briefly. There's a lot of need in organizations to manage the DevOps processes, and this kind of comes in a couple of different flavors. You know, one is looking at the DevOps process in terms of automating the DevOps tool chains themselves, or also bringing workload automation into the DevOps environment through jobs as code, you know, to give the developers the ability to have more control over how they're automating their applications. Big data, a lot of focus within organizations to manage their big data. A lot of that stuff is living in the cloud right now. And again, and also support of that, the hybrid file transfer, the ability to manage file transfers across all of the different hybrid IT environments. So file transfers, basically for hybrid IT, providing event based triggering, secure, reliable file transfer, this plays a key role in supporting anyone's evolution to the cloud and keeping your data synchronized between the different disparate systems that you have. So let's talk about what we mean by hybrid IT. So most organizations today are moving to some kind of hybrid IT environment. And what does that really mean? Hybrid IT means that some of your applications run on premise, some of your applications run-in the cloud. So unless you're zero percent cloud, in other words, one hundred percent on premise, or you're a zero percent you're a one hundred percent cloud, you have a hybrid IT environment. And this is where most people are are moving to. Now, there are some people we're aware of that are one hundred percent cloud, You know, the hybrid, it's still a hybrid environment because there are different aspects of the cloud, and we'll kind of talk through what all the terminology is as we move forward here. But most people are either in a hybrid IT or cloud environment or moving to that. So hybrid cloud basically means that you're using a mixture of public and private cloud. Multi cloud is where you hedge your bets between one or more cloud providers. Distributed cloud takes advantage of different geographical locations, and cloud native refers to applications that were specifically created to run-in the cloud. They're cloud applications and they use the capabilities of the cloud. So, you know, within all of those terminologies, and we hear them used interchangeably, but they do have specific meanings, but hybrid IT is the overarching thing is basically, hey, you're running some cloud, you're running some on premise, it's a hybrid environment. And that's a challenge for a lot of organizations to manage and coordinate activities across the board. So why is it important? There's a need to connect on premise and cloud platforms applications and to manage them in single view. There's a need to securely send data, know, file transfer between these different environments. There's a need to have some form of automation to make these transfers happen in real time, so that the data is where it's needed, when it's needed. And there's also the need to control this from a visibility. So if we're running some applications in the cloud, we're running some on premise and potentially the workflows will span both, We need to have a single place to have visibility to manage that in a consistent way. And it comes down to how are you going to manage the deployment of a mix of solutions, things like containers, maybe that's running in Kubernetes being managed by OpenShift, the worker automation schedule, the agent technology, managed file transfer, all of the different orchestration platforms that is that's the challenge. And that's some of the things that we're going to try and address in terms of looking at how that can be done today. So before I hand over to Nils and his demo, he's got a specific fictitious scenario that he's going to run through. We're going to talk a little bit about a real life case scenario. And I have an exciting announcement to make, is that Berna Tenbrock from AXA Switzerland has agreed to join this webinar and participate in our Q and A. AXA needs no introduction from me. They're the second largest insurance company on the planet. I think if you don't do business with them, you've heard of them. And I'm not going to go through all the different things that they do in terms of that, but I would like to do is talk a little bit about their deployment and their scenario in terms of what they're doing there. So AXA's been a long term Stonebranch customer running various components at the Universal Automation Center. And Axis Switzerland, which is where Werner is from, have been using the software as a service universal controller offering for Stonebranch. And so basically, their controller is in AWS. It's managed by Stonebranch employees in terms of the setup, maintenance, etcetera. And they basically just access that in the cloud. For their OpenSift file transfers, access use case involved basically wanting to transfer or needing to transfer data to and from their containerized applications to and from on premise legacy mainframes and servers that they're running Linux environments that they're running in three different cloud providers. So the solution allowed them to leverage and reuse their existing universal agent infrastructure, which they've been comfortable with and using for a number of years. And they're supporting a couple of different OpenShift applications, their MyAXA Business and MyAXA Web, which are deployed as OpenShift pods. And basically, the deployment involves then having, as part of that pod, having a sidecar container with a universal agent within that pod. So that's using the public universal agent Docker image that that we push and publish. You know, every time we push a release, we update that. So there's documentation available in the documentation page about how to access that. If you're not already using the agent in containers, it may be something that you want to play with. There's certainly capability to do that. And that agent Docker image that we've published has also been certified by Red Hat for use within the OpenShift environment. So we've gone through a certification process with them to take care of that. So using the Universal Agent's built in Universal Data Mover component, that's been able to handle the required file transfers securely using TLS one point two and various other security mechanisms. And one of the advantages there for Axler is that that involves being able to do the transfers without having to open inbound ports into the container environments, into the pods running within OpenShift, which is, you know, a fairly solid security requirement that you don't want to have, you know, you want to limit the access into those from outside because those are environments that you want to have sort of set stable and secure from that point of view. And we provide that capability as long as some automation around that in order to manage the the transfer. So, you know, basically, as environments in OpenShift containers tend to be transient or tend to be, scaled up when demand comes and then scaled down when demand goes away is effectively as those pods are started, the agent in the sidecar container just registers with the controller, the access controller in this case, And basically then will be registered itself with a specific agent cluster, which means that we don't have to configure workload every time we get a new agent coming in from these environments, because that happens dynamically. The workload's configured to use the clusters. And we can see then that the workload will be able to manage itself across the available agents within the application, depending on whether they're scaling up or scaling down at any given time. When you scale down, those agents deregister. And that has a couple of advantages for customers, one of which is that we can take care of the ability to release licenses for the agent if I'm not using it, if they're not holding a license. But also then it means that workload is not going to attempt to run within those different environments as we scale down. So the SAS controller, you know, gives Akstra a number of advantages. You know, it's a central logging security concept. We provide a high availability environment with a database that's across three availability zones. You know, if there's some kind of disaster or issue, the ability to switch to another geographic region, so that they're basically nice and protected from that point of view. The communication that we do, particularly for file transfers, is all secured. And they provide a SAML authentication for all of their users. So it fits in with their IT environment, way that they're managing and provisioning users within their environments and so on. So we'll talk a little bit more about that when we get to chat with Werner at the end of this. We'll be asking him some questions, and you'll have the ability to ask him some questions, too. But let's get on to Nils' use case. So Nils is going to take over in just a second and do a demo for us. And his use case is kind of a mass media news website with a breaking news feed application. So basically, he's going to demonstrate how all web server instances for the application can be simultaneously updated when a news update is provided from a local server or cloud storage. So basically, the ability then to dynamically move the data from the on premise environments to the cloud environments across your hybrid IT infrastructure. Okay, Nils, over to you. Thanks a lot, Colin. Okay, before I show you these breaking news applications, how I'm going to update it simultaneously, all the web servers, I'm going to give a short introduction into OpenShift because not maybe everybody is very familiar with OpenShift. I will keep it short, but let's have an overview. OpenShift is basically a platform that allows you to run containerized applications powered by Kubernetes under the cover. And one of the big advantages is that you can run OpenShift on public and private resources. This includes bare metal or virtualized hardware, which can be either on premise or in the cloud. So on most of the customers I'm dealing with, they are running it in the cloud, the OpenShift resources. On top of that, we have the operating system. Usually, it's Linux, for example, Enterprise Red Hat Linux, but it also would support Windows. And basically, the operating system runs the Docker containers. On top of that, we have Kubernetes. Kubernetes uses the concept of a pod. A pod can run one or more containers, and this allows you to package, for example, multiple container for an application in one single pod. Kubernetes is also used to scale up and down the applications and distribute the load over multiple nodes. Let me give you an example. If you have, for example, deployed an application in a pod, you can start multiple applications by just starting an additional pod. And I will show you this also when I show you this breaking news application. So I can start one web server or I can start twenty web servers, and this goes all automatically via this Kubernetes cluster. And Kubernetes takes also care of the load distribution. So I will also show you in the breaking news application that I connect to one single IP, and then automatically, the part that is free will take over my request. And now on top of Kubernetes, we have OpenShift. OpenShift is basically a layer built on top of Kubernetes and acts as a facade around Kubernetes. It takes care of a lot of difficult tasks like deploying applications and performing the day to day operations. Let me give you an example. It brings the concept of projects, teams, and users, which enables multi tenant use of OpenShift cluster with access privileges. So this makes it very handy to work with these Kubernetes clusters using these projects and the Teams concept. OpenShift is also used as a platform as a service to develop and deploy applications in an automated way. And for this OpenShift, it's integrated with many tools like source code management tools like GitHub, Jenkins to support to support develop and build and test pipelines. You can integrate it with registries like Docker Hub, Quiet. Io, and so on. So it really takes a lot of these, let's say, maintenance away from Kubernetes and makes it much simpler. Okay, let me show you a bit more in detail how the architecture looks when it also comes to our universal agent. So first of all, what you have in OpenShift are the containers. So the containers run you basically your containerized applications. They act like a virtual machine, we would call it in the past. Then actually, you can group containers and put them in a pot. So maybe you can do, for example, one application can equal one pot, and then you put all the applications, all the container which belong to one application into one pot. On this case, I would say, for example, here, two application, each containing two container. And the nice thing is if you put containers into a pot, then actually each pot has an own IP and the storage you can map the storage volumes so that basically each container can access the same storage volume. So they can share the storage. Then, actually, you can distribute your pods to the different nodes of the Kubernetes cluster, which is done by the master. And this is actually automatically done for you, and, basically, OpenShift takes care about this. Okay. Now how come our universal agent into play? Our universal agent is just another container inside each pod. It's a so called sidecar container. Sidecar is just a naming. Basically, it's just another container in the pot. We call it sidecar because it doesn't belong to the main applications. It's basically a health container. Let's call it like this. You can add a sidecar container to a pod. Very simple because there's a so called deployment script for your pods. And in this deployment script, you just add another container which contains the universal agent. I show you this in the demo. It's really very simple. So this means as soon as you now start a pod, it will automatically contain the universal agent. It's also very cool if you, let's say, want to update the universal agent, you just change the universal agent version number, and then it will automatically use the newest agent because it pulls it always from our either from the Docker Hub or it pulls it from the internal Red Hat registry because it's certified by Red Hat Red Hat and also available now in the catalog. Okay. Now let's go to the demo. So this is a demo scenario I've been setting up. So let me quickly explain what what you will see here. First of all, you see here a so called Linux server, which acts as a file transfer gateway. Then we have a a reverse proxy. Then we have the OpenShift cluster. In the OpenShift cluster, I have x at the moment, two started pods. Basically, I've started two times this news flash or breaking news application because I've started two pods. If, for example, the load increases, I could start another pod. So that means I would have another web server with this breaking news application. Each of these breaking news application, as you can see, contains the sidecar container with the universal agent inside. So that means as soon as you deploy the pod, the universal agent is also started in the sidecar container in the pod. Then on top, you have your Universal Automation Center and the cloud. So the Universal Automation, you have the user interface, and you have our message bus. And the message bus is important because each time you start a pod, the agent in the pod will connect to our message bus. This is a standard functionality in our software, that as soon as you start an agent, you tell the agent where to connect to. In this case, I'm telling the agent to connect to this message bus. There's now one new thing. Each application is, let's say, mapped to a so called agent cluster in our controller. So that means if you have two applications, you would have two agent cluster. In this case, I have only one agent cluster because I have only one application. So each time an agent is started for an application, it is assigned to this agent cluster. This is important because later on, when I want to transfer a file, for example, from the Linux server into this pod cluster, I just assign the so called agent cluster name, and then it distributes automatically to all started pods. Then you see also this Asia bubble because I also want to show that you can transfer data directly from an Asia storage container into this pod cluster. That's basically the same concept. You have a task that downloads for example, the file from Asia and then transfers this via our Universal Data Mover Protocol to the Universal Agents. Okay. Let me start. Let me show you the demo. So I'm now connected to the OpenShift user interface. So that's the OpenShift GUI. This GUI is to maintain your OpenShift cluster to set up new projects, etcetera. I'm using the very latest version of OpenShift, so that's so it's all brand new. So the first thing, if you want to do something with OpenShift, you need a project. So that's very simple. So you say create a project. And my project is called news flash. So that's my breaking news application. Breaking news app. So that's the name of my project. Okay. Now I have a project. Now what I need to do is because I will start several web servers, so what I need to do is I need to have a service. The service, in this case, acts like a load balancer. So I don't need any F5 load balancer or something. I can just create a service, and and then every call to these web servers is routed through the service. And and this and if I start ten pods, for example, I just get a single IP address where I can send my request to, and then will it be distributed on the cluster by the system. So I create a new service. And this new service looks like this. Basically, what it does, it says root everything which is related to this project root it to a certain port and IP address. Now I say create. Now I have here a port. This port I need to remember because this is a port how I can access my web server in the back end. The IP address is the IP address of my OpenShift cluster. Okay. So now I'm let's say I'm prepared. I have a service. I basically have a project, and I have a service, but I have no container yet. So I have no pods yet. So what I need is a deployment file. And this is very simple. I will show you this deployment file. I think it's very easy to understand. Let me just show you. One second. Just need to get to the correct screen. Bigger. So this is a deployment file for my application which basically creates the the pod. It contains, first of all, of the container with the web server. So that's my newsflash application. So that's an NGIX web container. And it contains of another container. Maybe remember, there was a sidecar container, and this is a container of our universal agent. So that's a second container, which is the sidecar. And you can see there is nothing written sidecar or something. It's just another container inside my pod, the second container. I tell which agent it should install. In this case, six dot nine dot zero dot one. So very simple to upgrade. If you have a new agent, just put the new attack here. That's it. So you don't need to install anything. Then, actually, I have a shared file system because if I send a file to my agent, I want that it's accessible by the web server. So I have a shared file system in my pod, and the the share is called pod share. So if I move a file to this pod share, then it's accessible by both container. Then I need to tell, and this is the only thing important, I need to tell basically to which server it should connect, to which OMS it should connect on our in the cloud. So this agent should connect to our message bus at this IP address with this port. And it's an outbound connection. So now inbound connection to the OpenShift cluster. And I need to tell to which so called agent cluster it should connect. Because if I want to transfer a file, I want to transfer it to all agents which are assigned to this cluster. So that's all. So basically, the only thing I would need to do in in let's say, if in your in your environment is basically adding this part to your deployment files. That's all you have to do. Okay. Now I copy this into my OpenShift system. So I said create a new deployment. Second deployment configs. Deployment config. I delete this sample one. There's always a sample one. And then I say create. So now it will scale up two pods because when I when you maybe you've seen it in the deployment config that was written that I want to have two replicas, so it will start automatically to web server. And this takes around fifteen seconds. So in this fifteen seconds, what it does, it connects to the Docker Hub, It downloads the application container for the web server. It downloads the container for the for the universal controller and start these pods. And you can see the pods already started. So everything is fine. So if I go now to pods, you will see these are my two pots which have been started. And if I now go into one of these pots, so for example, I go into the first one, then you will see that the log files of the NGINX container but also of the Universal Agent are always streamed to the Red Hat console. This is because both the NGINX and also universal agent are so called Red Hat certified applications. And that means the log files must be streamed out so that the agent never grows. So in this case, our agent will never grow, And all the log files are streamed out to the console and can be directly looked up here. And you can also access the applications via the terminal. For example, if I look into the NGINX container in the main directory where normally the web sites are lying. So the HTML data, you see there's nothing there. So if I do an LS, so no web pages there. Also, if I now go and try to exit this, you will see NGINX is forbidden. That means there's no data yet on the NDX server. But the good thing is I reach it already, and I reach it through this port. And this is basically now one of my ports has taken over this request. That's because there's an open end on top. So now I want to have breaking news data also in this web server, and this I'm doing with the Universal Automation Center. So I connect to Universal Automation Center. So first of all, I want to look at the agent clusters. So this is our user interface, and we have so called agent clusters. If I go to the invert, there's the agent used cluster. And you can see two agents have automatically connected to this cluster because these were the two that I started with the deployment file. And you can see there's one there are some some configuration items also on the cluster. For example, you can say ignore inactive agent or ignore suspended agent. So that means if you now send a file to this cluster, it will not send it to clusters which are down, for example, ports which are down. It will only send it to active ports. I think this is also an important feature. Now what I will do is I will show you if I now go to the configuration set again. Deployment configs again. Now I want to scale it up because, let's say, my breaking news is so important, so let's have it start more web servers. So I can just press here this button. And now it's scaling up another pod. Just need to wait until it's started. Now I have started three web servers. If I go to Universal Automation Center, go to my agent cluster, as you can see, there are now three pods because it automatically the agent has started and connects to our Universal Message Server automatically and into this agent cluster. Now I want to transfer data now to this agent, to these three agents which are running in the pod. So for this, I've created a small file transfer task. This is a standard file transfer task in our system. I don't want to go through the details now. Basically, it can transfer data from anywhere from any source. It can be a mainframe. It can be a server, in this case, to another agent. And I'm transferring it, in this case, to the agent cluster. And I'm doing a broadcast, meaning to every agent in the cluster. I can also say just transfer it to the agent with the least load, maybe the pod with the least load in this case. And if I and I'm doing this with a transfer script. And in this transfer script, I'm just saying that the source is this Linux machine with these credentials. Of course, you cannot see them. And the destination is the pod share. Maybe you remember when you saw the deployment file, this is the file system that you shared between all the containers in the pod. And I'm sending the index file and some pictures to this web server. Let me launch the task. As you can see, three file transfers are running because we have three agents in the cluster. So for each of them, one file transfer will be started. And you can see it's already successful. So if I now go back to my news flash application, press enter, it worked. So now you can see there's now data loaded to these these pods. And there's this new storage universal agent, six point nine three one certified through Red Hat OpenShift. So basically, I did this already yesterday, but so since yesterday, it's now in the in the Red Hat catalog that you have our universal agent there. So maybe I can just quickly show it to you. So if you're in the Red Hat catalog, then you can find now under container image, you can find now the six point nine point zero point one. So it's not only available in the Docker, but also now completely in Red Hat. Okay. Let me switch back to the Red Hat side because I wanted to and let me quickly go into one of these pods. If I now go to the terminal and press LS, then you can see the data has been transferred. So the data transfer was successful. So I transferred to all of the pods. I can do this now with every pod this new web page data. Now I want to do an update from the cloud because I think this was just an update for where I have a file on a server, which I want to send to OpenJeff. Now I have something in an Asia bucket. For us, it doesn't matter if it's Asia, if it's s three, if it's Google. We support all these cloud storages out of the box. So for this, what I'm going to do is I'm going to my Azure Storage Explorer because you will see that's really real. So that's not Storage Prog. That's just a standard Azure Storage Explorer. Let's say I'm a web designer, and I've created new news news information. So I will up upload this now. Upload files. I select the stuff, and I have these two. So we'll upload these two files to the Stonebranch PM container in Azure Storage. So now this the information is there. So now what I want to do is I switch back to my UniVerse controller. And I've created another sample task, which is called copy newsflash update copy newsflash update to Azure. So what I'm basically doing here, first of all, I'm reading from the container storage pm. That is actually the container Azure where I just upload the file, taking everything. We support here stars and all kinds of mechanisms how to select the pod. So I'm selecting everything in this container and sending it to this pod share. And I keep the same name. That's the star. That is and I send it to this broadcast cluster with all the agents. And if I look again here, you can see here are my agents where where I'm going to send it, basically the pods. Yeah. Then I launch this task. And as you can see, it's running. Take some time. This was done. So basically, I have now transferred the data to the pod cluster without using any outbound parts to the OpenShift cluster. Okay. Now let me have a look at the web page if it has been updated. Yes, it has. That's good. So, basically, now, Thormel provides built in support for Kubernetes and Docker. But that's also a new feature which we have in the Universal Controller. So now in the Universal Controller, you can see we have now, out of the box these built in tasks for Docker, handling Docker tasks like Docker Compose, Docker Compose, Compose, Compose, start stop container, build images. You can deploy pods on Kubernetes, create Kubernetes pods, and so on. So that's a Kubernetes and Docker task both available now. Yeah. Let me quickly look at these the news flash of the pod. That's the last thing I want to do. Let's say I'm going to this this pod now. That's another one that you see that's the same. So if I press the ls command, then you can see there is now this Docker JPEG. And the Red Hat is still also there because I have not deleted it. So that I could also do, of course, I could also delete the stuff. Yeah. Let me summarize what you have seen. Basically, you've seen how you can transfer data from any of your applications, either running in the cloud or on premise or even on the mainframe, how you can send those data into the cloud or into the OpenShift cluster, basically, which might run-in the cloud. And this goes very, very easy. So the only thing that you need to do is you create an agent cluster in our Universal Controller for each OpenShift application. Well, this is still not automatic, so you have to do this manually. Then, actually, to your deployment script, you add the universal agent as a sidecar container. So that's just the small part that that you saw in the deployment script. And there, you need to tell to which message server it should connect the agent, and you need to tell me tell also which of the shared drive which you are using between the between the container and the pod. Yeah. And the last thing is you need to configure via wire drag and drop a workflow using the universal controller web user interface. Of course, the whole stuff goes also the other way around. So you can also transfer data from the OpenShift cluster to the server. Because for us, it's this file transfer which we are using since twenty years. It's a file transfer between our agents. So it's very robust and also one hundred percent secure. Yeah. I want to hand over now back to the Q and A session. Great. Thank you, Nils. So so before we I guess now it's time to ask questions. Effectively raise your hand in the GoToWebinar panel and we'll unmute you or use the question section. We'll read the question for you. I'd recommend raising your hand because it's always easy. We maybe have a little bit of a conversation. But anyway, while we're waiting for the questions to come rolling in, I'd like to introduce you to Werner, Werner Tenbrock. Werner's a systems specialist with AXA Insurance. He's got a wealth of experience with Kubernetes and OpenShift. He's been driving a lot of, I guess, the project at AXA. And he's joining us today from Switzerland. Welcome, Werner. Thank you for joining us. Hello, Joel. Werner, I have a couple of questions for you, if that's okay. So I'm sure I didn't do your implementation justice in my description earlier, but you're more of an expert on that than I am. But I thought it was interesting to bring that to people's attention. But in terms of your, you know, Stonebranch OpenShift solution, you know, what was the business technical problem you were hoping to solve? You know, was that really, you know, just an on prem to cloud automation or, you know, was it big data pipeline automation, you know, given that you're an insurance company, big data is a large part of what you do. Kind of what was the sort of drivers and problems you were trying to solve with that? Yeah, well, first and foremost, it was the replacement of our on premise control with a modern cloud focused solution. Since AXA is one of the largest insurance companies in the world, big data pipeline automation and orchestration is, of course, important to us. So that's one of the reasons. Our big data strategy is also cloud based, so it fits in nicely with our overall undertaking and transition from mainframe to cloud across the business. Okay, very interesting. Thank you. So what were the kind of limitations you had to work around in terms of, I guess, things like budget, legacy systems, needing the scale for what I assume is a fairly large environment that you guys have, obviously a lot of data and so on? And how did you manage those limitations? Well, since everything is moving in the cloud these days, we had to be mindful that eventual mainframes will have no support, as our workforce laid out. And of the triple knowledge that current mainframe teams have. So we know that eventually our IT teams will not be able to support the on prem mainframes anymore. Therefore, getting ready for the cloud only future now makes sense to us. That's one reason. And another objective we had was to grow our DevOps strategy at AXA Switzerland. From the technical standpoint, Stombrant is well positioned to support and promote this objective. Good to hear. So from an outcomes point of view, I mean, what were the lessons learned? What can you share with our audience in terms of things that you learn, challenges you overcome, things to watch out for for these kind of projects? Because I know, you know, I suspect a lot of our audience are relatively new to some of this. Some of them may have already taken steps on this journey, but I think for those that are looking at taking steps on this journey, what can you share for us in sort of snippets or nuggets of information that you wish you'd known before you started the project? Pierre, the implementation of the Stomrad solution went smoothly without any technical problems. So, if we ran into anything that needed to solved promptly, it was addressed right away in a satisfactory manner, thanks to the good support from Stormrage. A very positive aspect for me is the fact that we are now working, communicating and seeing more across all platforms. This also shortens the organizational process and ultimately you are on the move faster, at least. Very cool. Thank you. Okay, so looks like we have some questions that have rolled in. Anyone raised their hand Sorry about that. We have two people that have raised their hand. Peter, Paul, Amhoff, I am going to unmute you now. Well, I think Paul had asked his question online there. So as opposed to raising his hand, did he raise his hand also? So the question for Paul, Peter Paul Amhoff, is that the one? Yes. Yeah. So so he's, pods, meaning transferring files away from pods. A file event monitor cannot be started in broadcast mode, so the event is only started. Okay. So, Peter, we actually do have a solution that we're working on for that to so your I guess, let me describe it. Your issue is that, you've had some, obviously, some issues with the with the agent file monitors in terms of having them dynamically started when when pods are spun up and spun down in terms of doing that. Because obviously the traditional broadcast capability, you know, effectively looks at what's there at the point that it starts and throws it out. So we have been working on a solution for that. We do have a prototype that Nils and his team has been reviewing. So we should be able to make some announcements around that for a solution that really does dynamically handle the ability to monitor for files on, well, in your case, pods, but on containers as of when they're spun up and spun down. So kind of watch this space. We do have something coming for that. And we also have a question from Liti Mahaptra. Excuse me if I butcher your names, I apologize. And this is, are there any alternate ways to handle the use case you used in the demo? What I mean is, when would you replicate data versus maybe accessing data directly from, say, another microservice? I'd say the answer is yes. I mean, the demo is very much a specific use case, fairly simplified. I think I'd have to understand your application a little more, but the data sources or the triggers for the actions could be coming from multiple places. So you should be able to combine these together to do the automation you need. But for your specific use case, I'd kind of have to see it or understand a little more detail. But I believe the answer is that, yeah, we should be able to handle subtlety differences to the use case in terms of scenarios. Okay. We do have a few raised hands. Would you like to answer a question? Yeah, let's have someone talking. It's always much more fun to hear people. All right, Thomas Palm, I'm going to try to unmute you. And you can go ahead and unmute yourself as well. Hi, Thomas. How are you? Hi, all. Hi, Werner. Thomas Palm. Hi, Thomas. My question about the process, do I see, for example, the amount of files and the size in total what has been transferred inside one pot? And if it's possible to collect all the, let's say, statistics about a bunch of pots. So, in this case, the universal data mover, task that's run that does the transfer will contain that information. The Universal Data Mover scripting language does provide the ability to write out custom logging. So you should be able to adjust the scripts to capture that specific information and write that out to to a custom log, which you can use for more statistical analysis. So if you wanna if you like collate information for multiple file transfers to and from the same pod or across all the pods, that should be possible. It would certainly need adjusting from the demo that Nils had. He didn't have built that capability in. But you should be able to. Yeah. Okay. Mean, what what you what I'm showing in the demo, in the log files, see at least the number of files which have been received, not the number of files that have been transferred into a certain pod. So for each pod, there is a log file available now. Yeah, but that's in the output. So if you wanted to collate that information, there's custom logging available where you can write custom log files within UDM. So you should be able to write that information out a central place. Bearing in mind that using the broadcast functionality is, you know, you should be able to collect that information. So it should be possible. It needs a little bit of analysis, but off the top of my head, I'm saying yes. Yeah, okay. Because the reason why is I thought if we are doing this stuff like this broadcast technology, let's say, and we have to sell it to our customers, and they have to pay for the things what they need, what use. So, I need to have something in my mind or on the paper to show, okay, you need one gigabyte, you have to pay one thousand euro, for example. Okay, that makes sense. Thanks a lot. Lauren, do we have any more rate hands? We do. Gavin Johnson, I am going to unmute you from my end, and you can go ahead and unmute yourself. Thank you, and hello, everyone. So I saw the Stormbranch running in OpenShift. Just simply want to know if it's running in any other cloud environments, maybe Azure's Kubernetes or Amazon's EKS service. They're they're all supported from that point of view. So so what Nils is showing, and Nils will probably technically correct me here. So OpenShift is effectively the management layer. Ultimately, what we've got at the the the pods, it's it's a docker container. So, you know, we provide the the public Docker container, or can build your own. We provide examples about how you can do that as well. So, basically, you know, any one of the the container management services can can take care of that. So, yes, is the answer to the question. We're not restricted just to the the Red Hat stuff. Okay. Thank you. Nils, did you have anything to add to that, or was that technically No. I I think it's fine. I just showed it on OpenShift because there we are now certified, and it's, of course, what AXA is using. So and now to the other customers. Okay, good. Lauren, do we have you on next? We do. We have one more raised hand. Andrew Hakalo, I'm going to unmute you now. Hi, Andrew. You'll have to unmute yourself. Good morning, everyone. Good morning. So a question we had from our end is if it's possible for Stonebranch to kick off a Kubernetes job. So Kubernetes has the construct of not just long running workloads, but a batch task. And the idea would be you could eliminate a lot of these hosts that just sit around to run batch at night, right? Like you might have a bunch of Linux servers that just run a collection of scripts. So the construct would be that the agent would have to come up, register itself, it would do its work, and then go away. Is this something that people are doing or not quite yet? I believe there are people doing that. I've run into several use cases where that happens. So over the last few controller releases and agent releases, we've been adding capabilities to support this as well. So, you know, we spent some time, probably a couple of years ago, you know, looking at, how you spin up an agent in a containerized environment, how you pass all of the different, environment variables you need to, you know, control how it registers. But also with the licensing that we put out in the six point eight and six point nine controllers and agents, we added a transient capability. So it's really designed for the containerized agents. So the agent registers, but basically then when the agent, stops, it deregisters, which basically means it removes itself from the agent cluster, It removes itself from the licensing there. So the agent's really only there and active for the life cycle. So the capabilities are there. My understanding is that we do have customers that are actually running using those capabilities. So yes is the answer to that question. Thank you very much. Thank you, Andrew. It looks like we're going to run to the full hour here because we still have a number of written questions I'm going to go through and tackle some of the more read ones, and then maybe we'll take a couple of live questions as we go through. So Ron, Colin, I probably pronounced that wrong, but anyway, can UAC Promote Task be combined with the GitHub commit? So I guess there's a couple of answers to that. There's no quick answer to that. So could take a long time to answer. I'll try and do it justice in a short period of time. So there are a couple of things. One, the APIs provide a lot of capability. So we don't have direct integration into GitHub for things like App Bundle and Promote versioning yet. We are investigating that. So that is something we're keeping an eye on and maybe something that we can improve in the future. But I don't have any details or can't make promises at this point. The APIs for the ad bundle and promote capability are fairly rich. So you can combine that into your process so that when you do a commit, you could call an API. You can build the bundle through the API. So there's a possibility to do some integration. You also have some capabilities to use the APIs to pull the definitions from the controller and have those, you know, as part of your GitHub environment, part of your process, your package. And again, when you do the commit, can call the APIs to push those up to whichever environment you're pushing to. So there are ways of doing it. This would require, I think, a more detailed discussion that we have time for here today. But hopefully that kind of covers the answer there. So another question, this one should be a relatively quick one from Alexei Godek. Where is your Stonebranch deployed, your cloud or bring your own? And the question is, it's whatever. So we fully support all of the clouds there. So that's covered. Do we run it as a service for the controller? Yes. So we do provide a software as a service environment. This is what Axis Switzerland is using and many other customers there. So that's something if you're interested in, then just reach out to Stonebranch. We can put you in touch with the right people that go through how that's configured, what the options are, etcetera, etcetera, in terms of managing that. Did we have any more raised hands, Lauren? No, not right now. Okay, so we'll go through a couple more questions. We still have four minutes left, so we may not be able to get to all the questions, but what we will do is we will reach out to those people if we haven't had a chance to cover your question and try and provide adequate answers. So this one from Andrew again, is it possible Did this one you asked? Yeah, this is the question you asked us on my Okay. And the question, I guess, when we talk about SAS also from Alexei was IPAS or SAS. It's SAS is how we term that. Okay, I've covered that one. Sorry, just make you go through the questions here. Okay, so there's a question about the licensing here from Thanh Huang. In the agent based license, did client have to pay for the agent installed on pod or they only have to pay for server VM agents? And and and there's a complicated answer to that question because the licensing has a number of different options, and it really depends on what licensing structure you have with Stonebranch. So some or all of the above could be true. That's something that, as far as I understand it, although I'm not in the sales licensing side, I just know the capabilities we provide is something that's really handled on a case by case basis, what makes sense for individual clients as to how you license it. Some people license by, you know, specific infrastructure, some people license by the number of tasks they run, or combinations of those things. So that's that's a it depends answer. Okay, so we covered, this is a question for Lexi. So no file or file delivery dashboards at this point. No, that is something we're looking at longer term. This is a follow-up to the question, I guess, that, Thomas Palm asked about getting the data for the file level. That is something that's on our our longer term road map to to to look at that. We see that we see that being a useful feature, but not something that's directly provided in the UI at this time, although, you know, we may see some movement on that in the near future. Okay. I think that was a follow-up question from Ron regarding the promote stuff. I actually meant to promote the promote task that moved the changed HTML as per the demo, and that can be fine the moment that you commit the change in the HTML. You should be able to automate that. I think that still comes back to the APIs, but that might require a sort of a more one on one discussion. Ron and will reach out to you separately, and maybe we can get a call and I can show you some things on that. That may be a bit complicated to answer here. And we're right down on time, I believe. I think I got all the questions. Sorry, this is scrolling kind of strangely on my screen. I'd like to thank Nils and Werner and the audience for attending. And Lauren, did you have any closing words? That's it. Thank you, everyone, for attending, and have a great day.