 Bonjour tout le monde, I'm Chris Plank, I work as an enterprise architect, an evangelist, passionate advocate for platform engineering at NatWest Bank. Yeah, I'm Derek, I'm a principal engineer at Cintasso. Yeah, we, that's pretty much it. I'm from Brazil originally, it's from Scotland, as you can manage from the accent. Yeah. Yeah, and we're here to talk about... Platform engineering and what we're doing right now at NatWest Bank, so this isn't a polished speech, this isn't about right to the end what we've done, it's about what we're actually doing right now. And for those of you who don't know who NatWest Bank are, we're one of the top five banks in the UK. We serve 19 million customers, we've got 62,000 staff worldwide, over a million new personal current accounts last year, 1.5 million new saving accounts, we process one in four UK payments, we do about 750 million financial transactions per month, 94% of our customers needs are met digitally nowadays, and we've got about 10.9 million active digital users, so all good stuff. Yeah, and for those that are not aware, we are at Cintasso, we are the creators of Cradex, it's a framework for building platform, for building platforms, and Cradex enables you to go faster, to decrease risk in your organization, and to really manage the day-to-day operations of all of your deployments, all of your services, and I'll be running a demo later now, hopefully everything will work. There is some stickers around in the desks, there is a QR code that you can join our Slack channel, we're gonna be donating 10 euros per person that joins, feel free to check it out later as well. Excellent. So, before I start, a quick show of hands, how many people in the room have got a main frame? Great, how many people are working on trying to get rid of those main frames? One, two, how many people are running Kubernetes on the main frame? One, us, excellent, thanks for that. So let me start by saying enterprise transformation is hard, it's really difficult when you're a massive organization, when you've got tens of different departments, hundreds of teams, thousands of staff, and in financial services the risks of getting it wrong are huge. The fines alone are massive, and the number one thing that we've got to do is keep the show on the road whilst we're trying to transform. This light here, oh Derek, let me play with a laser, it's deliberately blurred, but this is something that we got from our internal customers on their journey for platform modernization, standing up provisioning, standing up tools. You spend a number of months on the design phase, Derek, pick a number, one in six? Five. Five months, okay, that'll do. And then you go through a number of hoops and hurdles in the next phase, the build phase. I want to use the laser. Pick a number. Three. Three, good, three months on the build phase, and then on the deploy phase, pick a number again, Derek. Four. Four, okay, so you can see it at a massive amount of time that they might spend going through all these hoops and hurdles. Each one of these is a step on their journey, each of the boxes down at the bottom are all the different teams that are involved, the different handoffs, the different cognitive load that they've got to go through, the different things they've got to learn and understand on that journey. And you can see from this picture, even though it's blurred, it's massive. There's a lot of things that they need to learn about, and with that AI and other technologies coming along, containerization for new teams, there's a lot for them to learn, a lot for them to understand, and a lot for them to manage. So what's the problem? Well, over time, we try to resolve that by creating this library of all the different patterns and the different processes that they should go through. We gave them the promise that if they went through this process, they would get an easy path through governance, it would make their life easy, and they would get into production as quick as possible. But over time, these things have bloated, they've evolved, they've had everything thrown in there. And we now have over 135 patterns in the bank. Some of those are just copies for the same thing, but done in a different way by a different team for very valid reasons. And so what we start to do over this process is start thinking about how we can modernize this, how we can decrease that complexity and the slowness that has come about by everyone pushing in all their requirements, whether that's security, whether that's the governance process, whether that's the engineering practices we've got to go through, the attestation and things that we've heard about today. And how have we gone about resolving this? Well, our leadership set us four challenges. Could we use platforms of product-based thinking and approach to deliver an opinionated way of provisioning services for our customers and allow them to do that in a self-service way? How could our existing platform teams and our business teams contribute in a democratized way? So we heard earlier on today people talking about inner sourcing. That's one of the things that we want to do. How do we get them helping us build that platform in some of these new things that we want to do? How can we do this ten times faster, four times more efficient, simplify this? And how can we ultimately move to an end-to-end delivery which is in one hour rather than those seven to ten months that we talked about earlier? Okay, so how did we do it? Well, we went wide. We came to events like this. We listened to what was going on in the industry. We went and talked to Gartner. We went and talked at various conferences like this one. We watched an awful lot of YouTube videos. An awful lot of Abbey Bangs are talking. An awful lot of Victor Farrak talking as well. And we changed our thinking and our approach. You know, we started thinking about, wait a minute. How do we bake everything in here? How do we make this simpler for our developers? It's not just focused on the automation, but like you've heard from other speakers today, think about that end-to-end view. Think about how we simplify that, simplify the cognitive load. How can we change the provisioning so that we can provision those services back to minutes rather than hours, days, weeks or months? And how do we promote this inner source and this democratization approach that we wanted to do? So we looked at all those patterns, that library, those 135 patterns that we created and we started to assess those in a different way. I think in the past, we tried, everyone tried to use those patterns as one way of doing something in the bank. And we quickly realized that there's really three approaches. The first part is the self-managed approach. You know, we've been very successful. We've got hundreds of applications running in the cloud at the moment and hundreds of AWS subscriptions. We've got thousands of microservices running on our platform as a service internally. We've got thousands of applications using our IaaS platform. So we've been very successful in our cloud adoption, whether it's public or private. But how do we take that and how do we start treating these golden paths that are minimizing this cognitive load? So we've got self-managed patterns that install these business units, they've got their own engineering capabilities. They imagine it themselves. They're carrying on following those patterns, but how do we make them better for them? We've got the self-orchestrated. So that's the ticket ops that we heard about earlier on today. You know, people making requests and getting someone provisioned for them. That's a lot of our user base, say, 80% of our user base, maybe. And then there's this third one, the emerging one that we're looking at, which is the self-service-based approach, where we really want those business units that don't have engineering capability just to select some pre-approved, pre-engineered, fully automated golden paths from a portal, just like we've been talking about today. And if we go back to those 135 patterns that we had in the past, customization is the enemy. We don't want customization. We don't want another pattern each time we come up with our self-service model. What we want to start thinking about is options instead, where they can select those options from that developer portal and be able to say, well, I don't want a Postgres database, I maybe want a Redis database with that. How do we do that? How do we support that? Without them needing to actually understand the technology that's behind that. So we came out with our platform as a product approach. What you see in here is a very, very high-level view of what we're doing right now. So we're using backstage, and we had someone talking about backstage earlier on, which is great to see in here and validate everything that we are doing. We're doing an awful lot around our CI and CD2 chain and pipeline. We're using GitLab. We're using Flux. We're starting small, and we're building bit by bit. We're adding more things in the CNCF landscape. And then we're creating these repos. And that's probably where a lot of the power is going to come from for us. This is what we're hoping we're going to get out of it. As we create these things, as we start to demonstrate it, as we build up that trust, that evidence, those working services, those minimal-loved products that our community really like and really want to use, maybe want to extend, they can start going in there and start using inner sourcing, start collaborating, start making those things better. So with that, thanks over to you now. Great. Thanks, Chris. So just quick recap of that West Objectives with their platform as a product initiative. So what Chris just said, that they want self-service. They want the teams to be able to go to backstage and self-serve on the services that they have in their platform. They want it to be democratized. That means they inner-sourcing, they have lots of teams, like organizations like Northwest have lots of teams and they all have their services. They're responsible for different parts of the organization and they want to provide the service. So they need to be open for other teams to come and then provide their services in their platform. And they want to build those golden paths, like all of those 135 plus patterns. They want to make that easy to follow, simple, so users can come and get like the safest and the right approach to request their services. And that's exactly what Cradex, I may be a little bit biased, but that's exactly what Cradex is really good for. That's where Cradex shines. So the main concept in Cradex is a promise. A promise is a encapsulation of something as a service. It's what will enable teams that not to ask to provide their services as a service, like their things as a service. It also integrates quite nicely with any particular API. It's an API-driven software, so it integrates with any portal, like backstage, and that's exactly what I want to see later on. It's also an open framework. The core of Cradex is what we call the workflows, and the workflows can be written in any language using any technology. So different teams doing different things can actually contribute to the platform with the expertise they already have. And Cradex also has this concept of compound promises, that actually encapsulate other promises and orchestrates those other promises. So this allows teams to build those code and paths. So use the building blocks that has been provided by other teams and build, like, more compelling user experiences. Before I jump into the demo, just a quick, like, high-level 30 seconds overview of what a promise is, just so we can talk the same language. But it's basically an API for you all that are more familiar with Kubernetes. An API is pretty much a CRD. It's a set of imperative pipeline instead of steps that need to be executed in order to fulfill the service. So this goes things like notification, billing, compliance, and actually deploying the service, if that's the case. And it's a set of dependencies. Dependencies are anything that needs to be installed or pre-configured in order for that service to be provided, for that promise to be fulfilled. And with that, you have everything you need to understand about the demo that I'm just about to execute. So let me try to do this. And hopefully you can see my terminal. Here it is. This may be a little bit tricky because I need to look at that monitor over there. But this is backstage. This is not exactly the promise that ATO has built, but it's heavily based on what they wanted to provide and what they want to give to their customers. So you can see that what they have is backstage. Backstage is a framework for building developer portals. I'm pretty sure that you all heard about it. We heard about it here in this talk and allows teams to easily consume and see what is available in the platform. So in this particular example, you can see that I have three promises already available in the platform providing different things as a service. So I have a bucket, a deployment, and a Postgres promise. So a user can quite easily come over here, click the create button, choose one of the tiles, let's say deployment, fill the form out. Let's just do that relatively quick. I set some defaults, so I don't actually need to type too much. But this is kind of the form, the API, the API that the users, the platform team at Northwest is actually providing. The users fill those in and then they can create. All of this is auto-generated by critics. So when you install a promise, critics will auto-generate those templates and those components and populate backstage on the back of it. And when the user sends the request, what critics will do is trigger those series of workflows. So those series of steps that are defined by the team that is building this promise to actually deploy the service. So you can see that the pipeline over there for the deployment is running. And in a moment or so, we should see the deployment coming up on the worker cluster for that particular deployment. So that's what we just saw over here. And that kind of fulfills the first criteria, the first objective of Northwest, which is to provide on-demand self-service services. So you can have deployments here. What is interesting to see is that different teams can contribute to this platform. So you can see that the deployment promise, for example, was built by the networking team. The infrastructure team built their bucket promise. And the Postgres team built the database team built their Postgres promise. As I said before, critics is a really open framework. An example of that is that our bucket promise over here is actually using Terraform. So if I request a new bucket, it will run Terraform commands to actually deploy the bucket on the cloud. But the Postgres promise is actually backed by this Postgres operator that is running there as my dependency. So different teams can go and contribute to the platform, the services that they're using, the technology that they are more familiar with, and then they can evolve over time because the API is there to provide that interface. The third thing that we shout about is that the third objective is the golden path. So right now, for users to get their app running with a database, and let's say that database should be backed by an S3 bucket, they will need to manually go and create each one of those individual services and components and wire themself together. So a platform team in Northwest could actually go around, talk to the users and figure it out what is that they need, what is like taking that platform as a product approach, what would make their life easier. And then they may come up with, for example, app as a service promise. So let's just go ahead and install this promise real quick. And what that app as a service promise will do is actually coordinate and orchestrate in that all of those wiring up that needs to happen between all of those services should be able to provide not only deployments, not only databases, but like the entire developer experience, the entire golden path as a service. I just installed that promise. So in a moment or two, I should see a new component appear on backstage for representing my app. Again, this is auto-generated by Cradex. And if we go ahead and click Create, the user can now see a new template. So a user of this platform can now come over here and say, well, I want to deploy a new app. Let's call it to-do app on my default namespace. Here are the fields that need to configure. So all of the complexity about requesting that service is not hidden for me. I can request, oh, I want a database, or I don't want a database, I want a Postgres database. I can reveal and hit Create. So what Cradex will do on the back of this request is exactly the same as it did for the other request. It will go and trigger out the pipeline. So let me go back to the terminal and I should see the pipeline for the app running. But this pipeline is different. It's actually using those building blocks to define it by those different teams to provide that experience. So in a moment or two, we should see other pipelines triggering. And those pipelines are actually the pipelines defined by each one of the individual promise. So you can see the Postgres pipeline coming up. You can see the deployment pipeline coming up. We can see the bucket pipeline coming up and running. This is going to take a little bit of time. It's downloading a lot of Terraform. Not a lot, just AWS module, which in the conference Wi-Fi takes a little bit of time. But eventually it will complete and create those buckets and wire all of those things together. And you should also see the Postgres database coming up and the Chidoo app coming up there as well on the back end. And now the user can also go back to backstage and again, it's auto-populates for those components so you can see all of the bits that make the Chidoo app in a single page. So as Derek said, we're trying to realize some of those patterns that we're going to be using from Crattix. We've gone after the type three patterns that I talked about. Really simple use cases. Just like we heard earlier on today, start simple, start small, start iterative on that platform journey, build up those products over time, add more features in based on the user needs, requirements, feedback that we heard about today, build them up into those more fully fledged offerings. Part of this is really about bringing on board thousands of new developers every year. How do we reduce their cognitive load? How do we make them productive on day one instead of say, I don't know, day 50 of them joining the organization? They don't need to know that they need to go and talk to Bill and Eddie and John and different teams. They don't need to know they need to fill in this form and triplicate and go to this service now page that's been changed and hasn't been kept up to date. They can just go to this one portal. They can put in the information that they know and that they need and then they can start being productive. That's really what we're trying to do with this. Yeah. And that's kind of the end of the demo. So just a quick review. They can use, I started with a backstage so you can see a bunch of promises and those promises are what provides the self-service aspect. It's democratic, different teams are contributing to the platform, installing their own promises, defining their own processes. And yeah, the golden path can be offered by compound promises via the platform team. So I'm just going to hand over back to Chris. Yeah. So key takeaways I'd like you to take away from this presentation today. I probably went over it far too quickly but the slide that showed all the steps and all the processes, that came about through engaging with our customers. It actually came from one of our customers and we went through that process, we followed it, we felt their pain. We empathised with them when we went through that process and validated it and now we're trying to do something about that and I heard some people talking about that earlier on this afternoon. So you can kind of relate to that. Another thing, embrace different thinking and different doing. A lot of those type one and type two patterns that teams are doing at the moment are DevOps. And a lot of what we're talking about today is GitOps. Thinking about how to bake things in, thinking about how to simplify, reduce that cognitive load by platform teams baking that in, taking that need for developers to do that away from them and giving them something that they love, they use and they enjoy. And then the third one is don't boil the ocean. You know, start small, simple things. Don't try and change everything, but just try and get something up and running that you can then demonstrate the value of the platform. You can get buy-in to the platform. You've got some evidence there, some examples there that people can start collaborating on, they can look at the code, they can start contributing to that code and then they can actually start adding new features and working with you. I think that's it really. Time for questions. So a quick question. In a bank where you have lots of siloed sources of knowledge, you've got your database team, your middleware team, how do you get them to buy-in to the platform? How do you get them to build those promises that other people can consume? Yeah, so we've... It's on now. So we've started working with our platform teams we've brought them on the journey, we've taken almost a train, the trainer approach with our platform teams, we've taken some of those into a feature team that our leadership is funded and we've helped them on their journey of learning, discovery, we've helped them, working with Sintasso, we've done a lot of pair pairing as well, pair programming, get them up to speed and then in the next PI, they're then kind of the focal point of the team to then expand that out into that wider team. And so we've brought in different teams whether that's the observability team, whether that's some of the cloud team, whether it's some of the database teams, we've brought them together actually working on some real promises. The beauty of the Crattix model is they're like Lego building blocks. So a promise is just like a building block so we can put them together. Some of the things that we've talked about today about it's the platform team's responsibility to create those in the API. Well that's what our platform as a product team does but they're also kind of guiding and mentoring those platform teams that are developing the individual promises and then the platform as a product team wires those together to create those APIs and those products and those patterns for people to use. So you get a lot more collaboration, a lot more deeper collaboration because you're bringing someone into the team and working on them but then you're getting that expansion as well through the organisation into their home kind of teams and they start talking about it, they start doing it and then other people hopefully over time will start actually contributing to that. So we've got some objectives for this year. I mean we're right at the, not right at the start of our journey but you know we're in the early stages of our adoption and we had a call on Friday really wanting to talk about how we expand this out through the whole of the hosted solutions division that I work within, how we get all the platform teams onboarding, how we get them doing some promises at the end of the year, every single team and meaningful things made available for our customers. We've been engaging with the customers as well and asking them what they want so we're trying to bring all that together through this initiative to just make it easier for people to consume and ultimately get products out to market quicker, cheaper, better for those platform teams that actually need these hosting solutions. Sorry, last question I promise. So family that sound like you need to build an internal developer advocacy and developer evangelism I guess within the group, right? But do you need a starting point before you start evangelising to the other teams? So in true proper style, we've got lots of starting points, we've got lots of teams trying to do the same thing and it's how you corral that enthusiasm together. We've got brilliant leadership who set a lot of the direction and we're now in year two kind of year three transformation on how we want to align our whole division and call it DigitalX and we've got a brilliant team Enterprise Engineering that work with us the other ones are actually pushing ahead with a lot of the developer experience they're pushing ahead with a lot of the backstage side of things the GitLab adoption we're pushing ahead with the Crattix stuff, Crattix and backstage work nicely together so you know by collaboration and talking we're working on this I got an email on Friday from a presentation Derek and I did on Thursday to our infrastructure as code community and it was from the security team actually asking well can we do our vault onboarding now working with you guys using Crattix, right? So we had someone else in that presentation it's a business unit, it's our data business unit and they said well we're working on some technology we want to expose that to our users, could we use Crattix to do that? So we're beginning to see the early kind of green shoots of people seeing Crattix, seeing what it can do and thinking about how they could use that how they could contribute to that that's really how we want to grow this we've got a lot of different people talking a lot of different conferences about our open source approach and what we're trying to contribute we're members of FINOS we're trying to use events like this really to talk even to ourselves about this is what we're doing internally come and be part of it hi over here, I've decided it doesn't really matter really interesting talk I'm kind of curious how far do you see your platform going do you see it going to the point where you're actually managing things like AWS accounts or GCP projects or Azure accounts as well so one of the first promises that we actually have been working on is our account machine process but we're looking at that to embed it we can make it available for developers via the developer portal so that they can just go request that instead of going through the current process and that will definitely make it quicker but we're really thinking about how we bake that into some of the products and the Intuit guys that were talking earlier on about the developers not having direct access to the platform that's very much where we're trying to go for the type 3 patterns we've probably got just say it's 80% of the business don't have those engineer teams with those terraform skills, you know we've got some brilliant teams like our M platform team that looks after all our customer facing websites and does phenomenal work there but we've got teams that have maybe only one or two members in that team and they want to do single page web apps and they want simpler internal things that they want to do, they don't really need to learn about AWS, all they want to do is publish content so we're going to build all that into a product for them to use because that's actually quite a popular thing that we do already on our platform as a product, platform as a service platform at the moment same with micro service publishing and several other things that we put on that platform how do we start doing those and spread those out to public cloud, that's what we're trying to do and then we'll manage those accounts and those services they just manage kind of the consumption and the actual application part of that that was a very nice segue to my question oftentimes there are people that come with one or two members and they say okay I want to start with a simple web app and they go with the self service approach after a few months they come okay my requirements have changed, now I want to build X or add on to this now you don't have that big capacity of a team where you are supporting that team for every requirement that comes into play have you come across this challenge and have you thought about how you would scale at that point so I think that's part of the challenge we're trying to address you know in the old pattern model we came across that we would have a pattern and then a new application would come along from some other team and it would be a dash application name kind of copy of that with some subtle changes we're now trying to address that and you know I had on the slide customization is the enemy we're trying to get away from that customization we're really trying to minimize we don't want 135 patterns anymore if you think about AI coming along it's almost like a tsunami of new unknown patterns that are going to hit us so we're really trying to move towards more of a documentation at the end of the pattern you know documentation is code so that as part of building this as part of people using it the documentation is there and if all that documentation is there and we make that a really easy path for them then we should recognize all those different variances and we should be able to kind of steer the teams towards these things that will actually do the work for them and explain why it's better for them to do that than try and come up with some other pattern I think just to maybe add to that as well on the critic side what we show using the compound promise using the building blocks is that one team is actually consuming other teams service via an API so you can change what is happening there so I think segue the next step on the demo would be what happens if there is a new mandate that every single deployment needs to have HA and other characteristics like other things the networking team that owns that promise can easily apply that and get that update rolled out across the fleet I think that's kind of what would help with that as well like requirements change Hello, nice presentation thank you very much for that so a couple of questions how do you deal with some components that are very secure sensitive in terms of security like DNS or fire or whatever and not all the teams so the application team should have access to them and what happens with the governance I know you're a bank you're heavily regulated with governance and the procedures on how to deploy things how do you deal with that do you have a proper processes or yeah so a lot of that in the moment patterns describes those processes and those security controls that you have to go through and we have different parts of our organization different teams and kind of platform teams create some of those controls that everyone has to apply to say their public cloud or the private cloud stuff we already have that right we're very successful in DevOps at the moment so how do we take that and turn that into Crattix promises how do we maybe simplify some of those controls that we've got that were guardrails for how people do engineering in public cloud we're now working on that how do we get those kind of smaller simpler as part of the products baked into the product rather than something that's separate maybe there's a bolt on that's one thing that we're doing at the moment just to add to that as well the Crattix promise the workflow bit is that a lot of those automations about compliance billing notifications security scanning all those things can be incorporated into the product so when the user requests something as a service it actually goes through that series of steps that are like built by the team that is built in the promise or provided by another team one part in WC as well is like you have a security team that builds a stage in the pipeline and what they ask is can you incorporate this stage into your promise because this needs to happen for me to expose a service via the internet for example so I think that's how those things fit together as well Thanks Eric Thanks Chris Thank you