A microservices infrastructure will be much more efficient with regard to the resources used when scaling out than a monolithic architecture would be. Correlated logging across services can be challenging. Command and Query Responsibility Segregation (CQRS). Of course, when identifying and designing microservices, you should try to make them as small as possible as long as you don't have too many direct dependencies with other microservices. Command and Query Responsibility Segregation. Each microservice has its own database, allowing it to be fully decoupled from other microservices. Containers start fast, which makes developers more productive. But that is not usually the case, because each subsystem's context boundary and requirements are usually different. Also, if the chain of service dependencies gets too long (service A calls B, which calls C), the additional latency can become a problem. Mac and macOS are trademarks of Apple Inc. If you have comments about how this guide can be improved, submit feedback at https://aka.ms/ebookfeedback. Microservice Prerequisites With each microservice responsible for its own data persistence. In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky. The application must be able to be deployed in multiple infrastructure environments (multiple public clouds and on-premises) and ideally should be cross-platform, able to move from Linux to Windows (or vice versa) easily. The guide and related reference application will be evolving, so we welcome your feedback! Development and testing. Refactoring across service boundaries can be difficult.

More important than the size of the microservice is the internal cohesion it must have and its independence from other services. All other marks and logos are property of their respective owners. Either way, using containers for data sources lets developers build and deploy in a matter of minutes without having to provision an external database or any other data source with hard dependencies on infrastructure (cloud or on-premises). The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing. Multi-architectural pattern and polyglot microservices means you can mix and match languages and technologies to the needs of each microservice and still have them talking to each other. Data integrity. Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end. A microservices application has more moving parts than the equivalent monolithic application. In a real production environment, for high availability and for scalability, the databases should be based on database servers in the cloud or on-premises, but not in containers. New features may be held up waiting for a bug fix to be integrated, tested, and published. Architecting fine-grained microservices-based applications enables continuous integration and continuous delivery practices. Finally, no matter, which approach you take for your microservice architecture, another challenge is deciding how to partition an end-to-end application into multiple microservices. Scalable infrastructure for the services (that is, cloud and orchestrators). It discusses architectural design and implementation approaches using .NET and Docker containers. The eShopOnContainers application is an open-source reference app for .NET and microservices that is designed to be deployed using Docker containers. It is much easier to perform schema updates, because only a single microservice is affected. Complexity. This approach is because the higher degree of granularity and distributed services requires more global resources. Figure 4-6. Carefully evaluate whether the team has the skills and experience to be successful. Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate. Or alternatively, it makes it easy to compile the custom Docker images using the .NET CLI and the Docker CLI, and then deploy and run them in a Docker development environment. Therefore, requests from the client application to the back-end system should be minimized. To be successful with microservices requires a mature DevOps culture. Similarly, complex microservices with ever-changing business logic should not be implemented as CRUD components, or you can end up with low-quality code. Use domain analysis to model microservices, Build a CI/CD pipeline for microservices on Kubernetes, Monitor microservices running on Azure Kubernetes Service (AKS), Microservices architecture on Azure Kubernetes Service (AKS), Microservices architecture on Azure Service Fabric. Therefore, their internal architecture and design is straightforward. For more information, see Designing a microservices architecture. To make it easier to get started, the guide focuses on a reference containerized and microservice-based application that you can explore. Depending on the priorities of each microservice, you must choose a different approach for each, as explained in the following sections. You can update a service without redeploying the entire application, and roll back an update if something goes wrong. This component is the application's domain logic. Writing a small service that relies on other dependent services requires a different approach than a writing a traditional monolithic or layered application. The above diagram shows that Mobile and SPA clients communicate to single API gateway endpoints, that then communicate to microservices. Data isolation.

In Figure 6-1, you see several containers deployed within a single Docker host. Instead of having a single monolithic application that you must scale out as a unit, you can instead scale out specific microservices. In certain cases, the client application might need to make many separate requests to compose the UI, which can be inefficient over the Internet and would be impractical over a mobile network. Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support. If you are not using a microservice-oriented infrastructure (like an orchestrator and scheduler), that additional complexity can require far more development efforts than the business application itself. Microsoft and the trademarks listed at https://www.microsoft.com on the "Trademarks" webpage are trademarks of the Microsoft group of companies. Existing tools are not always designed to work with service dependencies. However, you might have other microservices, such as the ordering microservice, which is more complex and represents ever-changing business rules with a high degree of domain complexity.

In the microservices approach, functionality is segregated in smaller services, so each service can scale independently. Figure 6-1. Figure 6-3. New team members must become productive quickly, and the application must be easy to understand and modify. We wrote this guide to help you understand the architecture of containerized applications and microservices in .NET. The application consists of multiple subsystems, including several store UI front ends (a Web application and a native mobile app), along with the back-end microservices and containers for all the required server-side operations with several API Gateways as consolidated entry points to the internal microservices. Atomic transactions. The business requirements have to embrace eventual consistency between multiple microservices. Figure 6-1 shows the architecture of the reference application. We also have the catalog service and the basket service that implement other capabilities. For instance, the catalog service or the basket service might need to be scaled out, but not the ordering process. In fact, the application is in a permanent beta state, as it's also used to test new potentially interesting technologies as they show up. This guide has been revised to cover .NET 6 version along with many additional updates related to the same "wave" of technologies (that is, Azure and additional third-party technologies) coinciding in time with the .NET 6 release. As the name implies, a microservices architecture is an approach to building a server application as a set of small services. https://aka.ms/dockerlifecycleebook, Containerized Docker Application Lifecycle with Microsoft Platform and Tools, https://azure.microsoft.com/blog/microservices-an-application-revolution-powered-by-the-cloud/, https://www.martinfowler.com/articles/microservices.html, https://martinfowler.com/bliki/MicroservicePrerequisites.html, https://www.infoq.com/articles/CCC-Jimmy-Nilsson. Each might have a different architecture pattern and use different languages and databases depending on the application's nature, business requirements, and priorities. The application will have a long-term evolution and ever-changing business rules. That means a microservices architecture is mainly oriented to the back-end, although the approach is also being used for the front end. As Figure 4-6 shows, in the traditional monolithic approach, the application scales by cloning the whole app in several servers/VM. Figure 6-2. Over time developers might want to change how the system is partitioned into services. Program Manager, ASP.NET team, Mark Fussell, Principal PM Lead, Azure Service Fabric team, Microsoft, Diego Vega, PM Lead, Entity Framework team, Microsoft, Barry Dorrans, Sr. Security Program Manager, Rowan Miller, Sr. Each service is self-contained and should implement a single business capability within a bounded context. You want to practice continuous integration and continuous deployment of the application. It also includes the back-end microservices and containers for all required server-side operations. That would be the case when deploying to a single Docker host with the docker-compose up command. But a successful microservices architecture requires a different approach to designing and building applications. The important point is that no particular architecture pattern or style, nor any particular technology, is right for all situations. As shown in Figure 6-3, in applications composed of many microservices (Bounded Contexts in domain-driven design terminology, or simply "subsystems" as autonomous microservices), you might implement each microservice in a different way. When the application is large, with dozens of microservices, there are challenges and limitations if the application requires direct client-to-microservice communications. For example, they might merge two services or split a service into two or more services. Therefore, this guide is intended to be infrastructure agnostic and more development-environment-centric. Monolithic deployment versus the microservices approach. These products deliver container solutions that help companies build and deploy applications at cloud speed and scale, whatever their choice of platform or tools. Ideally, each service should have only a small set of responsibilities. This design decision was made only to make it easy for a developer to get the code from GitHub, clone it, and open it in Visual Studio or Visual Studio Code. Content Developer, C+E, Microsoft Corp. Mike Rousos, Principal Software Engineer, DevDiv CAT team, Microsoft, Jeffrey Richter, Partner Software Eng, Azure team, Microsoft, Jimmy Bogard, Chief Architect at Headspring, Udi Dahan, Founder & CEO, Particular Software, Jimmy Nilsson, Co-founder and CEO of Factor10, Glenn Condron, Sr. Why a microservices architecture? Each service is simpler, but the entire system as a whole is more complex. By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features. https://www.infoq.com/articles/CCC-Jimmy-Nilsson, Cesar de la Torre. Embrace eventual consistency where possible. The Docker whale logo is a registered trademark of Docker, Inc. Used by permission. This especially applies to cross-cutting functionality such as logging. This approach is similar to the single responsibility principle (SRP) applied to classes, which states that a class should only have one reason to change. The first part of this guide introduces Docker containers, discusses how to choose between .NET 6 and the .NET Framework as a development framework, and provides an overview of microservices. Cesar de la Torre, Sr. PM, .NET product team, Microsoft Corp. Bill Wagner, Sr. This guide does not focus on the application lifecycle, DevOps, CI/CD pipelines, or team work. If there is an issue in one service, only that service is initially impacted (except when the wrong design is used, with direct dependencies between microservices), and other services can continue to handle requests. A single small team of developers can write and maintain a service. You can use the latest technologies. Services can be versioned or refactored without needing to update all of the clients. It focuses on the development and microservice patterns for implementing applications using .NET and Docker. Versioning. Containerized Docker Application Lifecycle with Microsoft Platform and Tools (downloadable e-book) Network congestion and latency. So that you can focus on the architecture and technologies instead of thinking about a hypothetical business domain that you might not know, we have selected a well-known business domainnamely, a simplified e-commerce (e-shop) application that presents a catalog of products, takes orders from customers, verifies inventory, and performs other business functions. You want to take advantage of emerging technologies (frameworks, programming languages, etc.) A team can update an existing service without rebuilding and redeploying the entire application. Our intention is that you read this guide when thinking about your application design without focusing on the infrastructure (cloud or on-premises) of your production environment. In many cases, when you replace a monolithic application with a microservices approach, the amount of initial global resources needed by the new microservice-based application will be larger than the infrastructure needs of the original monolithic application.