 I'm Sri Krishna, Krish Sharma from Canonical. Canonical is primarily known for the Ubuntu platform, the Linux distribution. So the question I think I was asking myself is, like when you talk about the broader adoption of open source projects, right? What is the biggest challenge as enterprises that we face in, right? It's a day-zero operation, installation, configuration, integration of that application with the existing landscape. But the question that we should all ask ourselves is can open source address that problem? And that's what I'm trying to focus in the next 20 to 25 minutes about how open source can help a broader adoption of other open source projects. I'll do so by two case studies and what better way to actually pick up case studies from Finos itself? So legend and waltz. If you have not come across and if you have not been familiar with the Finos landscape, I'll spend some time explaining what those applications are. I think nobody would dispute this saying open source is certainly driving innovation in financial services, right? If you look at around what open source is doing is it's one of those biggest evolutions that has happened in the financial services because it is allowing innovation to be faster. It is lowering the barriers of entry in terms of product experimentation. So open source is definitely driving innovation. This is a landscape. If you have been in the sessions earlier, you would be familiar with the open source landscape. And I think this is just Finos, right? The Finos landscape and some of the featured products. The reason why I've actually displayed this is I'll pick up a couple of those applications which are well known within the Finos landscape and let's use that, those applications which are popular which are being used by institutions and the wider financial services ecosystem. Can we help and address can that application be adopted quicker, faster? Now let's take a step back, right? We've seen the Finos landscape and that landscape itself is quite big. If you look at that chart, there are lots of applications but all the names on this list, I think you're all being in the industry and you actually know that you'll be this list of applications you would be familiar and many of the financial institutions would be using quite a few of these applications, right? Now, this is just a subset. Look at this. I think this is like overwhelming, right? And it's not intentional. This is a chart from CNCF, the Cloud Native Computing Foundation and what you would find is that themselves actually feel on the top if you would look at it, saying is it overwhelming and it suddenly is overwhelming. But the good thing behind that is that really shows the explosion of open source, right? There's so many open source projects and this is just one single area. This is about Cloud Native. Imagine an enterprise which is actually working with different application development methodologies and frameworks and thinking about Cloud Native, there's so many applications. Now, there is a way, way, way more software stuff and that's good in one respect but what is the downside of it, right? What is the challenge? Obviously, enterprise would be struggling. The open source is fragmented. Almost we are in a territory where it's a vendor-less territory, right? There are so many options but at the same time, enterprises and the leaders in the enterprises would struggle with the choice that you have got in the industry, right? Like if you're looking for a database, if you're looking for an open source database, there's so many choices. Now, comparing those choices with the use cases, I think that's mind-blowing, right? That is a problem. Now, if open source is fragmented, imagine what it will do to your operations. And when I'm talking about operations, this is software operations, right? You bring in a new application and you have that application deployed in your developer's workstation, in your development environment. You've got a testing environment, staging, pre-prod and that's just for one single open source application. Multiply it by X number of applications that you already have and then imagine the integration that it will be between applications. So there is no question that the operations and software operations, management of those applications, life cycle, not the initial just the day zero operations but the day in operations, continuous management of that application across the application life cycle management is going to be difficult. So the question is, we have to make software operations easy for the enterprises to adopt open source because that, as you can imagine, will be the biggest barrier. You have got a new application and if it takes two weeks for a developer to set up that environment, you can imagine X number of developers multiplied by the number of environments that you need to create for that application to be used in the production environment, well-tested and integrated with X number of applications that it needs to connect with. So we have to make software operations easy for enterprise and that's the question that I think we at Canonical with the open source community are trying to address. We are thinking about can open source solve that problem and this is a problem that we all will have to solve if we have to make that adoption easier for enterprises to try quickly, fail, determine what works for them and then move forward. So rather than actually talking about how and what it is and the theory behind it, what better way to actually pick up a case study, right? Let's pick up a case study and as I was mentioning earlier, if you're already been a Phenos member, if you've been following Phenos projects, you would be familiar with legend. You would be familiar with walls, the two case studies that I'll be picking up. But for those of you who are not familiar with legend, legend is just an end-to-end data management platform which is helping organizations break that barrier between the technology side and the business side. So it is helping them to create data-driven applications and business intelligent platforms. This application was contributed to Goldman Sachs by Goldman Sachs to Phenos in 2020. So there was this business problem as I was saying, right? Goldman Sachs has contributed to Phenos. Now, another bank, which is also a member of Phenos, would like to use legend. And when they actually tried this with a set number of developers, it almost took two to three weeks for them to install this application. And I'll showcase why, all right? So let's look at the 30,000-feet view. That's not surprising. Like, if you look at an industry application, any enterprise application would be comprised of many application components. And this is just a very high-level 30,000-feet view. It comprises of many application components. You have data sources. You have got another application components with explore that data that resides within the various data sources. You've got an application component called Studio where the model would be designed. Then you can actually query the existing models. And then you have got the integration layer with integrate with other applications and the enablement layer, which is about the SDLC server and engine. So we looked at it. It's a complex application. And it's a familiar scene, right? It's just not legend, but any enterprise application will have multiple application components, which will have dependencies, integration between the application components, and integration between different applications in the application landscape. So imagine a scenario that if you could deploy an application with one single command, right? That is a problem that every admin will have. Application users will have. The application manager and application responsible owner would actually want his application to be used and seamlessly used, right? So I'll come to this. I think I'll just say this is the command, but I'll actually explain what juju is and we'll come to that later. But this is one single command. So if you say juju, deploy, and then finos the application name, right? In this case, it was finos legend and I'll explain why it is a bundle. So it's finos legend bundle. So that application. So let's look at that in action, right? So instead of talking about through what is happening, let's look at the demo. So keep in mind, like, the time it takes in this demo is exactly the time it would take to deploy that application, right? So what we are saying, as you would have seen in the command, it says juju, deploy the finos legend bundle. So effectively, I think I'll come to the point of what chance is. And if you're familiar with the Kubernetes design patterns, you would know it's called chando operators. Now here what is happening, as you say, we are looking at the status of what it is. You have got a legend database, as we saw with one of the application component. You have got legend engine, a GitLab integrator because they use GitLab for authentication of the application and the users. Now if you would see, the status actually shows that each of those application units which have been defined in a model. So you've actually defined an abstract model where you have said, here is the application composed of X number of application components and here are the underlying cloud resources that we'll have to use. So in this case, we are actually using microcades, so Kubernetes environment. But the beauty with this framework is that organizations which are still using VMs, they could use it. You could actually deploy your application on bare metal. And it will work across. And that's again one of the points that we have heard all through during the day. I think we are talking about interoperability. So it's really important for you to be able to have an application, have a tooling and a framework that allows you to deploy an application, manage an application lifecycle, irrespective of the underlying resources. The application and the substrate. As you are seeing, as I'm talking through, you would see that they are in waiting state. The status, when you look at waiting and why it is because you could see there are internal application component dependencies. So you would actually have a legend DB. It's waiting like MongoDB to initiate. It will take for the time because if you work with databases, it takes a time to instantiate. So it's waiting for MongoDB to be actually up and running. So that unit will run. As I was mentioning, it requires a GitLab integrator and here, as you could see, you can actually go to GitLab and this is the way application has been performed. This step wouldn't have been necessary if the GitLab was not there. So you get the token from GitLab and then you actually make sure that as you would see slowly, all the components of the application, each instance is actually active. Now, as legend application is set up, you would take the IP address of the studio. What you would do is you would actually go and use the GitLab token to authorize that application. So we use IP address, the port 8080, and here you go. So you say the application is authorized. There you go. So the application, this is the studio. So this is the front end of the application that you're talking about. But still, as you can see, it's unauthorized. So it's not just the deployment part. It is taking care of authorization, authentication, and then it takes the concept further about the management. So now we go to the IP address of SDLC server and you authorize the user, the end user, to use that application. And effectively, you authorize the end user and then when you actually start the application back, you would be able to see the project that you would have created in the legend application. So I think effectively it was around just three minutes, three minutes and 15 seconds. Now, isn't this beautiful? Like if somebody was trying to deploy this and tried and tested and none of the banks were using that, that was a business problem that Finos actually came up with, saying adoption of an application and how long it takes. And that becomes a showstopper. That effectively was the time it takes to install an application on a developer's workshop. And as I said, it could be on the workshop. And the VMs on Kubernetes environment, it could be any Kubernetes flavor. It could be microkits in this case. You could deploy it on EKS. I've got demos where I can show you how we have done within the similar time frame if you had got an EKS cluster. Same command. You have got the same charmed operators and deploy it on EKS or EKS or GKE, whichever cloud provider that you're using. Hopefully, I think that gives you a flavor of why automation is important. So let's now look at what were the ingredients, right? Why it is so simple in terms of having a tool and a framework that allows you to deploy an application for your DayZero operations that quickly. There are two key components. Like one is juju as you saw in the command, juju deploy application A. Now, what is juju? I think in simple terms, juju is an operator lifecycle manager. So operators, it's a design pattern that became very popular with Kubernetes. And essentially, what you're trying to do is encapsulate the application management knowledge. For example, if it's a database, you're a data administrator. You would actually know what do you do. How do you install a database? How do you back up a database? How do you restore a database? Now, all those operations are actually the knowledge that is the site in the mind of the data administrator, right? And effectively, what we are trying to do is codify that knowledge. Codify that knowledge so that it's a consistent deployment. It's automated. It's faster. It's seamless. It's repeatable. So it's an open source tool, 100%. Canonical is just supporting it. It's for the community. Anybody can download it. You snap install juju and start working with the framework. As I already mentioned, it's an operator lifecycle manager. And the beauty here, I will actually come down to the concept of why it's hybrid, multi-cloud ready. Because this is, I think, the status quo effectively in financial services industry. Like, you will have certain application and workloads that will run on-prem. That's a given. Like, some of the applications will run on-prem. Yes, banks are actually thinking about the cloud for strategy. They would be working with one cloud provider, two or three. And in that environment, you can imagine how complex the landscape looks like, and how complex and time-consuming and costly management of applications across their lifecycle, managing the integration between these applications in a hybrid, multi-cloud scenario would look like. Can you imagine how costly it is? And that's where I think the IT budgets for most of the major banks actually runs in billions of dollars every year. There's no surprise there. So it's a hybrid, multi-cloud ready tool, and it's vendor agnostic. So I'll come across in a high-level logical diagram as to why it's vendor agnostic. The other component that I said, the two key ingredients. One is the framework, which is operator lifecycle manager. And the other component is the charmed operators. And this is something which I addressed earlier. If you're familiar and working with Kubernetes, you know the design pattern. It encapsulates that knowledge. And then we are trying to distill that knowledge of the know-how that resides with the resources into a code that is repeatable. So here is the high-level logical construct of what's happening, right? How does Juju do that? So you have got the apps, which is any application that you're going to deploy. And the underlying host is once you try to bootstrap a cloud resource. Once you bootstrap a cloud resource, which could be either VMs, Kubernetes, BMHL, any of the cloud providers, the Juju abstraction layer, wherein the model resides, once you have defined what that model is. You've got an application, X number of units of those applications. Here are the application components. Here are the integration. Here are the dependencies. Once you have defined that in a model, you deploy that model. That's what you do, Juju add model. So you have actually defined all the dependencies. You have captured all that knowledge. And then the Juju controller is the one that manages the interaction of the application that is deployed on any of that substrate. So as you can imagine, that is the beauty of when it comes down to a hybrid multi-cloud scenario. It could be any cloud. It's vendor agnostic, any cloud resource that you're using. The Juju controller will play that abstraction layer. Now, when it comes to the apps, there are a lot of companies which actually create their own operators, right? Now, those operators effectively are Kubernetes operators. The charmed operators, which we call as charms, that's where actually I think we differ. We actually have our charms, which can run on machines. And it also can run on the Kubernetes environment. And it can be deployed on bare metal and using tools like mass, which is metal as a service. Or if you're using, for example, MongoDB, if you're using Cassandra, if you have RabbitMQ, we already have charms, and the community is creating charms. So as you can imagine, this is about leveraging the power of open source. Community coming together to solve a business problem. So you have got hundreds of charmed operators available, which you can actually pick. But again, if you're actually configuring your MongoDB differently in your organization, you can actually play around with the ML file, and you can actually create your charmed operator that works within your enterprise. As upon this topic earlier, integration. I think is one of the topics, and as we all know from the industry, it's the biggest challenger organizations have. It's one of the costly affairs. Lot of projects actually don't become successful. I think either they're delayed considerably. They run out of the run-over budget. And the reason why is that most of the projects when they start, as you all know, I think we underestimate the complexity of integration. We bring a new application. We are focused on the new application. You're building a new application with open source components. But the complexity is hidden in terms of integration. And that's where, again, Juju and charmed operators are trying to resolve the problem. So what they're actually, as you can see, what was happening in the backdrop before I explained what the Juju, Finos legend bundle was, there was a legend studio, and it requires a token from GitLab. And effectively, the framework manages the interaction between those two interfaces. So there is an application, A, which requires the data set from application B. So you have got an application that requires something, and there is a provider for it, which actually can provide that data set. So again, one single command, you can actually Juju relate application A, application B. You can imagine how we are abstracting the complexity of the actual integration, which the framework manages, because you've actually defined the dependencies. You've defined the data set that actually would move between one application and another application. So from an end user perspective, from a system admin perspective, if you are dealing with hundreds of applications, imagine a scenario where you can actually relate and hide the underlying complexity using a framework like Juju and charmed operators. So Juju relate application A, application B. The other point that I was coming through, you had multiple components, legend application requires MongoDB, you've got studio, you've got GitLab, the other components of the application itself, or it could be any other application within the wider landscape. Now, they can actually run, as I said, the beauty here is they could run on any cloud resource. And what cloud resource by me is it can be on EKS, one component of an application running on EKS. The GitLab might be actually installed somewhere else. It could be a GitLab locally installed repository. You can have SDLC running on a different environment. Depends on the needs of the application. It may not be the case, but I'm just picking up an example where you might have application components or different applications running on different cloud substrates. And what is the underlying part? Because once you have defined the model, which understands that application A requires this underlying resource. Application B requires this underlying resource. Here are the dependencies between two applications. Then the rest, Juju takes care of it. That framework, well, define, the model defined is taken care of by Juju. It's just a Juju dashboard, which again, actually show what you saw on the CLI. This is a graphical representation, which really says each of those application components and units are active. Where is that application component residing? Which is charmhub.iu. As I said, it's almost like a store. Running on Kubernetes environment, it could be VMs or on bare metal. So it's a graphical representation. I wouldn't spend the time again, as I said, for playing through as to what, how we have done with Waltz. But the other case study is the Waltz. And this is an application that Deutsche Bank has been using it internally for a long time. And it's an enterprise architecture tool in simple terms. It allows enterprises to visualize and look at their organizational resources, right? And manage and plan and look forward in terms of their roadmap and planning. So again, this is an application which is an enterprise application. And what we have done is we worked again with the Deutsche Bank colleagues and the wider open source community. And similar to what we have done with Legend, we created a Waltz bundle. And we were able to deploy this. So this, as if you could see this, I can showcase that. This instance, if you would see, this running on, oh, I think I don't, I think it's the wireless that I've connected with. But if you look at it, I would actually after this showcase that. But is there a different network that I can pick up? But it's effectively, STTP if you go through even on your phone, I think instead of spending time, it's just demo.waltz.finals.org. If you just type this IP address on your browser and what you would see is the Waltz instance running. And the underlying method of deployment for this is juju and chums for Waltz. So the question that you would ask is why do we need, I think I'll just reiterate it very quickly, why do we need the Legend and chum bundle, right? It's a one simple way to evaluate Legend and Waltz. So far as I said, if you actually want to try out an open source application before you bring it into an enterprise, what easy way for your developers to bring in, have a single command, deploy it, the environment is set up, and then they can focus more on developing that application, using that open source component to build enterprise application that you're focusing on. It's an intuitive approach. I think as you would have seen, three to five minutes application is deployed right from setting up your developer environment across the lifecycle into the production environment. And as you could see, like it's not only providing the orchestration capabilities, right? It's just not a deployment script. It's not just day zero operations that you have got a configuration script. You've deployed this application and that's the end of the story. This is more than that. This is actually about managing the entire lifecycle. So it's more than the deployment scripting. And then it easily plugs into the release cycle. So for example, Goldman Sachs comes up with a new version of Legend and Deutsche Bank releases the next version of Waltz. What do you do? I think again, in traditional environments, you will have, the system admins will have to spend a lot of time trying to do the testing, loading the application, deploying it and making sure that it's ready to go into production. With Charms and Juju, you have tried to automate that, right? You've already tried to automate not only the deployment application, but the management of it as well as the release cycle. So just to summarize, I think what we have seen here is the power of open source, right? One open source project like Juju and Charmed operators can help other projects to be able to get adopted within the organization. You're making the engineering experience impactful. So the financial institutions, enterprises that any industry for as a matter of fact can realize the day zero value of an application, right? If the application is working, it delivers value to it, you go ahead with it. So simplifying the software operations to enable the broader adoption of Finos projects. So that's me. Thank you for listening. Got any questions? Friendly or not? Yes, so effectively, as I said, like you have an option of having Charms from Charmhub.iu, but in financial services industry, you would actually want that application, the Charmed operator to be created within your firewall. So this is a framework that the developers within the financial institutions can actually download it and create their own Charmed operators. And the beauty here is, for example, if you take up a bank which has got a retail banking business unit, you've got wealth management, investment banking. And some of the open source applications like databases or like front end applications or messaging softwares, they are used across, right? There is no differentiation between how a database would be used here. Yes, there might be certain cases or exceptions of how a database is set up for a particular use case. But if you're using MongoDB, you would actually use that across, right? Once an organization has created a Charm for MongoDB, you would be able to use it across business units. You would be able to share it. So you're actually saving time, you're saving effort, you've automated the software operations, and you realize the value really quickly. Does that answer your question? Okay, any more? I'll be around, as I said. Yeah, please go ahead. Yeah, so I'm a bank. Yes. Yes, there you go. So where are you? I think we are here to help, right? I think, again, as I said, Juju is an open source project. Canonical has been working through this because we realize this is an industry problem. This is a business problem. This is not just technology, right? How do we solve that business problem? Can open source solve this problem? So yes, I'll be more than happy. I'll sit along with you. I will certainly give you my contact. And we can suddenly take this forward. Roland, thank you so much.