Application architectures have evolved over years in various ways like shown below
So as you can see idea behind micro services is to divide a large monolithic web app to smaller pieces.
So why Microservices?
- Build and operate service at scale
- Improved resource utilization to reduce cost (especially considering cloud deployments)
- Fault Isolation
- Continuous Innovation
- Small Focus teams (e.g. ‘two-pizza team’: If you can’t feed a team with two pizzas, it’s too large.
- Can be written in any language and framework.
What are Microservices?
- Autonomous – A microservice is a self-contained unit of functionality with loosely coupled dependencies on other services.
- Isolated – A microservice is a unit of deployment that can be modified, tested and deployed as a unit without impacting other areas of a solution
- Elastic – A microservice can be stateful or stateless and can be scaled independently of other services
- Resilient – A microservice is fault tolerant and highly available
- Responsive – A microservice responds to request in a reasonable amount of time
- Intelligent – The intelligence in a system is found in the endpoints not on the wire. ESB is an anti-pattern to Microservices.
- Message Oriented – Microservices rely on asynchronous message-passing to establish a boundary between components and Applications are composed from multiple microservices
- Programmable – Microservices provide API’s for access by developers and administrators
- Configurable – Microservices provide an API and/or a console that provides access to administrative operations
- Automated – The lifecycle of a microservice is managed through automation that includes dev, build, test, staging, production and distribution
- Evolutionary – Can be developed alongside existing monolithic applications providing a bridge to a future state
- Open – Language agnostic APIs, Highly decoupled
- Resilient – No monolith to fall over, designed for failure
- Speed of Development – Adding, updating and maintaining services and can be done at velocity
- Reuse – Reusable and Composable
- Deployment Governance – Services are deployed independently
- Scale Governance – On-demand scaling of smaller services leads to better cost control
- Replaceable – Services can be rewritten and replaced with minimal downstream impact
- Versioned – New API’s can be released without impacting clients that are using previous API’s
- Owned – Microservices are typically owned by one team from development through deployment
Challenges with a Microservices Approach
- Communication is Key – Communication across teams becomes critical
- Automation is not an Option – Speed of change requires investment in automation
- Platform Matters – Your platform must support elastic scale and resilience.
- Versioning must be Supported – Composability requires versioning
- Testing – Unit, inter-service, extra-service, composition testing
- Discoverability – The ability to locate services in a distributed environment without being tightly coupled