>>Well, thank you, everyone. And welcome to winning the roadmap race. How? Toe work with tech vendors to get the features that you need. We're here today with representatives or RBC Capital Markets. We will share some of their best practices for collaborating with technology vendors. I am Ada Mancini, solution architect here at Mirant us. And we're joined by Tina Bustamante, senior production manager, RBC Capital Markets and Minnows Agarwal, head of capital markets. Compute and data fabric. Um, RBC has been using docker since about 2016 and you've been closely involved with that effort. What moved you to begin, contain arising applications. >>Okay, uh, higher that. Thank you for having us. Um, back in 2016 when we started our journey one off our major focus, Syria was measuring develops capabilities And what we, uh what we found was it was challenging. Toe adopt develops across applications with different shapes and sizes, different text tax. And as the financial industry, we do have, um, a large presence of rental applications. So making it making that work was challenging. This is where containers were appealing. Tow us. In those early days, we started looking at containers as a possible solution to create a standardization across across different applications to have a consistent format. Other than that, we also saw containers as a potential technology that could be adopted across across enterprise, not just a small subset of applications. Uh, so that that was very interesting. Interesting. Tow us. In addition to that, uh, containers came with schedulers like kubernetes or swarm, which were, uh, which we're doing a lot more than all, which would do a lot more than the traditional traditional schedulers. As an example, resource management fell over management or scaling up and down, depending on a application or business requirements. So all those things were very appealing. It looked like a solutions to a number of problems that are number of challenges that we're facing. So that's when we got started with containers. >>So what subsequently motivated you to start utilizing swarm and then kubernetes? >>Yeah, other than resource management, the follower Management Aziz, you can imagine managing followers. D are Those are never difficult, Never easy on with containers. We saw that, as the container schedule is, we saw that it's a kind of becomes a manage manage service for us. Um, other aspect We are heavily regulated industry in capital markets, especially so creating an audit trail off events. Who did what? When? Uh, that's important. And containers seem to provide all those all those aspects tow us out of the box. Um, the another thing that we saw with containers under the schedulers, we could simplify our risk management. We could control what, what application on which container gets deployed, where, how they run on when they run. So all all those aspects of schedule er they simplify are seen to simplify at that time a lot off a lot off the traditional challenges, and that that's what was very appealing to us. >>Eso what kind of changes were required in the development culture and in operations in order to enable these new this new platform in this new delivery method? >>Yeah, that that's a good question, and any change obviously requires a lot of education. And this was not just a change across our developers or operations, but it was the change across throughout the change, starting with project managers, business analyst developers, Q A, uh, Cuba and our support personal. In addition, I talked about the risk and security Management so it it is. It is a change across the organization. It's, uh it's a cultural change. So the collaboration other than education collaboration was extremely, extremely important. So across those two, we started first with internal education, using something like internal lunch and learns. We did some external workshops or some hands on workshops. So a lot of those exercises were done in collaboration across all those all those things. The next item that we focused on is how do we get our high end developers the awareness of this technology on, uh, make sure they can. They can see, uh, the use cases. Or they can identify the use cases that can benefit from this technology. So we picked high end developers, noticed application and kind of try before you buy type of scenarios. So we ran through some applications to make sure they get their hands study. They feel comfortable with it on. Then they can broadcast that message. The broader organization, the next thing we did it waas getting the management buying. So obviously any change is going to require investment on uh, making sure there's a value proposition that's clear to our management as well as our business was critical very early on in in container option face. So that that that was that was another item that we focused heavily on. And the last thing I would say is a clearly defining strategy benefits so defining a roadmap off how we will proceed, How do we go from our low risk to high risk application or low risk medium risk applications? And what other strategy benefits are these purely operational? Are these purely cause best benefit? Or it's a modernization of the underlying technical facts. So if the containers do check all those three boxes So that that was that was our fourth item on the left that, uh, that, I would say, changed, um, in a container adoption journey. >>So as as people are getting onto the container ization process and as this is starting to gain traction, what things did your developers embrace as the real tangible benefits, um, of moving the containers of container platforms? >>It's interesting. The benefits are not just for developers. And the way I will answer this question is not from development operations. But let me answer it from the operations to developers. So operationally the moment developers saw that application can be deployed with containers relatively quickly without without having them on the collar without them writing a long release notes. They started seeing that benefit right away, but I don't need to be there late in the evening. I don't need to be there on call to create the environment or deploying, uh, deploying Q A versus production versus the are to them because, like do it right one on then repeat that success factor of different environments. So that was that. That was a big eye opening, um, eye opening for them. And they started realizing that Say, Look, I can free up my time now I can focus. I can focus on my core development, and I don't need to deal with the traditional traditional operational operational issues. So that's what that what? That was quite eye opening for all of us, not just for developers. And we started seeing those, uh, that are very early on. Another thing, I would say the developers talked about waas. Hey, I can validate this application on my laptop. I don't need to be I don't need to be on, uh, on on servers. I don't need all these servers. I don't need to share my service. I don't need to depend on infrastructure teams or other teams to get their check is done. Before I kept start my work, I can validate on my on my laptop. That was that was another very powerful feature. Um, that that empowered them. The last thing I would say is that the software defined aspect, uh, aspect off, um, off technology as an example, Network or storage. Although a lot of these traditional things that something Democrats have to call someone they have to wait on, then they have to deal with tickets. Now, they can do a lot of these things themselves. They can define it themselves, and that's very empowering. So they are perspective. Our move towards left, Um, s o the more control developers have, the better the product is. The better the quality of the product. The time to market improves on just the overall experience on the business benefits. They also start to They all start toe, um improved last part. One extra point. I would like to make here the success success of this waas so interesting, uh, to the development community even our developers from business. They they came along and they have shown interest in adopting containers. Whether it's, uh, the development developers from the quartz are the data science developers. They all started realizing the value value proposition of containers. So it was It was quite eye opening, I would have to say. >>And so while this while this process is happening while you're moving to container platforms, um, you started looking for new ways to try and deliver some of the benefits of containers and distributed systems orchestration more widely across the organization. And I think you identified a couple areas where, um, the doctor Enterprise kubernetes service wasn't meeting the features that you anticipated or it hadn't planned on integrating the features that you required. Um, can you tell us about that situation? >>Certainly. Haida. Thanks for having us again. Um, from the product management perspective, I would say products are always evolving and the capabilities can We have different stages of maturity. So when we reviewed what our application teams what are businesses looking to dio? One area that stood out was definitely the state of science space. Um, are quantum data science is really wanted to expand our risk analysis models. Um, they were looking for larger scales, uh, to compute like a lot more computing power. And we tried to see, um, come up with a way to be ableto facilitate their needs. Um, one thing, and it really, really came from like an early concept was the idea of being able to leverage GPU. Um, we stood up like a small R and D team, trying to see if there was something that would be feasible for our on our end. Um, but based on different factors and considerations and, you know, technical thinking involved in this we just realized that the complexity that it would bring to our you know, our overall technical back is not something, um that we would be, um, best suitable, I would say to do it on our own. So we reached out Thio Tim Aransas and brought forth, like, the concept of being able to scale the kubernetes pods on GPS. We relied on there authorities on their engineers Thio, you know, think about being able to expand, uh, kubernetes there kubernetes offering to be able to scale and potentially support running the pods and GPS um, definitely was not something that came from one day to the next that it did involve a number of conversations. Um, but, you know, I'm happy to say I was saying the recent months it has become part of the KUBERNETES product offering. >>Yeah, I believe that that effort, um, did take ah, while took a ah lot of engineering effort. Um, and I think initially all had done some internal r and D to try to work on those features, but ultimately, you decided to go with a different strategy and rely on the vendor to produce those assed part of the vendors product. Um, can you elaborate on the things that you found in that internal R and D? >>Well, we definitely saw the potential for there was definitely potential there. But, you know, the longevity of actually maintaining that GPU, uh, scaling using communities on our own was just not 100% like, in our expertise, expertise of something that we wanted to collaborate more closely with the vendor. Um, you know, technology is always evolving, So it's just the longevity of keeping up with, like, the the up to date features or capabilities testing que involved was just not something that we thought it would be. Something that we should be taking on on our own. >>Okay, So, like spending the time and engineering effort, focusing on the data science, the quantity of analysis parts I see. Um, and then ultimately, um, working with the vendor produced a release and where these features are now available. Um, how what did that engagement look like? Um, with RBC s involvement, >>I would say the engagement started off with, you know, discussing bringing it forth, being very open, you know, having transparency. So that delivery was always a little bit was the focus. Um, but it definitely, um, started office, you know, discussing what it would be like the business case. Why we would require the feature. Definitely the representative. Those and others engaged from them. A ransom side had their own, Um, you know, thoughts and opinions. Um, it had to be being able to run the work clothes, um, on GPU would be something that they would ultimately, as I mentioned, have to support on their end. Um, so we did work with them very closely. There was a very much a willingness collaborate we held a number of meetings. We discuss how the CPU support would would actually evolved. So it wasn't something that came about within like one sprint. No, that was never like our expectation. It did take a couple weeks to be able to see, like a beta product opine on it, see a demo, review it, discuss it further. Um, as you know, sometimes there might be a relief where this capability maybe offered, but there are delays. It's just, you know, part of off of our industry in a cent. Um, we're very much risk versus the nose mentioned, you know, >>when >>you are a financial institution. So we just wanted to make sure it was a viable product, that it was definitely available off the shelf, and then we would be able to leverage it. Um, but yeah, the key point, I would say, in terms of being able to bring the feature forward with definitely constant communication with Miranda, >>that's excellent. I'm glad that were ableto help bring that feature forward. I think that it's something that a lot of people have been asking for and like you said, it enables ah, whole new class of uh, problem solving. Okay. Uh, Meno je Tina, Thank you for your time today. It's been wonderful talking to you again. Uh, that is our session on working with your vendors. I want to thank everyone who's watching this for taking the time Thio contribute to our conference. Uh, awesome. Thank you, kitty.