http://www.woshipm.com/it/2844056.html
Strongly agree, for complex business, distribution and development team can learn from.
“
This company level "micro-services (Microservice)" benefits of architecture is that each team can quickly develop their own part, without considering other teams - they can use their own database, its own technical library, its own internal design - but, finally we must pass the API so that other teams can call these services without the knowledge of their internal principles.
Then, between teams can quickly and flexibly to call other people's services, data through the API, without having to cross-team collaboration meetings tear force each other. The API enables fast, flexible, reusable, and loosely coupled characteristics - this time, the team can continue to iterate internal evolution, as long as the external API normal work on it.
In addition, Dirk also proposed another architecture point of view, it is "two-nil always good."
That is, since the team is working in highly distributed, it is likely there will be two teams inadvertently come up with the same height or something similar.
This is no problem.
Because they allow several teams to work quickly to do the same job, than to let them spend days, weeks or even months to tear force, and ultimately arrive at a common solution is much more valuable. Although there is some redundancy final thing, but always avoided meeting worthless tear force.
Finally, if necessary, several projects can be combined, or over time, a project to overcome / replace another project.
However, considering the two teams at the same time made it a relatively low probability of success - after all, Amazon encourages rapid, bold experiment, but most of the experiments ultimately failed (remember what Fire Phone) - Horse racing between internal teams actually appear, to see which really run out, is not the problem.
”