1

Introducing Microservices - the Big Picture

Microservices are featured in every avenue of software development. This software development style has been touted to increase development speed and efficiency and improve software scalability and delivery. Microservices would have you assess that monolith, break it into smaller and more perceivable chunks or services, and develop and maintain the code base per service as independent units.

"Microservices are small, autonomous services that work together"

- Sam Newman, Thoughtworks

Traditionally, applications have been developed as a single unit or monolith. All the components are tightly coupled, and a change to one component threatens to have rippling effects on the code base and functionality. This makes long-term maintenance a major concern and can hinder developers from rolling out updates quickly.

This development technique is not unique to any stack and has become extremely popular in enterprise application development. While microservices are seen as a pattern, several sub-patterns are employed to ensure the code base is as effective as possible.

Microservices are typically developed as APIs via HTTP (REST APIs) or a remote procedure call (gRPC) that may or may not interact with each other. These services are then generally unified as a single application that allows users to complete operations without knowing all the underlying and moving parts.

The general notion is that each microservice is autonomous, has a limited scope, and aids in a collectively loosely coupled application. There are several industry-level success stories where microservices architecture is implemented. A popular application that boasts this approach is Netflix. This application started as a monolithic DVD rental system, and the company later embraced microservices to support its streaming services. This architecture allows Netflix to deploy thousands of services independently, enhancing scalability and resilience and enabling rapid feature development.

Other popular applications include Uber, Amazon, and Etsy.

This book is designed to cover the intricate details of various implementation styles and design patterns used in microservices. We will focus on implementing them using the .NET development stack, and you will learn how code can be written and deployed. You will learn about design and coding patterns, third-party tools and environments, and best practices for handling different scenarios and cross-cutting concerns that arise in microservices application development.

In this chapter, we will review the following:

• Traditional development approaches
• Building microservices
• Why design patterns are required
• Why .NET is a suitable framework for microservices development

Let us begin by exploring monoliths and why they are needed or need to be replaced in some scenarios.

Free Benefits with Your Book

Your purchase includes a free PDF copy of this book along with other exclusive benefits. Check the Free Benefits with Your Book section in the Preface to unlock them instantly and maximize your learning experience.

Approaches to software development

Before exploring microservices, it's essential to understand the architecture they evolved to replace: the monolith. A monolithic application, or "monolith," is a single, unified software system in which all components and functionalities are interwoven.

A monolith in .NET and C# encompasses a single application's user interface (UI), business logic, and data access layers. Figure 1.1 is a depiction of this structure, which typically includes several layers, as follows:

• Presentation layer: This is the part of the application users interact with. In .NET, it is often implemented as an ASP.NET MVC or Razor Pages application, potentially combined with a JavaScript client-side framework such as Vue or React. This layer handles HTTP requests, UI rendering, and user interaction.
• Business logic layer: This layer contains the application's core functionalities and rules. It is where business-related decisions, calculations, and workflows are managed. It acts as the application's brain, executing logic based on user inputs or data requirements.
• Data access layer: This layer handles communication with the database. It enables create, read, update, and delete (CRUD) operations and supports complex querying and transaction management. In .NET, this is often implemented using Entity Framework Core or ADO.NET.
• Database: Typically, monolithic applications use a single relational database, such as SQL Server, to persist data across various functional areas of the application. All modules access this central database, sharing schemas and structures.

Figure 1.1 - A typical monolithic application with all application layers and a database

By default, every ASP.NET project starts as an all-in-one project. As the code base grows, it is common to separate the different layers into independent projects. This helps enforce the separation of concerns as our project grows. This is a common design pattern called n-tier architecture, and it promotes the separation of concerns by organizing an application into logical layers, or "tiers," where each tier is responsible for a specific aspect of the application's functionality. The most typical implementation is a three-tier architecture, as seen in Figure 1.1. By adhering to the n-tier architecture in .NET, developers achieve better modularity, maintainability, and testability and form a strong foundation for building scalable and enterprise-grade .NET applications.

Since all functionalities are part of the same code base and runtime environment, components of a monolithic application are tightly interwoven. Monoliths are developed and deployed as a single unit, so any modification, no matter how minor, typically requires extensive regression testing and redeployment. This becomes increasingly burdensome as the code base grows.

As the application grows in scale and complexity, however, the monolithic structure presents some serious challenges:

• Scaling difficulties: Scaling requires duplicating the entire application rather than scaling individual components. If only one module needs more resources, the whole application must be scaled, leading to inefficiencies.
• Limited technology flexibility: Since all components share a single stack, developers need more flexibility in choosing technologies. For instance, if the data processing layer would benefit from a more specialized technology, it might be more challenging to introduce it without impacting other layers.
• Deployment bottlenecks: As mentioned previously, even minor updates require redeploying the entire application. This often results in bottlenecks where a minor feature or bug fix can lead to delays, as it requires complete integration testing and downtime for deployment.
• Higher risk of code debt: As the application grows, the code base can become unwieldy and difficult to manage, especially if not modularized properly. Over time, dependencies can pile up, creating a spaghetti code situation where it becomes difficult to determine how various parts interact and change behavior.

A modern development pattern, modular monolith, has emerged to combat many of these concerns. This method seeks to segment the parts of the application into logical segments (often based on modules). We will review this next.

Modular monolith development pattern

The modular monolith development pattern seeks to address the most common issues in a traditional monolith by introducing a structured approach to monolithic architecture. They divide the application's code base into distinct, self-contained modules, each responsible for a specific business domain or functionality.

Some of the tangible and immediate benefits that this approach introduces are as follows:

• Separation of concerns: Modular monoliths divide the application's code into modules based on the different business domains or implemented functionalities. This segregation improves code organization and readability.
• Independent development and testing: Development teams can work on different application parts concurrently without interfering with each other. Modules can now be developed and maintained independently.

This means the application might end up with several micro frontends or components, which interface with specific business logic and data access layers, as implemented by the module.

Figure 1.2 - A modular monolith application with modules encapsulating specific business and data access logic...