Event-Driven Microservices - not (just) about Events! • Allard Buijze • GOTO 2018

[Music] all right good afternoon I guess it's it's sort of almost afternoon right now so a few months ago the the program committee sent me an email and asked me hey allard can you can you give a talk about events like well that's a particular broad topic but yeah I do know something about events and I could could talk about them but actually I prefer to talk about the fact that it's not about events and okay that's okay you can do that etc and of course now I'm here and when I was preparing these slides I thought well it's actually not even about micro services either so what does that leave us if we take event-driven micro services to take out the events and take out micro services well driven is mathematically correct but so we'll see where we end up let's let's see where we started first so this is a an architectural diagram that probably matches much of what you've built in hopefully the very far past unfortunately I still come across this architectural style a lot nowadays and a lot has been said already in this in this conference as well as others and the the the big problem with a an architectural style in which you define layers and then a a domain model that is basically used by each of those layers is that you you end up with a domain model that in some cases is anemic and in some cases is not and then you map these services that you build to entities in that domain model right and I worked a lot on greenfield projects and they're really lovely because you have this greenfield idea every mistake you make is yours that's the downside of greenfield programming but in the beginning at least the software is is very elegant and it's easy and it's clean and everybody understands it because basically everybody is you and Tok but everybody understands it so you have these services and their map really nicely - usually one of these entities in your in your model and then a second service is built and it still Maps really nicely to that entity and then there's that one feature request and that service maps to more or less about everything you have in your model because the model is not really suitable to do whatever that service needs to do in there and I'm pretty sure you you recognize this situation or otherwise you recognize this this is a perfectly normal sequel query that fortunately I did not have to write somebody else gave it to me to use in slides and I had to make that person a promise and that promise was that the attendees cannot read what's in the query so usually the projectors are relatively they were at the time relatively low resolution so you had about two pixels per character they were definitely unreadable and then I gave I used this slide in a presentation on a high resolution projector and I was not aware of that and suddenly I realized oops people can now read the characters so I thought okay let's try to read the characters and I still could not read the query so I guess I'm still okay with my promise you cannot read what's here I think nobody can even if you have it full screen so I'll give you a little summary there's the 22 joins and six sub queries in this nice little sequel statement now put your hands up if you think this performs very well put your hands up if you like to work for that company because they have an open position for somebody to maintain this alright so what do we do if something doesn't perform we and we cannot fix it right we add caches or other technical aspects to our to our application and in this case I've exaggerated a bit I've put caches all over the place and there's some worker pools because async makes stuff faster right wrong cassia's are very poor problem-solvers they are very good at making something that works very well make it work faster but they're not very good at making something that works problematically not even sure of that easy from an English word but if there's problems in your application the cash is not going to solve that problem right it's going to hide it and make it explode even harder when things got really wrong but the thing that struck me while creating this diagram and I've been using it the diagram for a while is that all the solutions that we do are in the user interface layer service layer data access layer but the problem the real problem is in the domain MO the domain model that we were using was not suitable for the activity that we want to to implement in this in this application so what we basically built is something like this it is a perfectly aerodynamic machine that probably takes corners really fast so this has all the characteristics of something that moves really fast right it has the spoilers has the side skirts but the core of the whole thing doesn't work yeah well might work but not as fast as we want to and this is a typical caching caching problem in in software we call this a big ball of mud and this might be a revelation for you but a big ball of mud is not really made of mud so this is the I guess the a big ball of code smells and everything that we we put together and there's always a little architect sitting on top of it proudly protecting its creation so that's something we don't want right and I put micro services in the title of my slide so I might as well talk about it a bit so the idea of micro services is to split applications into smaller piece is so that they become easier to maintain and that our organization becomes more agile in the sense that if we if somebody in a suit has a nice idea the deaf guys can implement it a lot faster we are we can move a lot faster right it also helps scalability right the the amount of people you can have working on a single git repository is limited so if you split them up into separately deployable units then okay you can scale your organization much better that's the problem I promise sorry the problem is micro services are not easy they're actually pretty hard I mean we fill conferences with talks about how to do micro services and how not to and a lot of these talks focus on technical aspects fortunately also a lot of talks focus on the non-technical aspects and I think although the technology that we need we can cover that we can get there right we can find the tools that we need to to do all of that but there's something else and it has to do with there was an observation by by Martin Fowler already quite a while ago is that all the successful projects of micro services started with a monolith that was taken apart and all the situations are not all but many of the situations where micro services were built from scratch those projects ended up in trouble in other words they spend all of money and maybe never even made it to production and that is usually not because of technology I mean the kubernetes is something you can learn right you can find people to help you that's all right the problem here is whether we like it or not the concept of noun driven design I'm not sure if Albert I was here but I have to attribute this to to him he came up with this this term while we were having a beer because that's where weird terms come up and he said you know micro services is actually pretty easy just you just do noun driven design and then you're all good what you do is you take this the document that describes what you need to build find all the nouns underline them those are your services all the verbs there your API calls and there you are of course he said that jokingly so this is basically the mathematical formula for noun driven design and of course that's not the way you want to build them but if you look in practice when when micro services are built from scratch we do see that they end up like that quite often so you end up with an order service and a customer service and a product service an inventory service the formal name for this is entity services and basically what what what you've built at that point is a relational database schema using HTTP abstractions imagine that query earlier but then with HTTP calls what was it 20 joins six upgrade something like that rather one view than me to be honest but I guess you feel the same way so with entity services instead of ending up with this big ball of mud and then I'm afraid this is a diagram that you've seen multiple times already you end up with a distributed big ball of mud well is that going to make you any happier than the first situation to be honest I prefer the left situation and the right one now I was involved in some of these projects that ended up in in big balls of mud and I don't mind make mind making mistakes I love making mistakes because they provide you with a learning opportunity and I love to learn so what's wrong with making a mistake but what I really really hate is making the same mistake twice because it means you had a learning opportunity and you fail to use it and I made me some mistakes twice and then I thought you know I I really need to find a way to resolve this and I came across this concept that is now called CQRS and at the time it was called distributed domain driven design it was a very vague concept that Greg young presented at some conference in 2008 or nine and the idea was pretty simple instead of making a single model for your application you create a lot of different models for different models for different purposes and these purposes you can split those into the commands and the queries so the components that are responsible for processing changes in your application you can split those from the components that are responsible for providing information of the current state of your application and if you do that you end up with two things whatever that really is so one part is responsible for commands and one for queries and what you can then do is create different models focused on whatever the behavior is of that specific part that you want to to use and this also allows us to take of course skipping one step here of course if you execute a command then somehow you want any query to to reflect the changes that the command has has made right so nowadays we would use events for that if you were still in the 80s you can use stored procedures or table triggers or whatever whatever you like but events are really well they're quite mainstream at the moment either hype or not so you could call it whatever you like but there is something to events that is really really useful and what we can now do is take into account these different non-functional requirements that we have in different parts of our application because now we have modularized if you will are our domain model and if the part of our command model has specific requirements for example being able to handle 1 million transactions per second with a latency less than 10 milliseconds you will treat that model differently than a model that handles 20 commands per second and has the latest of is a louder latency of about 100 milliseconds right you want to focus those the the efforts on the parts that are harder if you will and also we can now make a clear difference between the command model and how fast that should be in the projections how up-to-date them your projections really need to be do they need to be consistent or do you allow for some eventual consistency that's a choice you have right so seeker s does not equal eventual consistency it gives you the option to deal with it if you want to so what is that what does that have to do with micro services you might might wonder so when I was exploring this concept of secure s around almost 10 years ago time flies their more micro services weren't all out there yet so I definitely did not have micro services in mind when we're working on unsecure s but in practice we saw that a lot of the users of our framework they they use it in a micro services environment so we started to find out ok why do you do that what's the what's the benefit there and basically you have to realize that a monolith is not the same thing as a big bowl of mud there is nothing bad per se in a monolith right for one it doesn't smell you can touch it without washing your hands etc but more importantly there's you can you can probably tear it apart right there's ways to tear a model of there's ways to tear a big bowl of mud apart but let's not go there so when you have a way I have an idea and this is an icon always used for a for the for a business model right you have an idea of something some process that gives you money that's the simple form of any business actually and you want to implement that using my services now what you can do is go straight that way right but we already said that's dangerous and there's a way you probably do not want to go because you end up not where you think you are but in a distributed big bowl of mud situation so what you can do instead is why not build a monolith but then a structured one make sure that there is very clear internal structure that allows you as time evolves to start extracting some of these components and start to deploy them separately and that is usually driven by by non-functional so it might be driven by team size right the team is getting too big we need to organize I could be slightly different so that one team can work on one part it might be might have to do with the stability of one of these components may be that blue component has exceptionally high memory use and you want to isolate that from the rest so that if it crashes it doesn't take the rest with it it might be anything right anything but functionality as timing falls further you can extract more components those who have been to to my colleague Frances presentation you've couldn't you've seen this in practice right he gave a demo where he he displayed this if you haven't I'm sure the recording will be published soon and maybe you can even evolve your micro service environments of a service environment right that could be a next step in this in this journey and we notice in practice that people that embark on this journey they get stuck on the top rights not because they got stuck not being able to advance but they have got stuck they're not having to advance from there so they end up in a much simpler situation to manage than the one they would have had if they went straight for micro services and that's what I meant with this is not really about micro services it's it's about embarking on the journey towards micro services not to have to do micro services unless you have to now the ingredient that allows you or that is required to be able to go on this journey is what we call location transparency and occasion transparency is to come is the idea that two components should not be aware sorry two components that interact with each other should not be aware of their respective locations and that sounds easy well it is actually pretty easy and it starts with a good API design getting your API is right is the first step unfortunately it's not the last one and one thing that really helps is explicit messages just sending explicit message objects from one place to another or events so this is something that event-driven microservices has all have also discovered or some people have discovered and they are using event-driven micro-services and basically what they do is they event all the things so everything we do everything we communicate becomes an event because events are really powerful right because the sender can just send an event the recipient is not it doesn't matter where the recipient is right and in this case they're really decoupled both in space and in time it doesn't matter where they are or it doesn't matter whether they are there right now or at some point in the future they will get that message some time now the problem with this is that everything becomes an event and we are very good in our industry to go from way over there to well that doesn't work let's go way over here oh that doesn't work either then there's a new generation of developers and they think oh these old guys they don't understand we should do this and then the next generation comes and here we go again now this this problem might be familiar to you as a Maslow's hammer right if all you have is a hammer everything looks like a nail I was researching a bit of the origins and I came across that there's a it's called a Birmingham screwdriver so apparently in Birmingham they like to repair houses with a hammer but sometimes you need a screwdriver but basically what's the difference just whack it and if it doesn't work whack harder now the problem with this is it sounds like a cocktail right it sounds like something you can join in the evening maslow's hammer is not really a positive thing so I don't really like that I wanted something that sounds like a disease so why not call it Maslow syndrome from now and it is a it's it's a it's a nasty disease because usually you don't notice you have it right people around you might not even notice it's people slightly further from you that might know that you you do and it manifests itself by people that have this disease they build stuff like this there's an order service and there's another service that needs to know about ordered items this is probably quite common scenario now I imagine of course services have their own database right they're isolated that's good so far and there's a way for these services to communicate which is all fine now there is order service omits events to notify other components that something has happened right so far no problem this is all good except that the or the service on the right now needs to know which items are ordered and there's some business rules that need to apply to all those events to find out which ones were ordered because an item is not ordered when it's added to the order it is ordered when it is added to the order not removed and then that order is confirmed not extremely difficult maths but I'm pretty sure you can imagine situations where it does get pretty complicated so we need to copy some of the logic that is probably living in the order service and some of the meanings of the of the mathematics behind those events and the rules between those events to the service on the right and it gets worse so this is it as a scenario that somebody presented in a presentation of course not here at go to some small Meetup and you know this is we've got ultimate decoupling in our systems and this is what we do we have an order service and it just emits an order created it is not coupled to anything oh that's great and the shipping service picks that up okay so there's the coupling right so the shipping service needs to know the fact that the order service is emitting those events otherwise so there is coupling and it will send an inventory confirmed event to say that okay we've got the stuff that you sold oh that's great says the order service and it emits a ready for payment event the payment service big setup so the payment service is aware of the order service emitting those events so there are some coupling there and when the payment is completely says it's paid and the order service is aware that the payment service omits that event so there's a coupling from the order service to the payment service as well and then the process goes on now the problem with this situation is that there is coupling but the events basically they switch the dependency around so instead of having a dis pendency from the sender of the message to the recipient it's not just the other way around but the dependency is still there if you communicate everything through events you will still have to wait appendices and two-way dependencies are not your friend and we need to realise that there's more than just events but it is well in our case we believe that there's three reasons why components want to communicate one of the reasons is still events it is the the you want to notify another component of a fact something has happened and I will tell the world and whatever they want to do without facts that's theirs right it's a typical pub/sub situation you just publish it and move on with your life and whoever picks that up whenever they want to pick that up that's fine and in some cases you want to communicate to a component because you want to trigger a side effect you want the state of the application to be different after the command and it was before so that case you would send the commands and commands have typically have one destination and they might come back with an okay or not okay or maybe a small piece of data if there's some also generated values in there but it's not about the data returning it's about the side-effect that the command creates and the other type of message is a query sometimes you just need information sometimes you just want to know what the current state of the application is in some form right and the query they can have different routing patterns for those queries a very typical one is the point to points where you which is very useful if you have a single Authority answer to your question right if you have a simple webshop you say what is the price of that product and it comes back with a price and that's it but you can also do more complex routing strategies where you say well we don't have a simple webshop our pricing engine is actually pretty complex and there's different rules that we apply to come to different prices like if you are a member of the exclusive club whatever you get a 10% discount or if it's the temperature is above 30 degrees outside will reduce the price as well or increase depending on what it is you sell so that case you can do a Scout together query you can send a message to all the components that potentially have an answer for you you can gather the answers and do a reduction function on it to get back to a single results and that's a very powerful principle because you can change the behavior of your system by not changing any existing component in your system just add a new component to provide a different answer and the system will behave differently it's both powerful and scary if you if you ask me if we do that we can redesign that the problematic scenario from earlier and we can reduce the decoupling in logic or the copying of logic on the writes by saying well if there's an order confirmed that is still a notification that is useful for the - no ordered items it can do a query it can just go ask okay what are the details of that order because then I know from that object that I get back I can iterate through all the items I don't care what the order has looked like before it was confirmed but as soon as it is as it is I want to know what it looks like let's have a look at the other scenario so the order service instead of emitting an event it could it could just accept that there is a dependency of the ordering process on shipping right I don't think anyone can explain at the exact ordering process without mentioning shipping so it's fine to have that dependency so why not have the order service said well I expect this inventory to be reserved to make sure that I can actually sell it right then there's an event coming back now the dependency is now fully from order service to shipping service shipping does not need to know about order service and the order service can send well I need to I need you to perform a payment now because that is really what I expect and you can say well the order was paid ship order etc so now the dependencies are not two-way anymore they're just from order service to the other two and in this situation that might be good might might be bad I don't know but at least they're one way and if you want to model them in the other direction you can still do that but then by choosing other message types there is one thing about events though that makes them somewhat special in comparison to the commands and the queries in that events retain value the fact that something happened someday is valuable for longer than just when it is emitted right when a command has trigger it's a side effects while the side effects might be important because there are events typically if you do a query basically if you've got your response you don't care about the question that much anymore right the typical 42 problem so there's a concept of event sourcing and event sourcing is very often correlated to to CQRS they are two independent concepts you can do CQRS without event sourcing you can do event sourcing without secure s and then you can do both of them regardless of whether you do micro services or not so just imagine this order service and there's another service that there are some really smart analytics so it needs to know everything that happens so it can be really smart about what was happening now each of those services would have its own database and it would both have their own model write their own the way they update their at their data internally and this order service will emit events as things happen to that order so far this is not event sourcing nothing that is happening here is event sourcing this is just not just it's already quite interesting but it's it's just event processing which is different it becomes event sourcing if the order service itself uses the event it's generating as its own source of truth that is the only way you can guarantee that all the behavior that the order service is showing is based on all those events and everything that happens results in an event and if something is not shown as an event it did not happen it's sort of I swear to speak the truth the whole truth nothing but the truth right it's the three elements that you need to be complete so instead of having a model that order service would just store its history it would just store all the steps that it took to get to the current state and that way you can guarantee that everything you emit is true and that last ingredient that is essential that's the essential difference between event processing and event sourcing and for event sourcing you need some way to store those events which is typically done in event store and the event store has some very typical characteristics and I've a lot of blogs about hey we're using technology XYZ and or we do events or seeing using tech XYZ and that's great and I sometimes know tech XYZ and I know event sourcing and I wonder that's not possible that technology cannot do that and quite often they do event processing another event sourcing so the event store what it needs to do it needs to be to be able to efficiently append events and in doing so it has to be able to validate some sort of sequence in those events and that is not a global sequence per definition but there is within a within any service and in my example I've used order quite a lot within a single order you will have consistency requirements you cannot confirm an order that was cancelled for example if you have those requirements you must be able to ensure that there is no order cancelled event or sorry or the confirmed event after an order canceled event because there's a rule that says that cannot happen so you do not want to execute commands concurrently on the same order in that in this case order would be an aggregate in terms of domain driven design another thing that an events or needs to be able to do is a full sequential read so some of these projections they will want to read every event that comes by and update their projections regardless from which order they came right but if we read a single order and want to apply something new we want to be able to very quickly read the events that that order emitted in the past so we can recalculate its current state and yes there are some caching options and snapshot things that you can do to make that fast so you don't have to to read millions of events just to get to the current state so you want to be able to find those events that were emitted by that order so you can really quickly recalculate that specific order states and that is the required ingredient to ensure the correctness of all the events that you produce so basically and this is when I read this slide I thought world do I really have to say this but I will just say it and you can ignore it or say oh I knew that already but the step is wrong if you consider these explicit messages first of all you want to then the final care which routing patterns do I want to apply to these messages right do I want to use pops up or do I choose a single destination or multiple destinations etc and then you choose a technology and a lot of us go for technology first like oh that's cool tech that's them Maslow syndrome I like the text now I'm going to find some solutions or some problems that I can bang this on right and it will probably work in my little lab environment and they'll all blog about it and say hey we use event sourcing on Kafka be careful so relax won't we we like this this evolutionary approach and we've we've accidentally built this this framework if you want to hear the full story you can come up and and find me I'm usually around our booth downstairs and and that works excellent framework is an open-source framework for for java and it really helps to build this structured monolith and make sure that that communication happens and it allows you to split that application into two parts but now we have a gap between the two that we need to we need to fill and as I said you know look at the routing patterns and then choose technology so you could for example choose my sequel as an event store beside specific technology focused to be an event store we have found that a relational database is the best second place you can get so before looking at no sequel just look at the old-school sequel so there's components that allow you to integrate that with with the framework and then you can for example use spring cloud Netflix so with Eureka to to do some discovery between the services and then you can use HTTP to send commands come of a single destination and a discovery service allows you to find a destination so why not you can you can use that if you want sometimes you want to publish events not through an event store but through something else well they follow a follow the pub/sub principles so you can use rabbitmq for example RabbitMQ works with exchanges and queues you publish events through an exchange and you read them from the queues and every application would then get its own queue so that they they each read their own copy of the message right simple so far let's take the next step now we extract another service so now what we're doing what do we need to do well we need to hook that into the existing components and then create a new queue for that application this becomes quite complex over time and this this is how well some accent allows you to build applications for for quite a while now and we thought well there has to be a better way there has to be some way to to reduce that complexity in the middle and we thought well there's basically if you look around there's there's different types of messaging systems right and you can you could put them on a scale of how smart they are in terms of understanding the messages that they transport right so it's not a positive and a negative thing it's just how much of the message do they understand so on the smart side you would have an ESB these bees understand exactly what they carry and as a result you get in companies you quite often get the ESB department that tells you exactly what you need to publish so that they can do all the transformations and make sure everything works for them that didn't quite work out the way we hoped in most most enterprises or in many enterprises so we go to the opposite like we do quite often where you go to a message broker the dumb pipes right you just put a message there the message broker has no clue what it is transporting and they just publishes to whatever queue it that is connected to that specific exchange they're much simpler easier to maintain often perform a lot better as well and we're so well that's not ideal either because commands and events and queries they have different routing patterns you just don't you don't just pops up all these messages so what if there is an ideal middle ground what if there is a system that just understands the stereotypes of these messages not the payload doesn't understand what the message means or but just knows okay this is an event so this is pops up this is a command of a specific type maybe a name or some identifier as you know okay we can route that to that components because it said it can handle those commands in that case we could replace that by this in theory right we like simplicity so we had a dream and we looked at and we couldn't find anything and then we realized well this is this idea that we have of evolutionary micro-services and how important commands defense and queries are so we started looking if there's any technology that could help us with that either we didn't look good enough but we didn't find anything so that's why we started out building and the way that works is basically a component just says you know this is what I can do I can handle these commands and I can handle these queries and with these I just mean a name just as some type identifier and if that's a component there says well I want to get some order details so I'm going to put a query and that system in the middle would then magically quote unquote of course there's no magic involved I promise rub that to the component that has said it can provide that query and also axle server is a product that we've built which is open source and and freely available as well if you'd like to to play around with it now if we scale it out if we extract that components basically it just changes the abilities of these specific components each component will still say hey this is what I can do I can create an order I can confirm an order and the other one says I can give you some order details and then the routing system would know okay I need to get that query to that compound up there nothing nothing in the configuration of the component on the left has to change nor in the middle right this is just all operational volatile data now this is all good and fun and this will work in the laboratory no problem you can do micro services on your local deaf machine really easily and it will work you'll understand it probably and there's no problems there but at scale things work differently and this is that skill of massive rollouts of micro services or large teams or especially the combination of the two so how do you route all these messages to all these components and how will that scale well the simple answer this concept lot just like that does not scale right not for technical reasons for non technical reasons actually what you get is an unmanageable mess and imagine all these components being able to talk to each other now this component is a shipping module and it once know when an order is placed that is the language that the Department there uses to express an order and it's placed and then we do our work that is not the language that they use in the order Department where they talk about no it's not it's not that easy right in order it just doesn't get placed there's much more to it it gets created items are added items are removed shipping addresses or other billing addresses etc etc and then it confirms right and probably confirmed is what you call placed now again we get this copying of logic right from one place to another you have to understand somebody else's language to make any sense in your own components and you have to realize that everywhere we have communication you have a contracts and especially with events that's problematic because you send out an event which means you have a contract with the components or many components because it's pops up but you don't know which ones imagine being married but not knowing to whom the only thing you know is probably more than one well the idea scares me to be honest so leaving the house not knowing for sure whether they expect you to clean the dishwasher or vacuum the floor or maybe both I don't know that's horrible so fortunately there's a concept of bounded context and I do not want you to read the entire text because that's really boring so about it context is is a boundary around a natural language sort of a sub a part of the ubiquitous language that you have in an organization it is the place where a specific word has a specific meaning and outside that boundary that word might have a slightly different meaning right and that's perfectly fine it doesn't mean that one word is wrong in the other ones right things just mean different things to different people and that's alright that just means that you have a different context so within the abandoned context and whether these blocks mean microservices or they mean components in a monolith it does not matter what matters is that when you share an event it's safe to share it within with those that understand your language right if you listen to events then it's fine to listen to events that are expressed in your language be careful when sharing events outside of your context you might want to use a different language because you do not want this marriage with unknown components outside of your intimate to direct environments so you want to share more consciously there so imagine we have these two components again that one wants to know one orders placed and one is emitting all these these other events and again in domain-driven design there's this concept called anti-corruption layer and that's basically what this is an anti-corruption layer in this case transforms the internal language to a language that can be used outside or in some cases the language that uses in from the outside you transform it to something that is more comfortable to use in the inside so in this case it could be a little component that so I'm going to listen to order confirmed events because that isn't that's an important event but every event is important but this one is slightly more important we sometimes refer to those as a milestone event right something really important has happened and then I get the order details and I create this nice event that says here's an order placed and maybe there are more coarse grains maybe they're just carrying identifiers that's all fine they're all different different ways to address this this problem so we're running out of time we'll do a small very short recap events are useful very useful but we should not forget about other reasons for communication and we should also not forget that these events will retain value they can carry value over time that we can we can use later on by modeling our messages explicitly we can stimulate location transparency but beware of your marriages and consider bounded contexts in those cases and lastly and I'm not the only one saying this evolve your way into micro services don't just go there straight away and with that I think we have about two minutes left for questions [Applause] [Music]

Channel: GOTO Conferences

Views: 22,337

Keywords: GOTO, GOTOcon, GOTO Conference, GOTO (Software Conference), Videos for Developers, Computer Science, GOTOber, GOTO Berlin, Allard Buijze, Axon Framework, AxonIQ, Event-driven Architecture, Distributed Systems, Microservices, Event-sourcing

Id: DzGuDNHsOQ0

Length: 45min 47sec (2747 seconds)

Published: Thu Mar 21 2019

Reddit Comments

[u/mto96]

FYI, here's the talk abstract before you dive into the 45 minute talk:

"Events" have recently been given a lot of attention as a very powerful means of communication between components. They pop up almost everywhere in different shapes and forms, and for different reasons. Unfortunately, they often completely miss their purpose, and instead of decoupling components, they subtly introduce an implicit coupling in logic.

The distributed big ball of mud is born.

Throwing more technologies at it won't solve the problem, all it will do is simply introduce a new layer of mud on top of the old.

In this session, I will take a few steps back and look at three reasons why components need to communicate. I will demonstrate that by considering the reason of the communication, you can select suitable routing patterns, choose an appropriate protocol and technology to transport each type, and end up with proper decoupling of components. This decoupling means that it doesn't matter anymore whether the messages are handled in the same process as the sender, on different hosts or even in different data centers altogether. This so-called location transparency then becomes a big enabler for building evolutionary "message-driven" microservices.

[u/berlinbrown]

Awesome

[u/threecheeseopera]

Thanks for the link, I'll check it out. I'm not sold on decoupling services in this way, it's hard enough to operate them and keep visibility into what's happening at runtime. It would really solve some problems for us, in an abstract wat, but I'm guarded about the complexity it will add.