 Hi, everybody. Thanks to be here for this talk about chopping the monolith. I'm Nicolas Frankel. Well, nobody cares anyway. Just to be on the safe side, I do this talk in multiple countries. In some countries, it can be considered offensive to contradict the attendees. I'm sure here it's not the case, but if at any point you feel offended by my opinions that contradict your core beliefs, just leave at the moment and don't hold it against me. So that being said, we live in interesting times where if you are doing microservices by default, you are a good developer. And if you are working on a monolith, you are a bad developer. Who here is a good developer? Good. So you are doing microservices, right? I know, hey, come on. That's the assumption. Who here is doing microservices? Come on, raise your hand. I want to see everything. OK, half the room. That's an interesting take. So we live in an industry where we are supposed to be engineers, but we mostly live by hype. Microservice is good, monolith bad. You might see that I have a bit of gray hair, which means that I'm probably either old or experienced or both. I would like to think that I am experienced. And I want in this talk to perhaps challenge some of those beliefs and offer some ways that you can do otherwise. So just to get back on the initial microservices stuff, I won't read it to you, but basically this is the definition of microservices by Martin Fuller. So if you have anything against this definition, you bring it to Martin, not to me. That's not my problem. This, I consider the truth. If you are not happy, well, go back to him. Again, in the same article, he describes several characteristics of microservices, right? And in general, here, cool, right? You know, just once I did this presentation internally, not this presentation, but a presentation, and I thought that was a very cool demo. And when I did this stuff, everybody said, oh, I thought that was my demo. Not at all. They didn't care about the demo. They care about the stuff. This is $100. Anybody can buy it. Anyway, so the microservices stuff, well, componentization of your services, everybody does it. That's basically the definition. Organize the run business capabilities, blah, blah, blah, blah, products, not projects. Among the people who are doing microservices or said they were doing microservices, who is organized around products, which means you have a star date, and you have a recurring budget over the years. You have no end date to the project, at least at the beginning. At some point, it might stop. Whereas a project has a star date, end and end date, and a budget over the project, and probably over budget after some time. But that's normal. So who here is organized around products? OK, like 10 hands, at most. Yeah, because you have two hands. Good. And so you see that people were saying they were doing microservices. According to this position, they are not really doing microservices. They pretend they are doing microservices because they have some of the characteristics, but not all of them. Now, if we get even further, I remember when this microservices trend started, like everybody was talking about Conway's law. The people who advertised for microservices said, you must reverse Conway's law. Who is not familiar with Conway's law? OK, so the idea is in the thesis by Melvin Conway that your architecture mimics the communication channels of your company, of your organization. That's his thesis. And yeah, I was happy to meet him. Come on, I need to brag a bit. And so because we are organized like this, so we have front-end engineers, we have middleware engineers, and we have database administrators, then we have a layer architecture. So if we want to do microservices, we need to use Conway's law. So if we want this architecture, we need to have self-contained autonomous teams. So I will ask the question again. And I have nothing against you. Who here is organized and who is doing microservices is organized like the diagram on the right? Not the half-half. In general, it doesn't go in your direction if it's half-half. But anyway, OK, still 10 hands, but not the same who were organized around products, which is interesting. And the poster child for this organization is Amazon Web Services. They popularized the idea of two-pizza's team. Well, the side of the pizza depends on which country. If I belong to the team, that's different. But basically, they are like small self-contained autonomous teams. So the idea is you want to go from the organization on the left, which is probably your legacy organization to the organization on the right. And for that, you need this person. So now the question is, who is this person? Who I want to illustrate with this picture? Who? Banana man. Banana man. Yeah, you are a second person who tell me that. I don't think you have many banana men in your organization at the moment. So that's the wrong answer. But that's a funny one. Anyway. Markies. Among keys. Yes. OK. You are now responsible for the real answer, which is middle managers. Is there any monkey in the room who belongs to the definition? And now everybody is super afraid, right? No. On a more serious note, yes, if you want to move your organization into a certain direction, you need the help of middle managers. Of course, you need to have the willing and the backing of the executives, but nothing will happen if you don't have the help of the middle managers. Never works. And now comes the $1,000 question at the head. In this group is a middle manager. In this group as well. In this group as well. Where are the middle managers here? They become engineers, I'm not sure. Another answer would be pitchy. But actually, it's that the problem. You want the help of people to help you make themselves completely useless. Because even if on the organization on the right, you might need some middle managers. I mean, the basic idea of autonomous self-contained team is there is no manager. And if I might have, you might think that, again, something against the managers, I have something against the bad managers. And bad managers' main task is to accept my vacation requests to be the proxy of my raise every year when I have one. And when I mean the proxy is you cannot negotiate, right? Hey, you've got x%, thank you, or oh, I'm super unhappy. But whatever happens is just a proxy. And do some reporting. This is what bad managers do. I have a couple of good managers who helped me achieve my job. They were really supportive. But in 20 years, five, perhaps four. So that's the problem. So I believe that it's very, very hard if you have a legacy organization to do microservices. What you might achieve is you will have technical microservices and still your regular organization, which means you have none of the benefits of microservices and all of the problems. Congrats. Now, how does it work in real life? Well, you have one senior architect, someone who is very technical. He reads about microservices in a magazine. He said, wow, that looks cool. We can solve all our problems. He has some influence in the organization, talks to the chief executive officer, talks to the other executives. He got buy-in. You go full microservices. As I mentioned, you've got none of the benefits. Then he quits. Who is going to maintain the microservices architecture? Because you call them monkeys, right? So the people who are left need to maintain that pile of crap. But at least the guy has all the women, because everybody needs to be represented as microservices on their resume. Full win for them, full loss for you. But the question is, why are we so obsessed with microservices? I mean, there must be a reason somehow. So in another article, a follower lists three main benefits of microservices architecture. The first is strong module boundaries. The second is technology diversity. And the third is independent deployment. So let's see if any of them is reason enough to move to microservices. First one, strong module boundaries. Yes, you have completely separate repositories, unless you have a mono repo. And then I never understood why you can have microservices and mono repo. But let's forget about that problem. So you don't have related code base. Of course, you have no dependencies between them. This is strong module boundaries, right? Yes, this is, however, a small benefit for a huge, huge investment. There are other ways to get strong module boundaries. For example, if you are in the GVM, you can have your modules, your, like, GPMS modules. You can have, like, static checks with Sonor that says that this package cannot call this package. There are other ways to achieve that. This is not reason enough. It's like saying, oh, I want to learn with my left hand, so I will cut my right hand. It will work, sure. But not sure it's the only way, and it has a strong side effect. Technology diversity. Everybody loves diversity. We are in IT. We must be diverse. And so technology diversity is saying, hey, we are a Java shop, but I love Rust. What? I love Rust. I also love Kotlin, but Rust is a better example. So I love Rust. I want to learn Rust. And though we are a Java company, my next microservice will be in Rust. And it's good because it's diverse, right? And now I leave the company. Yeah, you are still the one going to maintain the Rust shit that I created, right? Thanks to be seated on the first row. I have stickers for you afterwards for your pain. I really appreciate that. So diversity is the good thing, but the idea of technology diversity being a benefit for the company is complete crap. I mean, even if you are the Java shop, it's very hard to recruit a good Java developer. Imagine recruiting a Rust developer if you have no clue about Rust. No great idea. So the only thing that I have is independent deployment. So this is like projects, and you have like free main phases, specification, implementation, and deployment. So this is outside our scope, the specification. Mainly it's communication between the business and us. It's incompressible. However, what we can work on is implementation and employment. And this is like known as the lead time. So the idea of deploying often is not a new problem. We already had this problem before. But before, we did it in a very different way. Before, we had really strains. So we deployed, let's say, four times in the year. It's not funny. You're probably using right now software that we deployed like this. And the idea is that it's very hard to test the whole monolith. So we cannot test it completely all the time. So we need to reduce the number of deployments again to x time, let's say, four times a year. The thing is, the business needs to wait three months to get their feature. But who here is a developer? They're not only everybody. We are always late, right? Come on. We are always late. So if you miss the train, they need to wait three months extra. Business is never happy to wait three more months. So what do we do? Well, we cannot deploy. But there is a trick. You can still deploy if it's a bug fix. It's not a problem. You just ship the unfinished feature. And of course, now there is a bug. And you can continue working on the feature. Drinks the bell, right? I know. I mean, if you have a stupid rule, then we are creative people. We find a way to go around the rule. But this is based on an assumption that it's not possible to test the monolith well if you release often. And the assumption that the microservices people tell is that they never tell it. It's not possible to test the monolith well. The underlying assumption is that it's, of course, very easy to test the microservice well, meaning that the microservices is completely self-contained, has no dependency to others. There will be no side effect, whatever. Of course, there will be less ripple effects, unless you have a mono ripple, blah, blah, blah. But still, the assumption is completely crap. You have hard contracts, yes. But I'm pretty sure that there is some implementation detail that leaked. And then you can break something if you just test the microservice. So in my opinion, the real problem is we think of the monolith as a monolith. However, if you have worked for some months or even some years on a code base, you may have noticed that some ports change very frequently or very randomly. And some other ports are very stable and very rarely change. Do you also have the same experience? I mean, the only one. Yeah, OK. So my experience is that, in general, it's the business requirements that makes the change or a change in law. So business requirements, frequent, low, random. We already had this problem at the time when I was young and a young engineer eager to develop my stuff. How did we handle it? We used the rules engine. Who knows about rules engine? Oh, not that many people. Who doesn't know about rules engine? OK, and then some people are shredding us cat. They are between knowing and not knowing. OK, that's interesting. OK, so for those who don't know, the idea of a rules engine was you would deploy once the engine, and then inside, you would deploy code on the fly. And this code would get evaluated by the rules engine, blah, blah, blah. And there were a couple of benefits. The benefit is that the business would be independent of the release cycle. They could go to production, make directly their change, and it would be applied immediately, which can create issues because sometimes the dates, you need to apply the change at the correct date, especially with law, blah, blah, blah. I mean, I don't want to work on the detail because this talk is not about a rules engine, but the idea would be that. And so some businesses would be very afraid to rely on IT, depending on the organization. And they would say, we want a rules engine, and then we want nearly all the code there. The problem with this approach is that, well, IT would be very happy because then it becomes their problem, not yours. But the problem with this approach is the idea of the business changing a rule is crazy. I never worked on such a project, but I asked one of my colleague once, hey, show me the code. But how does the rule looks like? And wow. So first, I don't believe any regular business person could have changed it. You need to be a developer to understand the rule. And then you need to be also very familiar with the business. So the idea of being independent is an idea, but it's not a reality. Anyway, this is only one of the ways. My idea is if you isolate the quick changing part or parts, you can replace it with a single microservice, with a serverless function, with a rules engine, with whatever something that is not invented yet, and keep your monolith working. Do you know this microservices pattern by Chris Richardson's book? Do you know the book? OK, very, very interesting book, like this thick. I read halfway through the other book. He does everything by the book. And then halfway, I understood that nobody is crazy enough to implement everything. So about halfway through the book, I just put it back on the chef's table. If you want to do microservices the real way, you should read the book and implement everything. It's a lot of effort. Anyway, there is a companion site, which is also very interesting. And in one of them, he talks about strengthening the monolith. So basically, there is this like Martin's folder design pattern, strengthening pattern. And the idea in strengthening the monolith is very similar. So basically, you start with a monolith, then you chop one part, which becomes a microservice, then several more parts and parts and parts. And at some point, you don't have the monolith anymore. You only have microservices. And this is a very good idea. But his idea is this is to be architecture. Everything is microservices. That's the grail. Everything is nice. We have achieved microservices' paradise. Whereas my idea is why don't you stop there? So here, you just have the quick-changing parts, and you keep everything in the monolith, which is very stable anyway, so you don't care. So one way to achieve that is to use an API getaway if you are in a web environment. So you can like, through the monolith, you send everything to the monolith and at one point, you just change the routes to one function that is serverless, microservice, a rules engine, whatever, I don't care. The best example I have is like, I've worked in e-commerce, is the pricing. Who has worked in e-commerce as well? Yeah. Retail, oh, the worst kind. And the pricing is the crazy sport. Yeah, there you go. I didn't work on taxation so much, but the pricing was always crazy. Like, the business always had crazy idea. Like, the regular stuff like, okay, you buy this product, and if you buy X, you get, let's say, 10% is easy. Then they come with, oh, if you buy X of this product, you can get Y for free, okay? And then they come, yeah, but if you buy Z of this product, then you get no shipping costs. So every time you wanted to do something, they had more crazy idea. I worked on the hybrid platform that was impossible. So my idea is we can chop the pricing engine and do something fun. And then I have 10 minutes, so it's demo time. And of course, it's the time where I want to show you that it works and there is a chance it doesn't, otherwise it wouldn't be fun. Chopping the monolith, which is not the right way. Chop monolith, new window. Okay, so here I have my architecture. Is it big enough for you? Good, so I work on the Apache API6 project, so I will be using Apache API6. Of course, you can use any API get where you want, but of course, I will be very grateful. My boss, if you used mine, but okay. API6 depends on ETCD, where it stores its configuration, its distributed key value store. Then I have my application, which I need to downgrade here. So I can show you the codes. And I have MariaDB, where I have all the data from my project. So who here is a GVM developer? Oh, not that many people. Okay, so this is a regular Spring Boot application with Kotlin. And the idea is I will start the stuff and then I can describe the codes. Docker compose up here. I have this pricing stuff. And at the moment, pricing is super hard. I just add the sum of all prices, right? The idea is not to show you how you can do a pricing engine, it's just to show you how you can change it easily. So I have this pricing stuff. And basically when I call it here, so I get the cards, I price the cards, and I return everything in one JSON payload, right? So when I go there, so here it should have started. I will just configure the API get away. So I send everything to the shop shop. And here is just to remove caches. So I don't have bad experiences during the demo. Okay, now I can, oh, I need to start Firefox. Yeah, I got interested in this stuff in the Czech language. I don't know if you see it. I don't know if you see it. Sorry, but I won't learn Czech anytime soon. And so I can go to local hosts. And I learned something that's not like only the Czech language, it's called syllabic consonants. So that's how you can pronounce all those consonants and there are even vowels somewhere that stupid foreigners cannot know. So here I add stuff to my cards. I will just check the network and I go here and here in one go, I got everything. So if I get here and I say the response, I see either total and I have the lines of my cards. And the origin is a monolith. I cannot make it bigger. You should have seated in the front row. But trust me, do you confirm this written monolith? Of course, thanks. You really want your stickers. I understand. Okay, so now to actually start my journey, I will need to make pricing not a regular function call but an API call. So now the pricing here and I will just update so it's Docker compose start chop, chop, chop. And normally at some point, no, I always forget it's up. It's not start is up. Yes. So at some point, yes. Okay, it's doing this. So the pricing now has become a route. So now I compute the route. So the client, the browser will first request the content of the cards. It will get the content of the card and we make another request to the pricing. This is very stupid. It's not the client that should do it. It's the API get away. But you understand I'm too lazy to implement further. So now I have this, I get back here. I go, I didn't implement the sessions. So I need to redo everything but that's fine. I go there, I go there, I go there and here I go on the cards. So you can see it's another version. And now when I go to pricing, so first I have two requests and here the origin is still the monolithic. So now my architecture is ready to be chopped. What I did finally is I kept the whole stuff but I implemented the pricing in like JavaScript. Yes. And I put the codes on the Azure Fast. And so now the only thing that I need to do I don't redeploy anything. I just go here and I still have everything that goes to the monolith but I have one special endpoint, the pricing endpoint. And I say, hey, when I receive a post request on the pricing endpoint, well you just go to Azure instead. So I do it and now if I do like the refresh, like it should be like slower and then you can see Azure here. And I didn't redeploy the monolith. And now I can change the code every time I want on serverless and again it can be serverless, a rose engine, whatever I don't care. But basically I kept my monolith. So thanks for your attention. You can follow me on Twitter even though Twitter is now dead. You can follow me on master.down where I'm trying to find new and interesting content. If you're interested about the code itself because even you should trust this guy that it was everything was fine but probably I bribed him or whatever so you can get the code on GitHub and do it by yourself. And if I got you interested in Apache API 6 somehow just have a look, it pays my bills to come here so I can do better talks next year and I come back again. And now we have like three minutes for questions. Wow. Yes, thank you. You really want your stickers. I know. Remind me. So the question is, when do you stop chopping the parts of your monolith? When do you know what's the right time? So I will completely change the question because that's my privilege as the speaker. And I tell you the question you should have asked instead. The question is, when do you start chopping? And there is one single reason in my opinion to start going to microservices and it's not about any technical reason. The only reason you should start doing microservices is because you have too many developers working on the same code base. And my experience, and this is very personal, we started to feel the pressure at 70 developers. So we had a dedicated release manager who handled all the branches of the Git flow. It started to get really messy. That's at this level, we should have started to think, okay, what part can we start to chop? Before that time, scaling, hey, like stock overflow, they don't do microservices, they scale super well. So every technical reason you have to do microservices is probably bullshit, in my opinion. I accept stickers also. The companies that go on the stage and advocate for microservices, they have the right organization, they have many developers, and yes, they are at the point where the benefits of microservices outweighs the problems that you will get, like distributed tracing. But I believe that most regular companies are not mature enough to do microservices anyway. So unless you start feeling the weight of those like many, many developers, don't do it and we can talk afterwards because I'm out of time. Thanks a lot, I have stickers for everybody, don't worry. Thank you. And I have a talk tomorrow about open telemetry, it will be less funny but still interesting, I believe.