When Services Attack

Lately, I’ve been hearing about some nightmares when considering bad service design. They fall into three basic problem areas:

First, services that are too course grained, and thus are basically cumbersome applications until themselves, not services. We’ll call that one the “Fat Service” problem. Developers are asked the reuse this beast, and can’t really find a use for it since it is an all-or-nothing proposition, providing too much bulk for a single service. How would you like to deal with a service called General_Ledger? This issue has typically be caused by developers that learned early on that course grained services…good…fine grained services…bad. That’s not always the case.

Second, and as you guessed, are services that are too fine grained, decomposed to nothing, and do a very good job in saturating the network as very heavy HTTP calls are made (of course, you don’t have to use Web services). We can call this the “Skinny Service” problem. I think the developers actually had good intensions here, but just go carried away, assuming that thousands of services can plug into a composite, and it will all be good. It won’t.

Finally, poorly designed services, or services that perhaps are the right weight, neither fat, nor skinny, but the way the service is structured leaves a lot to be desired. Poorly designed interfaces are the bulk of the issues that I see, as well as services that are, well, not built like services. The end result is something that needs to be redone from scratch, going through a good service design process, re-implemented, and tested. We’ll call this the “Ugly Service” problem.

So, what’s a service builder to do? It’s really not complicated. Services contain certain patterns that should be considered during design. I’ll hit upon those patterns in the future. I hope your services are never fat, skinny, or ugly.