!!! Overview
[{$pagename}] When building communication structures between different processes, we have seen many products and approaches that stress putting significant smarts into the communication mechanism itself. A good example of this is the [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: [{$pagename}]. 

Applications built from [{$pagename}] 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. 

Typically, these are choreographed using simple [REST]ish [protocols] rather than complex protocols such as [WS-Choreography] or [BPEL] or orchestration by a central tool.

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
}}}

[{$pagename}] 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.[{$pagename}] or something similar is a requirement to do Internet 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.!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]