 Welcome Good afternoon. It's quite a long way down there. There are many people down there I think. Yes Hello! I hope you had a nice lunch. Any feeling all nice and full? Not too sleepy? You're going to be scintillated now by my talk. I would just like to say there are a number of amazing tracks at this summit. a number of fantastic speakers Beautiful speakers The choice is is vast so I do appreciate you You've made a choice to come and listen to me and talk this afternoon Thank you, I appreciate it I hope you'll get something out of it I'm going to talk about how we at Fyserv and Finkit합绿 migrated from one set of Language and framework, another one. I apologise to our american friends for the spelling of tyres. I also apologise to our continental european friends for the mouth prior reference, we are British and we just sit somewhere in the middle of everything. Who knows Fisiv? Anybody familiar with Fisiv? I was. Just in case no one came, I bought an entire posse of five servings with me, so I'd have somebody to talk to. Five Serve are a pretty large financial services organisation, operating largely out of the US, although we do have significant presence worldwide. Yn ym 24,000 oesolwydd ac ym 12,000 oesolwydd. Yn ymwneud o fewn i'r cyflwyno, yna fydd yn fyddi gweithio. Mae'n ffair yw'n ddod o'r cwmpernyddau i gydigio'r cyflwyno, yng nghylch yn fyddi'r cyflwyno sy'n gwybod yw'n gwybod yw'r cyflwyno. Ac nid oed, mae'n gwirionedd o'r bwysig yn ymweld y tynnolaeth yn gweithio'r gweithio. Ac rwy'n meddwl Ady yn ymddangos i'r gweithio'r brif. Yna gweithio'r bwysig yn ymddangos. Mae hynny o'n fwy ffordd mewn hoff, right? Rwy'n mynd i ddysgu'r gweithio'r gweithio, ond rwy'n gwneud ar gweithio'r gweithio'r gweithio'r gweithio. Rwy'n gwneud yn ogylched i'r gweithio'r gweithio'r gweithio'r gweithio. That is quite a sobering thought, as a person who works for a financial services organisation. So, what we're looking to do is to help our customers get what they need, when they need it. And so, as an enterprise development team, and as somebody who provides enterprise development teams, we have to be able to respond to that change. But also we have to be able to do it in a way that is safe and secure, and that scale. And the security piece, the compliance piece, financial services, regulation, as you can imagine, we are constrained by a number of quite difficult regulations. This all comes into play right here. And I guess this is where Finkit comes in. So, hi, I'm Anushka Street. I lead the engineering function for Finkit. These are some of our number. We are all here today and tomorrow, and more than happy to talk to you about anything you want to talk about, within reason, keep it safe. And basically, Finkit is a platform that's built upon Cloud Foundry application runtime, managed by Bosch, which we love, in case you didn't get that from this morning. Which is designed entirely around a developer experience, a frictionless development experience, obviously underpinned by all the goodness of Cloud Foundry. But we've then enhanced that and added a developer environment, a build tool chain and pipeline, and some kind of compliance and regulatory wrapping around that as well, which I'll kind of touch on a little bit later. So, there's a bit of it. There's a little bit of history here. And so, as well as our, we provide this platform that allows our associates and our developers to be able to build really quickly. But that platform in and of itself also needs to be kept current and up to date and respond to change. Customers want different things, different features need to exist on the platform, and we need to be able to deliver those in and of itself in a safe way. And so, over a period of time, as we've been running the Finkit project, we made some decisions at the outset of that, which we changed. And this is one of them. And this is how the fact that, and I'm going to talk to you about what we changed and why we changed it, and importantly how we changed that in a way that didn't impact our consumers in a way that was in zero downtime, and it was all underpinned by the Cloud Foundry ecosystem that we run up on. I want to set some house rules, okay? This is not the start of a flame war between two languages and two frameworks. I'm going to tell you what they were. So we moved from Scala and Acre to Java and Spring Boot. And I'm very comfortable with that decision. It was the right decision for us. I completely and utterly appreciate there are going to be people out there who just love Scala and Acre and think it's the best thing ever. And why on earth would you want to move from Scala to Java and Spring Boot? Spring Boot is really bloaty. It does things. I don't want it to do it. Forces, yeah, I know. We haven't quite like it. And so I get it. It's Horses for Courses. I use that quite a lot. And it works for us. It might not work for you. But this is not about language A, language B, or X and Y in this case. It's about how we made that change and how Cloud Foundry made that change. I'm more than happy to have a conversation with you about why. And we will go into some of that. But we'll be in the booth crawl later on. My orange associates over there are also available to talk about this. More than happy to do that over a beer. It's also not a final and best practice architecture for building a cloud-native system. It's fair to say that software engineering is an act of relentless compromise. And so at any given point in time, your system is in some sort of suboptimal wrongness. So what you have to do is kind of build a platform that will allow you to change it. And that's what we're all about. So at Finkit, we're all about having a frictionless, really pleasurable developer experience, which is actually one of the reasons why we made this change. But also we were about being able to operate that sustainably and reliably on day two and beyond. And so again, there might be things that kind of come up. And you see, I am going to show you some boxes and lines. You may not agree with how we've organised those boxes and lines. That's cool. I'm happy to talk about it over a beer. So what are part of this talk? I am going to tell you a bit about Finkit and what it does. It's useful context. I'm also going to tell you why we made the change. And I'm going to tell you how we made that change with zero downtime and what we learned, which was quite a lot. So just checking time. You all know that, right? That's quite familiar. I would hope. And so this is basically lifted from, I think, a Chip Childers slideshow. Cheers, Chip. And the box in the middle with the light bulb is kind of, this is our service. This is our idea. This is what we want to build on Cloud Foundry. And it's not complete, right? So these are the kind of core elements of the Cloud Foundry platform that we call upon every day as developers and probably don't even know it. And that's kind of the point. That's kind of why it's so great to use Cloud Foundry as a developer. I CF push and I don't have to worry about my routing. My routing is all taken care of for me. I don't have to worry about my application lifecycle and how my app is being staged and managed. And I don't have to worry about how it's running. I don't need to worry about the DAEgo cells and how many instances. And I don't need to worry about if my app is up or down because Cloud Foundry is just going to sort all that stuff out for me. It's just, it takes, I think Dan Jones gave a really good talk actually a couple of years ago about reducing the boxes about things you need to think about when you're a developer. And I think Cloud Foundry does a fantastic job of reducing the cognitive load on your developers to kind of, you know, I only have to think about pushing that app. And what Think It does is layer on top of that, if I push the right button, some other kind of enhancements and extensions to the platform which is specifically built around supporting services for financial services, okay? So we have a protection layer which kind of manages tokenisation of sensitive data. And so in the EU right now we all care quite a lot about GDPR. We're quite present. But there's also PCI and other kind of regulatory compliance things that we care about which the protection layer helps us do. We also have and we provide out of the box some help around identity and we're not talking about identity in the kind of UAA terms of identity but actually kind of consumer identity onto the platform. We have a kind of federated identity model. We also provide support around kind of multi-tenancy. So it's a fully multi-tenanted platform so we have multiple customers on the same platform so we have services around that. Again this is simplified and we have a kind of agreement service and below that then kind of abstracted interfaces into some compliant backing services. So an example there would be kind of persistence and data store. And then with that, so none of our developers will directly CF push. They get push. And so they'll get push into a pipeline which then goes through all the various kind of build and test and then finally deploys onto this platform. Now there's also a vagrant based developer environment that we have that our developers use. Again just to kind of get rid of snowflakes and to get rid of any kind of inconsistencies around developer development kind of experience and so that if someone says, oh my JVM is not, I've got the wrong version of the JVM, it's like well if you've got the wrong version everybody's got the wrong version. And if we need to make that change we can make that change once and push it out to every single developer really, really quickly. It's all about consistency and reliability of the same experience for every developer. The services that I've highlighted there in green we're written into SCALA and the ACA framework. The remaining services, and again I'm not going to go into the history of why, I don't think it's particularly relevant again but I am happy to talk about that. And then we have other services that were built on the platform using Java and Spring Boot. It kind of worked out that a third party team that we had based out in Romania were writing the SCALA ACA services and the Java Spring Boot services will be written from the UK. What happened over a period of time is the relationship with that third party kind of peated out as they kind of do, we had attrition and these services slowly started to come back over to the UK left with my Java Spring Boot guys to maintain. There were a number of challenges with that. First of all, as you can imagine, there's a pretty big skills gap between, yes, SCALA and Java, they both run on the JVMEA. That's about where they are. I can write SCALA and I can just miss off the semicolons and it's pretty much fine. The problem is it's more than that. It was the framework as well. It was the ACA framework which was a completely different kind of model and having been used to working with the Java Spring Boot model, that was quite a big step change. We did send people on training but I think you could all agree that if I send you on a five day training course that's not going to make you overnight the best SCALA ACA developer there is out there. There was some technical conflict. At the time, and I know this isn't necessarily the true now, but at the time it was actually quite difficult to run ACA with Cal Foundry. Again, if we go back to that whole reducing boxes thing, there was some additional cognitive overload for the developers to have to get through. Also, we'd had to write quite a significant amount of middleware to support SCALA the same way that we were able to support Java. Spring Boot gave us a whole ton of stuff that we just used. We just used the bootstrapping and we plugged in Spring Cloud for our IaaS layer and Spring Security and it just all worked. None of that was there with SCALA. That was again, if you're talking about shrinking the boxes, this was hard and this was something else we had to operate and look after. You put those two things together and you end up with human limitations. We had two types of developer. We had the really keen, I've gone on my SCALA training course, I love it, I actually embraced this technology, I want to use this technology and they were, yes, this is cool, I'm getting to learn something new, and they did, they learned it. The market rates for SCALA went through the roof and they left. It was great, not. And then you had the other side of the COVA. I'm expert in Java Spring Boot, I really like writing this and now you're asking me to write in this thing that makes no sense and actually it's fighting against me. The way that we're using it with ACA and CF, it's not helping me, it's actually making it harder. I'm not happy. So I've got unhappy developers and developers who are leaving and when they leave I can't replace them because our primary data centre, I'm just checking time, is in Cardiff in South Wales, I don't know if anyone's familiar with Pedigal Wales, amazing place, come visit. It was hard to recruit these people with the right level of skill. And then there was the last thing, our platform is all built around day 2 support, day 2 operation and making that as easy as possible. And there were a number of tooling decisions that we were unable to make because Scarlett just simply either didn't support them or there were third party products that were available on the market but they were prohibitively expensive. So I'm talking about things like just being able to scan for licences. This is really important in the regulatory world that we live in. We have to be able to scan for licences because static code analysis was really hard. And that's something that you get for free with SonaCube, with Java, it's really easy. And so all of that kind of stuff was pretty hard. And so all of these four things together were kind of adding up into something where the total cost of ownership of these services was just too high. And it was obvious and it was obvious to us obviously as an engineering function but it was obvious to our product team as well. These services, if I kind of work back, these services are the kind of services that are core to our platform, there are others but these are kind of core to our platform and so they kind of change quite a lot. And every time it was like, yeah we need to make a change to the identity service. Okay, we'll just wait while Bob gets his head around the scholar code in that. And we kind of had this problem where it was a vicious circle where developers didn't understand the code, enhanced the service, but they didn't properly understand it and so this had many balls of mud being created all over the place and so it was just a mess, frankly. So we said, do you know what we're going to do? We're going to bin it and we're going to write them in Java and Spring Boot. But we needed to be able to convince senior management that that was the right thing to do. That was quite hard. Senior management see something that is working, that functionally does what it's supposed to do. So why on earth would I throw that in the bin and write it again for no actual functional benefit? You're just going to give me exactly what I add and for what? And so what we were able to show is that look, we write Java Spring Boot services and they take us this amount of time and whenever we come along to write a change for the identity service or the agreement service, it's taken us this amount of time and it's fairly crude but we were able to show it's longer. We were also able to show that through our product owner who was engaged with us through this process who was actually really supportive as well saying, actually guys, I'm seeing this and so I had allies across the business and this is the right thing to do and we got it, we got it through and they agreed and so what did we do? So who's familiar with Martin Fowler, Strangler Patton? What I'm going to show you now is actually really straightforward but the reason it was straightforward is because of Cloud Foundry. It's kind of the... Those guys are there going, it wasn't straightforward. I was like, head of engineering, yeah, it was trivial. And so for most of those services, we were able to kind of just use a Strangler Patton and I'll show you how we did that. There was one particular service that that wouldn't work for and I'll tell you about why that is. And so there we go. We're going to use the agreement service as the example and that's running there, it's running quite happily and we've got kind of post-get delete and the first thing we're going to do is we're going to just create a shell and all that shell is going to do is route straight to the old service. This was again relatively trivial because we're contract first, right? So we're an API first company and so it was dead simple. Those were just swagger specs that we just kind of moved over and they just passed through straight to that service. And then what we were able to do is kind of a resource at a time, kind of switch those over and change the routing so that as a resource at a time, as a new resource comes online, we're able to point that back directly through the routing and again this is all managed, really trivial configuration for the config services that Cal Foundry provide and then just chomp our way through it. I appreciate that this is a nice straight forward, relatively kind of straight forward use case. We've got a shared backing service for a start right, which made our life a lot easier. That doesn't preclude you using it for other use cases. You can absolutely use this for other use cases. You just probably have to think a little bit more about replication of data. What's really important here and something else that Cal Foundry provides is metrics and logging and the ability to know what is being called, when it's being called, how it's being called. It was really dead straight forward. We could see no-one's calling the agreement service anymore. We didn't bin it and so we cut that off, we undeployed it, we unmapped the routes and it was gone. Boom, it was that easy. Honestly! So, we strangled those three and there were a couple of others as well but just keeping it simple. Then there was a proxy service that is a hub that sits between all of our services and acts as a bit of an orchestrator across some of our services. Because of the way that that sits in the middle and because of some kind of routing problems, we realised that we weren't just going to be able to particularly around identity, we weren't just going to be able to resource at a time, bleed that over, it was going to be really difficult. So what we did there was just do a complete version upgrade in situ. And so obviously we're making sure that the API is exactly the same. And what we were able to do is again now we've got the blue-green deployment feature again, which is out of the box with Cloud Foundry. We've written our pipeline kind of supports that blue-green deployment. And the fact that we run this on Bosch means that we've got absolute confidence that we don't have any configuration drift between our environments. So we know that our test, sit, staging and prod environments are all the same and are going to behave in the same way. And so we were able to just click this through. Again, it was that easy. Honest. And then it went. So did it deliver what we thought it would? I think it's fair to say that, yeah, it was a really big success. We were able to replace all of our remaining Scala services both through the Strangler pattern and the kind of more standard version upgrade process. We did it all in about six weeks and with zero downtime. Nobody noticed. And what was quite, apart from the developers who were doing it obviously, really interesting was at the same time that we were doing this work we were also moving cloud providers. So we moved from a managed service cloud foundry provider to an open source and we also moved from one I as provider to another I as provider. And what again I just want to emphasise because cloud foundry was the common delta between all of this. It means that from a developer point of view if I'm one of the associates building on the platform I don't see any of that because I'm git pushing to my pipeline and that's just CF pushing to a cloud foundry somewhere. The fact that it's on some different I as or it's a different provider doesn't matter and that's kind of where some of the greatness of cloud foundry come in. So yes we were actually able to recruit people now because Java and Spring Boot is far more prevalent in the market space. The retention went up. We had happier more satisfied developers who were building in a language that they understood and felt comfortable with and again that day two stuff all that kind of compliance out of the box again with the ability to automatically scan and know what our licenses are doing and pull that into our compliance framework and the associated reduction in lead times everybody's happy. We did learn some pretty big lessons along the way though. I know I kind of trivialised it a little bit and said it was look it's easy because I can just click the clicker it's really simple. But there were a number of really big lessons. So and this was the behavior is the asset in fact it's one of our principles. Behavior is the asset not the lines of code that you write. In fact lines of code are just a cost that you have to maintain. And so that was the message that we gave to our senior exec when we wanted to do this. The way that we can help ourselves with that is to write really good tests so that if we decide that we want to change something later then it's really easy to prove that you've done it the right way. Some areas of this we had done a pretty good job. I think it's fair to say we could have done better in other areas and we made it slightly more difficult for ourselves than it could have been and I think we learned quite a lot from that exercise about how important it is to have good tests. Be able to measure stuff and again Cloud Foundry really helps you with this right. So Cloud Foundry is the logurgator and it will be able to log some metrics to use them. They provide you with some really interesting and useful data. Want to support things like use cases when you do go to your boss and say can I do this crazy thing but also just to have good insight into what's going on on your platform. The whole kind of just do something thing we kind of already started doing some of this stuff as kind of a little bit of a type works and so we had some data and additional metrics to be able to give to our product owner and to our execs when we were doing this kind of just do it get on with it you know don't hang around. Training helps but it is definitely not a silver bullet you know I think how many software developers in the room? Awesome. Is it something that you've practised really hard and learned over many years to become really good at? Yeah I think it is. It is for me. Well I became okay at it. And and so I think you know by thinking we can just send people on a five day training course and then they're going to come back and they're going to be these great enterprise developers immediately is a nonsense it takes time to become really skilled in your craft so just watch for that. Again the kind of whole watch what you're doing is kind of linked to the metrics piece and the contract first services. Again if we hadn't done that and if we didn't have well defined swagger specs I don't know how we'd have done this equally I'm not sure how we'd have done this if we weren't running this on a platform like Cloud Foundry we'd have had to write a whole ton of routing craziness to be able to make that work and the last thing is the feedback from the teams that this was really dull it's kind of repetitive and quite mundane it's stuff we've already done we're doing it again but a lot of them understood why they were doing it but maybe just mix the teams up a bit and make it a bit more interesting rather than just say you're doing this for the next six weeks it's fine and I think that was it unless anybody's got any questions I've got about a minute hi hi I have a question about the slide where you show your new spring boot application and the old service where you said that you started first with the post and the deleted service we didn't no we'd start with get I don't know why it's there we start with the idempodent one idempodent ones first because Cloud Foundry first doesn't provide each of them okay but then I don't have a question because my question would have been how did you solve that because Cloud Foundry doesn't provide verb based routing as far as I know so you can just root you can specify the route but you cannot say get goes to this service post goes to that service and yeah we did okay okay okay my bad I wish you solved it anything else at the back driven design that you just said sorry I didn't hear the first bit okay how did you define I know it's a bit technical the contract driven way of of those services perhaps that's something we should have a chat about in the bar okay yeah it's interesting that's quite detailed okay I think that's my time thank you very much I'm happy to take questions afterwards