Edition 0 Updated to asp. Net core 0

Additional resources 
•
Building a scheduled task in ASP.NET Core/Standard 2.0
https://blog.maartenballiauw.be/post/2017/08/01/building-a-scheduled-cache-updater-in-
aspnet-core-2.html
 
•
Implementing IHostedService in ASP.NET Core 2.0
https://www.stevejgordon.co.uk/asp-net-core-2-ihostedservice
 
•
GenericHost Sample using ASP.NET Core 2.1
https://github.com/aspnet/Hosting/tree/release/2.1/samples/GenericHostSample
 
Implement API Gateways with Ocelot 
Important 
The reference microservice application 
eShopOnContainers
 is currently using features provided by 
Envoy
 to implement the API Gateway instead of the earlier referenced 
Ocelot
. We made this design 
choice because of Envoy’s built
-in support for the WebSocket protocol, required by the new gRPC 
inter-service communications implemented in 
eShopOnContainers. However, we’ve retained this 
section in the guide so you can consider Ocelot as a simple, capable, and lightweight API Gateway 
suitable for production-grade scenarios. Also, latest Ocelot version contains a breaking change on its 
json schema. Consider using Ocelot < v16.0.0, or use the key Routes instead of ReRoutes. 
Architect and design your API Gateways 
The following architecture diagram shows how API Gateways were implemented with Ocelot in 
eShopOnContainers. 

---

164 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications 
Figure 6-28. eShopOnContainers architecture with API Gateways 
That diagram shows how the whole application is deployed into a single Docker host or development 
PC with “Docker for Windows” or “Docker for Mac”. However, deploying into any orchestrator would 
be similar, but any container in the diagram could be scaled out in the orchestrator. 
In addition, the infrastructure assets such as databases, cache, and message brokers should be 
offloaded from the orchestrator and deployed into high available systems for infrastructure, like Azure 
SQL Database, Azure Cosmos DB, Azure Redis, Azure Service Bus, or any HA clustering solution on-
premises. 
As you can also notice in the diagram, having several API Gateways allows multiple development 
teams to be autonomous (in this case Marketing features vs. Shopping features) when developing and 
deploying their microservices plus their own related API Gateways. 
If you had a single monolithic API Gateway that would mean a single point to be updated by several 
development teams, which could couple all the microservices with a single part of the application. 
Going much further in the design, sometimes a fine-grained API Gateway can also be limited to a 
single business microservice depending on the chosen architecture. Having the API Gateway’s 
boundaries dictated by the business or domain will help you to get a better design. 
For instance, fine granularity in the API Gateway tier can be especially useful for more advanced 
composite UI applications that are based on microservices, because the concept of a fine-grained API 
Gateway is similar to a UI composition service. 
We delve into more details in the previous section 
Creating composite UI based on microservices
. 
As a key takeaway, for many medium- and large-size applications, using a custom-built API Gateway 
product is usually a good approach, but not as a single monolithic aggregator or unique central 
custom API Gateway unless that API Gateway allows multiple independent configuration areas for the 
several development teams creating autonomous microservices. 

---

165 
CHAPTER 5 | Designing and Developing Multi-Container and Microservice-Based .NET Applications