BT

Entity Services Increase Complexity: Tareq Abedrabbo Discusses Microservices Antipatterns

| by Andrew Morgan Follow 4 Followers on Jul 13, 2018. Estimated reading time: 2 minutes |

Entity services are a microservices anti-pattern, writes Tareq Abedrabbo, independent software consultant. The core reason for this is that they form shallow modules, where the interface is complex in relation to the functionality it provides. 

Entity services are modelled after defined entities (or nouns) within a system. For example, an accounts service, order service and customer service. Typically they have CRUD like interfaces which operate on top of these entities. 

By taking this CRUD like approach, entity services tend to not contain any meaningful business functionality. Instead, they are shallow modules, not really offering any complex or useful abstractions. Thus, in order to achieve functional requirements, coupling between these services ends up being introduced:

Entity services are conceptually small but shallow. They do very little aside from manipulating or exposing their internal state. As such, they often have to be composed in order to be useful, so in that sense, they are not truly decoupled or independent.

When complex queries require access to multiple data sources, they fall outside the remit of entity services and are often implemented as separate services or views atop their own data.

A good abstraction allows unnecessary details to be minimised and hidden, thus simplifying the way we think about the system. Entity services do not give good value for money compared to the complexity they add.

Ultimately, these shallow entity services can turn into a cluster of highly coupled components, write Abedrabbo. This leads to an operational burden, where more components must be deployed, scaled and monitored. This high coupling can also lead to challenging release processes, where many microservices must be deployed in order to deliver a single piece of functionality. 

It can also produce single points of failure, where many services depend on each other, meaning that if one fails it can bring down the entire system.

Abedrabbo also explains that entity services create conceptual complexity, as the knowledge of how to compose them is not immediately obvious. This is because service composition can occur anywhere in the system and is often not straightforward.

The pattern can also lead to easy to make breaking changes:

More subtly, entity services, and shallow services, in general, provide no meaningful mediation or indirection between the interfaces they expose and the functionality they implement. Thus, the client of the system become unwittingly coupled to the implementation details of its services, all the way down to the database. In such situations, it becomes very difficult for the service implementer to modify or optimise the system without breaking everything because of this lack of a buffer between interface and implementation.

Abedrabbo concludes that there is no single approach for decomposing a system into microservices optimally. However, he advises on some best practices. These include driving design from business requirements, hiding information effectively, and avoiding shared contexts between microservices. The decomposition should also avoid the creation of single points of failure, allow parts of the system to be scaled independently, and make it easy to implement new functionality by keeping it within a single microservice boundary.
 

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Who is advocating for Entity Services? by Richard Clayton

I've seen a couple of these articles on InfoQ about Entity Services being an antipattern. Is there an author or community advocating for this approach? I feel like common wisdom already considers this level of service segregation to be fraught with issues.

Re: Who is advocating for Entity Services? by Daniel Bryant

Hi Richard,

I believe a lot of these discussions are happening based on experiences from the field. I've previously worked alongside both Andrew (InfoQ editor) and Tareq (author of the source piece) in a London-based consultancy, and we saw this anti-pattern quite a lot with clients.

I've also had quite a few chats with other consultants (from global consultancies) at conferences like QCon NY recently, who said the same thing. Although all of this is anecdotal, I believe that many engineers are mis-interpreting some of the core principles with microservices, DDD and service design. Hence the increase in the production of articles, and our corresponding coverage.

Best wishes,

Daniel

Re: Who is advocating for Entity Services? by Richard Clayton

Daniel,

Ok, that's fair. It seemed weird since I wasn't seeing any literature from the "other side".

Thanks,

Richard

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT