
“Wait, What? Our Microservices Have Human Users?” Stefan Tilkov at MicroXchg - danielbryantuk
http://www.infoq.com/news/2016/02/tilkov-microxchg-human-users
======
cscharenberg
This is my favorite quote from this article "building services that “actually
do something” is a recommended practice". This is an argument I make all the
time at work when a team wants to create microservices to serve very specific
data types so you can get, put, delete data about a Person, and Organization,
or whatever.

The service endpoints are easy to define, easy to test, clean and simple...
and nearly useless to expose to the frontend. Congrats - you've exposed the
database over HTTP. The layer doesn't accomplish anything, so it's pointless.
To my mind, every layer should _do something_ or it should be removed.

The end result in some cases has been creating microservices that clients can
theoretically build upon, but the orchestration of them is super complex
because the services are too data-specific rather than workflow-specific. To
do something, a frontend has to make 6 calls just to gather data before it is
even ready to present a page of UI.

I'm not making an argument against microservices, just the architecture of
exposing data in tiny self-contained (self-absorbed?) chunks. Microservices
can expose data that people may want in those tiny pieces, but they should be
wrapped up together by other services to aggregate related data to expose to
consumers that need to care about workflow. So build a Person service,
Organization service, Blog Post service, whatever. But present a Context
service that returns large collected pieces.

~~~
danielbryantuk
I agree - I'm seeing some application frameworks even encouraging developers
to expose CRUD functionality via REST (Spring Data REST, I'm looking at you)

There may be a few narrow use cases where this is valid, but in general we
really should avoid doing SQL joins over HTTP :-)

As Stefan argues in the talk, one of the original sins with SOA was caring too
much about the services (and potential "reuse"), and forgetting about the
notion of offering a cohesive piece of business functionality i.e. a bounded
context with well-defined responsibilities

