 Very good morning to you all. I'm Krishama, Financial Services Section 8 at Canonical, for me sure, of course. Personally, with two decades of management consulting and large-scale program development experience, I have witnessed firsthand one of the issues that financial services institutions grapple with is managing software operations. In today's session, what I'm going to demonstrate is how open-source tools and the community can come together to address enterprise software operations challenges. So let's take a look at the new picture. The financial services industry is in the middle of the perfect storm. Why would I say that economic conditions are shifting, the customer expectations is rising, you know, got new technologies? There is a lot of competition in the index phase and the regulatory impact. So what do organizations have to do? They would have to sustain, they would have to grow and transform continuously and that rate of change is right. So one of the challenges that organizations are facing is that they would have to adapt really quickly. They would have to catch up with innovations and as we all know in the financial services industry, we have to deal with complex application landscape. What are the underlying challenges? The underlying challenges is aging technology infrastructure but for this topic and for this presentation I'm going to focus on software operations and the integration, which are two key challenges which financial institutions have to grapple with. 20, I think we come across by the principle quite often, any guesses in the context of IT budget, what will be transferred. 20% is all that financial institutions are left to it when we look at the breakdown of a change project. The 80% of your change project is spent either on regulatory change, process re-engineering and especially on aspects of revenue growth. So how will organizations manage that change? If you have got a set budget and you are spending a lot on software operations and maintenance, it is hardly anything that's left for your innovation, for your change in terms of R&D and providing innovative services to your end customer. And that's where smart operation comes in. If you are able to optimize your operations, if you are able to automate software operations, you have more left to innovate and be able to adapt. So let's look at what is the expectation of software operations? We believe and what we wish for is that software operations is simple, it's reliable and it works every time like our trusted kettle. We actually fill up a bottle, we have got a hot cup of water for our tea or coffee. That's what we wish for. But what's the reality? I think we all come from financial service institutions who know that enterprises of software operations are costly, especially it's hard, it takes time and resources. That's the reality that we have to face. Why isn't that hard? What are the operational challenges that we have to face? Software maintenance. They've got software lifecycle management, integrating new applications within only a complex landscape and then you have to do a service authorization. All of this leads to a higher level of entrepreneurship. From a business standpoint, what they expect IT to deliver is an innovation platform, something that will help the business to innovate. In order to do that, one way we can actually reduce and optimize software operations is automated. Open source is everywhere. Now based on the report by the US Foundation, 80% of any given piece of software is open source. Four of them will fix it later. Can open source tools and the community can they come together and solve the problem of software operations? Slides on the projector. Now when you're using an application like Sandro or Kafka within your enterprise, it is open source. When application code is open source, can the open source software operations stand in and acknowledge that it's within the minor system administrators and the best practices that they have got in terms of installation of the application, deployment of that application. But it's not only just the day one operation, the day one task, it's about the day two operation. Can be done. So let's look at a case study here. I think if you have been in other sessions, you would have heard about Legend, an application that was open source or open source. And what we thought is what better way to be one straight, the value of software automation, if you could pick up Legend as an application, which is open source, quite a community member. And within a few days, can we try at hand at using open source, bring the community together to address the problem for software operations. So for those of you who haven't been in the earlier sessions, have not come across Legend. Very briefly, Legend is a data management platform. It's a data tooling platform. It's an environment which is being widely used in pricing, risk, and other business functions. As I said, it's contributed by Goldman Sachs. The team has worked internally on that application for seven to eight years. And they have open source serving components to Finals. Now that's the power of open source. You have got an application, it's open source for the community. Now other financial institutions can get involved. They can utilize that too. So let's look at the 30,000 feet view of what that application is. It's not an architecture diagram, as you would see, it's just a schematic. Even at that high level, what you see is there are four components which currently have been open sourced. Two Finals, which is studio. You have got the engine, the data modeling engine, and you've got SDLC server and GitLab. Now even from this schematic, you can appreciate that deploying this application would be complex because there are four different set applications for that enterprise application if you have to consider that. That would take time, that would take resources. And what financial institutions really require, the value of their software engineers working, is on creating a business application on that platform, not spending their time on deploying that application. So imagine a scenario, if the click of a button, going back to the analogy of kettle, if we get hot water, can we do the same thing with the deployment of application, enterprise application, like the engine, deploy with a click of a button? Yes, you can do that. And that's what we have done together as an open source community. The command that you have to use is juju deploy in our legend. That's one single command that you would have to type in to deploy that application right from the scratch. I'll get into it, what is the magic behind this, what is it that actually does what institutions have to spend a lot of time and effort deploying that application and it's also about not once. You have to create multiple environments developer environment, you should have to create multiple times you would have to have a staging environment, you would have to have pre-crod environment and you can imagine the number of time organizations would have to set up an amount of time and resources to spend. That one command can do the magic but let's understand what's behind that. So what are the key ingredients for it? What is the magic? There are two things here, charmed operators and simple terms I think it looks a lot full charmed operators. Those of you who are closer to Kubernetes world, you would understand that operator is nothing but a design pattern. In simple terms, operator is an application code plus the code, the software code that actually encapsulates the knowledge that's in the mind of system administrators so it's about actions on those applications and the application code together that is together might call as an operator and we call it as charmed operators because we are only helping organizations to deploy and install it the first time but also the data task which is about management of an application moving away from the concept of just configuration management to application management. So in short, charmed operators are nothing but trying to capture the application domain knowledge and distill it into it. So that's one ingredient. The second ingredient that you saw on the command line which was juju deploy and also what is juju? And juju is an operator life sector management so it's a framework that allows you to manage the functions and actions that you want to do for the software deployment and you can have multiple charts. So this is almost like an abstraction layer which allows you to manage the charts which are applications and the software deployment code together and that's a framework. It's a 100% open source tool. As I said, it's an operator life sector manager and integration is built in it. It's not enough to manage it. It is ready for a hybrid multi-cloud scenario. For financial institutions, I think it's acceptable. It has become a status quo that some of your work loads, organizations are pushing into the public cloud and majority of your work loads will run on-prem in your private cloud. It's also vendor agnostic because if you decide to run your application on, for example, AWS or run your application on Google Cloud or on Azure, it can work. So effectively it's a concept that that tooling is an agnostic hybrid multi-cloud ready. So enough of talking. I think that was just a concept. Now let's see that in action. Let's have a look at it. So here what you're seeing is juju status. It says that it's completely, it's nothing, it's starting from scratch. What you have done, you can actually see the juju cloud command is trying to look at the resources. So it's got a LXD container which is hypervisor and then it's running on micro-gates, which is given in this environment. The command line juju bootstrap is what abstraction layer is. It allows multiple applications to run together and that's what juju is controlling environment. We have just added the model, which is an agnostic legend model. It's something about a workspace which confines the complete environment, complete resources, defining the boundary and now what we will do is play that command. juju deploy in oslo legend bundled and the channel is edge. So you could actually have multiple channels where you could have a Pita release, you could have a deployment route. You can again run on various architectures where it is. So the services are starting. So remember when I was talking about that highly schematic, there were four components, right? You had got the studio, which is the front end, you had the STLC engine, you had the server. Effectively, as you could see on there, they are working. The reason why you could see them as block initially is because if there are interdependencies between application, as it's trying to integrate two different applications, it will be in the block status and once you have one of those right parameters, it starts to connect. And now as you could see, even if you far forwarded it within four to five minutes, I think the bundle was deployed. The next step is you will have to authorize the GitLab application. So effectively we have actually captured the token there. It's about 758. You provide the 758. So we have actually captured the token from GitLab. Provide the token. And this step, as you could see, is the step that's required in the setup of the application itself. It's an application required, not the genuine chance requirement. So you could see all the services are active. You would actually capture the IP address of the studio. You go to the browser, to the studio. You have the 4880. You would actually see that the Legend app is already set up and you would see the studio deployed. So that's, if you actually go to the Legend, if anybody is there for one month's time, they will do it. It's actually the application is deployed. The next step, which is the final step here, is about authorization of the end user, which I think if you have got a private instance of GitLab, you would have your own end server, end app directory, or active directory, where you use some authorize to use a particular application. So the next step, you would actually put it in there. You would say it needs authorization and that's the final step. So effectively I think if you were a system engineer, you literally could actually start this one gather of coffee in a bag and your application is installed. And this application I think we have been interacting with the community. And this application as I said, it was open source by Goldman Sachs and other financial institutions like Deutsche Bank and others. They were quite interested to deploy Legend within their own enterprise and they spent quite a bit of time deploying it, so deploying it and that was a pain point. And what we have done as an open source community is address that enterprise pain point. So as you can see, it's actually deployed. So let me just give you a very high level view. I'm not going to get into the technical details of what it is, but the concepts about what was bootstrap. So the point that I was making earlier is it's actually independent of the substrate. You could deploy this application on AWS if you already have being on enterprise, you could deploy that. So it can run on Kubernetes, it can run on VMware or you could deploy the application on VMware itself. The key, what is the magic here is Juju. It is that controller, which is an abstraction between your substrate within the hardware and the application that's going to run on top of it. That's bootstrap and then you have got the applications. Now, as I was telling you Chomp.io is the web store where you would have the Chomp, which is Chomp operators. Again, for those of you who have joined recently, operators are the application code plus the code for the one application that's publicly available and it's again an open source project, it's chomp.io. You could go there, there are close to around, close to 400 Chomp that already exists and some of those applications you might be using internally within your own application. So that's the concept of bootstrap. And then again, you have a command that you would have seen that add model. Then you would be wondering what that model is. Effectively, again, in Kubernetes world, if you try to provide it something but namespace, you have trying to allocate a set of machines, set of resources. What it does, it actually isolates your service. Once you have defined it, it works within the boundary of it. You can actually have a price as you can see. It provides you access control. You don't want anybody within the organization having access to that application. So you have got access control to it. It's repeatable. So this is exactly the reason why you can deploy this application on any cloud or any substrate. Because it's repeatable once you've defined the parameters once you've defined what's really required to run that application. You can deploy that application anywhere. And then that model can transport from one cloud to another. So it's repeatability and then it sets boundaries to language in the world. What you saw earlier that came on, like due to deploy, what you could have done, you could have deployed each application independently. You could have said due to deploy in oscillating studio. You could have gone ahead and said due to deploy in oscillating server. The reason why I'm saying this is it's important in the context. If you have got other charms, other applications that you want to integrate, you have already got set up an environment and you run the command to deploy another application, another charm that connects and integrates those applications with the ones that are already existing in the benchmarks. So that's you can actually do that. But what we run the command that you would have seen is juju deploy PhenosLegendBundle. And as the name says, it's a bundle. It's a collection of applications. And that logic of integration and the dependencies is already built and defined in the bundle. So you juju deploy PhenosLegendBundle and effectively what is happening in the backdrop is it is exactly deployed each application. It has taken care of the interdependencies between those applications and the final output was the application was up and running. So one single command and the top board application running. I did touch upon the other point as well as to say software operations, but the challenge for enterprises is integration. You have existing landscape. You have to integrate one application with another. And for all of you who have been in the industry, you would realize that integration is slow. It's hard. It's complex. It's costly. What we have done with the juju tool is let's look at the two application components at your point. One was the studio, which is the front end. You have got this DLC. It requires a credential, you get the credentials and one application provides the credentials and the other application requires it. So if there are any points in the interface that's matching, it's as simple as juju relate. Relate is integrating two applications. The one point that I actually want to leave the thought with, and I was touching earlier, is in order to respond to that rapid change, organizations are adopting a hybrid cloud strategy. It's a journey. Majority of the institutions are somewhere in the spectrum. They will have some workloads which they have decided. It makes sense to actually be on a public cloud and some of the workloads of course are running on the front end. In that scenario, if you had the studio which is running on a mesa, for instance, your front end, and then you had the server running on branch, for example, and then you have got micro-base environments that are up for your hosted Hitler. The beauty here is that juju abstracts that conversation between applications. Your workload can be required anywhere. Once you have defined your model, it can actually integrate those applications which are on different cloud. So, the summary I will leave it and I'll tell you is projects, open source projects like juju and charts, what are they doing? They are simplifying integration. They are simplifying software operations. Perhaps in the demo, I think as you would have seen, if you would like to know more in detail as to how that's working, I've got with me the whole canonical team outside, they've got a group, please by grabbing a cup of coffee. Do spend some time with them. I've got from the engineering team as well, but this here, we'll be happy to spend some time with you and explain in detail as to how that deployment became so easy, what is juju and the various elements of it. Effectively, I think we are getting a step closer to that vision of just clicking a button, with one click of a button you can actually take one application right from scratch. And this is an enterprise application to keep that in mind. So, that's basically it. I think we had a problem statement. We looked at it and how we were trying to solve the problem. Any questions?