By Martin Heller
What does “big enough” mean? It’s sometimes useful to argue by reductio ad absurdum. Hello, world doesn’t need to be broken down into smaller services. At the other extreme, building a monolithic enterprise resource planning (ERP) system is just asking for trouble: it’s too big, and it needs to be decomposed.
Find a balance
Where’s the middle ground? It depends. You want fine-grained units of execution that do one thing really well, according to Jason Bloomberg, and he cites one of Sam Newman’s rules of thumb for the meaning of “fine-grained, “cited in his book, Building Microservices: Designing Fine-Grained Systems—small enough to be managed by a single team.
Bloomberg also suggests looking at services through parsimony. If a service looks cohesive and deals only with a single concern, then it’s probably small enough. If, on the other hand, you look at a service interface and see a number of different concerns being combined, perhaps it’s a candidate for further decomposition. At the other end of the spectrum, if the service doesn’t do enough to feel useful, perhaps you overdid the decomposition and need to combine it with a related service. It’s very much like the game of “find the objects” that people played when designing object-oriented software 25 years ago, but now the objects are services, not classes.
Read the entire article at http://techbeacon.com/why-your-project-may-not-be-ready-microservices.
