Microservices and Microfrontends: Scaling, Learning, Growing | Lofi Dewanto & Patricia Erdelen (EN)

This talk discusses the transition from a monolithic software architecture to microservices within an insurance company, highlighting the challenges and strategies involved in this transformation. The speakers outline their use of the Technology Organizational Environment framework to explore the changing landscape of the insurance industry, with increasing competition and the demand for faster product deployment. They detail the technical specifics of their legacy monolith, which consisted of over 900,000 lines of Java code, and the complexities that arose from its tightly coupled structure. The session covers their journey towards adopting modern frameworks and technologies, including Spring Boot for back-end services and Vue.js for front-end development. The speakers emphasize the importance of CI/CD practices, cloud deployment, and the shift to a microservices architecture that promotes agile product development and improves user experience. Finally, they share insights into organizational changes necessary for maintaining service quality and governance in a rapidly evolving tech landscape.

[music] >> First of all, a welcome to all of you to our session. Uh our journey from uh Mike Monolith to Microservices and um microphone ends. Just maybe a short questions to the all of you. Who has already done such a journey? Okay. Some of you already did it. That's great. That's great. So, um >> Welcome from me as well. I'm Patricia. Uh Lufi and me, we

are working for the VK. It's an insurance company in Cologne, so quite close to the Synedome, which we really appreciate. Yeah, so um Lufi, would you like to start with describing our environments? >> Yes, um because the journey is a quite long, right? So, we need to have a framework for this part. So, I can or we can go with you together. And we use the so-called

the technology organizational and environment framework, TOE. And therefore, it's also the agenda is just similar to this part. So, we would take a look with you together the environment of insurance today. Right? So, the next part would be the technology part. And then the at the end is the organizational part. If you have a questions, please um ask with this part. So, at the end, maybe we

can discuss with you together and take a We will not the way to go through this migration to to move to new city, right? But uh we just want to tell you how actually it is because this is already 5 years now. So, it's time just to um take a week back and and go back and take a look actually. All right. So, let's uh start with

the environment. Right, the insurance environment in Germany is getting hard as we all know. Now, we have uh tougher competitions, new uh players. We have um cost and pricing which always higher today with the cost of the oil and so on. That's for sure uh a lot more higher. And also, [snorts] the integration of property uh insurance in e-commerce solution. Amazon in integrate uh the the the

um insurance part into their product directly. So, this is quite hard. And in Germany, I think we lost the generation, the golf generation. I think uh all of you in Germany know that that um today we don't want to uh go by car to somewhere, but we want to use bike. Yeah, which is good for our environment. But, that's also a change in insurance company because insurance

almost all of them are basically based on the uh motor insurance. Right? This is actually the power of All right. And Patrizia, what is then in the product development? What do you think about that? >> Yeah. Uh resulting from those changes in the market, um our business departments want us as architects to uh be able to provide new instant uh insurance products and to have uh faster

lead times from a concept to a deployment. And also, uh maybe they want to be able to change pricing conditions maybe in real time. So, a lot of new requirements that we didn't need to fulfill in the past. And in addition, uh we have some requirements coming from um uh regulation part like Dora or from security part, governance compliance. Um although we had uh to fulfill some

security aspects in the past, it wasn't that much enforced as we have to uh do it now. So, a lot of stuff for us. And in addition, we as the user of software have different expectations than 10 years before regarding UX and UI. So, uh this is our environment from outside. Um Lufi, would you like to tell us a bit about the monolith, the past, and its

environment? >> All right. That's nice because you were you have been there before, right? The monolith. I'm there >> [laughter] >> for the monolith part. So, this is my part. Okay. Um the focus is applications. We are from sales area, so um we have three type of sales application. The first part is actually the the consultant advisory part. Uh if you want to sell uh insurance product,

you have to make a consultant for them, right? So, you have to take a make a documentation and so on and so on. The second part, of course, the customer um relationship management system. And the third part where we are actually now talking about in this session is the so-called um uh pricing um quotation and the application process of um doing the insurance product uh selling. This

is the part where we actually uh today talking about. There are other other part, but this is um our point of view for today. So, the key data from this uh application is actually a monolith, a huge monolith with um we have 20 people working on this monolith. Uh, we have a three-week test phases with release every two months, Java 8, um, approximately 900,000 line of code.

And we have 10 deployment units, 10 applications, and the services, which is, we have, also four stages. So, you have 40 um, total in total. Four large database per stage and totally about 9 terabyte of data only for the sales application. That is really only for the sales application. All right. So, what is how is the technical structure of this monolith application? You need to analyze that

one, right? But, just to give an impression what the technical structure needs to deliver, we have here a scribble of the parts that we have to deliver. For example, we have here our insurance products that we have to deliver, relying heavily on core components, like creating documents that the customers uh can uh provide. And also, we have three sales channels. So, our monolithic structure is about all

our insurance products uh relying heavily on central core components and providing all the products in all the sales channels that we have. So, this is a lot and maybe it isn't a surprise. Each of those products uses all the components. Uh, especially the shared data model, it's uh on the upper part. Shared data model is really very good to create tightly coupled structure. And of course, all

those products are present in the sales channels. So, in in the end, what we had is something like that. A big ball of mud. And uh the observations that we we found are not really a surprise to us. It's a very high complexity. We have a tightly integrated code. Our software developers need to understand all of that stuff, all of the 900,000 lines of code, because if

they touch one thing on one side, they could affect a totally different insurance product. And um yeah, create bugs. And creating bugs is not really good because we had slow release times. Um yeah, all of that stuff that you can imagine because you're familiar with software development. Um you can hide it for a long time. You can keep it under the hood. But there is a point,

a kind of escalation point where the risks get obvious. we already talked about the the business challenges that we have. we did not only found out that we have operational risk regarding stability, but we felt that we are not able to respond to security vulnerabilities. And that we couldn't ask answer the requests for new insurance products. That our competitors are faster than we are. And even if

we could implement new products quickly in the monolith, um we were not really sure if it would be stable enough accept more traffic. Yeah, that's it it it was not really a good time there. How how did we get there, Lovi? >> All right, that's you know, all of you already see this problem everywhere, right? The typical problem is actually a big growth. That's just too fast,

right? So, they put everything inside it. Come on, we need that one, we need that part. We just integrate without thinking about the whole architecture. Right? This is a completely the typical problem. And now, um, let's take a look at the technological part. Yeah, what is actually already there, yeah, where we want to go, and and etc. So, this is uh the first step what we did,

we analyzed the whole system, right? Um, just make a a short introduction here with the whole component and the technology we have. Uh, and just make an example, RPM is actually our deployment um mechanism at the time. All right. So, VMware on the base. Uh, we have old versions for everything, um, and no standards, um. Uh, what else here? Long time long long boot times also, and

etc. etc. So, we have to take a look everything, and then we move to the next step. we take a look, we discuss, but at the end, um, we think, "Okay, this is really uh not possible to make a small or short time changes." Uh, actually, we we need completely, um, um, take away everything, and rebuild it from scratch. Right? Is it like that? >> Is it

really we need to start from new? >> I think so. Yeah, and and therefore, we also then think we have a decision, we have to start from the scratch, right? >> It's uh something like that. Uh, there are facts in the monoliths that you can't really change. It's like trying to change the height of the ceiling in an apartment, or to implement different windows in an apartment.

It's not really possible. And of course, we didn't want just small improvements. Uh we want that. We want to have a big party. We want to have a modern framework. And uh nothing like just a new tapestry. but that's um really tough uh transformation that we would >> Yeah, and it's uh will be a lot of work. >> And um you see here uh we have to

touch everything, right? So, we have to touch the infrastructure uh from data center, our own data center on premise to cloud. We have to um make another deployment structure uh with the container at the end. And we have to take a look at the application uh architecture from monolith to microservice, right? And micro front ends. From the development process, we have to also change this a bit

uh to HR dev ops. That's also a huge change. And uh from a huge large team and we have to make a smaller team uh which is um actually um required to do the whole um business contacts and the the whole product development. That was our vision. And uh um the management uh had to be convinced that uh it is worth enough to give it a Um

when we had a go, uh we need to get uh a bit more specific because uh a relocation of uh that size that needs a kind of plan. Like, if you're trying to move from a small village, maybe as a young student coming from uh your family home trying to move in a big city, um you need to get more specific. Where exactly do you want to

move? And uh what are the the tools or surroundings that you expect um other topics like what would you do on your own, what you be uh customer of a supplying service, and uh what do you need to learn because you're not able to do it on your own. Um are there some new rules that we have to apply that we didn't need to take care of

um like uh when I was a kid, I didn't take care about cleaning up my room, but in my own department, I'm I feel responsible for that, things like that. And uh of course the budget. It's already related to the So, on the next few slides, uh we'd like get um more details about what we had and what we wanted to achieve. >> And what we are

afraid of, right? Because >> afraid of. >> This is a really new um um situation for us, right? >> It's a new situation, and it touches nearly everything. So, uh we start with the the basis, the infrastructure. we told you we are on a on-prem situation uh at that time, and uh on-prem, if you try to run uh multiple small services, maybe uh in a scalable way

because you want to be able to stand some more traffic, it is really difficult in an on-prem situation because hardware is limited, and you rely on uh other operation teams. Um although we were afraid of high costs and an unknown infrastructure, we were sure that we need to go uh into the cloud. Um but that's a big move on its own, so our approach was uh was

to to have a platform team help us and set up the basic um for example, skilled in a cloud systems. when we have a cloud infrastructure, it's heavily related to tools. Because on our on-prem systems, we had established tools. Uh, we had them for many, many years. For example, an Oracle cluster or um, RPMs that we deliver. But we wanted to yeah, modern technology. We want to

have decentralized operations. Um, and uh, yeah, a structure that is really good for microservices. And um, we changed all of our tools. Uh, none of the on-prem tools is used in our cloud infrastructure. So, this is a huge move to us, but this is really the basis to be able to build microservices in in our situation. of course, we are customer of a platform team that provides

us with AWS accounts and Terraform scripts. Um, also with the Kubernetes environment. Uh, we as teams are responsible for creating Docker images. we use GitLab pipelines instead of Jenkins. And of course, infrastructure as code with Terraform. yeah. Um, this is of course a huge setup on its own and we need to create a learning path for it and a check that the developers get familiar with the

tools. Um, so we really had to decide um, what is our basis. Of course, uh, all of our software applications that we create on our own are based on Java. Uh, we have a deep knowledge in Java development and we didn't want to throw it away. So, this is what we keep. But we add something more. We add front-end development, maintenance of database schemes, and so on.

And although a lot of stuff is supplied to us like the CI/CD platform, there is a lot of stuff that is new to us. For example, front-end development. And the learning path uh um is related to different topics, the complete DevOps stack, Terraform, but also JavaScript frameworks. we try to become full-step full-stack developers, but we started with being Java developers. So, it's a very huge move, and

it um requires a lot of more knowledge. So, um we thought about how could we um have a kind of of rail guards or guardrails uh that we don't uh get lost in all this new stuff. And this is why we had some goals that we wanted to achieve to be clear what we want to improve um in comparison to the monolith. And we created a vision.

And the vision uh for our microservices is not a uh big ball of distributed mud, um but it's a kind of marketplace approach. Um like uh Amazon um is treating their suppliers, um we wanted our business departments to be independent product providers. At the moment in the monolith, uh they had to stick with common releases. Uh they couldn't uh release a new product feature without the other

teams being ready. And without having to test everything. So, we wanted to achieve that they are able to uh release their stuff independent from each other. but on the other side for our users, for example in the insurance agencies, we want to have a common checkout process. We didn't want to have a checkout process per product looking differently, behaving differently, but a common basis, a platform. So,

this was our vision. then we thought about how could we design our back end? Of course, we stick to Java, but you can implement it in different ways. We wanted to achieve a simple structure, a really simple structure that could be easily understand. We wanted to avoid an over engineered this is why we decided to to go with Spring Boot for example to have a very simple

structure. To use typical layers for microservices, not a hexagonal approach. what was really important for us is to avoid separate scripts for databases, but use a tool like Flyway to have the code in sync with the database structure. >> Yeah, we have to say that also the the monolith is based on Spring Framework. So, we know about the Spring technology quite well. That's true. So, if we

imagine that we have now a lot of services each in a simple structure but in the end we have a lot of them related to different business topics. How would we integrate them and make them work together that it feels like one application for our users? And this is where we thought about the integration topic. If you have for example one product, this was our scenario. We

started incrementally by just creating this whole new stuff for one product. we knew that this product would use all of this common business context of the platform services. For one service, it looks quite nice. You could implement it with synchronous REST calls. Would be fine. But, if you add all the other services, it gets a bit complicated. And we were really afraid of structure and a communication

flow, a data flow that we couldn't handle and that affects each other, so that we couldn't isolate the services from each And this is why we decided to add a broker in between. it helps us to cope with several things we were afraid of and provide us with several things we wanted to have. For example, we want to achieve high throughput and we want to avoid that

one service with heavy load, heavy traffic affects the other services. asynchronous communication via broker. perform a big investigation which tool to take. It's It's Kafka and we used the version from AWS because it's it's just provided. You configure it, it works fine, and you don't need to take care a lot about Kafka configuration. Um we learned that using Kafka requires a lot of code. You need consumers,

producers, schemas, and so on. And so, we learned that it's a good idea create a library. Um an abstract library not related to any specific business topic, but it avoids boilerplate code. that was a lot about back end. >> And now the front end. >> The front end, yeah. Front end is very very strange in the monolith uh because it's not a really front end development. It

was created. We had a kind of of data structure and we created JSPs with the help of a self-created uh front end generator that no one understands at the moment. really nice UIs couldn't be created with this generation approach, but uh some years ago, some 10 years ago, nice UIs didn't matter. Uh the complete UX UI experience didn't matter. But we want to change it. We want

our partners be able to have nice UIs if they want to. So, we want to have a typical modern front end development with standard tools, component based, no no generator anymore. >> Yeah, maybe for um the context this application what we are building is actually based or for the uh whole um salespersons outside, right? So, it's not for the end user, but for the salesperson. And therefore,

at that time, you know, they don't care. You just use it. Use it or you die, you know. Just Just something like that. But we want to change it because we know, right, that if we make a nice user interface, have a nice user experience also for the salesperson, they view maybe sell more Yeah, also they had to get they had to get a training on using

the old UI because it's not self-explaining. things to improve. Yeah. >> Um we decided really to go with front-end development and with user engagement. we thought that we need a JavaScript framework to help us. Uh it's Vue.js because of the learning curve. We thought it would be acceptable for us as back-end developers having to learn a lot of stuff, you know, Terraform and so. So, it's a

Vue.js and we thought about organizing some common front-end components like using Storybook um and to create a component-based library not with huge business components but with basic date fields or drop-down field or So, that you need to don't need to build it uh new for every service. And also add some uh UX and UI knowledge and tools um like using Figma and really uh at the moment

setting up a UX UI team. Yeah. >> one one maybe one um interesting part in this uh situation is that actually I'm the one who always say, "Hey, come on. We just use a Java Vaadin and grid. I'm a fan of grid and transpiler, right? Um but our developer doesn't want to do we want to use a new cool uh cool stuff like Vue.js or React or

whatsoever, right? This was >> That's a really fun. But then that's a part, you know, you say, "Okay, come on. It's your job. You will do that part, right?" So, you have to uh to choose it by yourself, right? The the uh stack, the technology framework. That's actually the the thing. we talked about the back-end services and microservices approach and integration. Uh if you talk about the

front end, um of course, we don't want one huge front end because it would be a front end monolith and we wouldn't be able to be flexible and um be able to deploy new products without touching others. So, we are talking about micro front ends. And if you have micro front ends, you need integration as well as for back-end Um so, we um talked about our um

UX layout. Now, it's not that uh ugly, but it's just a uh draft to describe parts of it like having a kind of common header, common navigation, and a common footer uh where you have some platform services and in the midst, you have uh this specific product services that could be uh displayed or or not depending on the navigation. to uh have a a nice routing and

good loading and unloading of the front ends, um we decided to use a framework for this topic. Um it's called single-spa.js and it helps us uh with front-end events yeah, you could also use multiple JavaScript frameworks uh with single-spa. Uh we talked about Vue.js, but it would be possible to use uh React front end uh together uh with the >> That's a lot. >> That's a lot.

So, let's summarize that part, right? So, this is actually the whole architecture what we have. Um it's just a simple one-page, right? We have the front end, we have the back end, we have the the infrastructure, we have the integration part, and all and just just a vertical microservices. Yeah, we have a lot of microservices at the end today um at the end um yeah, we have

a party, right? So, we have the the new environment, we have uh the key data of this environment. Yeah, we have approximately about um 100 person organization part. We have um 70 deployment units per stage. And we have also um uh 30 databases per stage, um 2,200 merge requests per month, and uh we have uh approximately uh 45 deployment per month. Yeah, so it means um we

are going to that uh requirement what we actually in the beginning we are talking about. So, what but what is after this party, right? We have done our job. Do we go back to the situation but okay, come on, we have a chaos afterward? No, we don't want to have that, right? >> No, we don't >> We don't want to have that, and therefore we try to

uh make a a good solution afterwards. We want to have a quality at the end, a stable quality, and what are we doing in that part? >> Um to be able to party again and again, we need to uh discover uh what we have to do to keep it up. Uh one part is softy software quality, of course. Um listed there as what we want to have

is something that we didn't have in the There was no good test coverage, no clear test pyramid. The code was not easily understandable. So, this is what we want to achieve. Um and uh we do this with the help of some tools. The tools that we didn't have for the uh like Renovate that uh helps us in keeping up with a lot of patches because every library

has uh many patches. We have multiple patch requests per day, and Renovate is really a helper in that. Um we have applied strict quality gates that hinder us from deploying unsafe code to production or that keeps up the test coverage. Um we have tools like Sonar, but also Aqua Sec for vulnerability scanning. at the moment we're trying to set up end-to-end tests with Playwrights to um understand

that everything works together nicely. Another part of quality is related to a completely different topic. It's not about the code, it's about the services and the people and the service ownership. Um Luffy explained we're about or more than 100 people. I'm I'm not actually aware of it's 100 or 120 or so. Um but they have to work together and to be well organized. And um another aspect

we talked uh you about all this new stuff that we had to learn and about this multiple insurance products. So, uh how could we avoid uh that the brains of our developers are exploding because they have to understand too many things. I guess we all are aware that a team can only have a a limited amount of knowledge, and you can just try to understand how much

of this knowledge is related to business topics and how much is about technology. And because we are an insurance company, a lot of stuff applies to governance and and security we decided to group the people in teams and the teams around business contexts. Um for example, the um vehicle insurances are related in one team. The idea is to have a specific and limited business context that they

need to understand, and to have a kind of end-to-end ownership for the services, including front end, back end, and database. Um so um the um the hope is that they can develop a deep knowledge about their business context, and can um release their products um decoupled from the other teams, independently from the other teams. So, service ownership was really a a key in our journey um to

microservices. Yeah, but >> What about the cost? >> party and cost? >> All right, that's a um point. Um I think you already know about the article from the the builder of uh um Rails about the um they just moved back from uh from AWS to uh on-premise um situation because he said that um it was a really cheaper to build your own premise again. All right,

but that's a power point. We don't have the the transparent with our monolith, right? With our on-prem situation. >> Yeah. That's really a pity. Uh you remember um we told you about the on-prem situation with a VMware cluster and an Oracle cluster and a separate operations team. Uh on-prem, we don't have a really transparency about the specific cost that is um related to our sales applications. So,

first thing that was really important is to get transparency. Um this is done by tools like OpenCost or AWS Cost Explorer to really uh understand um how much uh cost we are causing with our lots of services and lots of databases. Um, one thing is related to the code itself because, uh, when you talk about costs, uh, sometimes it's related about scaling. Um, on prem, we have

just bought the biggest machines available. Uh, in the cloud, we want to scale down if this maximum of memory is not, uh, needed. Uh, so our services have to be able to scale up and scale down and, uh, in the end, it's about stateless services. Um, we use Keda Scaler for the pods and, uh, we also, uh, have, um, Aurora Serverless as Uh, we started with using

AWS Postgres with dedicated sizings because, uh, the first version of Aurora, uh, Serverless was not really, uh, good enough for production. Uh, but version two is stable and good enough for our use cases and it really saves us a lot of costs. And the good thing is it's really dynamical. You don't need to invest, uh, much time as a team in trying to figure out how many

requests could apply on a database and how you could size your services because you can't change it. It scales up and down. Um, it's like, um, paying by use. And this is really good for us. >> this is our new environment from tech technology part, back and front, and cost organization. >> And now we are going to the organization We'll show you how the organization now, um,

looks like. All right. We have DevOps, we have internal developer platform. This is actually, uh, our advantage. We have already, uh, internal developer, uh, platform for us, which is, uh, um, used for the whole D for car, right? So we just dock into this internal developer platforms. We have there our AWS platform. We also have our death rail people to show the how to it's work is

going to the whole D D for car, but in our case is our sales platform. We sales platform team which is already using or offering the services for example for Kafka and so on for the whole sales platform and on the top of that we just put the whole products. On the right side we also see here that we of course have UX UI team which is

like Patricia said to be able to have the same experience for the whole products and also we build such a call coordination community of practices. organization so that all the developer or the business analyst people product owner and so on they can also take a look to the whole part of our Right? And >> So let's talk about the roles that we have there. In the end

we are talking about teams of teams a team of teams. And it's a little bit like in in safe the scaled agile framework. We had people in D for car that thought about how could we apply agile to the whole company? they took many ideas of safe and created something that we call cluster. But there are some similarities. For agile teams there with a product owner scrum

master and several cross functional teams. We We business analyst there. We have developers there, but also UX UI people. Everyone, every skill that we need to be able to implement and deploy and operate our cluster product owner, chief product owner. We have also people manager implemented because we try to understand if separating the disciplinary part from the business part could help us to be more innovative. Um

and we have a coordinating team that tries to align all those the separate teams with regards to processes, uh governance, compliance, architecture. Um but also with regards to security stuff, yes. For example, Lofi is supporting us with the people manager Low Rick at the >> Correct. >> So, um >> So, now um we come at the end. What are our learnings? Flexibility and speed, we get that

part, all right? Because it's really really easy now to build a new product, to change the product, to deploy the product completely independent. Yeah. The point is actually we have to be careful. We just always need a new uh more employee for that. Because if you have a it doesn't work if you say, "Yo, come on. You have already built that product. You can get now build

that product also." Right? So, we have to be careful. Uh so, we have uh more employees in that part. And also high cost. Uh because we if we have 10 instead of three products, we have 100 products, we have to to build that part. Yeah, so that's mean we have to be careful about that part. Users are very satisfied. After 5 years, availability is very high. We

have a really high achievement in SLA. Crazy, this is never thought about that part. And also before in the morning part, you know that in Germany if you want to change your motor insurance, you have a such time timeline, right? So from I don't I don't know October until November, December or something like You have to put there and everything is going very high at the moment

to access our systems. And before in the morning part, you always say oh come on hopefully it will it will work. Because you know a lot of people use that part. But now we just very simple, very relaxed. Okay, just do it. It will just make a scalable and we don't need to do anything for it part. That's a very a nice nice way. 2024 was a

very good year also with a strong growth for the company. Yeah, because we can manage to have a lot of new products. We have a a lot of new Sell a lot of things. And we also think that the the whole sales people they like our UX UI, right? They they are very happy to use our application now. It's not like before, right? We all got we

have to use your application to sell that part. That's a really hard part. But today they love it because it looks very good, very nice. The UX experience very nice. And that part we should not underestimate. >> Another part that we should not underestimate is the learning path that we had to take to couple with the new tools. Java is really not comparable to JavaScript. It's a

new ecosystem. And also this applies to Terraform. So we really had learn much and we had for some times for several months we had a specific team that helped us to get a structure and to set up some courses and trainings and help us to be use those tools. And what we gained with these small applications is an easier onboarding. With the monolith, it typically took 6

months or more to be able to to deploy it, to build it, to understand something and not destroy everything. So you can't couldn't even scale by adding more people, but now this is much easier I guess our developers are happier with the new tool stack and that's >> Okay, you have some developers here from DFF you can [laughter] ask them if they're happy or not. >> Hopefully

they give the correct and accepted answer. >> All right and the point what we actually we we take a look all the how we migrate from monolith to microservices and so on and everything of you maybe have heard about the strangle pattern we take one by one we have a one input but that doesn't work with us. So I am have a postbank pattern we call it

because postbank has has has done the same thing. They build just a new system parallel right? So you can choose whether you want to log in into old system or the new system and every time the old system is just stay like that. So no features no other things new only security patch and so on but the new system had at the beginning a very small of

features but it will increase the whole time. So I remember that part because I okay don't you know it's just you cannot look at what okay everything but afterwards after sometimes the new system will be going increase in the features and so on and that's actually what we are also doing. Yeah we just separate completely separate the monolith just stay like that we make an upgrade of

security and so on and so on. Yeah, but we just let it like that and the new system with it will continue develop and mature and so on and so on. And that's actually the part pattern we actually find very very good. >> But it's also the reason why our journey is not finished at the moment. The monolith is still there, although it shrinked. It's not any

longer about this 900,000 lines of codes. The major part of the product and the most important product are in the new world and this year we will continue and even um switch the amount of new product even more to the newer part. I guess by the end of next year maybe we can really shut it down. But we have achieved a lot of stuff even before this

completely shut down of the monolith completed and this is also very important. It's a kind of incremental and iterative approach to it. >> Yeah, but we have to think about that if you do starting something like this, yeah, you know, because you have to take care of two systems at the end, right? So that's a really important part that we have also to talk with our executives

at the end. The team culture to be adjusted, of course, because a lot of the microservice, the permission concept is also complex because a lot of team, a lot of products now, but that's it. That's the whole story, yeah, that's I it has to be like that. The collaboration within the cluster is working very well, but outside the cluster unchanged because we only have the cluster for

the sales. But we have to talk with other part of DFO car, right? So that's still the same. That doesn't change at at all. >> Agility is not introduced for the complete company, so processes that are still very challenging. >> That's it, I think. Um We always also search for a new senior developer relations engineer for us to make the whole DVA car working like what we

are doing and our sales platform. And for questions and so on, thank you very much. And this is also feedback. Yeah. >> [applause] >> Oh, yeah. Um Oh, what does DAA stand for? A question. This is actually German word. Um >> Tarifierung Angebot Antrag. It's like a pricing order offer. [laughter] >> That's a typical insurance word. So, every insurance people know about that part. Okay, thank >>

Mr. T. >> No. >> What made you decide against hexagonal architecture? >> Yeah, because for each microservice, it's much too complicated. Um we have now parts that are maybe about 8,000 lines of code and it's uh good enough to have it in clear structures like having a controller package, a service package, a repository package. Um and it's it's easy enough for us to to keep a clear

structure and to avoid that it gets worse again. Next question. Did you think about using Eclipse store as persistent layer uh for some of your microservices? >> Which store? >> Uh Eclipse store. That's object-based um we did not with this store, but >> But that's from AWS, right? >> Yes. Uh at the moment uh with with the key figures of the monolith, there was something about 9

TB of of stored data. Uh most of these terabytes resulted from storing PDFs in the database. Uh we changed this. We use S3 as a storage for documents and our databases are much smaller as a result of that. >> All right. The next question or >> Two two minutes. >> Two minutes, okay. The next question did you consider Fatin for the front end? Yes, I'm a Fatin

fans, I'm a group fans, and Java fans, but the developer doesn't want to use it. I mean So, I have to follow, right? So, that's actually the point. All right, the next question. More development units, databases, lines of code, etc. How about the running cost, infrastructure, personnel? Sounds more costly than before with monolith. >> Yeah, it is. You see you've seen the figures. The monolith started 10

years ago with 20 people, and now we are more than 100. But, you also saw the slides about the challenges that and the changes in the environments, the new requirements that we see from from security staff, from governance and compliance staff, and also the expectation from our customer to have better front ends, easier setups, and also the expectation from management. Uh there is no investments without costs.

>> Correct. And And that's what That is actually the next questions. How could you sell the higher cost to the management? And that's the the point. If you don't have want to pay, you don't get anything. The next part. Do you use Agile practices like TDD, pair programming, CI/CD, trunk based development, etc.? >> Uh yes, we do. Pair programming, mob programming. >> Mob programming, >> We use

it. Not really test driven design, although some developers would like to. there we have to improve it's all about improvement again and again there is no end where you can say we are finished with improving or finished with learning. >> Okay and the last question is what was the timeline for the migration? When did you start? When were key milestones? We start five years ago. >> Started

2020 with a strangler pattern to restart six months later and I guess one year later we had the first product live. The second product took us I guess some nine months and now we can provide new products within around three months but together with complete new UX UI. It's not just taking the old code and putting into microservices but it's a real build from scratch with new

business features and then new designed layout. So it's much more than just having the code of the monolith put into parts. >> I guess we need >> That's it. Thank you very much. >> Thank you very much.