 So this presentation is about why I don't use microservices and quite a few of the projects I tend to work on and I'm going to go through a couple of particular case studies of things I'm working on right now That just are not microservice appropriate and and trying to do that kind of would make them fail I've got to figure out how to advance the slide Enter point click. Oh next slide. How about that button? Okay? Um That was a backwards button. Sorry, let's go forwards We don't see you see me. You can't see my screen All right, sorry, let's back to So our technical difficulties are still in place cameras on Camera off camera on I mean present mode Yeah, I'm wondering present mode. So that seems to be working. Yes. Yes, we can see it's like Or rather your screen. No good Still seeing it Yes, we'll seeing it Still seeing it. Absolutely. Yeah All right This is just a little bit of value. So one of the things you can see is I'm very old Um But the other thing is kind of more on the on the right side and that is I tend to work in new technologies On bleeding edge. So a lot of things I talk about sometimes are not appropriate for you right now But the chances are in the next five years, you'll get to do these things So I'm going to talk about Sort of requirements uncertainty Because as I see various projects over the years, especially around Y2k, there's some things that are really certain about that And some uncertainty And if you have if you have actually perfectly good requirements and everything's kind of known waterfall actually works pretty well I mean, we I deliver systems for you know, quarter of a century using waterfall technology successfully It turns out though agile lets you have a little less certainty yet still possibly deliver And this was kind of really cool because now I can sort of start out doing something a little quicker And sort of let the new requirements flow in But the problem was always that if the requirements are really kind of more uncertain Then basically you will be unsuccessful. So if you build the wrong thing or the customer says that's not what I really want it Or you can't figure out how to deliver it at all So a lot of promises made a lot of things fail. So I kind of figured that to be the graveyard But over time I begin to understand that there's some differences here So there's kind of fuzzy problems and there's traditional problems and I'm using Sorry for the graphics, but I'm using the Kenevin model from a deck I named Dave Snowden Some great YouTube videos from him about how that this really works But he says problems are either simple or complicated We're simple problems. The cause-and-effect relationship is very straightforward But for complicated problems the cause-and-effect relationship is more convoluted So it's kind of takes an expert to figure that out We didn't stop there. He says there are also problems that are complex and chaotic And a complex problem is one where the cause-and-effect relationship can't be figured out Even though you'd like to think it exists. It really doesn't and so you see things like Financial markets when people say I can predict what the financial markets are going to do They're just kidding themselves Because it doesn't really have that cause-and-effect relationship. It is a complex product And chaotic means I have no idea what's going on at all And just because a problem is complex doesn't mean it can become complicated Complex is complex and tends to stay complex Complicated just means maybe I need an understanding of it So for an example is a complicated problem would be something like You know figuring out financial transactions. There's the rules about how I figure out financial transactions a Complex problem is to be one that says well, what share should I buy? Well, that's complex There's no rules about how you make money in that environment. There were people that have already solved it So it turns out these problems are radically different than each other and therefore you tend to organize differently to solve them So for a simple problem are very traditional organization structures work really well I the idea is the manager is there and telling the people what to do and trying to make them work faster and better and Fewer errors and there's managers and managers training how the managers work So a very traditional structure. So a call center. This would be a perfectly good structure for that For complicated though, you've got to have some experts that understand the domain The problem is of course experts are expensive And so basically what you need to do is you put a team together to do what the expert tells you to do This actually describes more traditional agile quite well where the experts are going to tell you that what the stories are and prioritize the Stories for you and a team is responsible with delivering the stories and the experts looking for So again, a really nice structure that works really well for solving complicated problems and again a structure I use quite a bit Probably the complex is there's no one who can tell you what the answer is. There are no experts There's only people who are trying things out In fact, there's no real good man at role for a manager either because the manager can't tell you what to do either Because he doesn't know It's all about experimentation and trying things out And of course, that's a very very different organization structure in a very very different process associated with that So if you look at sort of these these requirements uncertain You one of the things you realize is you can do some of these things that we were used to be in the graveyard But I would call them fuzzy, but there are ways to actually implement fuzzy problems But you got to realize these are different problems and they require different approaches So for a more traditional agile structure stories are a really wonderful thing to do you put the specialists in place to understand How to do these things? You do so tight TDD you put your acceptance test in place right your migration scripts and all that stuff works really well But in the fuzzy world, it's about idea-focused features. It's about ideas. What's the idea? We don't know what this we don't have a story because we don't know what works We don't as we have to experiment so we have ideas and these ideas are implemented very quickly So you need a full stack developer who can do it all not just hand it off to somebody else to do pieces of it Because the faster guy can experiment the more successful. I am And so you want a system that actually realizes when things are working poorly, you know KPIs are being collected so you know when things are working and not working because Again, you don't know what the right answer is yet This is where microservices fit very very well. They're highly decoupled. They let us try ideas out aggressively They're easy to deploy And we can have multiple versions running at the same time And then you use an event-based architecture that really keeps the decoupling working well So different techniques to solve different types of problems And of course you do a continuous deployment. So I've been working recently with the Norwegian national benefits So I'm actually in Oslo right now working on this for the last year And what I found in this environment is that they are just starting to hire programmers in the last few years So they used to outsource everything now. They're actually bringing their programmers in-house So they get some really good programmers programming talent is surprisingly strong But they're new to this organization and the organization is kind of new for them They're actually quite it as an organization. They're very inexperienced in how to run products You know how to run projects and product management stuff, but they are committed to agile They're just not sure what that means when they said it So I worked on several projects We'll talk about each one of these in turn One is a sickness benefit in Norway you can get up to 52 weeks of sickness benefit paid by the government If you're sick for an extended amount of time And if you're sick longer than a year you can move into disability We give you some several more years of benefits So a very very strong benefit and of course we now have the unemployment benefit as well So if you're unemployed, you can get up to a year or two years depending upon your salary level of unemployment benefits And then on top of all this you throw in that we had in the middle of all this COVID-19 hit Which obviously has great implications to sickness and great implications of unemployment And so all of a sudden our case workers were completely swamped with work So this is the environment we're working in So how do we address this sort of problem? Well, the first of all you sort of look at the team the team in the sickness benefit case had been on the job for about six months They got some good domain knowledge so they began to understand what what sickness benefits all about and what the rules are associated with that But they're frankly a little bit They were fragmented they were sort of working on the individual pieces hoping to have it all integrated together at some point But no one's really focused on the integration and no one really had a vision of how the overall thing would work eventually So no vision of how to get there they were working on the individual pieces again sort of lack of frankly business leadership So what we did there was we basically decided we need to sit back and decide how we want to build the overall system The ultimate system what it looks like And start building the pieces that fit into that overall system and make sure they integrate as we build it So we organized a concept around we want to make a continuous delivery We want to deliver something constantly something that somebody can use at least to some degree So we kept going with that We actually put in the agile processes that were pretty much pure extreme programming. So we did tdd. We did pair programming Sometimes mob programming We would have continuous deployments we would push to github and constantly deploy that in fact, we're probably running right now around 12 to 14 deployments a day Into into production Into a lot of running systems Contrast that to going back a couple years. We did some analysis a couple years ago with these benefits stuff The organization as a whole we would probably want some about in a month. We would probably deploy Six or seven new systems a month Now we're doing that in a few hours for one system The other thing we need to do is create some business vision There's we need to lay out what the epics were that what the features where we're trying to build and the stories and sort of a roadmap of how we got there so How do we architect this thing? Well, the first thing we realize is The rules associated with the sickness benefit are coming from the law And the law does not change very often. This is actually a complicated problem Yeah, the law is complicated, but it's nothing fuzzy about the law And so you sort of read the law and you sort of see what sort of rules they have associated with it They talk about making payments. So we created an object called a payment period And the payment period should be you know, no more than 30 days because we like to cut you a check At least once every 30 days if you're sick And the idea that you know, there were certain rules about what it means to be sick Well, we built ourselves a timeline that says okay, what day are you sick and now or how sick are you and And what sort of job were you doing at the time when you got sick? So very obvious sort of concepts behind this that frankly Very traditional programming technology can model very nicely and that's what we why I'm doing In fact, currently in the law, we probably have about 320 concepts we model And over 3000 assertions that we constantly run think about think about 20 seconds to run the 3000 assertions Making sure that we haven't broken one of the one of the things we put into the system But the nice thing about the system is the law is relatively stable. Uh, law changes really slowly So we we're not going to be pushed to do the models. We wanted to model the law quite clearly What does change all the time is where all the information comes to fill in the law So we wanted to isolate that from the from the law itself So we use the traditional mediator pattern We put ourselves sort of a mediator slash controller between us and the rest of the world So the law only talks to the mediator and mediator feeds stuff to the law in the format the law likes to see But the mediator is responsible for sort of turning everything into sort of law format for us So for instance, we get a lot of Documents coming in documents from the doctors documents from the employee Documents from the company all about, you know, the sickness and how much you're getting paid and how long they've been on vacation All the information flowing in and frankly most of the times this information is in pretty much in sort of garbage format Oops, I just lost my screen I lost a lot of my screen Am I back? Anyway, I hope so so the We're getting extra on information. The other thing we're getting constantly Is uh, we we need to run off to legacy systems to get other information because there's other information We need to collect we go to the tax authority and see how much money you're making and who you work for We need to go see what your sickness history is because we have a limit on how many sick days we pay Across a three-year period We only pay 248 sick days across a three-year period So we got to see what used to be sick And we got to see if you're getting some other benefits Other benefits for example being things like are you getting a child child care benefit? Are you getting? Some other vacation benefit So we have to check those things And finally one of our other key sources of information is in fact Our case workers because our case workers need to look at your file look at everything going on And see if you would do do do indeed qualify for sickness benefit So for that we just built ourselves a little task manager. So If the mediator decides this information has to be gotten from the case worker We just send something over to the task manager He puts a task out in the database for for the case workers to pick up And that's how the system works So you look at the system and what problem we're trying to solve and there's no need for You know it elaborates your service-oriented architecture with tons of microservices The law is very straightforward easy to model with techniques we've done for the last 30 years The mediators are well-worn pattern for that. We are using new technology in some ways We got a Kafka bus there separating us from the world, which is kind of cool But the idea of a task manager, you know putting to a relational database that these are things that you know case workers need to handle And deadlines for handling them very traditional application and we built it in that fashion The only place we use microservices is when we are working to the outside world Knowing the outside world always is kind of Involatile so we want to make sure each one of these is different for each outside world interface So we have one per outside world interface. They're responsible for making sure to get the information and time in fashion And really retry as necessary Some of these outside services we have they don't work on weekends So the service doesn't decides it doesn't work. It needs a weekend as well So one of the things we have to worry about is you know waiting long enough for that to pop back up again So we till Monday morning then ask the question get the data back to us So again a very traditional structure So again, we're using new technology, but you know, we're only using a little bit of microservices We're writing everything in Kotlin My feeling right now is if you're still writing Java code, you're making a gigantic mistake for your organization Kotlin is way better than that And very compatible to all the Java code you have We are using multiple Kafka buses We're using a message sheet We're using a messaging sort of base interface. So we we send messages to other services Services send messages into us. So we we basically using Kafka buses very aggressively instead of restful interfaces Our UI is built with React And there is some microservices, but mostly for the purpose of externally isolating Things that we don't have control over and keeping that ugliness away from our core system So in conclusion about that one the sickness benefit didn't need microservices As much as they kind of thought they would like to play with those things. It just is not appropriate In part because the domain itself is is stable because it's law and the law is well defined So there is no kind of fuzzy in this sort of situation And these concepts can be these fuzzy these non fuzzy concepts can be modeled very easily with objects and We'll put some flexibility in the UI because we know that changes a lot We we eventually want to support mobile interfaces, for example But the back end law should not have to change for that So again, that's our conclusions associated with that is frankly, it's not fuzzy. So I didn't need that So don't try to do that and we didn't try to do that. We avoided it All right, and so now we moved on to Unemployment benefits and you're going to get a little feeling deja vu because it is the same organization In this case the team had been on a project more than 12 months Again the good domain knowledge. They'd actually try to use microservices They were in what they attended one of my classes about microservices and thought that would be an appropriate architecture for themselves It turns out it did work for all the easy stuff But it didn't do the hard stuff at all And so they did all kind of did all the easy stuff and kept running across the hard stuff and saying well We don't know how to solve this and Again, the problem was we probably shouldn't have been using microservices Again, little very little vision about what the ultimate system looks like Again to some degree immature leadership on the on the business side of the company as well So again, almost the same deja vu. Let's create a cohesive architecture. Let's build continuous delivery Let's put these rigorous agile processes in place For example, we're almost using exclusively mob programming and teams small teams of four to six doing mobbing And we want to we go we need to go back and create you know epics and stories that sort of capture the overall domain And that's still a work in progress From the architecture perspective Again, we have law a lot of law associated with this Probably just as complicated as the other law Um, but different in many ways But one of the things this law is quite clear on is about decisions. How do you make decisions? um So you make a decision based upon rules and some facts take some facts apply some rules and make a decision Uh in legal terms, it's called a subsumption Uh, and so it turns out that's what we want to model We want to model the concept of decisions Based upon facts and based upon these facts and decision Maybe I make I have to make another decision based on other facts or if it's not true. Maybe I go into a different direction So you wind up with this tree of decisions based upon these facts And the law pretty much specifies what these decisions are and even to some degree the order in which you need to make these decisions That's all very nice for the law, but that law doesn't make necessarily sense for a person trying to apply for the benefit Because some of these facts are are coming from other sources So we create another structure called a case So your application turns into a case a case that we're working in deciding should you get unemployment benefits or not? So in this case, we actually model this as these are the facts that make sense grouped together Like these facts all come from the system. We can look up your birthday We can look up your employment history We need those facts for the law purposes of the law But I give these facts by running, you know calls to various systems. We already have in place But there are other things that the applicant needs to provide So those facts go into a different sections. They put those in different sections associated with the applicant So these facts are associated with Things we need to know like what day would you like employment benefits for when did you lose your job? Do you have children? Are the children less than 18 years old? There's a whole raft of other questions and other facts we need to collect in order to make these decisions And it turns out in our mapping The various web pages associated with this depending on where you're going to Each section probably is a corresponding web page that solicits this information So you'll have lots of sections associated with applicant You may have lots of sections associated with system And there'll be another section associated with the case workers things they have to approve So the way the system's work is basically A applicant will come in and say I would like to have a new case So we will instantiate this case object with all these facts in it But these facts don't have values yet And then we'll go run over to the law and say law what sort of facts do you need first? And the law would say well this first decision requires these two facts So we send those facts back over to the case. He looks through his facts and say oh that that's these are system Facts I'm going to go over off to a legacy system and get these for you I'll fill in the values for you and I'll go back to the law and say hey law. Okay. No now in these facts What do you need to know now? I'll say okay when Ellen needed all these facts back to the case He figures out what section it is Perhaps this section says I need this data from the applicant So we'll pop a screen in front of the applicant say can you fill us tell us about these things So it's a ping-ponging back and forth Now the separation of sort of this ui grouping in the case from the law Allows us to have different groupings for the case We can in fact build a case version that would work on a mobile where you have very few things on a per page basis Versus a maybe perhaps a view that may be a more power user who wants to basically fill in things progressively From other sources. So he may have a bigger web page with more facts into it A power user version of it versus a wizard use So again by modeling it this way we don't have those connections Now as you look about this code Again, there's nothing about microservices The problem is not a fuzzy problem. The problem in this case is very concrete It does have some volatility about you know different uis in the future, but we've isolated that from the law engine And model it completely separately So again, you don't need microservices We had stable and well-defined law again Concepts are modeled with objects And we have great flexibility in ui to sort of recode the case to be a version of case for a mobile user Or for perhaps a web user So two projects, um, there will be a few microservices here like the in the other case. We haven't quite got to those yet Um, but again, no need for microservices for solving a very traditional problem Uh, by the way, all this code we're writing is open sourced Um, the nor have been if all the norwegian benefits code is published in github and it's open, uh To be to be read and studied So kudos to norway and taking a very progressive attitude about that Uh, so I can talk about the code and I can use it into my next project, which will be very handy Um, so it comes back to this picture So this is the picture I use with my clients as I sort of listen to them what problems they're trying to solve And I'm putting their problems into the appropriate boxes Almost all clients will have some in several of these boxes For example, a bank will have a lot of very complicated problems to solve Um, you know working working in how you do your balances and how you take your money invested and How you get your returns and how you calculate your interest and compound your interest and and ask for loans to be repaid All that stuff is very very complicated, but there are very specific rules But the bank also has complex problems that says should I loan you money? Should I raise your credit limit? Um, should I do something else like that? Those are complex problems And In the case of the benefit stuff We do have a few complex problems like we would like to sort of check for fraud is somebody cheating us in our sickness benefit Is the is their employer their uncle and he's claiming he's sick and he agrees with he's sick Where's your doctor your cousin and he's he's filling his paperwork out So we do are going we are building a sort of a complex engine to go run sort of fraud processing and provide input to us But that part is being done as a separate system because it is complex and it's doing being done in microservices So first of all figure out what type of problem you're trying to solve and make sure you're using the right technology A lot of problems we're trying to solve and still solve today are complicated problems Don't get sucked into microservices necessarily. It's it's too hard to get it working in that environment So that's the story about why I don't use microservices. Um, even though they're a lot of fun Even though they create your own intellectual challenges It's not doing my client any good services to use microservices when it doesn't make sense All right fred Thank you for that. Uh, I think this is uh, very good advice So if it's not doing justice if you're solving a complicated problem We don't you don't really need the complexity of uh microservices Yeah, it certainly you will find that first of all it's it's new to programmers. It's new to the architects um And there's a large learning curve associated with sort of getting over that and so Definitely invest in that learning curve if you need it for a complex problem But if you just have a complicated problem, don't do microservices You're you're you're sort of heading yourself off into more trouble than you can spend it's worth No, and you also kill the kill the thirst for microservices overall, you'll you'll kill the useful proper use of microservices One of the interesting thing I saw is uh, you're kind of using the canavian uh framework and you're trying to basically uh, maybe even separate out your systems by uh deciding what kind of uh domain they belong to and maybe separate them out so that you could use services for the complex pieces and for the rest of the stuff you could use something simpler or More traditional in that sense Yes, uh, and that's like we always want to decompose our systems that way that we want to decompose our systems so that we're looking at them It's it's it's small pieces that kind of make sense And then you want to make the judgment about the connevin model based up on that piece Uh But be be aware that the process you use for the complex stuff still needs to be different than the complicated Uh, I had a a client I was working with in london, you know several years ago Who basically had three separate team structures assorted what they were trying to do they had a very traditional retail back in That's their a store And a very traditional system doing that and a very traditional team doing that with very specific roles You know they had architects and designers and back ends and front ends Then they had some things they were trying to enhance into that system. They were usually a very traditional agile team And then he had some about the wild and crazy guys who were putting kiosk out saying, you know, oh look I I like these pair of jeans But you don't have my size so you just go to this kiosk you scan your jeans and you tell what size you want and gets mailed to you Those guys were shipping something new in production every three or four days So they were they were toying with the things because they're experimenting Three different teams three of an organization structures Don't try to have one price fit all That's the very essence of agile in some sense Yeah, agile should be agile and it's actually agile on a team basis not at the company level Cool. All right. Uh, thanks, uh, friend. That was awesome. Uh, also just for the benefit of everyone who's listening I think Fred talked about Dave Snowden briefly Dave Snowden will actually be talking at the agile India conference that is on the 13th october Next month, uh, you know at the end of this month. So, you know another 13 days He's also doing a full day workshop if you're interested in really getting the deep dive So do check that out And I'm sure uh, Fred is uh, accessible through the emails through the email that he shared earlier I Do see one question here a couple of questions actually Fred if you're okay, we'll take a couple of questions. Absolutely Okay, cool. So I'll read out the question. Uh, ankith Has asked a question saying how many projects make bad choice of selecting microservices architecture Just because it's fashionable What is your one key advice to avoid a bad choice? I would say about 80% of the use of microservices is probably wrong Um, you know part of sometimes they're wrong because they're not really microservices They're not really small very I mean, you know less than a thousand lines of code sort of things They really are services now service oriented architecture is a perfectly good architecture To some degree the architecture I showed you is a service architecture Because my services are big Um, but they still have crisp boundaries But I would say about 80% of the time that you hear somebody's doing microservices It's probably wrong And probably a half of that 80% is because you shouldn't be using microservices And the other is they're not doing microservices it really anyway But it is pretty bad right now And so what would be your one key advice to avoid that choice the bad choice? um Make sure you ask what problem are you trying to solve? um To some degree technologists or even cto's that come in and says we want to do microservices We're committed to doing microservices and You need to educate them about that's not really a good answer for anything except the fuzzy problems and Unless you're some really weird startup in silicon valley, you're probably not doing or even bangalore You're probably not doing fuzzy problems No fuzzy problems are the ones that don't have answers. That's where you get ai solutions and things like that in there as well But you're doing a payroll system. It's not a good idea to guess how much money you're going to get this month You probably want to really know the answer And so your microservices don't work very well in that environment All right. Thanks. The next question is from vijay Who's asking microservices do help in keeping bounded contexts well established in a domain driven design? on complicated problems and events Used across bounded contexts Is that an empty pattern? Oh, I think that is a good point But I would say that to some degree we're using that in our architecture as well So the interface to say the law portion of these components is actually very very very skinny um All the internals about timelines and all the payment periods and stuff like that's completely hidden from the outside world Uh, and so in in terms of our outside world, we are basically publishing events back to the rest of the world So we are expressing what we need and information So we're doing that very similar to that. So I think the bounded context stuff is is a good good idea So you want to make sure your bounded context are small as possible But not if it creates high coupling between pair of services So if two services, you know have to have a very high bandwidth exchange to make their decision You're definitely wasting your events like that your events bandwidth should be pretty narrow to that So a bad api is probably a sign that you have the wrong context boundaries But absolutely make as many small ones as possible with the skinny of interfaces as you can possibly make them cool I think for example in the in the case of the sickness benefit. We have 320 classes I think there's seven public classes in there The rest of it is none of their damn business pretty much That's the bounded context argument and even within there we do have context within there, but we we create the context around package boundaries So there's multiple modules involved coupling modules involved in the even each component to help further isolate those So congratulations on bounded context absolutely, uh, that's what makes a long lived application Yep, totally makes sense. Uh, all right. I think we have, uh run out of questions and run out of time. So Uh, thanks fred. I know it's late for you, but thanks for joining in Well, you're welcome and I appreciate the opportunity and I do apologize for our technical glitches So I look forward to see you guys all you guys in more in person in one of these days soon absolutely Thank you. Thanks everyone for joining appreciate it and uh, look forward to seeing you all on the 13th When we have the main event Thank you