Although the concept of micro-services have been popular for some time, but any technology has its advantages and disadvantages. After seeing decent and micro services while playing villains, ThoughtFocus technical architect Aibin John (Ebin John) issued a document suggested the development, if you are prone to micro-architecture as the default service architect or designer, best ask yourself the following questions.
1. Your application large enough to be subdivided into micro services?
Micro service is a lot of small services carry out their duties, in the ideal case, each service itself is a complete application.
Since the micro-services in terms of manpower and cost calculation requires minimal resources, so it needs a higher cost, even if it is lightweight micro service. And, your code base will be growing in the future, the code base itself may add a new field. But you should always remember: When you are near the threshold, well-designed code base can always switch to micro-services.
2. Do you really need to expand the various components of an application?
Hypothetically. Product Owner you proposed the idea to use Human Resource Management System (HRMS) applications to meet the needs of thousands of people the organization. As a technology enthusiast you immediately have a solution: micro-services architecture.
One of the main advantages of using micro-service architecture is easily scalable single component. You may find a large number of application components need to be extended individually, but your application really need to do it?
3. Your transactions across many services?
Now, this may be one of the most difficult strategic choice to make. Transactions across multiple service burden of the whole structure. To resolve cross-service transaction means: interlock between the service will lead to a series of untraceable impasse, and would endanger the health service, and sometimes even a race condition engineer health.
By definition, REST services are stateless. They should not participate in the boundary is not limited to a service business. In high performance environments, two-phase commit 2PC is unnecessary trouble. The SAGA mode only adds another layer of complexity you're not ready.
Since the micro-serving stick with distributed data management, it brings eventual consistency problem. If a monolithic application, you can update a bunch of stuff together in a single transaction. The micro-services requires more resources to update, and distributed transaction unpopular (which with good reason). Therefore, developers need to be aware consistency.
4. The need for regular contact between the service?
In traditional monolithic services, each service instance micro be represented by the module in the system. The link between modules in memory latency close to zero. The introduction of micro services means that contact by the memory transaction turned into a relay commands through the network.
There are a number of tried and tested solutions, but they all have a price: the delay. From memory transaction instead of network-based contact will become microsecond delay from nanoseconds. Imagine three different services through the network to contact each other. Assuming that each service call takes 100 microseconds (which is not uncommon under load), then in the end it will cost only 300 microseconds on the network.
While on the nature of the application is tightly integrated with components and services. Communication layer could have added real-time data processing applications disastrous consequences.
In addition to these four questions before using the micro-services also need to consider some of its other shortcomings, such as:
1. Complexity
Although originally designed to micro-services applications by breaking into small components to reduce complexity, but the architecture itself is very complex to deploy and maintain.
2. Distribution costs
Micro service is a distributed system with modularity, but the same distribution is indeed a price to pay. You monolithic service will be deployed on a large virtual machine or container of choice. But if it is micro-services, in addition to multiple virtual machines or containers, the service needs to be deployed on independent ideal environment. Of course, the service may be small, but you can calculate the total cost.
3. Adapted DevOps
This may be beneficial or deleterious, if you are a member of the small businesses, the establishment of a DevOps team will be more harm than good. But one thing is certain fall if there is no specific DevOps team, you will not be able to maintain and monitor micro-services.
4. Integrated closely
Some applications are naturally tightly coupled. Distinguish them from the "adaptation" framework will lead to disaster.
5. Lack of experience
It uses for both important considerations for any new technology. But when it comes to micro-services, With an abstract definition of the harm caused in particular.
6. confusing data contract
In a team setting to share data between data contracts and contracts very different team. You are in contact with micro-services, your team may not be in the same area, not to mention team members use the same programming language. Develop data contract will cost you time and space to specific requirements.
7. Debugging
Each service will have its own set of log files to be reviewed, more services mean more log files.
These are some questions to ponder before micro service, you are welcome to leave your own in the comments area