Top 5 techniques for building the worst microservice system ever - William Brander - NDC London 2023

uh we're going to be talking about how to build the oh the top five techniques to build the worst micro server system ever I really like this image as a representation of microservices because you've got this this gentleman on a scooter it's a bit washed out on the projector but he's going really fast and he's not he's not hampered by any bloat like protective headgear or anything and the center of gravity is really high and the pivot point is really low and all it takes is one bump in the ground and permanent brain damage just like microservices so who am I and why am I qualified to talk to you about microservices my name is William brander I'm from South Africa and I know these South African accent can be a little bit difficult to understand at times so I will try and enunciate a little bit clearer than I usually do and I will try to speak a little bit slower than I usually do hopefully that helps and see for the mug I am the world's okayest programmer I'm also incredibly passionate about building bad systems I hope some of that passion is going to come through and energize the room so that we can end the day on a high note there are three things that I dislike about this mug the first is that the a in program is tilted ever so slightly to the side just enough to bother my OCD the second is that the font is dangerously close to Comic Sans without actually being Comic Sans because that would be sort of cool in an ironic way but this isn't it's just like a weird knockoff and then the third is that the mug is unfortunately unverified it it may surprise you to learn that there was not in fact a worldwide census done on developerability with me Landing Square in the middle so I went about looking to see if there's a there's other ways that I could prove that I was an okay programmer and I spent some time looking through my company slack and my co-workers definitely don't think I'm the best programmer either but at least one of them doesn't think I'm the worst so I've got that going for me but what does being an okay programmer have to do with writing bad systems right being an okay programmer means that I've probably written some systems that I'm proud of and some that I'm a little bit ashamed of but I'm sure everyone has written some bad systems does it has anyone not written a bad system before if anyone's hiring look around for hands now we've all worked in some bad systems so what do I bring to the table that that can Elevate me and I can really make it that I'm the guy to teach you how to write bad systems well that's got to do with who I work for I work for a company called particular software we make in-service bus has anybody heard of particular well we've got a booth outside so if you haven't heard of us we've done a really bad job anybody heard of end service but I hope everyone anybody using in service pass my salary so for those of you who don't know and service bus is a library and framework for building distributed systems so whether you want to build microservices or so or just partition your system and service bus can help you do that but that's not what this talk is about so what does working for particular have to do with making bad systems well at particular if you work on the engineering team you also do support There's no distinction between engineering and support which means that if you work on end service bus you support in-service bus and you support the customers that use ad Service Plus and that's honestly one of the more fun things that I get to do is is support because I get to see a lot of different systems applied in a lot of different ways at a lot of different scales and I get to see how people are using and service bus to build these distributed systems but here's the thing about support if one was were to assume that system quality follows a normal distribution where you've got some really poor quality systems on the one side and a few really high quality systems on the other side with most systems having reasonable quality sort of in the middle that doesn't really help with support because the people that have got the high quality systems aren't coming to support for help and the people that have got the medium Quality Systems aren't coming either because they can probably work out their problems themselves so the types of systems that I see when I do support are the ones down here and I see a lot of these in fact as far as I'm concerned based on my history with support it means that the distribution of system quality does not follow a normal distribution like this as far as I'm concerned all systems are bad and as an industry we should be ashamed of ourselves for what we do into our Pro customers to microservices right why do we do microservices the Consulting answer for why we do microservices is we want to decrease coupling so we can have independent deployability we can scale things up and down without bothering the rest of the system and blah blah blah blah nobody does microservices for that we do microservices so that we can increase complexity and decrease performance we do microservices so that we can come up with the most convoluted way to render angle brackets for a browser and most importantly we do microservices because we don't want to be seen to be doing a monolith right monoliths are bad if you if you start a project and say well I'm going to start to the model of architecture uh you get you get looks of Despair from your colleagues every new project is it's going to be a microservice architecture right monoliths aren't bad though they're good this picture on the the left-hand side left hand side is of the kailash temple in India it's carved from a single Rock making this the largest man-made monolith in the world the Erp system you've been working on for the last seven years doesn't come close he has a different picture of it with a slightly better angle you can see there's people on the probably in the way there there's people on the side on the left to give you an idea of the scale of this this is huge this is a massive undertaking they carved this from hand well I mean not from hand they didn't claw the rock where they had tools but they weren't electrical pneumatic tools this must have taken an immense amount of planning dedication work effort this is this has been a labor of love for someone and a whole bunch of slaves probably but it's beautiful monoliths can be beautiful don't don't think you have to do microservices because the alternative is model if it's there's a there's a spectrum and a whole lot of options in between as a side note could you imagine what this would have looked like if they built this using scrum the talk I'm going to assume that we have a system and we're now trying to transition the system into microservices and make it as bad as possible and we're going to see a few techniques that we can do with that so we've got a monolith it's a monolith so it must be bad so it's a tire fire over monolith and we're going to transition this to microservices and a typical technique and it's come up a few times at the conference already is to apply with something known as the Strangler fig pattern where you take a bit of functionality in your system say the charge credit card method you isolate that from the rest of your code and then you move that off to a service and then your main monolith can call the the new service instead of having to have that call in process yay we've micro serviced what have we actually done though to our system so if we apply this everywhere what is the result well let's take a look at the throughput of the system and how the throughput changes as the load on the system changes we'll start at the monolith so as the as the load of the monolith increases the throughput will increase as well at the start it'll increase fairly linearly and by that I don't mean one to one but there will be some like K Factor where as the load increases by one that the throughput will increase by Point somewhere between zero and one hopefully not zero and as you as the load increases even more that throughput should increase a little more as well but the rate of change of increase will decrease a little bit because the as the system is doing more things concurrently there's more handing over to different threads there's more exchanges you're waiting for resources so it will start to taper off a bit and eventually it's going to get to a point where the throughput is going to drop off completely and you might ask yourself well why what is the behavior that's causing this to happen and this has got to do with the way that.net does memory management so in.net there's three types of garbage collection events generation zero generation one and generation two technically there's also generation three or large object Heap but for the purposes of this discussion we can fold that into generation two and the way that garbage collection works is that when you're trying to allocate a memory in.net if there's certain criteria met.net goes and says okay I need to free up some memory let me go and do a gen zero garbage collection event and a gen zero garbage collection event is intended to clear up resources that have been allocated and freed fairly quickly so VAR X is a function VAR x equals ABC and then the function finishes the garbage collector can retrieve that memory and return it back to the pool but if the garbage collector tries to retrieve or tries to free up a bit of memory in gen 0 and it can't it promotes that to generation one so generation one is intended to be for longer lived variables a longer lived memory perhaps it's a it's a it's a variable on a class and the class sits around for a bit longer and does a few other things if a generation one gobs collection event runs and it can't clear up memory because something still reference in that object it promotes it to generation two and that's where the problem happens so generation 2 in.net is a stop the world event where as a generation 2 garbage collection event starts all user threads are paused in your app domain which means only the or except for the thread doing the garbage collection so all of your your other threads will pause and many years ago stack Overflow experienced this and Mark grave I wrote a blog post explaining why this happened and what they were trying to do to work around it these three big spikes over here are increases in response time because the Gen 2 garbage collection event was pausing all user threads in the application so the performance at these points was very very poor it's gotten a lot better since then after this came out we got the concurrent garbage collection configuration and now that's been replaced with the background garbage collection configuration which doesn't uh at interleave some of the garbage collection for Gen 2 and it more proactively gets uh gen 1 and gen zero garbage collection done so Gen 2 garbage collection now pauses and then resumes a little bit and then the garbage collection carries on in a different thread a little bit later so the pause in this sort of split out it's still a horrible experience when you're dealing with performance the service it does load as the load increases the throughput will increase the throughput will also increase at a fairly linear rate but it will increase lower than the monolith because you've introduced a network hop network operations are expensive which means that these threads that are doing the the processing are probably going to hang around a little bit longer so there's going to be more contention for resources which means that flattening off is going to come sooner and because they're hanging around even longer there's more chance that they're going to be promoted to generation 2 which means that drop-off is going to come even sooner so by simply Distributing our system we could have potentially made the overall throughput of the system worse the first rule of distributed computing is don't distribute your computing but we've gone ahead and done this and we've potentially made our the throughput of our system worse this isn't always true for instance if the charge credit card method was on the hot path and we isolated this and moved this off we could then scale that Hardware up independently but we're not going to do that we're just going to microservice the way we learned at the conference so we're going to do everything on one machine anyway so the first Technique we can use to mess your systems up is to put an HTTP call in front of everything who you are remembers when dotnet 3 came out with WCF right there there were those people going around everything should be a WCF class operation contract at all it's a great idea that was a that was a very weird time there was what wcfwpf wouldn't work for a foundation in Cloud spaces and quad spaces just sort of disappeared very quickly on in the in the evolution of net there Okay so we've taken our monolith and we've strangled a figged it until it's no longer monolith and now it's distributed we still have the same coupling between the components we still have all the same problems we had before we've now just made the performance lower so it's still a monolith that's just distributed um and it that means instead of a problem that we have with our monolith we're working with our models we've now got to also introduce Network topology coupling to that so that's another layer of coupling that we've put in there so it's not just the tire fire it's a burning field of tires this is a good first step um but this is difficult for us to work on this isn't a pleasant experience and we don't want to make our lives worse we just want to make the system worse right we want to enjoy our job so we go to business and we say um I bet you I can rewrite the system in six months did anybody find themselves thinking that I've done it many times at that particular I've even tried a few times you failed miserably the thing with big bang rewrites is that they don't work little asterisks in the air they work in two specific scenarios which I'll get to later but why don't they work why do big bang rewrites of large complex systems fail and that's got to do with how software works for these large systems so as you're developing the system we'll have another graph here we're on the y-axis we've got the functionality that's available in the system the amount of features that we've got and on the x-axis we've got the time that we spent developing the system and at the start of the system as you start developing it's fairly easy to add new functionality because you don't have competing components with each other you're still getting to know all the business rules that you have to work through you know it's a nice time to work this is the green fields area we all love greenfields projects right as we carry on working though the rate at which we can add new features decreases because we have to add features where we didn't really design the architecture to match that feature set at the beginning so it's a little bit slower to add the features we have to change a few things and propagate and there's competing business rules that we have to worry about but that's fine and then eventually it gets to a point where adding any better functionality takes a lot of time and effort potentially even just changing the name of a field on a form could be a full Sprint process to do sometimes so let's assume that at this point here this is where we went to business after we've done our distributed monitors and we said please can we have six months to do a rewrite after we've done the rewrite everything will be wonderful the UI will be modern it'll the performance will be better and we'll be able to add features before you even know what to ask for it'll be so good and businesses well okay six months I'll give you six months to do this and you're ecstatic because now you get to do new work again that's great so now instead of working on the old system for those six months we work in the new system so we're not adding new functionality over this period so this little section here that we would have added a little bit of value to our users no longer exists that disappears and instead we start working on the rewrite of our system and at the start of our system in the rewrite it's really quick to add features probably even quicker than when the first system started because now we've got better ideas we've been thinking about how we would improve it for a few months before we did the rewrite we know more about the business domain things are looking great here but it's not going to take six months how do I know it's not going to take six months well that's because I'm a developer and developers are really really bad at estimating in fact instead of doing coding assessments if you try and hire someone they should do estimation assessments and anyone who's really bad at estimating must be an amazing developer if anyone is really good at developing is probably developing really good at estimating it's probably a project manager and shouldn't be developing I myself and the world's okay is the estimator but even if you could estimate correctly you're still not going to take six months even if you your estimation for what you think the system is it's going to take six months is 100 accurate it's still not going to be correct because developers are also a bit like that dog from up where you get distracted by a squirrel and you run off the systems that we work on it's very very unlikely that any large system that we work on will be 100 documented even if it is there's even less chance that we'll have all of that knowledge sitting in our head while we're trying to thumb suck an estimate it's going to be very difficult to be able to get those guesses right so we carry on working we do our rewrite six months comes and goes and it's now nine months and business comes to us and says listen we we can't go on like this we we need new features we've got a compliance deadline we have to meet gdpr 2.0 or something the return um so you start panicking and your team starts working weekends working nights you order pizzas every evening for the team you've got a masseuse coming in to to massage the team to relieve stress and tension and you're you're just driving a role into the ground and eventually you're still not going to be done and business is going to come to you at a point and say we can't do this we you've got to cut this rewrite and you panic a bit you panic because now you've put a lot of effort into the new system you love it you're emotionally attached to this new design that you've got so you compromise and you say Okay business I'll tell you what got an idea we've still got the old system that's running in production right so we'll have that and then we'll also deploy the parts of the functionality that we've currently written or that we've Rewritten and then the users can use the new system for the stuff we've Rewritten and then for the ones we haven't done yet they can use the old system right but now we need to keep them up to date so okay no problem we'll put an integration layer between the two and and then then everything will be fine except we know that the integration layer is going to suck because the original system sucked and the longer that this integration layer sits in production that we have to maintain and fix the more chance there is of some of the bad elements from the old system bleeding over into the new system because it is going to be time pressure you're going to say oh I need to get this field into a report I'm I'm just going to copy it in in the same way that it is in the whole system it happens but anyway we're going to do this so we're going to have three systems that we have to maintain but at least now we can add new functionality for our users so we can meet those compliance deadlines or whatever once we've added that functionality we can go back and carry on with the migration right I'm sure business will give us time then they they will right please someone they won't well they might give you a little bit but you'll have to you'll have to scramble for it and that original system is going to live much longer than you ever thought possible it's a bit like trying to build an airplane while you're flying it I asked a stable diffusion to generate an image of an airplane flying while you're building it and I've got to say this is also a really good description of microservices it's terrifying so now that we after we've done our distribute distribution of everything the second thing that we can do to make our system worse is to attempt to do a big bang rewrite I said there were two cases where Big Bang rewrite works the first is if the system is actually small enough to be Rewritten in a reasonable time frame this is tricky though because it developers sucker estimating so how do you know that it's small enough maybe it is maybe it isn't I don't know it's unlikely it's also you kind of have to take into the effect in into a consideration that working on an old system that you want to rewrite is is unpleasant it's emotional so it's hard for you to be objective about how long it will take to actually do a rewrite so the first time it works is if the system is small the second time that all that it will work is for your CV so you start the rewrite and you do the rewrite in the most amazing technology possible and then a month after you've started working on it you go for interviews um and leave it works for you not for the project but that's fine so this is what we've got now we've got three systems we're maintaining and the longer that these systems are in production the longer the more of the suckiness we've got from the first system bleeding over into our new system as well let's make it worse we don't want to be malicious about it though so remember this situation where we had the dropper from performance because Long Live calls waiting for responses we don't want to do that in the new system right we we want to accidentally make bad systems not purposefully make them so instead of service a call in the credit card service because it's going to wait around for response and the same problem is going to happen what we'll do is we'll introduce a queue and then server say you can put a message on the Queue to say charge this person's credit card and once that message is on the Queue service a can end its call and terminate and then we're done right that means that service a is less likely to live long enough to get promoted to Gen 2 so we've solved that problem and everything's fine we then go to our credit card service which takes a message of the queue call Swift or whatever payment provider we want to use and everything's fine okay cool cool except now our message gets the front of the queue and this message says charge Williams credit card 50 pounds cool as we do that call though something goes wrong the network fails somewhere along the line uh Swift fails for whatever reason something happens okay but we haven't actually charged William's credit card yet but that's fine the message is gone well that's no good we've lost money for our customers right that's a financial operation that we don't want to lose for them so we certainly think okay um what we'll do is when we take the message off the queue we'll we'll process it in a loop and in that Loop we'll put a try catch so if something goes wrong we'll just keep processing it and that'll be fine and then we call Swift and then something goes wrong and maybe something's wrong on Swift side and they have to reboot some servers internally whatever it is and they come to us and say you you're ddosing those guys uh whenever something goes wrong you're just calling us non-stop you need to back off so you go back and you introduce some sort of timer mechanism and you say well okay this message each message can only be processed five times every minute yes perfect and then that goes into production and and Swift is at least happy with you there but then you get someone like William who puts his credit card details in incorrectly on purpose because he doesn't want to pay 50 pounds and then the message will never actually get processed because that's an invalid credit card number or maybe there's a bug in the code Upstream that generated that message and that failed but now that message is sitting at the front of the queue and everything behind it isn't getting processed and you're like well okay I know what we'll do we'll introduce a dead letter q and then we'll take that message move it to the Daily queue oh don't worry we'll also make software to manage the data queue and this is a really cool bit of architectural kit this is fun to work with and you're you're living for this this framework that you're making but it is a framework that you're making and in this case this type of problem is solved by poly and service Transit Rebus come on there's there's many options in the.net space that will handle this problem for you so but instead of doing that you're getting a lot of joy out of working on this framework you might even open source it one day that moment when you get your first star and your open source GitHub project it's oh so the next technique we're going to use is we're going to make sure that we suffer heavily from not invented here syndrome and every framework that we come across we say no we don't want to use that because it doesn't 100 percent meet our requirements we're going to make our own one and that's how we ended up with so many JavaScript front-end Frameworks a few years ago but we're going to keep doing this because honestly when you've got a system like this some of the only joy you can get is working on cool engineering problems and you're not going to get that from business problems usually so we've got our monolith we've got our new system that we're busy maintaining we've got our integration layer between the two and then we've got this really cool framework that we're working on at least one try for many I highly recommend it and at this point we're basically not delivering any business functionality at all anyway it's we're having a lot of fun on our custom stuff but not really doing much for the business so they're going to come to us and say listen we we need the search screen that you've been promising us for months please can you give us a search screen and you think fine we'll do it we've got a product service and maybe they're an e-commerce site they're uh they're Amazon no rainforest.com so they're rainforest.com and you can search for product or that you can purchase project Products off of rainforest.com and you've designed your product service to meet to match this requirement so you've got for instance the name of a product you've got the price of the product there's images for it whether it's in stock somewhere description uh the rating of the product you know fairly standard producty things we've all seen these types of things before and you come up with a class and a data structure that sort of represents this which looks a bit like this all those fields except it's got an ID yay computer science and based off of this you can go and implement the customer's search screen that they wanted so you can in your product service have a little search API pass in a text string and we'll we'll search the name in the description and split back all of the products that match and you pat yourself on the back and you go back to work on your framework now the business is satisfied but then they come to you and they say I've got an idea the correct response when business comes to you and says I've got an idea is for you to excuse yourself in the room say you want to get a coffee or something quickly leave the building get in your car and go home and pretend it never happened but you don't do that so business says I've got an idea we have a theory that especially on consumable items if someone has ordered a product before there's a higher likelihood that they'll order the same product again so can we maybe have a little field that shows hey you've ordered this before on the search screen and you you pause what you're doing on your cool framework and you you swing over in your chair and you you kind of just look incredulously at this person has asked you the most obscene question ever because the order status is not in the product service that's in the order service that's a very different thing but you you want to get back to working on the cool stuff as quickly as possible so you make them promise that this is the only time they're going to do this even pinky promise with him and they agree that pinky promise and and promised to name their firstborn child after you as well so you said okay fine so the product service once we get the request we'll also then call off into the order service just this once and and we'll go back to doing the cool stuff again I mean this isn't this isn't pretty you've made your search screen slow because now your product screen product service has to First query its database then query another service then put all the stuff together but it's just once it's fine right then business comes to you and says hey I've got an idea remember the correct response leave the room leave the boat and get in your car go home and denial denial denial we want to reward our gold customers and give them a 10 discount so special pricing per customer please and I mean at this point you may as well give up because they're going to come and ask for every single service in your system anyway so the customer status doesn't sit in the order service it doesn't sit in the product service it sits in the customer service so we're just going to start chaining all of these calls together and eventually we're going to end up with dedicated teams that can manage our API gateways has anybody worked with in an environment where there's a dedicated data Power Team and only they can make changes to your API Gateway it happens these API gateways can solve these problems for you but they can become another not can they are another layer of coupling that you introducing into your system a new sort of Technology you have to worry about has anyone seen this video if you haven't do it it's called microservices on YouTube by a channel called crisam it is the best description of this type of thing ever the the man's face it's like a mirror image of me in business meeting sometimes why did we end up like this though I mean we've got a product service it's nice it's concrete it's very neatly encapsulated we've got an order service a customer service look at these classes these are beautiful why is this not working for us and the reason is that people don't interact with products on your servers they don't they don't productize things they don't product key they search for things they perform operations in your system they don't perform things even if you're even if your your user is busy updating your product catalog they're still not producting they are updating a product in your catalog and having having the idea that a product service a thing service is going to neatly encapsulate and not bleed over into other boundaries is a bit weird it's like when you do a search on a screen it's like a puzzle that you're building you take pieces from different places and you put them together to make the whole puzzle although I've actually just realized the person is a really bad metaphor for this because it's always got the same pieces in the same places but think of something like that right you you you're taking information from different places and you you're putting it together in to build one experience for someone the thing is people interact with your system by doing things not by objecting so the next technique that we can use is when we Define our service boundaries we can make sure that they are designed based off of nouns and not verbs anybody working in insurance this is a big one that I see very often in Insurance space you don't have to put your hand up if if you are doing this but if you've got a claimed service or policy service you know usually usually that's a bit of a red flag and something to look at people well I suppose claims might work sometimes because you do submit a claim but people don't policy they they do a quotation they go through the order process their underwriting is a process their own policy Okay so we've got our three systems our monolith our integration layer our new system we've got a cool framework that we're working on ezel and we've made sure that when we defined our service boundaries they're all based on nouns so that we can maximize the chance of having cross-communication service calls between everything building another great monolith on that side let's see if we can make this even worse by trying to make it better right so we'll go back to that search screen well we don't want this right this is bad let's see if we can improve it what we'll do is we'll introduce a new service a search service to search as a verb we're doing something right yay we're learning the search service will be a dedicated service only responsible for searching so it won't have a product class it will have a search product class which has a couple new fields on it and if we if we need to change the business rules in the search Cloud search service we can update that right sounds reasonable how do we get the data into the search service well that's easy we'll Pub sub it right so what we'll do is we'll table tell the product service Hey whenever you update your product list publish an event for us please and then I'll maintain a search catalog and I'll update that whenever the product has changes okay and whenever the customer status changes also publish an event and then the search service can update its list and we can do the same for the order service this is an awful lot of data duplication we've got things in different places but we're smart we're Engineers we can explain this away right the source of truth if you use that phrase that's clever the source of truth of the products is in the product service right what we've got in the search service is a it's a different model it's a what can we call it a read model that's right we're doing a projection this is cqrs yay and we're using we're using Pub sub right so there's events so it's a cqrs and event sourcing and and services Services domains domains we're doing dddcqrs event sourcing this is a good system design Go technology we still have the same coupling problems here if the customer service changes the way that it rewards customers that has to flow through into the search Service as well for instance if the customer service says instead of rewarding discounts based on status we want to reward the top 100 customers our 100 customers will get 50 off the next 200 get 10 and then the rest just get an extra 10 added on because we want to help them monetize their way up into the into the stream right we make that change in the customer service we then have to make that same change in the search service because now the search service doesn't have statuses that we have to worry about that coupling still exists we haven't hidden it away and the the thing to remember here is that even though this is it looks like it's separate and it looks like it's decoupled the The View isn't the same so The Logical boundaries and the deployment boundaries the physical boundaries are different and we've cheated at the as if they're the same if we have a search service and it's deployed separately it must be separate from everything else right it must be decoupled but it's not I've always really liked this poster for episode one with Anakin standing there and he showed up rejected as Darth Vader I've always thought this was incredibly clever because we know Anakin is Darth Vader who is going to become Darth Vader but in this particular instance In This Moment he is not The Logical Darth Vader is different from the physical Anakin at this point in time so what I'm going to do now is I'm going to show you a technique that can make this previous situation a little bit better I don't want you to go and apply this because you don't want to make things better uh also because it's not a golden Hammer it doesn't work in every scenario so don't just go and say William said apply this it sometimes makes things better sometimes it's not applicable but it is a technique you can use to get rid of the distributed uh replication of data that you're going to build so what we'll do is we'll replace our search service with a search engine right that sounds that sounds more natural doesn't it search engine search service search engine and what we're going to do is we're going to implement what's known as the engine pattern so the engine pattern has some coupling in it but not logical not business coupling what I mean by that so the search engine will expose a contract that the other services must comply to so they'll expose for instance three interfaces maybe and I find product interface which given a text string will filter through a list of products and return them we'll also have an interface for eye price products so for a particular user and a particular product what discount percentage should they get and we'll have a third interface for itrack orders which just tells you returns true or false whether someone has ordered a product previously or not the search engine takes these three interfaces compiles them into a dll and hosts it on the internal nougat feed or something like that the product servers the customer service and the order service can then download that nougat package and Implement whatever interfaces they want so what I mean by that is that the product service can implement the product finder class and the product finder class knows how to query the product service database I hope it's clear that the product finder Clause sits squarely within the logical boundary of the product service the customer service can do the same with a status pricer and then the order service can do the same with a order history class so all of these in classes implement the interface that was exposed by the search engine and they're currently sitting within the service boundaries that they're implemented in and this is great how do we wire this up together though so what we can do is we can take the product finder class compile it into its own assembly and then take that assembly and stick it in the app folder of the search engine and then when the search engine runs and it needs to do a search it can ask.net hey.net give me all of the classes that Implement I find products and don't know will go oh he has one it's the product finder class there you go the search engine can invoke that product finder class which will then go from query the product database because it knows how to talk to its own database and then we can do the same from the customer service you can take the customer status pricer and compile that into a dll copy paste their dll into the search engine folder and then the search engine can apply that to the products that it's got from the search result and we can do the same with the order history one we can track what the person is ordered before how is this different from the previous one we're still doing three sets of queries right well if this if the customer service changes the way that it does discounts and it goes away from status and and changes over to ranking the customer service deletes that status pricer and creates a new class A ranking pricer compiles that ranking pricer into a DLo and paste the dll into the search engine folder now the search engine when it does a query and it tries to find all of the prices the high price product instances it doesn't have the status price anymore it now gets the ranking pricer the changes were constrained logically with Indie customer service physically though we deployed a different assembly into a different runtime but that's not really a big problem the interesting thing with this type of pattern is that you can apply uh you can apply things that seem like they come outside of that domain into different domains so for instance the product service could Implement a daily pricer maybe every Monday these products get a 50 discount that can get put directly alongside the existing pricer the same with the order service it can create its own bulk history pricer where if a customer over the lifetime or the customer's account has ordered 99 of these items on the 100th item they get a 99 discount that can also just be deployed alongside and all of that sits and resides logically within those individual service boundaries physically we've deployed it somewhere else but logically it's separate I always find it interesting that when people consider this type of idea that it kind of it feels weird to them like we're putting these things together we're coupling it right but this type of distinction between logical and physical is fine when you're talking about scaling out instances we'll take the same code and run it in two places that's also physical differences but the logical logically it's still the same thing so don't do this in fact what you need to do is you need to make sure that you conflate your logical and your physical boundaries for everything that you do in your system so a quick recap what we've done is we've put an HTTP calling in front of everything we made sure to attempt a big bang rewrite note I didn't say do I did they I shouldn't do that oops we didn't use any official Frameworks we created a whole bunch of cool Frameworks that that we get joy out of we then also made sure that we use nouns instead of verbs when defining our service boundaries so that we can get the maximum chance of having cross-service communication and in the places where we have cross-service communication we made sure that we made we kept the logical and the deployment boundaries the same throughout the entire system and if you follow these five techniques you'll have a great time looking for a new job somewhere I'm sure I did say I would get you out of here a little bit early and I'm pleased to say that I did that if you have any questions you can ask them now otherwise you can also find me around NDC I'll be here tomorrow and maybe a little bit later I'm always excited to talk about right and bad systems so if that's a if that's a common interest we can we can write bad code together any questions no okay great thank you everyone [Applause]

Channel: NDC Conferences

Views: 178,287

Keywords: William Brander, Microservices, System, Archtiecture, Fun, Netflix, Uber, NDC, Conferences, 2023, Live, London

Id: 88_LUw1Wwe4

Length: 40min 43sec (2443 seconds)

Published: Tue May 23 2023