microXchg 2018 - Microservice Patterns & Antipatterns - Stefan Tilkov

welcome everyone to this talk about micro-services patterns and anti patterns it's kind of a brave thing to talk about at a conference that is exclusively about micro services I do something like this at a conference that's not only about micro services assuming there are such conferences anymore then there will be a number of people who don't know anything and they will get some value of some introductory stuff that I do not planning on doing that today and so the risk is that I'll talk about some anti patterns that you consider patterns or the other way around we'll see so my goal is to talk about words that's actually what I talk about patterns is about right the patterns talk is about giving names to things and that's actually something that I like to do because it's a good excuse for coming up with a talk topic and it also helps me talk about things to my colleagues to clients to people in the industry to people at conferences and I like this idea of having a shared vocabulary where you can talk about things with common names so that's what we're going to talk about talk about some patterns and some anti patterns for the patterns I've chosen a very very simple format so I'm not providing with a pattern language of some kind it's not formalized you might argue maybe it doesn't maybe not everything qualifies as a pattern but I don't really care so I'll just go about it and have the same format everywhere so a pattern always has some sort of description and it has something about the approach so how do you go about this what do you do if you apply this pattern and what are some of the consequences if you do so so to make this a little less theoretical let's start with a first pattern it's called microservices you might have heard of it so a microservice and is something that of course is any hypen be defined in many different ways this is the way I and many of my colleagues like to define it the idea here is that we design modules in a way that they are separated from each other and something that used to be an implementation detail becomes some very important aspect of your software architecture right so we would do this to get more and more degrees of freedom for our implementations so that we can do different things right so technical deployment architecture becomes something that you very explicitly do as part of designing your system right network communication gives you a boundary between those things so it isn't as easy as it used to be to violate those rules you build those modules and you don't just have to do the right thing you actually are sort of encouraged to do the right thing because it's harder to do the wrong thing to cross the boundary right it makes a little harder at least it should and you can have some consequences arising from this which are I'm not going to go over all that because you all know that and you believe it otherwise you wouldn't be here right ok so now what you can see here is that the way that I've chosen to phrase this is my specific view on the thing right so you might you might have a different view on what a micro-service is and in fact I'm going to be talking about some different kinds of micro-services specifically based around the size of microservices which i think is a very important distinction so I've given different names to different sizes of them and you can also see my personal priorities in this right so I like to make this very explicit it could argue that essentially if we if we just did things the right way then we wouldn't need microservices with this with this definition right if we just all built modular software everything would be fine but we don't so we need microservices please that's that's money now that is an example of a very technical pattern or we'll a somewhat technical pattern at this particular level we're talking about it's like a textual thing we can also raise the level a little this one's too to a different level this would be something like evolutionary architecture right this is now something that's more general it's a generalization of the micro-services pattern you could have lots of different things that qualify as maybe having an evolutionary architecture so what this means is you actually don't try to come up with with an architecture that's the right one try to come up with an architecture that can always be changed to be the right one at that particular point in time so you built evolution into your decisions or evolute ability I don't think that's the word but it should be right so we have the the possibility to evolve it and to move it forward now to do that we maybe probably have to separate things and in some way give those give us this chance of changing things independently from each other so we have those islands a change maybe we design so that we can easily replace something as opposed to having a focus on reuse this sounds a bit sounds suspiciously like micro-services right but you don't necessarily have to do something like micro servers to do this you can do it I'm a general fashion try to minimize shared dependencies we sort of put the put the put the lever in a different position but I have a pendulum swinging and the other extreme to say well reuse is not the most important thing efficiency is that the most important thing it's rather autonomy redundancy and the idea that we don't share so much that it slows us down and you can you can think of this as something like like the cells that the body is composed of right oh we all are the same person that we were 15 years ago to a certain degree I mean we're not we're still the same individual but we have changed but we still are the same person so that's kind of the obvious the feeling that we want to have for our systems as well they should be able to evolve they will change over the course of time none of the cells will be the same none of the individual parts will be same maybe not a single line of code is the same but it's still the same system because if it weren't you'd have replaced it and some sort of big bang operation which is something that we all want to avoid so those are just two examples of patterns right of course I've anti-patterns as well any parents follow a very similar format now they have some sort of description there is a reason for why I believe this happens not the reason for why it's an anti-pattern it's more reason why why this occurs why if it's an anti-pattern do people end up doing it it's not not an obvious thing sometimes and of course it has some consequence those are all the bad things that are that are the result of having this having this anti-pattern occur now a good example of an anti-pattern is a micro service so I'm going to call it micro-services gone bad right that will be the dreaded distributed monoliths where essentially you go to a conference and everybody tells you the microservices are awesome and then you go back home and you build something and you turn it into micro services and it ends up being something bad that is known to happen now to paint this in the most negative light that I can write you just come up with some arbitrary mode of sight of slicing things into smaller parts and you just put them together somehow and you end up with this giant mess of things that is just combines all the bad things from all the different approaches that you know right so it's a distributed model at the worst time it's called hype driven architectural conference given different architecture again it's it's not something that any of us would do right with all the others going to the conference's end up doing that typically you end up not caring too much about the business domain this is rather the situation where you end up doing it for the sake of doing it right because it's kind of cool to build something using micro services so you end up doing it this always goes hand in hand with getting lots of infrastructure components that don't serve any business value but rather give you technical solutions for problems you wouldn't have if you didn't whatever right so that's kind of a sign this massive over-engineering that you see where people invest in dynamic rebalancing registries and they make component load balancing proxy equalizer things whatever and end up missing what the actual business domain is now the consequences are obviously that you have this ripple effect of changes right you change something and if you get all the negative sides of a distributed model it so if you change something here something else falls over you get this very very complex environment where you now have lots of extra problems because you have all of this Network overhead both in terms of runtime overhead as well as the thinking time over a development time over because everything is now so absolutely complicated you have in the negative extreme this wild mix of technologies that nobody can manage because everybody can do whatever they like they do whatever they like and they have fun but you don't assuming you're the one tasked with maintaining this stuff again sometimes you can see the same thing painted as a pattern and as a nanny pattern that's something that I thought I might do again we'll see so let's go into more detail on the level of detail that I want to talk about so my first anti pattern I'm gonna start with e with the negative things to leave you and on a positive note at the end so starting with the negative things let's talk about this decoupling illusion now that's something that I've observed a number of times people introduce microservices for a reason very often the reason is that they want to be more flexible and be more agile on B but able to more quickly adapt to changes so you split things into those smaller things because a small thing is better than a big thing and I tend to agree as long as we're talking about software so you have different kinds of stakeholders look at this thing and now something interesting happens you have some stakeholder some businessperson who wants something and for for you as a developer or architecture designer to to actually fulfill their need you'll end up having to change something might people this you know these few micro services that you will have to change you can probably see where this is gonna lead because there's a second stakeholder who's involved in a different said the micro server visit this some overlap between the two it's just with this one micro service that both are interested in still you have to you have to take care of the fact that both of them want something from us a micro service you'll end up having different needs for this particular thing and of course this can get worse if you have more stakeholders so at some point in time you'll find out that you haven't solved the fundamental problem that you want to solve in many occasions which is you want to isolate the stakeholders you don't want to come up with something that is small for the sake of being small it doesn't help you if it's small and sand and in its own module if it can only be changed together with a number of other things that are also in their own modules because you're fooling yourself you just you just have one system they're all they all evolve in the same at the same speed you all release them at the same time you have all the same problems will you actually you actually have some extra problems now because it's all distributed right so you've made your life worse in this particular model I'm not going to go over all the textual descriptions I've put them in so that you can read them afterwards if you want to essentially the goal is that I'll always say what's on the next slide when I go to the picture slide right so this is sort of the description that I just gave these are some of the reasons that you end up having this of course it's very often because we're very much driven by my interest in technology I personally am very much driven by interest in technology so I want to apply something that I've heard of and try it out and looks like it's a cool solution when everybody can build their own little service and doesn't have to care about others until they find out they have to care about others right so consequences I think I talked about that now that is something that I'm going to come back to multiple times this question of size and the granularity of his services so so bear that in mind but there's also a different could say orthogonal stakeholder aspect here which is my second anti-pattern which I like to call a micro platform now if you consider the different stakeholders involved in your in your architecture there is another one about this maybe not that obvious it's this one did you did you see that it's a little grey box that just appeared in one of those anybody have a guess what that could be does this help at all right so essentially that's your magical platform that's your supporting libraries that's your runtime that's your micro services stack and it has its own stake holder which probably is your architect and that's actually the person involved in everything now now if you build something like that then you have a stakeholder who is interested in every single service and who everybody has to sync with to do something right this might be because they provide you with this great little library that validates your authentication token right in there they just assume that everybody uses that library right just very right to do that well unless you if you reconsider they're actually forced the technical dependency on you and now if they update the library and expect everybody to run on the newest version of that library everybody will have to update to that newest version as soon as it's required by the overall landscape which is exactly the opposite of what many people associate with a micro services platform so you could argue that's a key anti-pattern don't have the same platform in every service which probably tells you that things are in this black and white design as I like to paint them here right again you have a standardization of some runtime aspect which like many things seems absolutely reasonable in the beginning of your project right because otherwise everybody would end up inventing the same thing why would you do that right you want to reuse well now maybe you don't at least be careful and then give these things as options is something that people can use if they want to but not as something that they have to use and that you rely on them actually using right so reasons think I've mentioned that I've also included this little anti-pattern hash in a different different slide deck I have a have old set of slides on the main allergy which is one of my favorite high level anti patterns which is actually the fact that many of us like to play with tech and not so much with the actual domain so we end up building stuff that's fun in a technical sense and then and the polluting everybody else's code but it's fun so it's fine yeah probably mentioned that the bottleneck thing is kind of something that occurs reoccurs all the time and here it's something very very explicitly associated with a development time right with a development time you have this particular bottleneck because now there is a single team or even a single person who's responsible for this particular library that everybody depends on or this particular runtime platform and now everybody has to has to go to them and and expect to queue when they have a new feature that they want in that particular thing now that's that's one example it's a very technical example right but there's an also there are also examples like that in the domain aspect of things my favorite one is the entity service right so does anybody here have a service that's called the order service does anybody have an order well you don't raise your hand but I actually expect a half of you have an order service right now that sounds like such an obviously useable useful reasonable thing to have if you're in any sort of retail application or any sort of logistics after something that has something to do with orders right because now everything can use or reuse that particular service and it seems to make so much sense the problem now is that everybody who has a need of something that particular service will will actually enforce that need on that will force their needs of the particular service so it'll end up being a mixture of the interests of the aspects of all its clients of all its consumers sometimes that's exactly what you want very often it's not very often when you look at the thing it actually shouldn't be there in the first place it's only reason for existing is that the word order appeared in multiple different contexts so this is something that well let's just agree on what an order is right this polder people will remember that as then you know enterprise data model kind of that everybody agrees is a bad idea so I suggest any time you see something that smells like an entity service take a very close look and decide whether it's actually something that you need right because very often you find out that actually all of that stuff belongs into the clients they all have their own view on for example in order they might be well the fulfillment part of an order is very different from the bellying part of an order so I've just moved the stuff that used to be in the order service to the place where it belongs to that particular service that actually does something useful with it and then you'll have maybe some of that stuff there maybe even disappear completely which is kind of perfect because as soon as you have something that's called an entity service you've introduced some sort of layering could have made that an anti-pattern I decided not to but you know the layering is the the key point of a layer is that it cuts through your business logic and one of the key ideas in might be of micro service is to have that business logic contain one particular place so that you can change it independently from the others so very often you have that service boundaries that cross entity or the are aligned with entity boundaries and those entities are very often weighted fat it's it's a very well obvious or you could call it naive approach to the main table modeling that that often leads to you ending up this way so you have to think a little bit more about this whole thing actually if you what if you want to go all academic you can view it as a violation of the of the interface segregation principle which is a very one of the solid principles it's actually the principle that says don't make your interface too wide because the many people will depend on the interface it's exactly what we did with an entity service run it had a wide interface because it has like 200 attributes on order because now everybody can depend on it which is a very bad idea and it bottlenecks somewhat related to that is the next handy pattern which I like to call anemic service right it's it's not 100% the same thing but it's pretty close if you look at the typical layering that would be some sort of layered application then you could decide to have your service boundaries at the very low of the lowest layer right that would be like having JDBC in disguise it's like giving everybody access to your data just directly if you actually give everybody access to your data then I don't know please be smart and call it a day or Lake or something but if you actually do that as a service boundary then it's probably not a very good idea that was a joke by the way don't quote me on the data Lake part so in this in the same way that you wouldn't give everybody access to your database you shouldn't be giving them a service that allows them to do the same stuff most people agree that this is not a good abstraction you don't want to just wrap your database table or a collection in a service many people do something on this level though they built something that's reusable but still very low level it's on this order service level right it could be something else could be a collection of related things but it still doesn't you it doesn't do anything that's useful to the actual end user it does something that only makes sense if it's orchestrated if it's composed if it's used in some meaningful way and my ideal service would sit on top of that it would actually be a useful and specific service this is sort of a relation we'll get to that here between reusability and uselessness right because it's if it doesn't do very much it's reusable in many circumstances and so I'd rather have something that is very very useful but only one particular circumstance that's that's fine with me I don't I don't care much for reuse anymore okay so I'm not gonna read all of that maximises reuse at the cost of having uselessness and it's related to this a pattern of over generalizing alright so if you if you take a look at naive object modeling then many people come up with with objects that are way too generic it's like all those probably up everybody who really got into object orientation at one point in time rather started building some sort of generic thing machine you know something that's really cool if it you can do it can do everything for every kind of enemy there's a there's a this is sort of a this lying thing here you can you can start with something that's obviously very useful like say you build a service that doesn't some aspect of your invoice handling and you have another one that does some direct marketing stuff and those are very very different and they clearly have have purpose and meaning you built useful services and there's nothing wrong with that now if you look at them you might you might notice that both the invoice handling and that our marketing has something to do with email right so maybe you extract that email park from which still I think is a useful idea and it's sending email to be done different ways maybe this into the general abstraction here maybe you could extract something like templating where you can combine a forum letter with some net data tumor to do a mail merge kind of thing and then send that could be done in both maybe right so yeah okay printing hmm I don't know do you want a printing service I have a feeling my operating system already already has a printing service I'm not 104 maybe yeah what about a spell checker so now now imagine this little red squiggly line that underlines the words that you've that you've misspelled do you want to have every every keystroke go ahead a service somewhere and come back with them yeah I don't know maybe maybe I'd rather have some something gives me the dictionary back and then I'll use it locally because that sounds more reasonable I don't know you can see it's a slippery slope right you you you start with very useful things that make sense and then you get to the stuff where you maybe have something like a hash table make sure you can have a hash table service where you maintain all paddle maybe it maybe it exists maybe it's called Redis or Cassandra I mean you could but if we go to this level like we have now we concatenate a string and that's a you know at some point in time it gets real it becomes ridiculous and this as I said sometimes it's more useful to have something built something locally and you just use that as opposed to trying to come up with all this fancy service stuff again gonna skip over the textual description here another thing this is more of an organizational kind of thing that the main last approach this is something that I noticed in many organizations where you have these structures of having business units and you have all the developers and then you have different groups for different aspects of your systems right where essentially all of the organization is is modeled in a layered fashion right it's like you know it's not as if the use of these of a domain structure in the individual business units are the driving factor it's more like well everybody who knows how the program they obviously go into one group because who knows how to deal with those programmer people so let's just have some lead programmer and then they'll they'll do whatever they do I don't know but in the end you end up with the same problem that I had before right you have those different stakeholders interested in different things that require collaboration between these different units and they'll they'll actually compete about the same oh I hate the work with the same resources right there they'll compete about the same people about the same about the same capacity now I think if this were kind of in a different way then they might be actually able to actually be able to accomplish something that's really they're mostly gonna spend their time in meetings so yeah maybe don't do that yeah that's an ideal and of course this is a nice nice way for me to move over to patterns right I've spoiled your day but all of the negative things so let's talk about some positive things so my first pattern directly addresses the one that I just talked about which is this idea of aligning the organization with the actual needs of delivering something digitally it's if the if all of this computer stuff becomes important if people who know how to work with computers are now no longer stupid people we rather not have if you know if if if digitization is actually something that we want to do then maybe we want to align or organization so that they can actually deliver something locally maybe ideally you would like to have our have our systems or system boundaries match that by this idea of having this autonomous cell that's what I like to call it this this autonomous unit that can actually deliver business value on its own seems extremely powerful to me it's not a new idea I feel if you listen if you read up on this banner Fogle's interview from white a decade ago essentially this is exactly the idea that you have this this team responsible for delivering business value to a client and if they do it manually or using doing it or if they do it using some technology it's their decision right there in the position to make that decision and I think is the most empowering empowering idea I find it way more empowering than getting to use my favorite programming language because in this way I can I know actually know why I'm doing things not only motivated by with which tools I do it I'm motivated by what the result is that I provide I think that's something shared by most people now of course if you if you look at the difference between those models right then I'm very well aware that this is the default in basically every large organization especially if it's older all in like ten years right but you can see some new things starting up that actually look this way right this this autonomous cell way a new modern company so you can see many existing companies moving towards something like this there's DevOps or whatever you want to call it model okay now I promised that I wanted to move to the sizing part of things and that's actually one of the whole separate section because I think it's a very important thing and I think we need to have more discussions about this and that's actually one of the things that has driven me crazy about this whole movement for for a long time now which is that the name is so stupid I mean the micro-services name right does everybody agree that my cursor is a really stupid name I know who came up with it I think it's it's really sad because it makes something that is just one aspect a key part of the whole thing I would've loved a different term but it's too late for that so we'll have to stick with it so many of my sizing patterns are sizing patterns for things that you cannot really call microservices anymore but I don't care and do it anyway so let me I always start with an example it start with this slightly contrived example of a set of collaborating services that compute a value right these services in my example here compute a price it's a price for something that you maybe want to sell online and then this all of these services are responsible for just providing one little little aspect of the whole calculation so one thing you take a look at the weather and if it rains apply a special rain discount and another one we'll take a look at the client ID and check whether the client is some table that makes them an a client and then reduce the price by five percent whatever right this each of those little-little services just one tiny thing and they all collaborate and maybe do the day in a sync fashion using some sort of very very lightweight even bus infrastructure I'm not talking about an ESB monster I'm talking about you know some some high speed in memory kind of thing that connects all of those things and maybe you have a tooth that you have two thousand little calls of something where all the state is passed and you get something back I like to call that FAS stuff my invention that would actually be a function as a service model right we're each of those things super super small and stateless just a now if you look at that you could argue that this is actually the only thing that merits the name microservice doesn't really micro but micros typically associated with something else that'll have to call it nano or as I did here function has a service whatever typically over silver simplifying here triggered by some explorative events that may lead to other events that may trigger other functions that may compute something and put it somewhere maybe on some event queue and then you you have this these very very few things ideally written in a fancy language that lollies to get we get things done with two lines of code as opposed to Java whatever it's not as bad any mail so this is actually something that some of your respect a lot Fred George has been talking about even in this conference and this very very tiny kind of thing you can see the same approach in AWS lambda you know the service frameworks where essentially you have this very very small collaborating things if I want to put a negative spin on it I call them Oracle database triggers in the cool version but whatever now the consequences here are all these things collaborate to to give you something right they they share a strong dependency to be the AWS infrastructure it could be your whatever your event bus in your your contract here is you may have the same interface used multiple times to invoke different services maybe through some sort of eventing mechanism could you could say it's maybe you can map it to actors or something but I'm not going to go into that you could talk about emerging behavior or if you want to spin and negatively what the hell just happened just because if you think of it this is well just you know events occurring and then some other event is occurring and then some event handler is being cold that may become creates an event somewhere or just something that creates an event whatever you know something appears out of the blue and that's kind of cool actually actually I think this is I'm probably painting this in a way to battle light that doesn't probably doesn't do it justice and I'm frankly freely admit that I don't have much experience with this model I have I'm kind of skeptical about its usefulness even though I think it's really really cool one of the things that Fred applies it to and has talked about very very convincingly is this application to fuzzy problems where you have a limited time window maybe like a hundred milliseconds where you can have multiple engines competing about contributing what the right extra offer to show you with your flight booking is right and then they'll compete and then somebody wins and you get something and then if the outcome is more bookings of that service then it's it has been worth it well not maybe not for you but for the company providing you with that service right so that's kind of a cool approach so first it's so I think it pretty rarely applied approach but maybe it's gonna become more a big bonus with the with the surrealist movement and it's I think well-suited to a particular kind of problems now the second one the second example is this one now we're talking about my example a product detail page could be some ecommerce set up where you have a bunch of services that provide you with different things with maybe different kinds of information like in my example here the core product data and then maybe you get some description and some images and related content and some recommendations whatever it is that make up your your information that you need for that product details page and maybe have some coming composition going on here some service that calls a service that calls another service that and the result is mixed together and then you orchestrate the whole thing together to build up this composit page that includes all of this information from all of the different places I like to call it a micro so ah it's sort of the micro services services oriented architecture which is kind of stupid but I think it sort of captures the fact that it's very similar to an approach that used to be popular while ago and that's I think the most the most well known the most widely used version of micro services happy to be proven wrong here and love to discuss with you about this the idea here is those things are small and self-hosted they're not micro they're maybe not a few dozen lines of code they're more like a few hundred a few thousand lines of code they're still small they typically are containerized because everything is containerized these days they typically have this cascading streaming model we use some technology to make it easy for you to maybe talk to three services and get the results and version together and start delivering the results your to your upstream caller before all your incoming results are there I'm sorry we built these these things and that's probably most a best-known because Netflix is a big advocate of this approach there are others as well you can find numerous examples of this now this is really hard for me to to explain but I have a very ambiguous relationship with Netflix I love the company I'm a very satisfied customer I spent basically all of my TV time in front of Netflix I also love their tech and I love the people that they have talking about it there is super super smart amazing people there also completely useless as a role model for most of you and most of us because most of us are not in the business is building a video streaming portal it would be cool if we were but for now most of the time at least maybe maybe some of you are and now my my my statement my claim is that Netflix is architecture works extremely well for Netflix but that does not mean it works for anybody else you really have to look at the individual situations if that is your role model for your micro services architecture I claim there's a high chance it's gonna fail I'm not a big fan of this model I think it has a huge number of positive aspects ult's but it also has some downsides and you should be aware what you're doing here and some of the consequences are you have this close kind of collaboration you have this idea of a common goal you want to live or service in my example it was this product details page that's that's something that's assembled from all of our services but because you have now services that call services that call services you need to deal with the complexity and with the risk to the stability which is why you introduce fancy patterns for resilient patterns to address all of this stuff you also have wonderful problems regarding versioning and compatibility because you now have those this network of complex service is all calling each other where you know if you multiply that with all the versions of this thing that you have to keep in existence makes it a really complex thing which leads to a superbly high infrastructure demand you really have to have a very very cool environment to be able to do that and if you're in the business of building very cool environments that's kind of a very satisfying proposition to building here it's often combined with all this parallel and streaming kind of stuff and to to also make very clear why I think this is sometimes an excellent idea I think it's really well suited if you have extreme scalability requirements if that's your major factor if that is the reason why you're doing micro services for run time scalability then I think this is a very cool mop now in my experience that may be selection bias because I see we see certain clients certain people that work with us in my experience the reasons for many people the reasons if reviews are you doing micro service for many people people are different very often they have something like this they have some complex business application maybe logistics application that's composed of different parts and now there start noticing that they have all of these columns annoying meetings with with people who want other things and it's kind of I don't want to meetings I want to build cool software so I start up I start building those isolated places where I can actually do something on my own without having to deal with too many people at the same time so I end up having those things where I'm except some redundancy I maybe have some sort of inventing mechanism and I actually make sure that I have isolated parts that actually leads me to something which in the DDD world is called a bounded context and if I combine that with micro-services I get the DD DD pattern which is distributed domain-driven design I like that term and that's the next pattern now I think that's a oh yeah I have to mention one thing one nice thing here or one important aspect here is that there is a separate front-end right up made a point of putting there there so it's where you're talking about back-end services with a front-end that combines a lot of stuff and now we have those individual contexts the idea here being that each of those things is still small but probably a little bigger but most importantly it can do its own thing on its own it doesn't rely on synchronously calling to other services communication between those things typically occurs asynchronously by events and the front-end calls if you recall the front cults occur when they typically stay within one of those things yeah hopefully right so we end up with redundancy we end up having to manage that we're done in Siebel we gain is more autonomy more independence of those individual units right you accept that you have store something redundantly and then you actually implement some logic redundantly there are a number of clients I can't talk about ours to do that but I'm sure you know many who do that if you have some public examples for me I'd be happy to add them to the slide I think this is really a different way of approaching the whole thing many people do this I'm not claiming this is this exotic or anything many people do this do it this way they use bounded context and they make every service at most two speakers about a context at least as big as an aggregate and then you end up with a with a reasonable sized big kind of thing that can do its own stuff now this is I think the first one we explicitly want to manage loose coupling at the level of the hole you're really trying to to get those things to a science where they become autonomous units of their own I think it acknowledges this separate evolution it's really a different motivation the key motivation is not scalability it's trying to come up with those boundaries between groups the async approach increases stability of the whole things because you don't have these call stacks of remote services calling each other and I think it adds and emphasizes parallel development right so I'm a bigger fan of this and I've seen it applied successfully a number of times now if only there weren't this one thing that I'm always so annoyed about in fact two years ago I did I talked here about that easy UI thing and whether any of you were here but you know there's always this assumption is typical back-end architect assumption that the front-end part is the easy part yeah it's not that's the assumption that's reality the front-end part is not at all easy in fact I think the front-end part is the harder part it's the more important part it's the part we shouldn't be ignoring but many O's are ignoring it and I've actually turned it into a anti-pattern of its own it's the fun at monoliths right you have this fancy back-end micro-services architecture fronted by a front-end monoliths now if a problem out front at monolith is built by one or two people I'm fine I don't I don't think you should split something into micro services that can be built by two people but typically it's not typically in a large system you have a dozen people working on that front end all if with all of the downsides that model is have not going to go through all of them but very briefly you end up with something that it has all of the downsides of a back-end model if it has over in over reliance on one particular framework from one particular vendor and just because that vendor is very famous and you know because everybody knows and does not at all mean that their framework is gonna be there two years from now even if it has the same name in just a different version number it might end up being a completely different framework so maybe don't depend on that in the same way you no longer want to depend on back-end frameworks which leads me to my final size example and if you've seen some of my colleagues talks you probably know what it leads to and on my example here is an e-commerce site and I can see the type that I've added this part down here which is actually supposed to be the front-end part now if you look at an e-commerce thing at a larger scale then you not looking at the product details page but rather at the next level you can see different sort of vertical slices through the application maybe the part where you register and maintain your account and maybe the part where your browse the catalog and then maybe the part where you check out now actually each of those parts can have their own front-end and the finance can be connected right the idea here is that I do from an integration have maybe a link to a different system integrated here or maybe I have something embedded from one of the other systems it call this pattern the self-contained systems and it's essentially the next level in size where it's a little bigger because it now includes the UI part otherwise it's very similar to the dhih dhih dhih dhih part that i talked about a few moments ago it has you IND B and it's possibly composed but I'll get to that in a second you can also see a number of examples of that I claim that Amazon does something like this I may be wrong because of course they don't use the word but I think you can notice it some points in time when you go when you go through Amazon comms website and you go from one one part to the other you can notice that the UI changes somehow I'm not talking about the AWS mess I'm talking about the e-commerce part right where you go from from the looking at the product to the checkout part where it's sometimes that sometime it seemed a little more modern because I think it was billed a few years later in the other part I think that's an instance of this model there are a number of other companies and we also have a builder website there it's a public web site where you can contribute it's not copyrighted or associated with any product of any kind it's just the idea of building things this way now we have larger systems independent systems including data and UI we were able to autonomously serve the requests that come in and we have this lightweight integration typically front-end part no need for the fancy stuff up meant that an add some eventing to it which makes sense because of the redundancies but it's not the key part it's not as if they all communicate using events all the time so you don't need any extra infrastructure and I claim it's the best suited model it's extremely well suited if your goal is to separate developing teams but if that's what you want to do then that could be a very useful model for you to apply now I've given you four different sizing patterns but of course first of all this is extremely simplified because there are lots of gray areas between those models right back and 2/15 patterns so I'm just doing a limited number and more importantly possibly you could actually combine them now that's a good excuse to get that beautiful fractal fractal in there but essentially what I'm trying to say is that you can have a building block that includes that's built of building blocks that are built of building blocks so in that model that I just talked about you could have a self-contained system or a number of self-contained systems and then those self-contained systems could be composed to the next level maybe some of them are built in the Netflix style microservice so approach and another one is built maybe in the end the service style essentially you you can make that decision on every with every single box you don't have to do it the same way in all them you don't have to have the same hierarchy at each level you can start by splitting something into five of the big ones and then one of them is complex enough or maybe has scalability requirements that make you turn it into something smaller now why I'm so when I'm so going on so much about the size thing I have a strong feeling that if you're only structuring mechanism is one of the smaller ones you know the service part the function is a service part or the micro service Waupun that's gonna be tough if you're looking at an architecture that's composed of 2000 things that are sitting next to each other it's gonna be hard to understand so I'm advocating of having a little more structure on top of that not suggesting big upfront design I'm just saying you know things a little cost through them I have a final pattern that I think gets lost sometimes maybe maybe we're mature enough to not have it lost all the time the final pattern of course is the monolith because if you look at the size thing that I did I started with a very spirit of the smallest with the finest granularity if you compose a system into just functions best it's gonna be a lot of functions through the system is big and then I made the pieces bigger so we have fewer and fewer pieces until at the very end we just have one in this discussion which is maybe just perfectly fine for certain scenarios what because the monolith has benefits the monolith is highly integrated very cohesive you can load in your IDE you can look at it as long as it's as long as you can handle it it's it's really really nice it's a standard application internal bug that bla bla bla you can you can probably think of this I think it's ideally suited for many cases still again I don't think anybody really claims that everybody should use micro services for everything all the time but I still think it's worth pointing out that a monolith sometimes is a good idea if you think of the of the approach of taking a look at a big system and maybe splitting it into few big parts like maybe 7 or 10 parts there may be two or three of them are best billed as a monolith right and maybe the seven others are built in a different way so maybe they will abound with so much we should build many of them rights if they're if you're good model is and then we're happy with them so I conclude with some final recommendations and the risk here is that they really sound like absolutely applicable to every presentation I'm every ever going to deliver which is fine with me so the first one is this I think that is this is common statement you can put it into any slide deck and it's very true in this particular thing here none of those things is the right one right not service not the Netflix style not the DVD style not the model it's not the easiest thing all of them very much depend on context and you should never feel forced by a solution to apply it should always be driven by the problem by the domain by the business benefits that you're looking for sometimes those benefits are from an architectural perspective it's actually an architectural concern that you have and that's fine like for example loose coupling right or parallel develop and a paralyzed ability of development right so you have to look at that if scalability is your number one requirement you'll end up with a different architecture then when separation of development teams your key requirement or remove them the frequency the high frequency releases your amp is your main main intended benefit so take a very close look at that and then choose the matching solution pick the one that matches your needs and finally what's true for individual service is also true for the whole thing if you can in any way then try to create something that can evolve don't make a decision that ties you in the end to any particular technology or approach try to build an evolvable an illusionary architecture that can actually grow as you and your requirements bro that's essentially all I have thanks a lot thank you do we have time for questions yeah we have about five minutes for questions and we have a longer break behind afterwards are there any questions yeah I see one there on the last edge of the room first of all thank you very much for the talk pretty welcome very nice do you think there is a chance in the future that we are going to come back to monolith again because if you will think now we complain a lot about enterprise service bus and then come service mesh which is the solution for communication with micro services so we we have for example some companies having a mono repo and do you think there is a chance for that I don't think we will ever get back to the bad times we had in the past because they were bad times and nobody wants them back for very good reasons I don't think anybody still wants to build a monolith with 25 million lines of code most people would probably agree they don't want to have a model for 2.5 million lines of code maybe we'll will move from trying to build stuff that has a thousand lines to something that can accommodate ten thousand twenty thousand so you know it's like a pendulum that swings a little bit so I think it's gonna become a little less fine granular we're going to move to somewhat larger systems I don't think we'll ever get back into the monstrosity that we had in the past where you had like a hundred people working for five years and then releasing something in a Big Bang fashion that failed that's not something anybody wants to do again any other questions disagreements fine with that as well yeah discussions ah there Chris please pass in the mic well since since my talk had an order service mm-hmm I feel personally attacked actually I tweeted this so so one of the problem one of the problems with like saying like entity service is an anti-pattern is then it gets into the definition of what an entity service is right of course and so sometimes just calling something entity service is to me a perfectly good decent name right you even though the function like functionality that it's implementing like in the case of my order service it's got kind of like high level operations like place order revised order cancel order right and it's support you know and it's specifically supporting what a consumer would do who's interacting with the online store I don't know maybe my naming is an it is sort of unimaginative and if you have a better one tell me quick because then I'll do a global search from a place on my book and but that to me is okay and especially in my context where I specifically designed my water aggregate to be right to my opinion right sized and in fact what was previously a bloated aggregate is split across the delivery service that's handling some aspects of fulfillment the finite the accounting service and so on so it's sort of like yeah yeah yeah kind of you I guess but it's sort of like what do you really mean by an entity service yeah so I sort of feel unfairly attacked by the new ends that you bring to this discussion right I think this is all very much oversimplified if you're seeing an entity service as bad of course you're right to ask what I mean by an ADIZ service so some observations the first thing is that when we when we talk about examples then they're very often simpler than real-world systems so it may be perfectly fine an example scenario it's probably not gonna be fine in the real-world scenario where you end up with an entity service that has has too much responsibility I'm pretty sure you would agree with that if everybody keeps hitting that thing if you have very conflicting requirements for the thing all of the time then probably it's a sign that it's really not one thing it should be multiple things that if the energy service is probably a smell it's something that makes me look very closely at it if it's well designed as I'm sure yours is then it's perfectly fine but I've often seen it's not often often it's just you know people people use patterns and use approaches that they know and you know doing a data modeling kind of thing is something that people know especially if you're starting out it's very easy you can just talk to five people and then you come up with this thing and your draw this little model and then turn everything into service and I've seen it lead to disaster so you just maybe just be careful what you're doing here and that's probably something we can agree on yeah okay he said yes I have to he doesn't have a mic so I have the compile control I mean the other point is maybe the underlying anti-pattern is like blob I mean actually couldn't the classic anti-patterns book there was the blob right yeah problem and it's kind of like the blob aggregate that just sucks up all this functionality might might be more the underlying problem you may be right yes I'm really thinking about those those data base tables that have like 300 columns in your our DBMS right where everybody who wants to store something with that thing adds another column to the monstrosity table that everybody's rate of touching yes so I think of blob okay it's odd class is that well any other comment over there in between this is a great warm-up for the panel which will happen later you mentioned micro platform as a anti petal yeah what we can see now that some products arriving like linka de su and so on which take over some common functionality you like to have service to cover your so on forbidding it service mesh this is the wrong way to the sidecar its idea or is it just better to print faster clip well I'm really undecided I think there's a risk in there right I think it's a what I actually wanted to address was more of the stuff within your service right you're like like this these sort of everybody assumes that everyone's using Java anyway so just let's just build this useful Java library that anybody can use and then a few years later you discover oh I'd like to try out go and then you come up with a crazy idea like you know containers sitting as to the side whatever right so the I think this is the stuff that I wanted to address but the point you address is also very valid I think this adopting a product on the macro level between your services is a very useful thing but it's also very risky thing right the the more common that product is the less of a dependency you have on and that's true for everything it's true for your call provider it's true for your service mash it's true for kubernetes we're right yar do you want to depend on it or not so you really have to make this cost value this is I'm not saying it's wrong all the time we use lots of stuff all the time because it's useful to us and I think that's like that's a good approach just have to manage it and be very aware of the the sort of lock-in that you that you accept with that okay I want to just one more question if there's one yeah okay cool thanks a lot this was fun [Applause] [Music]

Channel: microXchg

Views: 8,628

Rating: 4.8701301 out of 5

Keywords: microservices, microXchg, microxchg 2018, conference, talk, architecture, pattern, antipattern

Id: RsyOkifmamI

Length: 55min 50sec (3350 seconds)

Published: Fri Mar 23 2018

Reddit Comments

[u/tenmilekyle]

Stefan Tilkov is one of the sharpest thought leaders out there on the modern enterprise, thanks for sharing this one.