“WHAT MICROSERVICES NEED TO WORK?”
Welcome to part 2 of our blog series on Microservices – a new approach to IT architecture that replaces monolithic system dinosaurs with highly agile swarms of compact, autonomous, collaborative services, with the coupling between services as loose as possible and cohesion within the individual service as strong as possible.
Such an architecture offers remedies for the immobility and uncontrollability of complex, organically grown systems. JIT has accompanied many clients during such projects and indeed recommends Microservices, provided that all technical and organizational prerequisites are really met.
Organizationally, every thinking should start with “Conway’s Law”. Although already half a century old, it is still valid: Melvin Conway teaches that whenever an organization designs a system, it will inevitably produce a copy of their team and communication structures. A company preparing to migrate to a Microservice architecture will therefore need to think deeply about business process anatomy and the distribution of tasks and responsibilities.
There more so because to achieve minimized coupling between Microservices and maximized cohesion within each service, the services and the underlying data models must be modeled with great care along clear domain boundaries and responsibilities.
Domain-driven design (DDD) is the tool of choice for modeling of this type, especially because it uses bounded contexts to divide the business domain into clearly defined zones like, e.g., Billing, Payment, Shipping etc.
Each “bounded context” defines an explicit interface used by collaborating services from other zones.
If you manage to organize your team structure along such clearly defined domains, your reward will be a clear, efficient Microservice architecture. If not, then not.
With the organizational requirements come the technical prerequisites. The first of those is a high level of automation: Continuous integration/delivery is essential in Microservice-based systems.
Of equal importance is continuous monitoring individual services as well as the entire system. This will prove somewhat more complex than monitoring conventional applications, because involves aggregating multiple servers, log files and metrics like CPU utilization or response times in one central location. Tools like Graylog, Graphite and Nagios will be helpful here.
Once you have checked all these preconditions off the list, the one remaining question is: do you want your future system to play like the Philharmonics? Or should it dance like Nijinsky? What does that mean, imply, and require? Read the answers in part 3 of our blog series.