Autonomous microservices don't share data. Period. - Dennis van der Stelt - NDC Porto 2023

This talk was recorded at NDC Porto in Porto, Portugal. #ndcporto #ndcconferences #microservices #dotnet #softwaredeveloper
Attend the next NDC conference near you:
ndcconferences.com
ndcporto.com/
Subscribe to our TH-cam channel and learn every day:
/‪@NDC‬
Follow our Social Media!
/ ndcconferences
/ ndc_conferences
/ ndc_conferences
Are you building a monolith using microservices? If a small change in business logic or in data requires you to modify code in more than one service, you probably are. Isn't it unbelievable that even using the latest technologies like .NET Core, containers, serverless and more doesn't help? In this session we'll discuss why technology doesn't change coupling. We'll have a different look at microservices. One where they'll truly be autonomous and not share data at all.

[@allanwind295]

Order numbers, btw, is also data, and you have wonderful things in the real-world like an order being split: these 2 items are drop shipped, this item is back-ordered, and rest I can ship out. Phone numbers are used as poor (possibly partial) identifiers.

[@frankhaugen]

Source of truth and then distribute your data. You CANNOT HAVE TOTAL SEPARATION IN REAL LIFE! Yes, maybe the first year you can, but then comes the business analyst: Customers needs to be able to tag other users in comments, and we need those bank accouts for suppliers available for the order ingest proxy server, and that reporting service, well that needs all the data all the time now because we are building a BI component with this consulting house, and... Architecture cannot be an anchor for the business, or the business will fire the architects 😂

[@FlaviusAspra]

As an architect, I can tell this talk is filled with misleading rules of thumb.
Just carrying over value objects will not help. For regulatory reasons, for instance, even product names need to be on the invoice.
So you end up with services tied to each other, only indirectly, through the events.
The funny thing is that even the speaker hinted at this problem, but he lost track by the end of the talk.
Keep it real: microservices always end up entangled. You can decouple them at the technical level by using versioning.
Semantically, they will always be coupled. Data has to flow. Broken events from one service will leak into another.
I'm waiting for the microservices hype to die down.
See you on the side of the modular monoliths.

[@dvanrooyen1434]

XML - I guess when you have to learn a whole new query language and validation language just for the mechanism that’s supposed to transfer for data that should give you a hint ;)

[@KellyClowers]

pretty sure if you have a service (micro or otherwise) that "doesn't share data period", you don't have a service, you have a lump of code that does nothing useful, since you can't get data out of it.

[@RFalhar]

Terrible talk. Only intersting part is like last 10 minutes. With useless fluff before it.
Also, the idea of just sharing IDs is absolutely ridiculous. Services often need access to the data from other services to do their processing. Two services might want to know who the recipient of the order is, one to do the billing, other to do the shipping.
90% of issues with microservices is figuring out how to efficiently and reliably share data that multiple services need access to for their processing. Putting them into events and building local read models is one way to achieve boundary isolation. Accessing data via RPC is another way.

[@bdeva029]

Clearly you are not an architect level employee. This talk isn't for people at your level clearly. He is highlighting important anti-patterns of resume driven development, and used historical use cases like any good engineer would.

[@dvdstelt]

Thanks for the feedback. Still, the first step in realizing how things can be improved is realizing what doesn't work. To make this easier, in the presentation we took a trip down memory lane and slowly realized that again and again, we became more aware that the latest technology doesn't change our architecture. We learned at school/university about function calls (procedure calls) and remote procedure calls (rpc) and retrieving and sharing data. But anyone who experienced building larger systems, knows that eventually there's so much high coupling and low cohesion. And remember about sharing data over RPC calls. We frown upon people that share databases, because we know that's a no-go. But sharing over an API isn't an issue? Don't forget that our database also has an API that we access! So how is sharing data via the database API bad, but sharing data via a microservice API is good? It's the sharing that causes a lot of unwanted coupling. We need a different solution. In this presentation, I share a different solution. It's not an easy solution, but the best solutions are never easy.

[@vincentcifello4435]

“ Services often need access to the data from other services to do their processing. Two services might want to know who the recipient of the order is, one to do the billing, other to do the shipping”
Why would any service, other than the billing service, save the data required for billing?
Why would any service, other than the shipping service, save the data required for shipping?
Shipping is responsible for the shipping, right? Tell shipping what the shipping address is. It is no other service’s business, literally.
Sharing raw business data across services is a smell indicating your boundaries are incorrect. Period.
You may be confusing the presentation/user mental model with the service’s responsibility. Of course, there may be the need to build materialized views in some specific cases for performance, etc., but a service must own the data it needs to do its work. Otherwise, it’s not a service.
You can watch Mauro Servienti’s Aggregates talk or his UI for Microservices talk, both of which are updated talks based on Udi Dahan’s 2 Own the Future (NSB style) original talks . Also, Indu Alagarsamy’s talk at infoq regarding Bounded Contexts. Finally, Derek Comartin addresses this very issue in a short video “I NEED data from another service” or such.
Either you take bounded contexts, boundaries, encapsulation seriously or you don’t. Either way calling this clarion call “ridiculous” and continuing to pretend that saving data in the wrong service and then sharing it is the only way or that your “services” are decoupled because events! says more about your failure to imagine and learn than anything else.

[@Fikusiklol]

@@vincentcifello4435 Sharing raw business data across services is called RPC / ECST and its there for a reason.
Even your suggest to watch Derek's video where he's literally saying that yes, there are when u want to share LOL
You, and the guys alike, saying that services dont share data, are clearly misunderstanding the concept of data ownership/ACL/alike. And that's pretty obvious why, when talking about such primitive examples.
I can literally name few things in that domain from the top of my head, where this theory of publishing only thin events (notification) with only Ids is gonna collapse.

[@user-ij5ky4lr3x]

@@FikusiklolI think that thin events are fine, but can't be the only form of communication. Single source of truth of data needs to be enforced at a microservice boundary. Any reads can be from a distributed cache like Couchbase or something similar. Writes must flow through microservice boundaries or you are going to end up with entity version issues. There must be an authoritative server for data. These concepts aren't even remotely new, but they can be challenging to design right - hence why architects are needed.
Events should incur actions. That doesn't really solve the issue of sharing data or accessing data.