Overview#The terms Microservice and "Microservice Architecture" has sprung up over the last few years to describe a Software Architecture Model in which large complex software applications are composed of one or more independently deployable services.
While there is no precise definition of this Software Architecture Model, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data.
Small & Focused#Microservice need to focus on a unit of work, and as such they are small. There are no rules on how small a Microservice must be. A typically referenced guideline is the Two-Pizza Team rule, which states if you cannot feed the Delivery Team building a microservice with two pizzas, your microservice is too big. You want to make the Microservice small enough so that you can rewrite and maintain the entire microservice easily within a Delivery Team if you need to.
A Microservice also needs to be treated like an application or a product. It should have its own source code management repository, and its own delivery pipeline for builds and deployment. Although the Product Owner might advocate the reuse of the Microservice, reuse is not the only business motivation for Microservices. There are others such as:
- localized optimizations to improve User Interface (UI) responsiveness
- to be able to respond to customer needs more rapidly.
Microservice granularity can also be determined based on business needs. Package tracking, car insurance quote service, and weather forecasting are all examples of services delivered by other third-party service providers, or delivered as a core competency chargeable service.
Loosely Coupled#Loose coupling is an absolutely essential characteristic of microservices. We need to be able to deploy a single microservice on its own. There must be zero coordination necessary for the deployment with other microservices. This loose coupling enables frequent and rapid deployments, therefore getting much-needed features and capabilities to the consumers.
Language Neutral#Using the correct tool for the correct job is important. Microservices need to be built using the programming language and technology that makes the most sense for the task at hand. Microservices are composed together to form a complex application, and they do not need to be written using the same programming language. In some cases Java might be the correct language, and in others it might be Python, for example.
Communication with microservices is through language-neutral APIs, typically an Hypertext Transfer Protocol (HTTP)-based resource API, such as REST. You should standardize on the integration and not on the platform used by the microservice. Language-neutral makes it easier to use existing skills or the most optimal language.Bounded Context.
- Componentization as a Service: bringing certain components together to make a customized service.
- Organized Around Business Capabilities: segregating capabilities for specific business areas like user interface and external integrations.
- Development Process is Based on Products Not Projects: following Amazon’s “eat your own dog food,” developers stay with the software for the product’s lifetime.
- Smart Endpoints and Dumb Pipes: each microservice is as decoupled as possible with its own domain logic.
- Decentralized Governance: enabling developer choice to build on preferred languages for each component.
- Decentralized Data Management: having each microservice label and handle data differently.
- Infrastructure Automation: including automated deployment up the pipeline.
- Design for Failure: meaning that more ongoing testing of “what if” has to occur to prepare for failure.
Project vs Product Mentality#Most application development efforts that we see use a project Mentality:
- where the aim is to deliver some piece of software or service which is then considered to be completed.
- On completion the software is handed over to a maintenance organization a
- project team that built it is disbanded.
The product mentality, ties in with the linkage to business capabilities. Rather than looking at the software or service as a set of functionality to be completed, there is an on-going relationship where the question is how can software assist its users to enhance the business capability.Enterprise Service Bus (ESB), where ESB products often include sophisticated facilities for message routing, choreography, transformation, and applying Business Logic.
The Microservice community favors an alternative approach: smart endpoints and dumb pipes.
Applications built from Microservice aim to be as decoupled and as cohesive as possible - they own their own domain logic and data and act more as filters in the classical UNIX sense - receiving a request, applying logic as appropriate and producing a response.
The two protocols used most commonly are HTTP request-response with resource API's and lightweight messaging. The best expression of the first is
Be of the web, not behind the web -- Ian Robinson
Microservice teams use the principles and protocols that the world wide web (and to a large extent, Unix) is built on. Often used resources can be cached with very little effort on the part of developers or operations folk.
Microservice or something similar is a requirement to do WEB Scale products where:
- Brand new deployments are rare.
- New versions deployed automatically and frequently
- No real need for general purpose orchestration
- Each deployment is customized.
Why Microservice#Benefits of using Microservice
Lower Learning Curve -
More Information#There might be more information for this subject on one of the following:
- Domain Logic
- OAuth Scope Example
- Smart endpoints and dumb pipes
- Web Blog_blogentry_010317_1
- Web Blog_blogentry_160515_1