In a Microservice Architecture the components that make up the software are discretely deployed and executed. That usually means that at least all tiers are separated, and potentially every logical discrete part “runs in their own service”.
The advantages of this architecture are:
- Collaborative development: Each component can be owned, developed and maintained by dedicated teams, that can focus on their component(s) and the “users” thereof; open ended scalable “bee hive” structure
- Resiliency Patterns are exploitable: Less complicated components themselves can be easier safe-guarded against failure, interaction between components can be made explicitly resilient against temporary or permanent failure; making the overall application a highly resilient organism
- Elastic resource use: each individual component can be scaled to match the actually consumed resources at any given time (assumes that components are accordingly separated)
All that comes at a price, which makes the pattern unfitting especially for early-stage application development, or most scenarios which do not involve Continuous Development (i.e. “one-off” creation of applications that have a constant load and no or little changes). Hence the disadvantages are:
- Added deployment complexity: Orchestrating the deployment of multiple components, that inter-depend, is no piece of cake.
- Added development complexity: Communicating within a distributed application is harder than within a monolith; more things can go wrong
- Added organisational complexity: With having ownership of components, there is still the need for someone taking on responsibility / perspective of the whole
- Unclear responsibility: due to ownership of parts, people may ignore problems because they are cloaked by a SEP field
Hence this pattern lends itself especially to mature applications, that are continuously developed and/or have non-constant load patterns.
Source
Related
- Monolith Architecture
- Resiliency Patterns
