đź”—Overview
The term “Microservice Architecture” describes a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics, including organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
We see microservices as being a logical partner of the API-first development approach, in which complex applications are composed of small, independent processes that communicate with each other using language-agnostic APIs. These services are small, highly decoupled and focus on performing a small task.
đź”—Properties of the Microservices architecture:
- The services are easy to replace
- Services are organized around capabilities, e.g. user interface frontend, recommendation, logistics, billing, etc.
đź”—A microservices-based architecture:
- Lends itself to a continuous delivery software development process
- Is distinct from a Service-oriented architecture (SOA) in that the latter aims at integrating various (business) applications whereas several microservices belong to one application only
đź”—Products not projects
Most application development efforts that we see use a project model where the aim is to deliver some piece of software which is then considered to be completed. On completion the software is handed over to a maintenance organization and the project team that built it is disbanded.
Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime. A common inspiration for this is Amazon’s notion of “you build, you run it” where a development team takes full responsibility for the software in production. This brings developers into day-to-day contact with how their software behaves in production, and increases contact with their users, as they have to take on at least some of the support burden.
The product mentality ties in with the linkage to business capabilities. Rather than looking at the software as a set of functionality to be completed, there is an ongoing relationship where the question is how can software assist its users to enhance the business capability.
đź”—How big is a microservice?
Although “microservice” describes an architectural style, it’s name does lead to an unfortunate focus on the literal size of a service, and arguments about what constitutes “micro”.
The largest sizes we see follow Amazon’s notion of the Two Pizza Team (i.e. the whole team can be fed by two pizzas), meaning no more than a dozen people. On the other end of the spectrum, a single developer could easily be responsible for multiple services.
