Saturday, November 8, 2014

Microservices Architecture - Finding The Sweet Spot

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.

Friday, May 2, 2014

Emergent software design?

Software seems to be the only area where we often try to combine designing a system with building it. Or declare that one should just start building it and the design will emerge.

Perhaps this is because in the material world, limitations of physics, materials properties and manufacturing processes are intuitively understood by non-specialists.

Building a house is a good example: a house is a composite of multiple subsystems: structural, electrical, plumbing, HVAC and so on. These subsystems won't just evolve independently to end up well-enmeshed in a coherent whole, and no future homeowner would assume such a thing and tell their contractors to just start building the house and not worry about blueprints.

Yet software has very real limitations in terms of complexity, physical resource utilization efficiency and so on, but these are not intuitively obvious to non-technologists. It is very easy to build something that appears functionally correct but is crippled in terms of scalability, maintainability, scalability, stability and so on.

So while not every detail has to be figured out and specified in advance, overall structure/architecture and how different subsystems should interact does need some forethought and definition.