Edition 0 Updated to asp. Net core 0

Additional resources 
•
Chris Richardson. Pattern: API Gateway / Backend for Front-End
https://microservices.io/patterns/apigateway.html
 
•
API Gateway pattern
https://learn.microsoft.com/azure/architecture/microservices/gateway
 
•
Aggregation and composition pattern
https://microservices.io/patterns/data/api-composition.html
 
•
Azure API Management
https://azure.microsoft.com/services/api-management/
 
•
Udi Dahan. Service Oriented Composition
https://udidahan.com/2014/07/30/service-oriented-composition-with-video/
 
•
Clemens Vasters. Messaging and Microservices at GOTO 2016 (video)
https://www.youtube.com/watch?v=rXi5CLjIQ9k
 
•
API Gateway in a Nutshell
(ASP.NET Core API Gateway Tutorial Series) 
https://www.pogsdotnet.com/2018/08/api-gateway-in-nutshell.html
 
Communication in a microservice architecture 
In a monolithic application running on a single process, components invoke one another using 
language-
level method or function calls. These can be strongly coupled if you’re creating objects with 
code (for example, 
new ClassName()
), or can be invoked in a 
decoupled way if you’re using 
Dependency Injection by referencing abstractions rather than concrete object instances. Either way, 
the objects are running within the same process. The biggest challenge when changing from a 
monolithic application to a microservices-based application lies in changing the communication 
mechanism. A direct conversion from in-process method calls into RPC calls to services will cause a 
chatty and not efficient communication that won’t perform well in distributed environments. The
challenges of designing distributed system properly are well enough known that there’s even a canon 
known as the 
Fallacies of distributed computing
 that lists assumptions that developers often make 
when moving from monolithic to distributed designs. 
There isn’t one solution, but several. One solution involves isolating the business microservices as 
much as possible. You then use asynchronous communication between the internal microservices and 
replace fine-
grained communication that’s typical in intra
-process communication between objects 
with coarser-grained communication. You can do this by grouping calls, and by returning data that 
aggregates the results of multiple internal calls, to the client. 

---

49 
CHAPTER 3 | Architecting container and microservice-based applications 
A microservices-based application is a distributed system running on multiple processes or services, 
usually even across multiple servers or hosts. Each service instance is typically a process. Therefore, 
services must interact using an inter-process communication protocol such as HTTP, AMQP, or a 
binary protocol like TCP, depending on the nature of each service. 
The microservice community promotes the philosophy of “
smart endpoints and dumb pipes
” This 
slogan encourages a design that’s as decoupled as possible between microservices, and as cohesive 
as possible within a single microservice. As explained earlier, each microservice owns its own data and 
its own domain logic. But the microservices composing an end-to-end application are usually simply 
choreographed by using REST communications rather than complex protocols such as WS-* and 
flexible event-driven communications instead of centralized business-process-orchestrators. 
The two commonly used protocols are HTTP request/response with resource APIs (when querying 
most of all), and lightweight asynchronous messaging when communicating updates across multiple 
microservices. These are explained in more detail in the following sections.