Autonomous microservices don't share data

00:05 Dennis van der Stelt

So welcome. Let's talk about autonomous services that don't share any data. And I added period because I strongly believe they shouldn't. But what kind of microservices and if they're the smallest and the different type of microservices and how period it is, we'll try to discuss. There should definitely be room for questions, especially at the end, so let's get started.

My name is Dennis van der Stelt. I work at Particular Software, and we are a company that built NServiceBus. But I don't want to talk about NServiceBus, I want to talk about microservices and perhaps some Docker as well, and maybe even containers because especially these containers, they are perfectly aligned. So I know other people that have OCD that probably think this is really great, except that the colors aren't really balanced really well. But everyone basically loves containers until they go wrong, unfortunately. We'll talk about the why's and the how, but first, I want to talk a little bit about history.

Right? Who knows what this kind of computer is? I hear some people sighing. Is that of the memories? It's a Commodore. I think most people recognize it. I don't know if it's a sigh of the memories or not that machine. This is a Commodore 64. I, myself, was more of an MSX guy. Does anyone know what an MSX is? No, I see someone shaking his head here. I loved MSX, and it was basically the competition to Commodore 64. This was my first computer. It didn't have any floppy drives. It did have a cassette player that I could record and play stuff with, mostly software programs and the current rates. And the first thing that I did... And obviously it doesn't work. For some reason, when I attach it to a Beamer, this stuff doesn't work. PowerPoint is the weirdest.

But I used to play this game, Konami Tennis. it was the first thing that I got with my computer. And I absolutely loved it until I didn't put in the cartridge at some point. And then the computer still booted up, but I got this console screen including a book that teached me how to write my first Hello world. And I loved it. From that moment on, Dennis didn't play any games anymore. I just programmed MSX BASIC. And that was basically in the year when these movies were released, Goonies, Breakfast Club, Rocky IV. Anyone know which year this was, an estimate? I was 10 at this time, so then you know how old I am now.

03:00 Audience

[inaudible]

Very well, 1985. Do you also know what I looked like in 1985? Like this. What I didn't know at the time was that I was doing procedural programming that came up around the year 1960 or so, and it's most familiar in BASIC and Fortran and COBOL. And I thought I was doing really great thing, everything was rainbows and unicorns, and I wrote basically the best code ever. But the more code I wrote, the harder it was to maintain. Little did I know when I was 10 years old that I was writing spaghetti code, right? Apparently, this term was already invented before I was born. And it's funny that, obviously, we don't write spaghetti codes, but we join projects where others have written spaghetti code. And it's a bit particular that apparently in so many years later, this still happens, rght? And already back in the days, someone said the goto statement is considered harmful. Do we know who that was?

04:03 Audience

Dijkstra.

Yeah, exactly. Edsger Djikstra. He is a Dutch from my hometown Rotterdam. Go, Rotterdam. He said to everyone he advocated structured programming. So that came up late '60s, we got structured programming, which basically introduced the if statement. It introduced loops and functions, and everything was rainbows and unicorns again, Well, apparently, we could still improve because late '80s, we got object oriented programming. And that was basically the time we wore this kind of clothes that doesn't really have to matter. But there were better things like classes and inheritance and polymorphism. That was what a lot of people focused on and are still focusing on when we talk about OO. But I think the really important part of that is encapsulation. I don't know if you've been to Adam's talk, but he also mentioned encapsulation as being important because with the proper encapsulation, we can achieve high cohesion and low coupling. Right? So we'll end up with a system with a lot of classes where supposedly all of these classes have their own high cohesion, maybe even their single... only a single responsibility from the single responsibility pattern. And we had a lot of classes calling classes calling classes.

The issue was that if we took one of these classes and modified it a little bit, right, we broke something somewhere else. So apparently, they weren't really high cohesive because otherwise, we wouldn't have been able to break something somewhere else so easily, right? And we basically tried to get across this by writing a lot of tests. So there was the unit tests. The TD came up. What we wanted with OO was encapsulation, but we ended up with procedural code under the guise of object orientation. So we were still writing spaghetti code, and we still had a lot of coupling because of all the dependencies these classes had on each other, right? So then, early '90s, we got component driven development. And we basically built the same system. We built components with classes in them, right? We tried to be cohesive with end components. But apparently, we could still improve because around the year 2000, we got web services and service oriented architecture, right? The entire software development community grew and grew and grew. And I can still remember that everyone was extremely enthusiastic about service oriented architecture because finally, we could design our system in a way that they are truly loosely coupled. I see a lot of people smiling. So I think they all agree with me.

It was also the rise of WCF. Who has worked with WCF? Almost everyone. Who likes WCF? Only a handful. Not WCF but web services brought us SOAP and XML and XSD, and everyone loved it because it was so clear, and we could communicate with each other, right? Now we know better. But remember, web services and WCF and everything was in a time that we didn't know any better. So if I could go back in time, right back to 1985 and look myself up, I said, "Don't get an SOA," which probably isn't the best thing because in Dutch, SOA is an STD. But anyway, at the same time that we were trying to solve all our coupling and cohesion and architectural issues, there was something going on at the same time. There were people that were trying to integrate a lot of systems, right? They were trying to solve systems integration. So this was basically the rise of the enterprise service bus with BizTalk, IBM WebSphere, etc. And they found the solution in these web services and in XML and XSD, right, where they could communicate with each other. And the development world probably thought, well, we have service oriented architecture. Web service has also the word service, so check. And we tried to solve our architectural problems with web services and XML and XSD. And even if we didn't fit, we made it fit.

There was another guy, Grady Booch, right? He was basically the father of UML. He was very enthusiastic about SOA. He said, "It's the best since punched cards. You'll even become a better lover." Might have been with a little sarcasm because he said, "What a rubbish," in the end. But what we did was we had basically the same picture, and with web services, we pulled everything apart so that now we communicate cross process boundaries, right? And we have web services calling web services, but we introduced a lot of latency while not actually solving the real problem. SOA or SOA was also classified a lot as reuse where you could build a web service or a service. And you could basically you reuse it everywhere. Everyone always used the example of, if you want to know what someone's postal code is, you can build a web service and look it up. And it basically stopped there by being reusable because I haven't seen a lot of other examples that basically worked.

I think that SOA was way more about boundaries, right? We've been looking for encapsulation. And I think that SOA might be a thing, right? Classes... They were just too small. That's why when we modified one class, we could break another class. And maybe services is the right way, but maybe Web Services isn't the end. At least for the development world, SOA had to come to an end, or SOA, and we invented microservices. And again, everyone was very enthusiastic about microservices. First and foremost, we got rid of all these, right. Because it wasn't the code, it was the XML that sucks. And now we have REST and JSON, and we have Swagger and Swagger Client. And it's so much better because together with Docker and containers, obviously, we now have microservices calling microservices, etc. Right? If we do it the same way as we've done it all along, right, we are probably building a distributed monolith. And we just introduced a lot more latency, right? I'm not saying that everyone who does microservices does it wrong. I'm just saying that if you have microservices that call micro services, and it just goes on and on, it's probably not the best thing.

Someone else also said, "If you can't build a monolith, what makes you think that microservices are the answer?" And a great question is on Stack Overflow that I've already mentioned a couple of times this week. There was a user that asked, "I have this system that I built according to a microservices architecture. And now I have a single user do a single request, and I ended up with 30,000 HTTP requests." We all feel that that probably isn't a good thing, right? And I hope you're starting to see a pattern. We continuously have coupling. And I think that technology isn't the answer. Maybe technology can help, but it's not the final answer, right? We need to be able to use something else or come up with something else. But before we do that, and before we look at what might help, I want to debunk some of the myths on microservices. It's basically questions that I get when I talk to people. So again, I'm not saying everyone does it this way, and everyone is doing it wrong. I'm just saying these are questions that I get, like, "I'm doing so much better now because of ABC." And I like to challenge some of them. One thing I won't be talking about is the X number of lines of code, right? We all know by now that microservices aren't about lines of code. But what about XML and JSON, right?

Here, you can see the differences of a very, very simple document. And I really don't get why on the right side, it's so much better than on the left side. People say it's less verbose, and it's more readable. But XML had really great features, right? Like XSD, we could verify if the XML that we came up with was valid before we send it to someone else. We have XPath and XQuery where we could search for data inside large XML blobs. We had XSLT where we could transform the XML into something else, maybe even HTML. And it's pretty funny that SDON these days gets all the features that XML already had, right? With Swagger and Swagger Client and other tools, we are now able to generate schemas, and I don't know what else. Obviously, JSON is great if you're building websites. If you're doing JavaScript, Angular, React, it's a great way to communicate between... I don't know, whatever, the back end or other components using JSON, right, because we have this relational database, and we map our relational model to domain models. And we don't want to expose our domain models to the outside world. So we first map those to data transfer objects, then we map those towards viewmodels, the viewmodel to JSON. And then finally, we don't have to map anymore because in the browser, we can use JSON. So yay, go JSON. Who's happy with JSON?

But it doesn't really improve our architecture, right? Another thing I often hear is that with JSON, versioning is so much easier. I can now add and remove stuff from my JSON without everything breaking. But that's part of the serializer, right? AT the very early start, the XMLSerializer probably didn't support it. I don't remember that. I do know, because I loved WCF, that the DataContractsSerializer supports that. Now we have the NewtonsoftJsonSerializer or any other serializer, and they provide the functionality to add properties and remove properties to easily achieve this backwards compatibility, right, that your services or things or whatever you're building still accepts the JSON that's coming in. But it doesn't improve your architecture, right?

Another thing is RPC. Why is it so bad to specifically call another service, right? It's because if we are waiting for all the other services their data, we are basically tied to the thing. We are dependent, and we have to wait. And Kanye West said that dependencies make slaves of us, especially if it's a dependency on a dependency, etc. So you basically lose autonomy, right? Another example why it's so bad to call other services... Imagine that you go to a liquor store, and you want to buy some liquor. Now I don't know how it's over here, but we have signs in the Netherlands everywhere that you don't get to buy cigarettes and liquor until you're 18 years old, right? So if you're buying liquor, and you want to pay for the liquor, then how do you do that, right? Probably you take money or a credit card from your wallet, and then you give it to the person behind the counter, right? And you might choose to pay with money instead of a credit card for whatever reason, but it's your decision. I don't know if you saw the movie, but it doesn't really end up for him because he handed over his wallet, and he got beaten up, and everyone was angry with him, set the car on fire. Luckily in the end, it turned out well.

But if you hand over your business data, you are no longer the authority over your... or you no longer have authority over your own data because others... They start making decisions based on what was originally yours. You lose autonomy, and there's no proper encapsulation, and there's a lot of dependencies. For example, imagine that you have 300 microservices. Any one of them can call you and retrieve data. You have no idea who actually copied incorrect data, right? Do you know which services queried your data? Invoices could be calculated by some other service, payments might be processed by other services, customers might become preferred because of data that you owned and gave away to someone else, right? You are not autonomously responsible anymore. If everyone just can query your data, you end up with an architecture that people look at like this, right? Obviously, RPC has its place, right? We couldn't query a database if we didn't have RPC. So it's ridiculous to say that RPC is but everywhere, right? I'm just saying that you introduce a lot of latency, and people take away your data. And we still built things calling things calling things, and there's a lot of coupling, right? RPC, so crossing in process boundaries, doesn't really help in coupling and cohesion. So building web services, having them called out of process, and sharing data among each other is probably not always a good thing.

What about deployments? I read on a website for some company that had a lot to do with Docker and I don't know what else. They said, "It's so difficult to achieve operational agility." That's great. Everyone wants to be agile. But it's easier to deploy 300 microservices than apparently one monolith, right, especially if they all have their own storage technology. And I know that if your system is running, either it might be hard to deploy the entire thing... And with microservices and maybe Docker container, you can take one down and replace it easily by another. But you also have to remember that if you rewrite this service, no matter how small or big it is, it's still a total rewrite. And total rewrites usually cause bugs because the thing that was already there was optimized virtually resolved, etc. etc. And we introduced Bootbox because we have coupling everywhere. You know who love microservices? It's the operations department because now they have to deploy, maintain an infrastructure, and monitor about 300 services instead of one big monolith, right? They are probably not very happy about it.

Docker is also great. Docker is absolutely great for deployment, right, because it isolates, and it scales very well. It's multi-cloud, so you can basically take a Docker container from Amazon, move it over to Azure, and it just works, right? Better yet, you can take a Docker container over from your own development machine, deploy it to production, and what works on my machine now also works on production. So that's really great. However, I don't get why improving... or what docker containers improve over the deployments using Docker. It definitely improves encapsulation and isolation of your processes. So Docker is certainly a great tool, right, but I don't get how it solves coupling of my entire system at runtime. I think there's still a lot of coupling and a lot of dependencies, and spraying a little Docker magic over it doesn't really help. It doesn't really improve the architecture.

So let's have a look at what probably or what might help, right? And I'm talking about systems that are more complex. Not every system uses Docker. Not every system uses services. Not every system uses... I don't know what, right? We are talking about distributed systems that are complex and we need to maintain for maybe 10 years, maybe even longer. How we can achieve this high cohesion and low coupling in those kind of systems? And probably you've seen the pattern by now that I'm trying to explain. It's not technology. It's actually the people sitting here, right? We need to take a step back and look again at what SOA was trying to bring us, basically these boundaries and encapsulation. When we listen to the business stakeholders or the business owners or whatever, we have learned so far that we should look at the nouns and the verbs, right? And we end up with a customer, product, order, and these become our entities. And then we look at the verbs like, a customer orders a product or an order was shipped to a customer or a customer receives a discount. And every time we look at these verbs, we are basically creating coupling between what used to be cohesive things.

We should look at it differently. And it's not... I mean, we see the things but usually, architects... They look at the bigger picture, and I think we need to look better at the smaller things, the attributes, for example, within an order. We have a customer. We have products. An order has several prices for products. Maybe we have a discount for a customer. Maybe we have a shipping status for an order, etc. etc. And these attributes, we put them inside a single entity, or we put them very, very close together. And my question is, do they actually need to be this close together? Do they need to be in the same transaction or the same consistency boundary, right? Let's have a look at an example. For example, discount and product info. Do they really need to be together, right? Do they share the same consistency requirements? And we should probably frame the requirements differently to figure out if they belong together. For example, this one. If a customer discount is higher than 12%, customers cannot order purple products, right? That's maybe a ridiculous one, but another one could be, if the customer's full name is longer than 20 characters, they cannot get a discount, right? Probably customers are looking at you, "I don't really get it," right?

And that's when we are actually on the right track because we are looking for things that don't share the same high consistency with each other, right? Then we can probably separate them. So the discount and the product info... They are probably not related. They don't share the same consistency requirements. They don't have to be modified within the same transaction. Back to the order, let's have a look at another example. Price and discount... Should they go together? Right? If we frame it in a requirement, if a product is on sale, the customer might not get its regular customer discount. And the business might say, "Of course." Then they probably do share the same consistency boundary, and they need to go together. Now if we take a look at this order entity that we had before, right, we might end up with this, where we have a customer, and we take the first name and the last name, then we have a product where we take the name and the description. But instead of taking a customer status and a product discount and putting them next to things that they don't belong to, we put them in something else, right? It totally depends on the business what this thing is called. I don't know, right? And besides that, naming things this early is probably not a good thing because then we start assuming a lot of stuff about these things.

Another example could be the order status and the shipping status, right? They might also go together with the result that we try to create these highly cohesive things. Now... Shut up. What we now have to do is make sure that... Because this is still a system, right? If we decouple everything from each other and don't share anything, then we have an issue because we can't build our system. So we can tie these together using identifiers. And we basically then end up with a customer identifier, where customer name has a customer identifier and lives over here. We have a customer discount that is tied to a customer identifier that lives over there. And we have an order for a specific customer, and it's also bound to this customer identifier. Now we don't share business data anymore. We only share the customer identifier.

And we've been doing this for quite a while already, but we've been calling those foreign keys, right? And I guess everyone can agree that foreign keys aren't the worst thing ever. They might actually be a good thing because otherwise, we couldn't connect data from within our database. But this basically changes how we traditionally think about domain entities, right? Finding these attributes and putting them in the correct silo is a pretty hard thing. It takes time, which is or which can be an issue if you have a lot of developers that say, "This architect has been busy for two weeks. When can we start doing some development?" Right? And then the architect says... Well, the architect is taking decisions. "I'm very sorry. But we're taking decisions towards the right direction." Right? Because if we build a system, it's pretty unfortunate, to say the least, that after building two years, we find out that we took the wrong direction, and we need to turn back because turning back means rebuilding the system, right?

So don't start prematurely playing with technology because that will mean that we'll end up with spaghetti code. But once we have these highly cohesive things or silos inside a consistency boundary, we'll end up with these silos that actually don't have to talk to each other that much anymore. So it's not a question of, can this silo call the other silo? They don't actually need to call each other again. And we can call them silos or components or even bounded contexts if you're familiar with DDD. They have a lot in common with bounded contexts. We gave a workshop about this topic the last two days. And I asked the question there as well, who knows the Blue Book? A lot of hands were raised. Who has read the Blue Book until the end? Not so many hands were raised. And Eric Evans recently gave a interview after 10 years of the Blue Book, and he said, "If I would have to do it again, I would have taken out probably most of it and focused much more on bounded contexts." You can call them bounded contexts. I usually call them services, but they're logical services, right? It doesn't really care how you name them. Lucille also doesn't care. They communicate less because why would code dealing with prices and discounts need to talk to some other thing that deals with a customer's phone number, for example, right?

Once we have these highly cohesive things inside consistency boundary, right, we have our system where we used to have layers, right, the business layer, the data layer, the user interface. But every single layer was responsible for all entities. And now we don't have these layers anymore, but we still build our system, but we now have all these logical services. And if we take out these logical services and look at one of them, then we'll see that these three layers come back inside one of these services or inside one of these pillars or silos because no matter what, it's not like what we did, we separated those inside code, right? But we always have a user interface. If the user interface is not for an end user, it's an API, we probably always have data and a data layer and a database, right? But now a single silo or a single service is responsible for everything. So it's responsible maybe for microservices inside of it, microviews, microviewmodels, microcontrollers, and so on and so on, until we're downgrading the database. So if they don't share data among each other, right, in the end, we need to build this user interface.

How do we do that? Via composite UI. And this is a nice example of it, an application that you can see is divided by a lot of small parts, right? You can call them microviews, if you want. They are small views, where for example, one of those services provides the HTML and the data for a part of the screen. And maybe the customer service and maybe the shipping services... I'm just making up names here. They all provide parts of the screen. So if we take a real world example, for example, this Amazon screen, right, and we break it down, then we could have these parts, for example, coming from a product catalog service and other parts, like the price from a pricing service. Again, don't put too much... How do you say it? Effort or whatever in the names, emphasis on the names. I just made them up. But this is how you can recompose the user interface again from all of these so they don't have to communicate among each other. Even the microviews don't have to communicate with each other, right?

One last thing. So far, we've had functions, classes, components, things, microservices, right? I'm always questioning myself, what's the next thing? And yesterday, someone said, "Yeah, the microservices are already declining on the hype train." Right? So wondering what is the next big thing, I hear a lot about functions as a service, right... as your services, for example. So we'll have functions calling functions calling functions, but out of process. And hopefully, you'll be seeing that the constantly repeating thing here is the word calling, right? We get technologies and architectural styles and I don't know what else, but constantly, I see the word calling repeated. And there's a great book written by someone with a difficult name. And he said, "We need inversion of communication for business events. And we need to supplement a service oriented architecture with an event driven architecture." So if we focus on this event driven as of the moment, these services, these silos that I've been talking about, they basically cannot call each other because then we have the same old problem has happened again, right?

But somehow, right, all of them need to keep in sync so that if, for example, we have an order and order lives in silo A, that we need to ship the things that belong to that order... we need to ship them, then this other silo needs to know when the order is complete or finished or accepted or paid or whatever. And for that we use events and publish-subscribe but without sharing business data. That means that our events are really, really small, right? I don't know if they're as small as the Millennium Falcon but Han Solo definitely doesn't fit. The idea is that we don't publish an event that contains the order shipping address. It rather contains an event order accepted with just an order ID. So to put it more concretely, the servers on the left can publish an event, order accepted, and it arrives on the other side without sharing business data. And it can say, "Hmm, the order is accepted. I know that I need to invoice the order. And I don't know the product name, and I don't know if the product is in stock, but I do know the price, and I do know a possible discount. And all I need to do my work is an event, a message with just the order ID." Right?

Because, again, why would you communicate address if no one is going to use it, right? Why would code dealing with prices and invoices needs to have data from another service that deals with a customer's phone number, for example? It just doesn't. And the reason is because every service is the technical authority for a specific business capability. And they deal with everything inside this service, and they are able to do their work without sharing any data. So we talked about order accepted. Let's have a look at another service. It also gets the order accepted events possibly. We, however, invoiced the order top right, and at some point it could say, "The order was paid in an event with, again, just the order ID." And this thing on the bottom might say, "Hey, I see the order is paid. Now I can finally ship it." Right? I don't know the product names. I don't know the product price. I'm totally not interested in, but I am interested in is knowing the weight and the size of the product because I need to package it, and I need to ship it in containers. See how the circle is now complete? I do also know the shipping address, and I'm the authority, the technical authority for the business capability of shipping stuff, right? I just said one more. I'll do another one.

Another one could be, if on the left side, this service decides a customer became preferred, right, who knows why it's decided that? Maybe because he earned enough money. Maybe they are customer for a specific time. Maybe they did something else. I don't know. It doesn't really matter to the right side. The right side doesn't know who made the customer preferred or why the customer became preferred, but it does know that it now needs to ship faster or provide faster shipping options, or maybe that it needs to package up the things nicer, right? And it does this because it's, again, the technical authority for this business capability. And we ended up by not sharing any business data, right? I said we call them services where I come from. And I also talked about service oriented architecture and how it was all about these boundaries and about encapsulation, right? I'll show you in a minute inside Visual Studio what it might look like. The thing is, a logical service, right, we talk about it. We can draw a lot of stuff. The service itself is not a technical thing that goes into Visual Studio, right? It does, though, have a lot of stuff like microviews, microcontrollers, etc. etc., and those can go into Visual Studio, right? We'll end up with a lot of autonomous services.

And inside these autonomous services, we have components that process events, right? So a logical service can be a bit bigger, right? But these smaller components that process events, they do a little bit of work and then immediately publish new events. Those will probably be the microservices. They can be called micro services. Let's have a look at them so that we can see how small they might become. So I have a project here, and I'll zoom in a little bit on this thing. This is some existing demo codes to more or less demo a full solution. So it contains some data. It contains controllers, etc., etc. I don't want to focus on that, right? If you want to know what it looks like in its full form, I'll provide a link at the end of the talk to make sure that you can get more info and also the codes on GitHub for this repository. So we've seen this triangle, right, where sale starts, and it says, order accepted. I'll drill into a single handler. This is it, the submit order handler.

This is the code. This is not three lines of code, but it's basically... It accepts a message with some data in it. And it just goes through the message to collect some product IDs, and then it stores them inside some entity framework thing, and it saves the changes to the database. But it also adds this, the product IDs to this new message, right? We have the order ID, the customer ID, and we have products. But products is, if you look up here, nothing more than a list of IDs. So every checkout order submitted event, it's an integer, an integer, and a list of integers. I'm not sure if you should use integers. This is just for demo purposes. But all it does is publish order submitted, and then anyone interested can access this message and subscribe to it. So for example, we have finance, and we have a handler here. And this is the order submitted handler. So it accepts this message again, and what this thing does this is, again, apparently... It's interested in the data. So it stores the data inside its own database. And then it sends a new message saying, initiate payment process. You see that I don't add more actions to it because I want this to be as small as possible, right?

I talked about business capabilities and technical authorities and that we have these cohesive things. I also want the single responsibility principle as much as possible inside my handlers. So I initiate the payment process command, and it's inside the same technical service. And here it says, process the payment, and it calls out to a third party API that makes sure that everything works. And then I publish. Hey, the payment is succeeded. So I've now talked about finance and about sales, and all they've been sharing are identifiers. Now we can have a look at shipping, and it has another handler. And it has two handlers, order submitted and payment succeeded. So this thing should do something with the data. That is what the order was submitted. This thing was payment succeeded exceeded. And now once the order is submitted and the payment is succeeded, it can continue. So maybe this waits for both messages, and then it sends out another message. Maybe it immediately picks up the shipment, I have no idea. But this is basically how small of code you would have and how small the data you would be sharing or how small the events are. I don't know if the data is ever small, but whatever. It depends on what is big and how big you think... because if you use a big integer, then the data be big. But nevermind, I'm going off topic.

But you see that we are taking small steps, right? And you could basically call those microservices if you want to. But it's more clear, hopefully, that we can make this work by just sharing identifiers, right? So to summarize, I think microservices is an attempt by some people to reclaim the core meaning of service oriented architecture, right? They try to get again back to those boundaries and find out if we can have this encapsulation that we've been wanting since object orientation. We've been looking at publish-subscribe to make sure that our services can somehow stay in sync of the entire processes that happen in our system, right? We're trying to minimize the coupling and trying to increase the autonomy of our services, again, where service is the technical authority for a specific business capability, where we have high cohesion and low coupling, right? I think microservices is just SOA done right. And I think that's how we create autonomous services that don't share data, right? I hope you notice I did a small trick. I removed the micro. Microservice in itself within a services can share data.

But if you want to know more about this, there's a lot more to learn. For example, Udi Dahan... That's the CEO of the company I work for. A few times a year, he gives this advanced distributed systems design. He does a training where he talks for five days about this stuff. We also had a workshop that we did yesterday and the day before, for two days. And we do this more regular at other conferences as well. Also, don't start writing down this URL. You can get fee. Probably you should get this URL. This contains the previous URL. The previous URL was for the ADSD training that Udi Dahan does. We have it also in video. It's much better to go that in person. But if you want the videos, you can watch some videos using the previous URL. If you go to this URL, there's much more information, and that longer URL is also on there. So I'm Dennis van der Stelt, and it's barely visible, but thanks for watching me go through 237 slides. Questions?

Autonomous microservices don't share data

🔗Transcription