Services and composition
Lately i have been giving some thoughts about service design and services composition in order to save network transversal. How chunky should a service really be?
Should we aggregate unrelated data in a single call (compostion), in order increase the chunkiness of a service and reduce network calls? Unrelated in a business sense, but are somehow related (to be read, will be used together somehow by a caller).
I've been keeping these thoughts to myself, but his post from Rich Turner trigered this post. A question formulated in the form of an answer in the hope someone provides me with the answer. :-)
Rich states two rules:
- “avoid the network wherever possible“. Otherwise stated - only traverse the network if you must and only pass across the network what you have to.
- Design your services to map to your business rather than mapping to the way your IT systems work internally
In order to achieve a balance, these rules have to be bended somehow since they are normally contradictory and you can't have it both ways.
Suppose you have two generic and independent services. One exposes a service that allows you to get a list of world ZIP codes your system supports, the other a list of countries (contrived example, i'm sure you could think of something better).
From a business sense there isn't any sense in putting these two together (and if there is, let's suppose there isn't for the sake of the argument),but suppose from a calling system point of view they make sense together, and somehow the system needs both data at the same time. Should we compose these two services into a single one, in order to save one network call for a single system? if other systems would never make calls to this composed service.
Should we violate rule number 2 in order to increase the use of rule number 1? when does it make sense to compose and aggregate services performance wise, even when it doesn't make sense business wise?
When should be the thin line crossed? what is the right balance?