Micro Services Series - Micro-service concept

A. Why do we need micro-services.

1. The use of traditional monolithic architecture (Monolithic Architecture) application development systems, such as CRM, ERP and other large applications, with the increasing demand for new, corporate updates and fixes large monolithic applications become more and more difficult;
2. With the development of mobile Internet, companies are forced to migrate their applications to modern UI interface architecture for compatible mobile devices, which requires companies to achieve rapid on-line application functions;
3. Many enterprises have limited the return on investment in SOA, SOA can be realized through a standardized service interface reuse capability, but for rapidly changing needs, limited monolithic applications, sometimes appeared to be inadequate;
4. With the growing popularity of cloud applications, cloud applications was born with a different technology with traditional IT development and gene operation and maintenance mode.

II. A large number of open source cloud computing and lightweight technology constantly emerge and maturing

1. Internet / Intranet / Internet is more mature;
2. Technologies emerge lightweight runtime (node.js, WAS Liberty, etc.);
3. New methods and tools (Agile, DevOps, TDD, CI, XP, Puppet, Chef ...);
4. The new lightweight protocol (RESTful API interface, a lightweight messaging mechanism);
5. Simplified Infrastructure: Operating system virtualization (hypervisors), containerization (eg Docker), Infrastructure as a Service (IaaS), workload virtualization (Kubernetes, Spark ...) and so on;
6. Service platform (PaaS): with automatic scaling cloud services platform, workload management, SLA management, messaging, caching, building management and other services on-demand;
7. Alternatively new persistence data model: As NoSQL, MapReduce, BASE, CQRS the like;
8. Standardization Code Management: The Github like.

III. What is Micro Services

Micro Services is an architectural style, a large and complex software applications by one or more micro-service. Each micro service system may be independently deployed between the respective micro-services are loosely coupled. Each micro serve only to focus on and complete a task well done the task. In all cases, each task represents a small operational capacity.

The concept of micro-services from March 2014 Martin Fowler wrote an article "Microservices" .

Although the "micro-services" such architectural style no precise definition, but it has some common features such as the ability to organize around business services, automated deployment, intelligent endpoints, to "de-centralization" of language and data control, and so on.

Thinking micro-services architecture is applied from the overall contrast generated.

Wherein the application component package approach is the primary difference between the overall structure and the micro-service architecture, micro-architecture service business logic and associated data in a boundary formed with independent, the purpose can be applied without affecting other components (Micro faster delivery and launch services market case) is.

Some common features 3.1 micro Services Architecture

According to the analysis MartinFowler of micro-services architecture has some less common features, but not all micro-service architecture application must have all of these features:

1. By application of the service implementation component (Componentizationvia Services): Micro service framework will be defined as a software component units are replaced independently and upgrade, the application may be divided into micro-architecture design independent deployment and upgrade service mode by cutting the overall application conduct component design.
2. Around business organization's ability to service (Organizedaround Business Capabilities): micro-service architecture to take to the operational capacity as a starting point organization services strategy, therefore, micro-service team's organizational structure must be cross-functional (eg: both pipe applications, also pipe database), strong DevOps with the development of integrated operation and maintenance team, these teams are usually not too large (such as: Amazon's "Two pizzateam" - no more than 12 people).
3. Product rather than a project mode (Productsnot Projects): The traditional application model is a model project team to develop a complete application development after the completion of delivery to the operation and maintenance team is responsible for maintenance; micro Services Architecture is advocated as a team should be responsible for the development of products like a "micro-service" complete life cycle, advocates "who develop, who operate" the development of an integrated approach to operation and maintenance.
4. Intelligent endpoints of the flat pipe (Smartendpoints and dumb pipes): Micro service architecture advocated related business logic communication between components / assemblies in the intelligent terminal side rather than on the communication module, the communication mechanism or loosely coupled components should be as simple and . RESTful HTTP protocol and lightweight asynchronous message routing mechanism provides only the function of micro-service architecture, the most commonly used communication mechanism.
5. "Decentralized" management (DecentralizedGovernance): monolithic applications tend to adopt a single technology platform, micro-service architecture are encouraged to use the right tools to complete their task, each micro-services can be considered to select the best tools to complete (such as different Programming language). Technical standards for micro-services tend to look for other developers have successfully verified the technology to solve similar problems.
6. "Decentralized" Data Management (DecentralizedData Management): micro-services architecture advocate Methods diversity persistent (PolyglotPersistence), so that each micro-manage their own service database and allows different micro-services using different data persistence technology .
7. Infrastructure automation (InfrastructureAutomation): cloud deployment and automation technology greatly reduces the micro-services building, deployment and operation and maintenance of the difficulty, through the application of continuous integration and continuous delivery methods can help achieve the purpose of accelerating the introduction of the market.
8. Troubleshooting Design (Designfor failure): One of the consequences brought about by micro-services architecture is fault tolerant mechanism of failure for each service must be considered. Therefore, the micro service attaches great importance to the establishment of real-time monitoring and logging mechanisms architecture and business-related metrics.
9. Evolutionary Design (EvolutionaryDesign): Micro pay more attention to quickly update service application, so the system will continue to count change and evolution over time. Design of micro-services affected the life cycle of a business function and other factors. As an application is monolithic application, but gradually evolved towards the direction of the micro-architecture application, monolithic applications remains at the core, but the new features will be provided by the application using the API to build. Another example is in a micro-service applications, the modular design of the basic principles of substitutability, found that after the implementation of a two micro-services often must be updated at the same time, this is likely to mean that it should be merged into a micro service.

About some of the more conceptual clarification:

1. In the same context the comparison makes sense:
   1) micro Services Architecture vs. SOA - both architectural style category, but areas of concern involving a range of different. SOA is more concerned about the enterprise scale range, micro Services Architecture is more concerned with the scope of application of the scale.
   2) micro vs. service component service components - both of which are described in the specific implementation of the business functions, except that different particle size, in addition to differences in manageability, flexibility.

2. Conceptual confusion inappropriate comparison
   1) micro-services vs. SOA - an inappropriate comparison. Micro Services is a component category, while SOA is an architectural style. Therefore, comparisons should be micro-service architecture and SOA.
   2) micro-services vs. API - an inappropriate comparison. API is an interface, is a mechanism for business functions exposed. Micro-service architecture is a component architecture for implementing business functions. They are therefore a direct comparison does not make sense.
   3) micro-service vs. service - an inappropriate comparison. "Services" under different scenarios have different meanings, it is necessary to further clarify its description of the context, it refers to the service implementation, service exposure, service definitions or other? Micro Services is also true, need to have the specific context before determining whether the comparison makes sense.

3. Comparison of micro-service architecture and SOA architecture

Features	SOA	Micro Services
Component Size	Large pieces of business logic	Separate task or small business logic
coupling	Usually loosely coupled	Always loose coupling
Structure of company	Any type	Small, focused on cross-functional team
management	Focus on central management	Focus on decentralized management
aims	Ensure that applications can interoperate	The implementation of new features, the rapid expansion of the development team

IV. Advantages and disadvantages of micro services

Advantage of 4.1 micro services

1. Each service is relatively simple, only focus on a business function.
2. Micro-service architecture is loosely coupled manner, can provide greater flexibility.
3. Micro service can be developed using the best and most appropriate of different programming languages ​​and tools that can be targeted to solve specific problems.
4. Each micro-services developed independently by different groups, independently of each other, accelerate the speed to market.
5. Micro Services Architecture is a huge driving force for sustainable delivery (CD), allowing at the same time frequently publish different services to maintain the availability and stability of the rest of the system.

Shortcoming 4.2 micro services

1. Operation and maintenance expenses and costs: the overall application may only be deployed to a small cluster application services area, while the micro-service architecture may become a need to build / test / deploy / run dozens of independent service, and may need to support multiple languages and the environment. This results in a unitary system if composed of 20 micro-services, may require 40 to 60 processes.
2. There must be a solid DevOps integration operation and maintenance skills development: Developers need to be familiar with the operation and maintenance of production environment, developers also need to have the necessary data storage technologies such as NoSQL, who has strong skills DevOps more scarce, will bring recruitment the challenges.
3. It will have a new interface after the system is divided into a plurality of components, which means that a simple cross changes may need to change many components, and the need to coordinate the release with: implicit interface and interface matching. In a real environment, a new release may be forced to release a large number of services at the same time, due to the significant increase in integration points, micro-services architecture will have a higher release risk.
4. Repeat Code: Some underlying functionality to be used by a plurality of services, in order to avoid a "synchronous coupled into the system", it is sometimes necessary to add some code to a different service, which will lead to code duplication.
5. Complex distributed systems: as a distributed system, the micro services introduces complexity and a number of other problems, such as network latency, fault tolerance, message sequence of unreliable networks, asynchronous mechanism, versioning, differentiated work load, etc., developers need to consider more than the distributed system problems.
6. Asynchronous mechanism: micro-services tend to use asynchronous programming, news and parallelism, if there is cross-application service micro transactional processing, its implementation mechanism will become complicated.
7. Can be challenging test of: in a dynamic environment interaction between the service will have a very subtle behavior, it is difficult to visualize and fully tested. Classic micro-services tend to be less emphasis on testing, more is by monitoring the abnormal production environment, and then quickly roll back or take other necessary action. However, special precautions need to avoid regulatory scenario or production environment error will have a significant impact for the special care risks.

4.3 micro-services architecture trade-offs

1. In the right project, the right team, the use of micro-service architecture benefits will outweigh the costs.
2. Micro-service architecture has many attractive places, but prior to embrace micro services, but also need to recognize the challenges it brings.
3. The need to avoid in order to "micro-services" and "micro-services."
4. The introduction of micro Services Architecture Strategy - For traditional businesses, the beginning may be considered suitable in principle part of the introduction of micro-services architecture to transform the existing system or new micro-service applications, and gradually explore and experience accumulated micro-service architecture, rather than opt for the implementation of micro services architecture.

Resources:
micro-services architecture (a): What is a micro-service
micro Services Architecture (2): The integration of micro-enterprise integration services architecture
micro Services Architecture (III): Micro-service remodeling applications and IBM solutions
Microservices
What is a micro-service architecture ?