Microservices architecture has been more in the spotlight lately, and with good reason.
As I wrote before in Loose coupling and integration - the pendulum swings, splitting execution into multiple processes requiring remote invocation isn't free however.
In my recent discussions with many practitioners, I noticed that microservices architecture is typically put forth in opposition to a more coarse-grained approach where multiple domains are lumped together, sometimes resulting in a 'God service' or 'everything service' anti-pattern.
However, it's dangerous to posit that more services is always better and create incentives to which teams and managers might respond - e.g. how many services did your team create last quarter? Nice, but that other team created twice as many!
So how to find the sweet spot in this spectrum? My answer is not to lump conceptually unrelated domains together. Another rule of thumb would be to look at persistence domains - if data/persistence architecture segregates domains properly, they should be exposed via separate service interfaces.
Fundamentally, services are simply public interfaces for domains. Each domain should have at least one. But creating too much fragmentation within each domain, exposing separate services for interrelated concerns shifts burden onto clients in terms of discovery, orchestration and invocation latency.
Ultimately, the goal of service interface design should be to allow clients to reason about the domain the service represents and integrate with it as simply and efficiently as possible.
Martin Fowler provides an excellent write-up on microservices here.
As I wrote before in Loose coupling and integration - the pendulum swings, splitting execution into multiple processes requiring remote invocation isn't free however.
In my recent discussions with many practitioners, I noticed that microservices architecture is typically put forth in opposition to a more coarse-grained approach where multiple domains are lumped together, sometimes resulting in a 'God service' or 'everything service' anti-pattern.
However, it's dangerous to posit that more services is always better and create incentives to which teams and managers might respond - e.g. how many services did your team create last quarter? Nice, but that other team created twice as many!
So how to find the sweet spot in this spectrum? My answer is not to lump conceptually unrelated domains together. Another rule of thumb would be to look at persistence domains - if data/persistence architecture segregates domains properly, they should be exposed via separate service interfaces.
Fundamentally, services are simply public interfaces for domains. Each domain should have at least one. But creating too much fragmentation within each domain, exposing separate services for interrelated concerns shifts burden onto clients in terms of discovery, orchestration and invocation latency.
Ultimately, the goal of service interface design should be to allow clients to reason about the domain the service represents and integrate with it as simply and efficiently as possible.
Martin Fowler provides an excellent write-up on microservices here.
