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

Did you start out building microservices, and somehow ended up with a distributed monolith? If a small change in business logic or in data requires you to modify code in more than one service, you probably did. Isn't it unbelievable that even using the latest technologies like Docker, Service Mesh, Serverless, and more, doesn't help?
I will tell a story in which we'll take a different look at microservices and discuss why technology doesn't change coupling or autonomy at all. How we need to take a step back and stop sharing data between services.

NDC Conferences

[dppage]

What is the github link/information for the solution that was shown at the end?

[gigiduru]

most microservice implementations just replace function calls on the CPU stack with network calls and not much else. They are not decoupled, can't handle failures, have no solution for distributed transactions if you have a separate database for each service. Maybe service mesh can help a bit, but it would be better to just not do it in the first place.

I think if you don't have more than 20 devs in that project there is no reason to use microservices. They should only be used to scale the organization, not for technical reasons, as performance and scalability will usually be worse with microservices (shocking, I know).

[mikemccarthy]

Dennis, what program did you use for your deck, PowerPoint? Asking b/c this deck kicks ass. It doesn't look for feel like PowerPoint...

[ehsnils]

Even when it's stated that the data isn't shared between services it is shared, but through the underlying database, not through direct calls. It's just the keys that are passed that ties everything together so that the data is properly accessed.

All that is done when "microservices" is done is to slap a label on top of a good design pattern. How it's realized is a completely different issue. In a way you can do microservices using programs in the cgi-bin area of an Apache web server, servlets in a Tomcat web server or for that matter run individual programs through a text UI.

But even then you will have some common objects between the services, most often objects representing data records in a database. In recent language updates like Java 14 there's now a new type called "record" that can be used. This seems to come from the Functional Programming language F#. A bit of a limitation or feature depending on your perspective is that this can't be extended from a base record. Just consider that you have a database where you have a pattern where you always have a primary key column that always shall have the same pattern. Then it would be convenient if all records declare this the same way and that could then constrain the use of the record type.

In an ultimate service separation design all data including the key information about what was updated is only provided in the database and the only interface between the services would be a notification to the other service stating that there's new data to process.

But regardless of what design pattern that's used you will have to consider that data exchanged between services have to have a consistent format, so if you change the data definition it's still the same problem that has existed since we started to use computers. Adding a new column to a table is usually a minor issue unless you put in a database constraint on it then all writers have to be aware of that, but changing the size of a column or the type of the data in a column in the database is still a potentially breaking issue for all services.

[dmitryshuvaev]

I hoped to hear about the publish/subscribe media he recommends to use as it is crucial for the whole architecture. It is quite hard to manage complexity there. So the event happened, but who processed it, was it processed successfully, if not what to do. In general the approach is good, but some important details are missing.

[jaimesangcap]

Given that the events just pass IDs or the listener cares/needs only the ID, how do they get other info if for example they need the product name or product weight in this example. How does the shipping context knows about the product weight? Does it have its own database of products with their weight and other info being encoded? Or does it listen to events from Product Catalog like ProductCreated and stores it own copy of the product info that was just created?

[jareeq]

I like how over 20 minutes we are going back from last 19 years super features like web services, micro services to old database foreign keys.

[kkenny]

Hello
Could You please explain how to reduce complexity if You need a list data that contains data from different bounded contexts?

For example -
Order 1-*(relation) OrderItem 1-1(relation) ItemPrice

You need next columns
OrderId | OrderItemCount | TotalPrice

If You do not share data You can not use JOIN.
And aggregating data via http couse huge coplexity comparing to JOIN.

[lollo]

Q: Transactions & rollbacks might become a gordion knot: if last action in process fails, callbacks must handle that as rollback for the whole transaction. What if calling service is already dead by that time? Function as a Service is great for cloud & load balancing and to scale processes, but finally sync concurrent data with main-db makes everything worse (Event-Driven or not; and there will be contextual overlapping in an RDBMS somewhere). @32:04 Each widget to receive it's own data is cool. I am just afraid that the (stateless) Init/Open/Call/Await/Close TCP-Connection calls will produce alot of offset (time+bytes)?! Though, this is very interesting stuff - truly not the ultimate answer to everything (but a question how to make things better).

[charleswoodruff]

The actually microservices talk starts and 11:00