 Hi. Good evening, guys. Good evening. Hi. Thanks a lot for showing up on the given track. In next 19 to 20 minutes, I will walk you through part of DevOps cloud native application. So basically this talk is more around how we as in had our journey around the migration of one of our legacy application, one of the very business critical application onto the cloud native and how we achieved our first part. So this was our first step towards getting into the DevOps mode. So while we go through it, while we will go through it, we will cover out why DevOps. So I will not get into too much details around it because I know you guys have been in this, you must be hearing on the DevOps for whole of the day today. We will, while talking about the DevOps, we will get into understand how to achieve it and over there we will try to touch base around what is the cloud platform has to offer over there. Definitely when it comes to the cloud platform, definitely we talk about the cloud native application. How to go about the cloud native application? What is so special about that? What is the features and what are the benefits they bring on to the table? Then we will get into the microservices architecture, nothing new around it. Yes, this is the key SCP to achieve the cloud native application and definitely towards then this is where we will spend most of our time and around our journey, what are the challenges that we face, why we had opted for it, what we have gone through it, what we achieved out of it, what are the next steps and what are our learnings. So certainly it was not like a very plain vanilla walk or a cake walk that we picked up one of our legacy application and we just had migrated into a cloud native application. So before I do that, let me quickly introduce myself. I am Ankur Sambar, I am vice president of global technology, JP Morgan. Over the last 14 years I have been working into the product development of telecom, financial services and e-commerce. So that's pretty much about me. It's just a 20 minute talk so definitely I think I will just spark and suggest you to hold your questions towards and definitely we will do a Q&A towards then. So to start with why DevOps? Why do we even need to have a DevOps now? So DevOps is not like a practice or something, it's more like a culture, that's my take on it. So what we are trying to do is we are trying to build in a synergy between the development and operations so that we can rapidly and quickly create the features and release it to the business. The reason for that is right now, the speed is everything. So time to market is the key in the current scenario. The market is so competitive, whoever can quickly go to the market, get the sense out of it whether this feature is working out or not, whether this new product is working out or not, take that feedback back into the development cycle and build something on top of that, he is going to be the winner. So definitely with the DevOps we can have faster feature deliveries, stable operating environments. If my operating environments are so stable, I don't need to worry around that, then I can very quickly keep releasing features into the market. I can take on those risks because I know if there would be failure, if I experiment something or if they are going to be failure, I can always recover from it very swiftly. And because I'm doing all of this, I can definitely innovate more. The reason being I'm taking more chances, I'm fine to take chances. So I know, so if I talk about say, Amazons or those kind of companies, I'll not talk about the JP Morgan because we are not in that business where we are releasing the features per say into the production on an early or a minute by minute basis. So then we talk about say AB testing and those kind of things. If you release a feature into the market and we see there is a feedback which is not working out, we always go and make a change. So if you look at it, this gives us a lot of time to do a lot of innovation around it. So we can always recover back. We can do far more experimentation around it, faster resolution of the problem because of all the smart ecosystem that we'll see that are built around the whole of the DevOps help us achieve it. So how to achieve it? So there are three key tenants around the DevOps and those are intelligent infrastructure, flexible application architectures and automated process. Now why my infrastructure needs to be intelligent? Can't we just application be intelligent? That should suffice. But now we are talking of in 2017. In 2017, your application just cannot be taking care of anything which my infrastructure can very easily take care of. By that, what I mean is if there is a failure, if my infrastructure is so intelligent that it know how to gracefully handle those failures, how to gracefully do a degradation of the feature. Then so well, so good. I don't need to build in those things into my application per se. If there is a sudden spike into the load and if my infrastructure can take care of deploying and horizontally scaling it by deploying some more additional instances, why not? So my application will be pretty much focused only on to the business and that's the key part. As part of whole of the DevOps or say clouded application development, we are trying to put focus where it needs to be. The focus needs to be for an application, the focus needs to be solving the real business problems that are getting into this peripheral world. Now I have this intelligent infrastructure pretty much in place. And how I achieve it, I'll definitely achieve it through the cloud. So now when I talk about whole of this peripheral things to be taken care of, the best thing comes into mind, why not just simply leverage any of the cloud, be it a private cloud or a public cloud? Now why do I need to even have a cloud? Can't I just have my own set of infrastructure where I can manage everything? Yes, I could do, but definitely not in this era. If I talk about Azure, Cloud Foundry and everything, most of the things are pretty much out of the box available through the platform, like elasticity. If I need to have increase in the scalability of my application, I just do simply deploy multiple instances of it. I don't need to go and now do the multi-thread processing within my application just so that I can handle more of the load. I'll never do that. Apart from that, the other peripheral services are pretty much provided by the cloud itself. It could be like authentication, log aggregation. So now log aggregation is no more just aggregation of log. It's more around building a business capability out of those log events. So there are multiple services which are out of any of your cloud platforms, say Splunk. So Splunk is one of the product which allows you to integrate whole of your log and you can make a lot of business sense out of it, which is very much required until unless you know what is happening in the real time into the processing of say any of your transactions or any other processing, you will not be able to do the justification when you try to do a re-engineering of your application. So that's why there is a big push to leverage a cloud platform. Because whatever you can leverage it out of the box, just do that and then put your real brain into building the business capabilities. With this, I already have my intelligent infrastructure in place, which can take care of all my peripheral services and everything. Now what I have required is flexible application architecture. Because I know my intelligent infrastructure can help me support only to a given extent. Beyond that, I certainly need some capabilities from the application. Now these capabilities, I'm not talking from the business perspective, but this is more around how flexible my architectures are. So if I look at the quick room, I think most of us have already spent some time in the industry where we had some experience dealing with one of the monolithic applications. And this monolithic application I'm talking about say, if we develop 10 years, 15 years back, and nothing wrong with it, with it, because at that point in time, that's what how the architecture was and that's how the development used to happen. So if I look, talk about the monolithic application, what is it? It is one big giant application which has whole of the business logic sitting within a single application. If there is one, it's a single line of code change. You have to deploy whole of the application together. Any problem with that? Yes, I would say most of the time. The reason being, because now it kills your agility. Now if there is a 20,000 lines of code which is lying within a single monolithic application, if I had to release into the production, I cannot just release it on a day to day or an R2R basis. The reason being, there has to be regression. I'm making a single line of code change, but I have to verify that it's not breaking any other feature within the, sitting within the same application. So that's why there were typically a lot of other issues along with this monolithic application. So if I look at my business logic, this is very much convoluted within that whole application. It's not segregated. So I cannot be 100% sure if I make this change, what are the other places it might break or it might not even work as it's expected. No magic van, honestly speaking. So it's only the evolution that what we have previously used to develop it like a monolithic, then we have so on. Now it's more of a cloud native application. So now cloud native application actually helps you tackle a couple of these pain points. Now cloud native applications help you do it to deliver the changes at a great speed. Again, what I had just explained to you about why the speed is so much required, why the stability is required, why the availability, those things are required. Those things will be taken care by the cloud native application. The key thing is how? So one thing is definitely at the back of it there would be an architecture, we'll just come through it. But think about it, so now I have an application which is sitting into the production. How can I take care of all the durability, scalability, availability sort of things? The key thing is about the visibility. Whenever there is an error or an exception is happening into the system, if I can get to know and have that visibility in real time so that I can take some corrective action or I can build my platform further more intelligent to take corrective action on its own. So that's what we talk about the self-heal processes. Fault isolation is another very key aspect. So now when we talk about cloud native application or any kind of micro services architecture, we talk about various smaller services which are providing a business capability, a specific business capability. Now this fault isolation is very much required. So now if I look at it into the monolith, what used to happen if there is an exception, my whole application used to go down. Doesn't make much sense. So if the recommendation engine is not working out, should it stop you buying something from a shopping cart, certainly not. So what would it do? It will just do more like a bulkhead sort of thing where it will isolate you the fault part. That only the given micro service would be isolated and would be tackled differently. Again there are various different patterns around it that how to handle the fault isolation. One I've talked about say bulkhead where you just isolate that piece for a certain point in time until unless that gets recovered. Another is that degradation of the service. If I know I can provide some default behavior, yes, why not? So in that case, I don't have a direct dependency on that service to be available again so that my different other flows can still go ahead. Automated recovery. This is again very much required. So when we talk about any of the cloud platforms, we are talking about the commodity servers or the commodity hardware. Commodity hardware by nature, they are bound to fail. And that's the key paradigm shift when we start designing and developing our new cloud native application because we have to design for failure. We know my application is going to fail. Like this cannot do anything. The only thing I can do how gracefully I can handle those failures. How gracefully I can recover out of those failures so that my business doesn't get impacted. Again, long back engineers at Heroku had defined some patterns which is commonly known as 12 factor app and what they talk about that these are the various patterns that you can use to define the stateless behavior within a cloud native application. So they don't have a shared anything kind of an architecture. All good. I will always say, okay, take it with a pinch of salt. 12 factors when they define, they define it with the Heroku perspective in mind and long, long back. They might not be applicable. All the 12 might not be applicable. It's not that, okay, we have not gone through it or we have not adopted it. Most of them we have adopted, but sometimes it happens that everything is not applicable in your given scenario. Now comes the interesting part, the microservice architecture. So we talked about that we have an intelligent system. We have the flexible application. Now flexible applications are nothing but my cloud native application and I need to implement it. I need to implement it using an architecture and the architecture that we use is microservices architecture. Again, so I have a big moral application where I'm trying to solve a big business use case instead of tying it and digging it out into a single application what I will do, I will create a business capabilities and just create a services out of each of those capabilities. What it means, I will have a bounded context where a service will do only a specific thing. Independent deployable service, so it provides a lot of benefits to us. So once we have segregated this into a separate pieces, again, when I see my big use case, all of my moving parts might not be having the same kind of bottleneck. Some might be having a different bottleneck, so I need to provide, need to do a scale up or scale down. So let's say in my use case, there are four different microservices. One is very process intense or a resource intense. What I would do, I would have a more resources allocated to it. In a monolith, I just can't do that. In this, I can certainly do what I'll do. I'll have more instances to it. I might provide more memory to it. But because these are independently deployable services, so if I need, if I see, okay, there is a degradation of the service. I can always have a separate instance through a horizontal scaling. Yeah, definitely it gives a enhanced cohesion and decreases coupling because now they are pretty much segregated. Now, in any of the typical microservices, architecture implementation, you have different services. They are talking to each other over a network protocol. It could be anything. It could be your RPC. It could be your REST based or it could be over through messaging. But those are pretty separate services in itself, their own separate JVMs and everything. So now I have my intelligent infrastructure. Now I have my flexible architecture. What is my third planet is around the automated process. Automated process are pretty much required to make sure that we are able to bind the bridges between operations and the development. So until and unless I have the capabilities to quickly deploy something and I'm 100% sure that, okay, my process is going to be so intelligent that it will make sure if there are any bridge, it will let me know. What we usually do, we have integrated test suits around it. We have the performance tests around it. We build up the pretty deep CI CD pipelines. Now just start having a CI CD pipeline with help you achieve a DevOps per se. But it definitely helps you identify and make your deployment process much more smoother. So the way we have achieved is we have a, because in a bank it's a very controlled environment. It's not that every check-in can directly go and hit it to the production. So what we do would be, whatever check-ins are happening, they definitely go till at least till UAT. But beyond UAT, they are the control gates. So definitely we have to make sure there are two separate CI CD pipeline. One that hits to the UAT, but another one that can be promoted from UAT to the prod. So the reason why I'm saying so is, it's not that there is a silver bullet. Just look up into what are the use cases or the scenarios or the business requirement that you have and how best it can fit into over there. Apart from that, definitely the release automation that I just talked about. Now let's just spend some time on our journey. So as I mentioned, this was one of the application which is like very business critical. If it goes down, definitely the trading stops. So directly moving into the cloud was not so easy, but definitely the time has come. It was like we have been leaving with this application for last more than 16 years. Over the last 16 years it was serving the business, but now we started facing the problem that the maintainability is a key issue. If we have to make any change, we just cannot make a change so simply and just deploy it. If the new announcements needs to go in, if there are faults, it just kills everything. And every day or the other, if you've got a P1 sort of thing that definitely you don't enjoy those kind of conversations. We started off with the cloud-native design thought process. We thought, okay, now anyways we have to move and we have a private cloud within our firm. So let's now deploy it onto the private cloud. Let's leverage a lot of the benefits coming out of the cloud itself and then build up the business capabilities on top of that. So then we started off segregating out this monolith into the smaller, smaller pieces. The key challenge over there was it was an old application. So 80% of logic is sitting into the database. Pulling out those logic from the database and segregating and creating into the bounded contact is one of the biggest challenge. So any one of you who has ever gone into the journey of migrating a monolith into a, so or a microservice architecture must have definitely gone through the similar pain. Build robust deployment processes because we definitely wanted to make sure that, okay, going forward our changes should be smoothlessly hitting to the prod instead of we getting the manual intervention. So we build all sort of different CSED pipelines. We have all sort of chaos monkey kind of a setup where we can put in and verify, okay, if some of the services are going down how the system is behaving and how they will recover. Leveraging peripheral services is the key part. Again, it certainly depends on what is the scope of your application, how critical that is. In our case, it was, it's pretty critical. So as much time that we have spent on building the business capability, the similar kind of efforts has gone in building out the peripheral services. So by peripheral services, what I mean is like, I need to make sure there are reconcilations happening. So there are pretty clear boundaries for each of the service. If a order or the trade has moved into a service and it has not moved out, definitely the reconciliation fail and the system will take care of it that it needs to be replayed. Apart from that, this all needs to be tracked and there has to be auditability around that. There has to be a feedback mechanism. If my service is down or is not responding back on from one of the dependencies for certain duration of time, then definitely the feedback needs to kick in. So all those kinds of peripherals are there. Apart from that, definitely when we talk about say history dashboards, we talk about the discovery for Eureka and Finn, when we talk about AppDynamics and Dynatrace, those kinds of things definitely help you build up a strong ecosystem around it. What, okay, thank you. So what we achieve definitely, Fleximan is scalable architecture, now all our services are pretty nimble. They are very segregated. We know what is the use case each service is serving. What is the bonded context around it? If a feature needs to be, or a feature enhancement needs to be made, where exactly it needs to be made? As of maintenance, because of all this peripheral services, there is a lot of auto recovery, auto diagnostics that kicks in. Clear segregation of business capabilities, challenges that we face, yes, the mindset change. It's not easy. It's just not easy for the same team who has developed this kind of a monolith application for a very long time to ask them, okay, now segregate and divide into a different microservices. The key challenge comes in, how big should be each microservice? What should be the scope of the whole of the use case that auto business capability that will be served out of it? So that's where, and another biggest challenge is no nano services. So whenever we get into defining the scope of your microservices, the biggest challenge or the problem over there is that you should not get entrapped into a nano services, which is another, the bigger challenge, that instead of having a microservice, serving a business capability, we just get into defining hundreds of nano services, which is going to be a nightmare into the maintenance. Uncle, we've already reached the limit of time. So yeah, that's pretty much from my end. Are there any questions? Cool. Okay, thank you very much.