Micro-oriented architecture services now popular around the world. This is because a faster pace and lower cost deployment is the basic commitment-oriented architecture micro-services.
However, for most companies to test the water, the more the development activity is to convert the existing monolithic applications into service-oriented architecture micro, which may be the source hamper on many levels and conflict.
Although Greenfield (undeveloped) micro-services-oriented architecture implementation can adhere to a strict interpretation of the current micro-services - design principles. But in the micro-services-oriented architecture, there is a break down of legacy applications shades of gray, if for no other reason but to meet budget and time constraints.
Somewhere in the chain of business management, business executives view there is a decomposition of costs associated with those legacy applications in the architecture of a micro-oriented service, and compares it with the value of legacy code already provides. Once the development costs exceed the expected benefits, business executives are likely to withdraw and cancel the project.
Such things often happen.
Therefore, the development manager is facing tremendous pressure, ask them to output the code as soon as possible. "Good enough" to be the ideal target transformation.
Now, this is not necessarily a bad thing. Compared with waiting for the arrival of the dream, the ability to work output code is always better. However, the "shades of gray" are difficult to manage, the problem is how to define "good enough" boundaries.
Therefore, the conflict began. Party want to output what they want, while the other wants to make more improvements.
For you, the challenge is not to let these different schools in nature to support the faith point of view of manufacturing a never-ending quarrel. If you do, it will create a situation that does not provide any code. Now, the conflict can synthesize the best ideas from the many competing ideas. However, when the discourse degenerates into endless conflict, it can be fatal.
I'll handle this type of situation through three focus on the following issues, in order to avoid such conflicts:
- What is the reason for the design?
- How much risk?
- What risk reduction plan?
Allow me to elaborate.
1. The design is no reason?
When you evaluate the design of micro-oriented architecture services, the challenge is to transfer to the last point of the basic theory. It is created mainly from the decomposition of a single application. Any design is possible "good enough", as long as you can prove its benefits and value.
For example, one of the preferred style of service-oriented architecture micro design is the use of event-driven method of inter-service communication. Specifically, this means that you use the message node asynchronously transfer messages between the micro-services. However, in the long run, though asynchronous communication more flexible and scalable, but the message system to implement than synchronous design uses HTTP calls between API "for" micro-services much more complex. Therefore, the time when the market is concerned, have every reason to be characteristic of monolithic applications reconstructed as a separate service to micro HTTP API that are represented.
与异步服务相比，同步微服务的实现通常不那么复杂。
In the long run, synchronous communication is not necessarily the best choice, but taking into account all the other work required to extract an independent micro-services from a single block of application, synchronization for the first version is "good enough". So this is a good reason.
However, this does not mean synchronization method without risk. In fact, there are many risks. When it comes to architectural design review services for micro, only reasons not the only factor. Risk must also be explained.
2. How much risk?
All designs have inherent risks. In the design example described above, the synchronization, the inter-service communication method which may cause the risk of coupling between the service type, due to the asynchronous nature of HTTP communications and other communications and increasing the delay increase the delay.
It is important to make people aware of these risks so that you can weigh them according to the rationality of the intended design. If the risk is huge, no amount of reason is not enough. On the other hand, given the current demand, some risks may be acceptable. The trick is to ensure that the risks are clearly communicated in the review process. Known risk discussion is always preferable to the hidden risk, and this risk may impact on the road. Also, if you previously aware of the risks, then with the micro-architecture for mature service, you can plan how best to move forward in a future release. This is why risk reduction.
3. What is the risk reduction plan?
A sign of a wise application designers is the ability to identify their design risk, once finalized he will articulate visionary a way to mitigate these risks. Without proper risk mitigation techniques recognition is thinking incomplete flag.
If the micro-architecture design services for marginal significant risks and plan to solve these problems, the design team needs to seriously consider its feasibility. In addition, if the mitigation plan unrealistic - beyond the expertise and budget projects - feasibility of the design also needs to be questioned. This is a question of balance.
Architecture design a good balance of micro-oriented services is justified because it wants to meet the conditions of its inherent design aims to address these risks and risk mitigation plans with trade-offs.
4. put them together
Conflict is an essential part of the creative process. Creative people often gritty of their own ideas. So, when you put them in a room and let them serve as a micro-oriented architectural design of a single design, it will certainly exacerbate tensions. That's the way. But take heart! Conflict is a good thing.
Fortunately, with a rational approach, with three problems I described earlier to review the architecture design for micro-services, you can promote an objective discussion, resulting in software, and when to meet your needs. No design is perfect, especially those designed to break down a single application. However, the micro-architecture for the delivery of services has a great advantage of this architecture is good enough effective functioning in the short-term and long-term flexibility sufficient continuous improvement.
Author: Bob Reselman
Translator: Lost dawn