Overview#Microservices 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.
- Bounded Context - which includes both the Domain Logic and Data needed to accomplish the goal.
- Single Responsibility Principle - Microservice should focus on small areas such as a "Method" or "Class" within a "Monolithic" application
- Isolation to the point that communication with Microservices is through language-neutral Protocols, typically an (HTTP)-based resource API, such as REST.
Bounded Context is an absolutely essential characteristic of Microservice. We need to be able to deploy a single Microservice on its own. There must be zero coordination necessary for the deployment with other Microservice. This Bounded Context enables frequent and rapid deployments, therefore getting much-needed features and capabilities to the consumers.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. A Microservice should have its own source code management Source code 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.Bounded Context and they communicate with each other over protocol, there is no reason they can not be written with different programing languages, even the same Microservice could be Polyglot. This implies Microservice should be defined as an Interface Description Language
Having a Bounded Context allows using the correct tool for the correct job is important. Microservice need to be built using the programming language and technology that makes the most sense for the task at hand. Microservice 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 (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.
- 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 Bounded Context with its own domain logic and Data Store.
- 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:
- Access Control Policy
- Domain Logic
- Functions as a Service
- OAuth Scope Example
- Remote Procedure Call
- Smart endpoints and dumb pipes
- Web Blog_blogentry_010317_1
- Web Blog_blogentry_040817_1
- Web Blog_blogentry_160515_1
- Web Blog_blogentry_230717_1