The Microservices Architecture (MSA) is a specialisation of the Service Oriented Architecture (SOA) helping with cohesion and decoupling. MSA is leveraging and enabling recent developments like Cloud Computing, Tribes and DevOps with Continuous Delivery of services.
Autonomy with Microservices
Well designed Microservices follow functional cohesion. They bring together a user or business requirement in a service, e.g. a recommendation engine for products for an online retailer. Note, this is different to the logical cohesion strived for in traditional SOA that often gravitates to a technical grouping of functionality closer related to what packages or classes are in OOP. Decoupled microservices can have autonomy and achieve reuse in a business or user context instead of implementation context. For example, the online retailer may orchestrate multiple microservices like the recommendation service to make up its web portal for end customers. And it may use the same recommendation service in different apps for them or use it behind an API for its marketplace business users.
Development and Operation
The autonomy (and usually small size) of microservices also extend to its development and operational aspects. A service provides a contract, i.e. a stable API and SLA. Hence, it can evolve and operate independently as long as it adheres to the contract. Consequently, small independent teams like tribes can take over the development and operation of the services.
The well-defined nature of the microservice further lends itself to automation in testing, deployment and fast iterations in an Agile environment. At the same time, containing operations and technical debt within the development team leads to balanced priorities and a DevOps culture.
We build, test, run, monitor, scale and fix it; we own it.
Cloud Computing, including IaaS standards like OpenStack or DCOS like Mesos, enables practical microservices. If microservices required physical hardware purchases and ownership, it would break with its flexibility. They would be exceedingly expensive since small or flexing services would require massive infrastructure to maintain its SLA. The benefits of private/hybrid/public cloud computing give microservice tribes essential independence and flexibility.
The benefits come at a cost. Some are organisational, and some are governance related. Full autonomy of microservices and tribes would lead to wildly diverging tooling and practices. Imagine each tribe working with a different toolchain and varying standards. They effectively become engineering and data silos. It becomes hard for individuals to transition between them, e.g. to help scale a team, to share standards or just for personal learnings. And it can be difficult for an organisation to report on, analyse and tap into the data assets it has, i.e. ‘do’ big data with it.
The solution is not to have a top-down dictated monoculture of technologies. There should be natural variation between the tribes on standards and technologies. However, the divergences should be driven by demonstrable and sustainable needs. The organisation should come together decide the collective capabilities needed and pick a set of accepted technologies to implement them. Imagine if every tribe choose a different version control, job automation server, configuration management tool, streaming engine and so forth. The chaos would be unmanageable. How do you transition staff, how do you train, how do you get enterprise support and so forth. The overhead and friction would be excessive.
There is a lot to be said on the data side of microservices. Maybe in a future post.