Skip to content
Permalink
Branch: master
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
45 lines (30 sloc) 3.85 KB
typora-copy-images-to typora-root-url layout header_image title author synopsis tags
..\img\posts\there-is-no-such-a-thing-as-cross-services-composition
..
post
/img/posts/there-is-no-such-a-thing-as-cross-services-composition/header.jpg
There is no such a thing as cross-service ViewModel Composition
Mauro Servienti
At a first look it might sound reasonable to use ViewModel Composition to allow services to talk to each other. Why not allowing services to share complex data structure composed at runtime? Let me put it simple: you don't want a distributed monolith!
SOA
Services ViewModel Composition

In fact there isn't such a thing as cross-service data sharing at all. Lately I started a series of articles about Service ViewModel Composition. I talked about:

Share all the things!

At a first look it might sound reasonable to use the ViewModel Composition approach to allow services to talk to each other. If Service X needs some information that are stored in Service B and Service H why not allow X to go to some sort of internal Composition Engine where request handlers from B and H could be deployed to solve the exact problem X has...? Thank you, but no, thank you.

As my Dutch colleague Dennis van der Stelt would say "Autonomous microservices don't share data. Period.". That by the way is also the title of a talk he's going to give this month at NDC Copenhagen, check it out!

Even if it's technically possible to build such a thing, if we don't want to end up with a "wonderful" distributed monolith we probably want to avoid it.

Poof, autonomy is gone

Regardless of the method we use to share data across service boundaries we'll end up with services that are not autonomous. Autonomous services can evolve independently from each other, non-autonomous ones cannot. They are coupled, they won't be able to evolve without breaking each other, causing evolution to stop or causing friction at development time, deployment time, and run time. But there's more...

The snowball effect

As soon as we have services querying each other for information we're immediately introducing temporal coupling. Whatever problem the queried service has, it's propagated to the querying service. Is it down? The querying service cannot work. Is it slow? The querying service might timeout or fail. And so on, you probably get the point.

Conclusion

As soon as we allow cross-service data sharing, for example by allowing services to request data from another service, we end up with a the worst of two worlds: a monolith suddenly turns into a distributed monolith with all distributed system problems on top of a monolithic one. The system immediately loses two key aspects:

  • Services are not autonomous anymore
  • Services are temporally coupled

Despite being technically possible, just don't do it. If you feel the need go back to the drawing board, it's very likely that services boundaries are wrong. Be careful, what at the beginning seems a small harmless snowball can easily turn into an avalanche that halts the entire system.

You can’t perform that action at this time.