 Good morning. It's 1115 people are still coming in, but we'll just start anyway. Good morning I would like to introduce the latecomers personally so Francesco great to be a great see you here welcome So I'm gonna talk a bit about our migration for a rubber amongst migration from a monolith to a microservices platform And the way and the way we did that before I go into that. I do need to tell you a bit about rubber bank I guess I See the first few rows in the Netherlands. You see the orange shirts. They're all Dutch So they they know rubber bank, but actually when you're come outside of the Netherlands Robbock isn't that well known So to give you a bit of insight on that Robbock is actually One of the one of the biggest banks in the world for food and Agri But we have our roots in the Netherlands So we are active in 39 countries with 1.2 million customers worldwide except for the Netherlands and in the Netherlands alone We have 7 million people. Well, we're here in Europe So you all know what the Netherlands are of two weeks ago I was in the US where I had to present this and I and I had to add this to show you exactly People they're Americans the Netherlands is over there and we have like 17 million people in there in the Netherlands We're one of the top three banks Yeah, a full-service bank. So we do so we do everything a Bank can do So with that said Robbock is over a hundred years old I think yesterday Abby told on the stage that she left her bank and went to an online bank because everything was an online thing Well, of course as a bank, that's also what we want to do Even though we're a hundred years old We are working on lots of digital stuff to make it more and more digital and here are some examples of what we did I don't think it's good. Yeah, it went automatic. So in 1996 We were actually the first Dutch bank to have an internet banking website followed by a mobile banking website on WAP You know that with his old old the old phones I'm not gonna go through all of this But you see here that we've been always been active in the digital space and just last month We opened up our developer portal for developers to build their own apps on top of our APIs If you go there today or to developer dot rabok dot and L You won't see a lot of APIs yet, but the beginning is there, right? So we're starting to do that and also last month or the month before we were launching partner of Google with their As Dutch version of the assistant in the Netherlands. So you see that we are as any other bank will do as any old bank We're trying to be fully digital and Doing that more and more The focus of today is the Dutch part of Rabenbank. That's where I work So I'm responsible for the architecture of our online sites. That's the public website It's also the internet banking website and also our apps and they all run on the same platform server side Which I'm gonna explain a bit and then tell you how and why we migrated away Our platform was built around ten years ago And it was like the traditional Application stack you could see it basically any bank at least in the Netherlands. It's Java based web sphere based and We built our own Stuff on top of that what we did do differently than already then was that we went for things called portlets Anybody still remember portlets? I can also guess that you don't even want to point to hold up your hand if you do What we did we build our own Framework so we didn't buy anything we build it ourselves It was our portal framework and and what it did is all incoming requests go through that framework and they pass on the Request to any apps on the same server so this allowed us for example to have multiple portlets multiple apps on the same page for the User all-server side rendered so this is all the the traditional server side rendering of stuff And actually this worked pretty well We we set it up in a way that we could scale it out easily Almost linearly so if the if the load goes up we just add a couple of boxes and it will it will work fine I have some words on that as well We we have groups of deployment units where we group our apps together on a single box And when I say apps I really mean small things so they used to be portlets now with our more tradition or more modern development we do single-page apps where we have from rich front end and we just call services that expose Jason data basically these apps are things like making a payment or Getting a loan or Getting your list of transactions. Those are all separate apps already So we already did this 10 years ago You could even say that we were already doing microservices then the only real big difference is that they all ran on the same box So and of course with microservices you stick your Microsoft's each Microsoft's in its own process Which is something we couldn't do then the technology wasn't wasn't available so in our own framework We build a lot of additional stuff mostly about non-functional requirements So we do a lot of security checks in there We do a lot of monitoring a throttling in there that we that we can leverage the system as best as possible And that's that's worked out pretty well actually, so we've been doing this for 10 years Today there are still over 400 applications on that platform Running most of your if you go to our public website You hit this you hit this system if you go to our app if you go to our internet banking websites You all hit these systems So over 400 apps it's does easily does over 2,000 transactions per second We have a 2 million log-ons every day and in those 10 years hardly any disturbances So it's actually been a pretty good platform for us still we decided a while back That it was time to move on and there were three reasons for doing that The first reason is that our technology was getting old right? It was web sphere Java AE although we don't do portlets anymore and its Web services more adjacent services It's still the web sphere box that we run on if you go to conferences these days you hear about The spring boot apps or the node apps or anything other than basically Traditional app server stuff and we simply couldn't do that our our stack doesn't support that Another reason to move on is that actually with 400 apps on our platform. It was getting bit full We we reached the limits of our scalability. We couldn't add many more apps We cannot add boxes, but then our load balancing is really tricky So it started to yeah, it started to creak a bit It started to get get difficult to manage so it was time to to look forward and the third reason also very important Actually, maybe the even the most important is that we have been doing agile development within the rubberbank for I think over 10 years now And a couple of years ago. We've been switching that to DevOps So where you move where the operations part of the teams really becomes part of the agile team And that means basically if you say to your teams that when you build it you also run it You cannot do that with a consolidated environment You cannot say to a team you own that stuff and by the way somebody else can also break it that simply doesn't work So you need to go to a system where you can really break it out and give each team its own responsibility So you need to go the full microservices route basically so that's what we did we started on the journey and It's being depicted here and a couple of things. I'd like to say about that So one of the things you see here is that we started this late? 2015 that's over two and a half years ago or even three. What is it that long time ago? So it's that that's a frustrating thing like so we are now we now have something in place We're very happy that we're there, but it took us a long time last year I was also here and I was as a Spectator as an attendee like like many of you and then we said either I'm back here again this year and talk about How we did this or we're not coming back at all. So the reason that I'm here is is okay, right? So that we succeeded some other things to note is late 2015 when we do that when we did our research Kubernetes didn't exist yet. So you might wonder why is cuban it is not on the slides Well back then it wasn't there. So there was Docker You could do maysos maraton and we actually build our own platform using that open source technologies But no cuban it is yet After we build our own platform. We fairly soon decided that this was not the thing for us to do We saw that running a platform actually this is still running today in another department The it's it's nice if you have a couple of developers and if a couple of teams and a couple of apps Then it's nice, but it to scale it out to the rubberbunk to have over a hundred or maybe 300 teams working on it That's that's something we would not be able to do with this except if we put a lot of people on it So we would be having to build a platform with maybe 60 70 people and that's simply not worth it, right? We're a bank. We're not about building platforms We're not about containers if you want to do that you go to Rotterdam where they have shipping We're a bank. So we want to we want to offer banking services to our customers So in there in somewhere beginning of 2016 we came to the conclusion Actually for us it's much better to go out into the market and see what's there and just get a platform as a service in Well, we pretty soon we we ran into cloud foundry We really like that also with the fact that there are multiple implementations of there just today Yesterday we heard there are eight certified Vendors now so that that's great that that gives you choice and it gives you exit strategies and so that that's nice And then we did a POC It's also nice to mention we did the POC with two two parties So we selected pivotal as one of the parties because they're basically as we see it The biggest driver behind a lot of cloud foundry stuff. Also, they own the whole spring stack Which we've been doing for a long time already spring related work and we also did with IBM with blue mix For the simple reason that IBM is our strategic partner. So we cannot not do it with them, right? So it's Easy one so we did it we did a POC with both of them And what we did differently is that what you normally see is that what you normally see is that? Pivotal or IBM or some other vendor they come in they bring their consultants They do their coding and they show you how great their platform is but we said well, it's it's going to be our platform It's going to be a developer platform. So developer experience is a very important thing So we're going to give you a couple of days to teach our developers how to run this platform How to how to build your apps and then we're going to do the POC ourselves So you can give us architectural advice if you see one of our big advice We're sitting in the back of the room I never so that helped a lot But actually in the end our own teams did the building and did the did the tryouts and did the selection Well, then you see a big gap after we selected it. It took us over a year To actually select it and implement it and basically buy it and all that stuff And why that is is on a sub note on this slide We selected pistol cloud foundry as for the bank and where when we started we said we were going to use this as a Replacement of our online platform architecture basically where we are now is that we say this is the platform for the whole of the bank So any any team within the bank even if you're not doing any online stuff if you if you built your apps Stick them on PCF and the reason it took a year is the side note is that we put it on the cloud We also have our own data centers But for this we see as a strategic goal to move more and more into public cloud And that's easier said than done especially if you're a bank and you have the Dutch Government and European guidelines and and all that stuff. So that that took us a long while Why did we pick PCF for one of the reasons you've seen this sort of these slides many times already a car last couple of days Actually, I claim them. I think I made them internally in 2014 or so or 2015 and after that everybody was showing the four abstractions Well, I'm kidding. Of course. They're not mine Basically, this is what you can do and what what I've seen in the past or in the last few years in the market is that we As as as techies we come from the right and we move up to the left and we think that's really cool So we've been doing VMs for a while We've done ansible scripting and puppet and chef and all that stuff and then we load containers And then we plugged cubanitas in and it was all awesome and everybody's happy Actually, when you look at it from an architectural perspective You should look at it the other way around as from an architectural perspective when you go to your teams You want to build your features your services at the highest abstraction level possible So what we actually say is when you want to build something you should first see if you could do it with functions serverless and then probably you find out that nine times out of ten or ninety nine times out of a hundred It's not possible yet. It might be at some point So then you drop one notch and then you should go to apps So where you see that the market is going from the right to the left We try to go from the left to the right And so we did a basically a survey amongst all of our teams along the 300 DevOps teams that are working in the Rabobank And what we what we found that is there is that 84 point nine six two percent of the teams And I hope you understand this is a bogus number that they Operate on that level when when we look at the DevOps teams within Rabobank Their goal is to build apps to build features not to manage Kubernetes clusters or to do other stuff with containers That's what they should be doing Building software is already very very hard thinking of all the non-functional requirements and security requirements Especially when you're online think about your performance requirements and there then there's this thing like that How they call it business requirements. You also have to implement those so it's already very very complicated So make it as easy as possible for the developer. That's that's basically what we found out So that's why we decided to go for apps Of course all the other three are also necessary So we can't do it with PCF alone You also need all the other stuff, but the majority of the teams are more than happy with with just doing PCF Just pushing apps So what we promise our teams today is a very simple model. Well, I probably don't need to explain it Otherwise if I would you shouldn't be here. I guess it's pushing apps and it's scaling them and the whole platform takes care of sticking them In containers running them exposing them. You don't you don't see load balance anymore You don't see VMs. You don't see all the hard stuff that the teams used to do It's a very simple API and you push your apps. So that's great. So we selected this We promised this But now what so we have this platform I showed you earlier which is with Linux and the WebSphere boxes and and our own frameworks and lots of apps in there Now watch so we have PCF as the platform to go to we still need to think about how do we do that? So what we did is we went into a nice technical track where we looked at first at all the features that our portal framework had and We broke them up in into separate pieces in separate microservices or we said well this feature We don't need anymore. We can just throw it away. For example the throttling and monitoring in there That's something we won't need if the platform provides us for us. So we don't need to rebuild that so what we basically did is went into a nice track, which I try to depict here is Is that we came up with things like the URL security? microservices where you can have all kinds of security add-ons for for making save URLs We have a temporary service where you can store your user preferences it ideally apps do that themselves Of course and and have their own database, but we need to offer a migration path away from the old platform So we need to mimic a lot of the APIs that are there except where well before they all ran into the same JVM They ran in the same JVM. We now have to support them as separate microservices. So we started breaking out these services We've been putting a lot of effort into building these dark blue blocks to allow other teams to move their apps on on top of On top of the online platform. So this is the new version of it and it all runs on PCF What we see is that the technology is great What we see is that the developers in and rubber bank they go to conferences and they learn stuff that they That they hear about spring boot or other libraries or maybe node or some other stuff They come into the office and they can actually apply that Before it was web sphere and then you learned about something like spring boot, but you it's nice to learn But you can't really use it now now. We're actually on par again with what's happening in the market. So that's great Developers really like that they learned what they learned today. They can apply today. That's really great It's also very complex We knew this upfront building a distributed network of distributed system is one of the most complex things you can do So you need to be really aware of all the stuff all the timeouts all the circuit breakers all the fallbacks and all All those kinds of scenarios you really need to think them through So I cannot I cannot say enough about this book. You probably know it probably heard about it it's the release it book from Michael Nygaard and It's just I have no no affiliation with the guy whatsoever It's gonna say if you want if you're doing microservices Go read this book is written from an ops perspective and all the stuff that can go wrong if you if you build microservices and how to how to how to solve that The same so so this is this is good. This is nice. Our teams are happy And they've been through a big learning curve to get all get get here, but it's also just to have the story Everybody loves technology part, but actually the the most Difficult thing within the rubber bank is the people As many enterprise organizations we are organized in in structure like this So this suggests a hierarchy. We have domains. We have departments and we have teams in there And what you can expect is in a such a big organization. It come ways law applies, right? So you see that the way of working is different the technology stacks are different the the maturity of the teams is different So for example, we've been saying that we've been doing DevOps for five years There are teams who really embrace that and do that there are also teams who actually do it in name only and We don't have ops in the team at all or work on a consolidated platform still and stuff Everybody is going in their own Going through their own speed in getting really to towards DevOps with all the problems they have in their departments and their teams So that's that's difficult Myself, I'm somewhere at the right or on the left for you Within the online department and what of course you see there is that the teams within online Well, we said first we're going to replace our online platform So all the teams are going to get training all the teams are going through that all the teams are actively working on Microservice these days and doing spring boot. Maybe not all of the teams with a lot of them So there's that that's easy and also in the in the departments relatively close to me So within the same domain, it's also easy to find those teams If not for the same simple reason that they are physically really close by one floor up one floor down If you go further away, then also physically you go further away So it's much harder to get get teams on board it So what's happening is that we see that some teams within the bank within across the various domains They do pick it up. They they learn about this They want to do this and they are very active and then around them some other teams also pick it up But we don't see the explosion yet that the whole of the bank is suddenly using using PCF So that's that's the that's the biggest challenge. We actually have it's not the technology It's how to get the whole organization on on the platform where it applies, of course It won't make sense everywhere, but in a lot of places it does. So what do we do? We have a lot of Training we provide a lot of documentation. So the teams that started out first They really put a lot of effort in writing down everything they did all the decisions they made all the reasons they made the decisions so we were very opinionated on that we were basically saying do this don't do that and And and why and that that just helps already So we have an internal wiki where everything that we do all the things that we do are Described that we provide workshops for other teams Actually, the one of the teams has an every Thursday an open day where teams from all over the bank Could just come in and ask questions on how do you do PCF? How do you do clouds? What are the issues there? We provide demos we we give events So we we have external internal speakers in where we try to tell all the the developer community within Rabelbank All the things that we do and we have pivotal do dojos with us So for the teams that are really need to learn the real agile and the whole labs way of working We have pivotal to help us do dojos But apparently this is still not enough so this is roughly where we are today and we are and we do all those things and Still the adoption rate within the rest of the bank is is is hard, right? It's also actually what I find the most enjoying so it took two years to put PCF in place But at the same time when you see all the teams then actually starting to use it. That's really gratifying. That's really it's really nice to see So where we are today I Recently learned that I was lying on this slide, but I just keep on lying anyway, so it's okay we have Over a hundred teams already on the platform and we went live in January 1st And so that was when the real production ready foundations were there in Azure on public cloud Then we started building our building our apps in there We have over about a hundred different applications in production today And when you combine it with all the instances and DevTest and prod then we go towards 900 plus And that's a lie. It's a bit it's a bit lower actually so that's that's where the lie is So it's actually growing nice nicely. We see this linear growth actually not this month That's why I left out September if I would have added in there. It would be mostly flat I blame that on the vacation all the days. I don't know. So we really need to we need to step it up again And of course I should say that we're hiring right that's obvious A lot of Dutch people in here So if you want to really really do nice stuff, even if it even though it's a bank, right? It's boring financial stuff We are looking for developers and the ops teams members Thing to add there is that our ops team, which is also a thing that that really makes me Makes us really proud is that we run our The whole of the platform so we have four foundations two in production and two for Dev DevTest actually we have five if a crash and burn environment that it's all being managed by three people and Those three people do other stuff besides so that that's kind of awesome that we can simply grow the number of teams And we can grow the number of instances and it doesn't affect the size of the team that needs to manage the platform for the teams So that's that's really that's really good That's actually it already so I'm going fast Questions then maybe that's better. Yes a question Yeah, so the question is how do we move software from Dev to production now with this or Well, of course, most of the teams already so we were doing agile before some so we have a lot of Jenkins pipelines already in place All of the things we already put into production on our old website environment was fully automated all the old ways with build pipelines So basically actually moving that over to pipelines that did see a push instead of all kinds of complex web sphere deployments Is that that was basically it so we didn't affect we didn't change the way teams need to work They still have their own choice of build pipelines to use their own software their own scripting. We do provide a generalized Build pipeline for them, which does a lot of other stuff as well for them But they it's their choice to adopt it or not They can also write it their cell themselves, but basically it's it's not a big step for us because we were already doing it Does that help? Kind of so I take it. They've just they're using save push from their pipeline straight into production Yeah, okay. Yeah, but of course we have for example We have SM 9 in there for our change management and we have in our on our build pipelines We have built in that we first create a ticket and that somebody else first needs to prove it Otherwise the whole build pipeline won't follow along stuff like that So we really try to automate the change process as it exists today Fully automated as much as possible. Thank you. Sure. Yeah Now that you've built so much capability with Cloud Foundry yourselves. What's your thoughts around? PCF versus open source That's a good question We should down the camera now now yesterday We had a we I was it as a nice presentation about moving towards the open source from the commercial And I think it was a nice inspirational session But for us we are very still at the start of our journey using PCF We were we will never be able to just pick it up pick all the open source components build it ourselves and start working It it's way too complex CF is a complex environment So for now it's really good for us that we have a commercial offering If we can just install and get all the build packs and then the upgrades from and maybe in a few years I don't know, but I think for now we're on the right track. Yeah, so I think I would I would it's of course That was in the session yesterday. It's about the appetite the risk appetite of the company I think our risk appetite is not such that we would start with the open source stack I think it's it wouldn't work for us But well, that's that's my feeling Other questions I have five minutes left so we can do all kinds of stuff sing songs Not me, but I did promise it didn't I I won't I won't so no more questions then. Yeah, sure. There's a mic coming. So you have all the time in the world. So Yes Hello, I Was I was gonna ask if you have some examples of some of the apps that are running on the platform today You mentioned that your your group which started it was kind of in the online side. Yeah, just any examples to share there Yeah, I'm not sure I'm actually not sure whether I can not know that I'm not allowed to share them Just that I simply don't know them so in my role. We have all the teams working on stuff They're going through their own faces, and I actually don't know what they're working on on the daily basis Sounds scary, right? But yeah, I just fake as if I do all the time No, but parts of our app are already already online I think it's a part of the payment request feature that we have it's like in the Netherlands You have tiki tiki dot guys know that way instead of making a payment to somebody else you can be sent a Link to make that payment. So instead of me paying you you would send me a link where I can easily pay you It's like a pre-filled Payment which were highly successful in the Netherlands And we have all we've also been offering our own version of that of that and that already runs on on PCF For example, so just parts and fragments of our mobile app and our website Slowly start moving over and I really don't know where we are exactly what I do know Sorry is I mentioned that we have over 400 applications on our old platform and the number of applications that has actually migrated is zero So we have over a hundred applications running But nothing has been really migrated yet because teams really pick it up to do the news features Of course, that's what the business wants right all the new features and then we think that's a that's okay We we also put an end-of-life date on the old platform And that way we tried to first do the fancy stuff the new features in the new way And then when you work on that and you also need to maintain that stuff on that old boring dusty platform You you take you take the effort and also move it over that that's a bit of a strategy. We hope to We hope will work, but we're not sure yet. Let's see Yes, what one question Was it difficult to fulfill the PCI standards in this environment? Yes, so I told you about the year That's all about that. So that's all about and then that's not especially I think PCF if you would have done PCF or another cloud found the instance in our own on-premise data centers It would have it wouldn't have been that hard but the fact that we run it on public cloud makes it really really difficult and Don't don't ask me about all the details. I've been involved in many especially security risk kind of discussions That I was but I don't know all the all the technical details on that But it took us a year to really get it in place. Yeah Yes, sure, maybe One question also Have you evaluated the effort to to migrate the 400 application from your website? Sorry, just in platform. Maybe you can Mike. Oh, yeah, sorry Yeah, have you ever evaluated the effort to migrate the 400 application you you have on the website platform to the CF environment What's the question is that do I think that's feasible evaluate the efforts to my effort? Yeah Yeah, no, we didn't no, and I don't think we need to so Actually the same question yesterday Somebody asked me that too. So of course we have a rough estimation and we have a rough feeling And we know that basically all of our Java apps on the old online platform. They are spring-based So depending on the complexity, it's either very simple to put that in a spring boot app or not So for example, if you use MQ, it's gonna be a bit more difficult than if you do HTTP based service goals But we didn't do that a really thorough Estimation basically what we said we need to move anyway our platform is growing old we need to replace it and we put that end of life date on our old platform with to push everybody into the new platform But if needed we can move the of course we can move the date We can simply say we'll keep it in place for another year But that's that will bring a lot of cost with it So we're basically looking at that model and not so much and on the individual effort needed Again, we think that if teams start building their features from scratch using spring boot and putting them on on the platform Then at some point picking up your old features Taking the effort to move it over to new platform is better than always switching off that oh, no I don't do the CF push anymore. I don't do spring boot anymore Now I do all that web sphere stuff that I really don't remember how it all works So actually I think that the the mental effort Is going to help us? Force the force the migration Yeah Okay, I think that's time. I think we're over time just one one more than short one Sorry, you said you're managing the whole all of your cloud foundries with a team of three people I was wondering what what's the task of these three people? What was the well automate a lot of it one of the people is actually sitting in the back very relaxed So that's also a good sign right just three people and they still have time to do nothing I'm kidding. I'm kidding So that it's mostly about it's a lot about Automating lots, so they have a lot of concourse pipelines where they reply patches. It's about Offering means to create new orgs and spaces quickly and stuff like that But it doesn't include the 24-7 operation of the platform. Yeah, but of course Since the platform is that is that highly stable. It's not a lot of work Okay, well, thank you