!!! Overview
[{$pagename}]s and "Microservice Architecture" has sprung up over the last few years to describe a [Software Architecture Model] in which large complex software [applications] are composed of one or more independently deployable [services]. 


While there is no precise definition of this [Software Architecture Model], there are certain common characteristics around organization around business capability, automated [deployment|Continuous Delivery], intelligence in the [endpoints], and decentralized control of languages and [data].[1] 


[{$pagename}] is part of the [API Economy]

!! What are [{$pagename}] [2]
While there is no standard, formal definition of [{$pagename}], there are certain characteristics that help identify a style. [{$pagename}] should have: 
* [Bounded Context] - which includes both the [Domain Logic] and [Data] needed to accomplish the goal.
** Implies they have [stateful] [data] can be provide [Consistency] __only__ within each [{$pagename}] but [MUST] be [stateless] between [{$pagename}]
* [Single Responsibility Principle] - [{$pagename}] should focus on small areas such as a "Method" or "Class" within a "Monolithic" [application] 
* [Isolation] to the point that communication with [{$pagename}]s is through language-neutral [Protocols], typically an ([HTTP])-based resource [API] such as [REST] or [gRPC]. 

! [Bounded Context]
Any particular [{$pagename}] does not "know" anything about underlying implementation of other [{$pagename}]s surrounding it. If for whatever reason a [{$pagename}] needs to know anything about another [{$pagename}] (for example, what it does or how it needs to be called), you do not have a [Bounded Context].

[Bounded Context] is an absolutely essential characteristic of [{$pagename}]. We need to be able to deploy a single [{$pagename}] on its own. There must be zero [Orchestration] necessary for the deployment with other [{$pagename}]. This [Bounded Context] enables [Continuous Development] and [Continuous Delivery], therefore getting much-needed [features] and capabilities to the [consumers] and delivering [Business value]

! [Single Responsibility Principle]
[{$pagename}] need to focus on a unit of work, and as such they are small. There are no rules on how small a [{$pagename}] must be. A typically referenced guideline is the Two-Pizza [Delivery Team] rule, which states if you cannot feed the [Delivery Team] building a [{$pagename}] with two pizzas, your [{$pagename}] is too big. You want to make the [{$pagename}] small enough so that you can rewrite and maintain the entire [{$pagename}] easily within a [Delivery Team] if you need to.

A [{$pagename}] also needs to be treated like an [application] or a product. A [{$pagename}] should have its own source code management [Source code] [repository], and its own delivery pipeline for builds and deployment. Although the [Product Owner] might advocate the reuse of the [{$pagename}], reuse is not the only business motivation for [{$pagename}]s. There are others such as:
* localized optimizations to improve [User Interface] ([UI]) responsiveness 
* to be able to respond to [customer] needs more rapidly.

[{$pagename}] granularity can also be determined based on business needs. Package tracking, car insurance quote service, and weather forecasting are all examples of services delivered by other [third-party] service providers, or delivered as a core competency chargeable service.

! [Polyglot]
Since [{$pagename}]s has a [Bounded Context] and they communicate with each other over a [protocol], there is no reason they can not be written with different [programing] languages, even the same [{$pagename}] could be [Polyglot]. This implies [{$pagename}] should be defined as an [Interface Description Language]

Having a [Bounded Context] allows using the correct tool for the correct job is important. [{$pagename}] need to be built using the programming language and technology that makes the most sense for the task at hand. [{$pagename}] are composed together to form a complex [application], and they do not need to be written using the same programming language. In some cases [Java] might be the correct language, and in others it might be [Python], for [example].

Communication with [{$pagename}]s is through language-neutral [APIs], typically an (HTTP)-based resource [API], such as [REST]. You should standardize on the integration and not on the platform used by the [{$pagename}]. Language-neutral makes it easier to use existing skills or the most optimal language.

!! Characteristics of a [{$pagename}] [Architecture] [1]
While [{$pagename}] is still more of a concept than a predefined [architecture] with specific requirements, Lewis and Fowler say there are certain attributes that typically come with microservices, including:
* Componentization as a Service: bringing certain components together to make a customized service.
* Organized Around Business Capabilities: segregating capabilities for specific business areas like user interface and external integrations.
* Development Process is Based on [Products] __Not Projects__: following [Amazon]’s "eat your own dog food", developers stay with the software for the product’s lifetime.
* [Smart endpoints and dumb pipes]: each [{$pagename}] is [Bounded Context] with its own domain logic and [Data Store|DataStore].
* Decentralized Governance: enabling developer choice to build on preferred languages for each component.
* Decentralized [Data] Management: having each microservice label and handle [data] differently.
* Infrastructure Automation: including automated [Continuous Delivery] up the pipeline.
* Design for Failure: meaning that more ongoing [testing] of "what if" has to occur to prepare for failure.

! Project vs Product Mentality
Most application development efforts that we see use a project Mentality: 
* where the aim is to deliver some piece of software or service which is then considered to be completed. 
* On completion the software is handed over to a maintenance organization a
* project team that built it is disbanded.

The product mentality, ties in with the linkage to business capabilities. Rather than looking at the software or service as a set of functionality to be completed, there is an on-going relationship where the question is how can software assist its users to enhance the business capability.

!! [Smart endpoints and dumb pipes]
When building communication structures between different processes, we've 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 [{$pagename}] community favors an alternative approach: smart endpoints and dumb pipes. 

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 WEB 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.

!! Why [{$pagename}]
Benefits of using [{$pagename}]:
* Simpler To Understand - Follow code easier since the function is isolated and less dependent.
* Simpler To Deploy - Each [{$pagename}] can be deployed without affecting other services
* Faster Defect Isolation - When a test fails or service goes down, isolate it quickly with microservices.
* Reusability Across Business - Share small services like payment or login systems across the [Organizational Entity].
* Avoid locking in technologies or languages  for each microservice and change on the fly with little [risk]
* Teams can work in parallel on different [{$pagename}]s  to get things done faster

The first benefit is that microservices are much smaller and simpler than a larger, [monolithic] application. This means it’s easier for developers to understand and, more importantly, get right. Microservices are designed around business initiatives, so a team can really focus on perfecting it without worrying too much about other parts of the application.

Having each [{$pagename}] logically separated from the others means they can be deployed and scaled independently from the others. If your [website] has a promotion and gets a sudden rush of signups, the front end and the user [authorization] engine might get hit particularly hard that day. With a microservices architecture, you can scale up just those services rather than the entire application. Scaling horizontally in this way can save you money on expensive [on demand] cloud resources.

Another advantage is that a fault or [bug] in one [{$pagename}] will not directly affect other parts of the [application]. If something does go horribly wrong, that [{$pagename}] can just bow out gracefully and let all the other parts of the app keep working as normal. Rolling back to an older version is also easier.

Each team also has the luxury of choosing whatever languages and tools they want for their job without affecting anyone else. This goes for hardware too. A [{$pagename}] that is particularly [database] intensive can be placed on a system with good access to a [database].

Developers and teams can work in parallel to get changes to production faster. Teams can test and deploy a new version of their [{$pagename}] on their own schedule. Scaling your development team is as simple as hiring another independent team for a new microservice. Amazon has thousands of teams building microservices. Smaller codebases also mean faster compiles, builds, and deployments.

Add all these together and it’s easy to see why microservices is such a strong trend.


!! [{$pagename}] Concerns
Of course, as with every method of building software, there are tradeoffs. The big one for microservices is that now you are building a distributed system, which comes with a few challenges:
* Communication between services can get difficult, especially with unreliable services
* Writing automated tests and creating consistent test environments for multiple tests is hard but a [MUST]
* There isn’t an easy way to recreate conditions where a bug occurred
* Communication between the services can slow things down
* Orchestrating multiple instances of different [services] requires good use of automation and [Continuous Delivery] tools
* now that all developers are responsible their features, and nobody is safe from a late night support call.


!! More Information
There might be more information for this subject on one of the following:
[{ReferringPagesPlugin before='*' after='\n' }]
----
* [#1] - [Microservices|http://martinfowler.com/articles/microservices.html|target='_blank'] - based on information obtained 2015-05-16
* [#2] - [Microservices from Theory to Practice|https://www.redbooks.ibm.com/redbooks/pdfs/sg248275.pdf|target='_blank'] - based on information obtained 2016-12-22