 Okay. Good afternoon. My name is Surya Dugurala. I'm an STSM with IBM's Cloud Division. And with me, I have Melorad from RBC, Royal Bank of Canada. Today we're going to talk about cloud foundry in action in banking and financial sectors. RBC is at the forefront of exploiting cloud foundry in their digital transformation. Today, Melorad and I are going to talk about how this whole cloud foundry journey at Royal Bank of Canada started. And what all the applications that we are using deploying on cloud foundry. And in fact, Royal Bank of Canada has 40 applications in production right now on cloud foundry, both in retail online banking as well as the commercial banking. So we're going to just talk if you are some of you are an account holder of our Royal Bank of Canada. If you are looking at your account summary or paying the bill pay or anything, you are in fact using cloud foundry right now. In fact, we have rolled out to six to seven millions of the retail banking customers. So it is a very highly scalable platform. And how we started this whole journey, actually this RBC's cloud foundry journey started back in 2015. So from 2015, now as of last week, we have around 42 applications also in production. So I'll just talk about the RBC itself. Some of you may not be familiar, but this is Royal Bank of Canada is a global bank. RBC is number one in Canada, but also it has full global footprint. It has around 80,000 employees and also you have operations in 42 countries. From RBC's strategic point of view, like any other major bank, RBC has multiple lines of business. You can see that you have personal commercial banking, wealth management, insurance, investor and treasury services. All of these lines of business have multiple applications, enterprise applications that we are looking at getting to the digital transformation. And today we're going to talk about mainly the personal and commercial banking. So those are the lines of businesses that these 40 applications belong. And we have a technology and operations, TNO, strategic branch which will be overseeing the digital transformation across RBC. So the main reason why we're actually talking only about the personal and commercial banking right now is because that's in the forefront and that's the number one leg of this whole LOB. And then the wealth management and other lines of business are actually following through. So when we talk about RBC's business financial services portfolio, one of the key pillars of that is the commercial banking. And I would like to have Melorot from RBC talk mainly about what is the strategy in the commercial banking and how the business financial services digital portfolio is actually adopting the Cloud Foundry here. So Melorot. Thank you, Surya. And I'm really sorry for missing the first portion of our presentation here today. So as Surya pointed out, my name is Melorot Stefanovic. I have been with RBC for some time and prior to that actually I lived here in California for about a year. So it's always good to be back. So very briefly, RBC as Surya pointed out is the largest Canadian bank. You may or may not be familiar with RBC in case you actually have wealth management products here in the U.S. You may be working with our U.S. wealth management business. And we recently have acquired another business here in California as well, Citinational. So what I'm going to talk about... Sorry. Yeah, no problem. What I'm going to talk about here today is our business banking platform. On the business banking platform we serve a broad range of clients from small business clients all the way up to the largest business clients in commercial clients in Canada. The group responsible for the time management lead is focused on digital business banking, so online and mobile for our business clients. What's interesting to know about RBC is that like all other banks it has been around for a while and in case of RBC the number is 150 years, around 150 years. Of course there is a long history of technology, legacy technology that we have in our stack. And the group that I manage is no exception to that. What you're seeing there is our current technology stack in terms of digital business channels, which is the group that I mentioned, and online banking. They all sit on a set of all their legacy systems in the back. So what we have done in the last year or so is we have had significant push and progress in terms of digitizing everything that we do from the full adoption of agile methodology in terms of delivery all the way down to using cloud platform for everything new that we are developing. And so far the journey has been very positive, I'll talk more about that later. In terms of the clients that we serve, we serve more than 600,000 small business clients. We have around 60,000 large commercial clients and of course with commercial clients we have a large number of users within those businesses to the tune of around 180,000 users. In business banking as you know payments play an important part. And the payments, when we talk about payments we talk about business to business payments, large corporate payments which are more than our kind of Starbucks shopping for coffee. We're talking about millions of dollars that are being moved. So why that's important? The critical importance of this is that we cannot afford for our assistance to be down or for those transactions not to be completed in a timely and reliable resilient manner, which is something that we have taken into account as well. We also provide a number of value added services to our business clients. And that's where innovation comes in. So in addition to innovation that we drive within the organization it is important for us to be able to work closely with external partners and to partner up with FinTech companies as well. And that's another important component of that puzzle that I mentioned earlier in terms of agility, cloud infrastructure and the ability to integrate through APIs. Should we go to the next slide? Okay, so I think I may have actually covered some of these points here. What is important to highlight is that everything we knew that we have been developing over the last year or so has been done as cloud native micro applications, micro services. And we also are on in the journey of taking our existing legacy monolithic applications and porting them or moving them to the cloud platform. We are doing that both as lift and shift, but in cases where it makes sense, we are actually making those applications much more modular and making them closer to the cloud native type of design. Okay, so maybe, sorry if I can cover this part. Thank you. Okay, you can hear me now. So the main thing when we have segregated all these applications, as I said, around 30 to 40 applications, they all under like retail online banking portfolio risk management, rewards mobile and all these different categories. All of these we started with one POC. The POC is about the online retail banking. So if I were an RBC customer and trying to check my account summary or trying to pay the bills, as I mentioned. So what we were trying, initially we were focusing more on the UI and security and the services, because all these applications are currently deployed in mainframe and using the existing middleware. So we wanted to take one small piece of that and then see whether Cloud Foundry can actually scale to the levels that we expect. And the ask was, okay, can we showcase 400 to 500 transactions per second with sub-second response time when we run this on Cloud Foundry. RBC has both, you know, Bluemix Cloud Foundry local as well as dedicated. The way they're using that is they have, for high availability, they have two data centers from a Bluemix Cloud Foundry local point of view. They are both active-active and they get the data back from the mainframe. So that's a typical pattern for most of the banking and applications. So what we did, we have redesigned the front-end with AngularJS and we have, you know, we have been using the trust association receptor plugin for security, for authentication. We have actually used that and we have customized the TAI module and then we have used for security and we have used both mutual SSL, you know, authentications there. And also we have these services because the way we access the service from the back-end is through a data power in between and that's the whole topology. So the simulation of that, we started with two Java applications. One application is simulating the orchestration layer. The second one is the stub layer which is simulating the back-end interaction from the mainframe. So those are the two main pillars that we have actually deployed in Cloud Foundry. And the goal of this whole initial POC was to make sure that, you know, we can scale and also we can use the autoscale features also to, you know, seamlessly scale and, you know, expand and shrink. And also we wanted to demonstrate whether Cloud Foundry can handle this massive load with stability at this peak load running for like 24 hours, right? So those are initial asks when we started this POC. And of course, you know, we have come across initially when we started this whole thing, we were at 12 transactions per second with 90 seconds response time. So we were thinking this whether Cloud Foundry is ready for the prime time for, you know, this kind of banking applications. And then we started working through and we have some of the issues that will be applicable for everybody, right? When you go from an on-premise middleware solution to Cloud Foundry, you have to look into your application, whether some of these things are ready. For instance, you have session affinity if you're using. The session affinity, if you start using autoscaling, then if you provision, of course autoscale service, you know, based on the traffic, based on the policy you specify, you can have multiple instances provisioned. But if you have session affinity there, then the traffic won't be directed to the other instances. So it will stick to the first instance. So those are some of the things that, you know, you need to look into when you move your applications to Cloud. And then other thing that we have come across was the, when you're running your Java node applications from within the runtime, then what will happen is the autonomic threading algorithms that these runtimes will use, they may not be working, they may not be agile when you are having the backend service latency. That is when you're accessing the mainframes. If the service latency is really high, then it may not really work. So those are some of the main things that, you know, we have identified and we have looked at the alternatives to fix those things. And that's how we could get from, you know, like 12 transactions per second to not only beat our goal of 402, like we have gone up to 900 transactions. So just to put some context that we are talking about almost 80 million transactions per day. These are all the financial transactions. They are heavy in terms of you have to bring a lot of data from the mainframes. And then you have to render that back onto the GUI with AngularJS. And also you have a lot of computations in between. So these are CPU intensive transactions that we are talking about with 80 million transactions per day. So some of the main benefits that we got out of this Cloud journey with RBC are, you know, you can see that the return investment and the client experience that we have, and then the digital banking channels that we have actually reduced the risk and cost. For instance, previously it used to take almost an year for us to release a second version of an app or so. That from an year to almost, it has come down to like hours. We can actually release the new functionality in terms of whether the front-end or any other channels. And also the quality and the production resiliency. So I would like to give it to Milorot to talk a little bit about what we have gained in this journey in terms of the production resiliency and stuff. Sounds good. Thank you. Thank you, Surya. So as I mentioned earlier, this is really very much part of our digital journey. From an old school banking institution to a digitally enabled relationship bank. And what you can see here is some of the key benefits that we have seen so far. The benefits that we are looking at here are the result of the agile delivery model that we are following today. And we have within digital business banking, we have 10 persistent agile teams. They are also the result of the DevOps processes and tools that we have adopted within our portfolio and the cloud platform that we are using. What you are seeing here is the improvement in production resiliency. And I mentioned earlier how critical production resiliency is for business banking. We want to make sure that our application is always available for our clients and that there is no issues in terms of the payments that we are processing. We have seen more than 90% improvement in terms of production incidents. So we have reduced the number of production incidents by more than 90% over a short period of time of about just slightly more than a year. We also during that time have seen significant improvement in terms of quality. So we measure quality of course in terms of defect arrival rate and the quality has improved by more than 40%. In some cases for our maintenance activities by 90%. What you can see here as well is the portion of the maintenance and new design and development projects or agile teams that we have in our portfolio. Do you want to talk a little bit more? Sure. So just to provide a summary maybe of everything that we have said so far. We had a very positive experience so far developing everything new in our portfolio using cloud native microservices based architecture. And we are very much aggressively pushing in terms of modernizing and cloud enabling our legacy applications as well. At this point we have a portfolio of close to 10 micro applications that are used by all of our business banking clients. And with our release schedule based on a monthly implementation we expect that number to double in the coming months. So basically from our RBC's cloud foundry journey using Bluemix has been exceptionally positive in terms of basically there are two types of applications. One is the lift and shift because they have a lot of investment that they did invest in the middleware like maybe WebSphere or any other message broker. All these applications without any changes to the applications they want to just deploy them and bring them onto cloud using cloud foundry. They were very successful in that and of course we had some migration tools that we had to use for verifying that you have any other capabilities that you had on on-premise that are not there so that you filter out so that it will be easy for. The second type of applications are the pure cloud native and microservices. The one that online banking retail application that I was talking about which is rolled out to six million retail customers that is a cloud native microservices application. It has been written from ground up and of course it has used some existing security modules and things but the application is a cloud native. So it has been a mix of both. So the third important point that cloud foundry usage by RBC Royal Bank of Canada is the operations and monitoring and how you can diagnose any problems that you may have in production as well as during the development. So we have another session around 2.30 to 2.25 that talks about the monitoring and diagnosis tools that are available in cloud foundry and how RBC is using those tools to monitor and diagnose any performance issues that we have encountered in the production as well as DevOps. So with that I can open up for any questions. Okay so the question is okay do we see any kind of performance, what is the performance characterization differences between an on-premise same application running an on-premise versus the same application ported and migrating in cloud foundry. We saw similar performance except we found if the backend service latency like when you are talking to the main frame and if the backend service latency is actually much higher because of any reason it may be a network or anything then you may have to tweak and tune the run times because certain algorithms in the liberty or the middleware run times they may not be agile enough if the backend service latency is much higher. Typically main frame latency is anywhere from 100 to 200 milliseconds that's what we expect. We simulated to 1000. That's when we saw really the autonomic algorithm doesn't really adjust the thread pool size for the traffic so then the performance will come down. But if that is the case you have two options either you adjust that latency or if you can't do anything in that then you have to override that autonomic algorithm with a manual you can specify the manual scheduler and then tune it that way. Okay so these legacy applications on cloud foundry we are running them on cloud foundry both. Yes web sphere application let's say you have a web sphere full traditional web sphere application like Java E application and you are trying to actually run that on cloud foundry in cloud foundry you have liberty applications you don't have the full traditional WAS so you have a smaller footprint liberty so as long as your application runs on liberty it will run on cloud foundry. Okay so the question is okay where these clients are residing and where the actual data center the cloud foundry is running the data center is in Markham that's like a real in RBC's on-premises and it is exactly the same like where our on-premise servers used to be there right so it's exactly the same as far as the data center is concerned for end customers. Yes yes we have both RBC has both BlueMix local which is in production and also RBC has BlueMix dedicated which they are using for development and testing so they have both BlueMix dedicated as well as BlueMix local for security reasons you know they want to keep this on the local that's the production you can actually you know developers can code their things on and test it on the Markham computer center that is MCC and they can actually push it for production on to the local. Okay so yes we did on both local as well as dedicated because the architecture of BlueMix cloud foundry is exactly the same so you will see exactly the same performance on both only difference you may see is because if you are having multiple tenants like sharing the environment let's say you have dedicated with like so many users that they're running then you may see a slight little bit difference in performance otherwise you will see exactly the same performance on both local and dedicated. Yeah so the network latency is the latency between the runtime on the back-end services right as long as you have we have a dedicated line between these two so because you have the dedicated line the latency effects are taken care of. Yeah of course again the end of the day you know if you have your runtime in Dallas and your database is in Toronto for instance obviously you will have the network latency as long as you know you have you know like the dedicated line with maybe you know 10 miles 20 miles 30 miles the performance won't be that much impacted on the latency sorry. Okay shall we use any certain window or you can do any time push application. We have some controls because this is production right so we have all developers cannot just push it so we have to promote and we have a process to promote that and we don't have any window as long as we follow the process anytime you can actually push the promote the application from development test to production. Okay online all app like online processing versus the batch kind of applications can you use both kinds of applications deploy them in Bluemix Cloud Foundry that's your question right. Yes yeah so the question if I understand right but this is a common thing if you are trying to access and bring large sets of data results sets from back in database Bluemix you can use some caching services to cache so that you can reduce the round trip costs so Bluemix can handle that caching you know you can attach your application to a caching service maybe you know Redis or something right so that you can reduce the latency of going back to the data service multiple times that's one thing we can do and then the second if you're talking about batching the applications yes you can do let's say you have a Cloudant in the back end as a data service and if you want to just have some kind of you know like because Cloudant is like an HTTP based if you're pushing each time when you go post or get or anything it's an HTTP call so you can batch those things together and then actually you can push at one time yes Bluemix has those features I apologize I'm gonna have to run to pick up make a call so thank you thank you very much right thank you