In a traditional monolithic architecture, we build the application as a single, indivisible unit. This leads to the functionalities being tightly coupled together, making it difficult to make changes or scale specific features. This approach makes creating a big ball of mud easier, particularly when the team invests little effort in domain modeling and analysis before and during development.On top of that, while this approach is simple and straightforward, it lacks the flexibility and scalability of more modern architectures. A monolith does not have to be indivisible, yet most end up this way because it is easy to create tight…
-
-
Before you begin: Join our book community on Discord Give your feedback straight to the author himself and chat to other early readers on our Discord server (find the “architecting-aspnet-core-apps-3e” channel under EARLY ACCESS SUBSCRIPTION). https://packt.link/EarlyAccess In the ever-evolving software development landscape, choosing the right architecture is like laying the foundation for a building. The architecture dictates how the software is structured, impacting its scalability, maintainability, and overall success. Traditional monolithic architecture and microservices have long been the dominant paradigms, each with advantages and challenges.However, a new architectural style has been gaining traction—Modular Monoliths. This approach aims to offer the…
-
The microservices architecture is different from everything we’ve covered in this book and how we build monoliths. Instead of one big application, we split it into multiple smaller ones called microservices. Microservices must be independent of one another; otherwise, we will face the same problems associated with tightly coupled classes, but at the cloud scale.We can leverage the Publish-Subscribe design pattern to loosely couple microservices while keeping them connected through events. Message brokers are programs that dispatch those messages. We can use event sourcing to recreate the application’s state at any point in time, including when spawning new containers. We…
-
We explored the Microservice Adapter pattern that allows us to connect two elements of a system by adapting one to the other. We explored how to push information from an event broker into an existing system that does not support such capabilities. We also explored how to leverage an adapter to break tight coupling, migrate features into a newer system, and decommission a legacy application seamlessly. We finally connected two event brokers through an adapter microservice, allowing a low-powered IoT device to communicate with a microservices system without draining their battery and without the complexity it would incur to use…
-
In this scenario, we are adapting an event broker to another. In the following diagram, we look at two use cases: one that translates events from broker B to broker A (left) and the other that translates events from broker A to broker B (right). Afterwards, we explore a more concrete example: Figure 19.42: An adapter microservice that translates events from broker B to broker A (left) and from broker A to broker B (right) We can see the two possible flows in the preceding diagram. The first flow, on the left, allows the adapter to read events from broker…
-
From this point forward, we are applying the Strangler Fig pattern to migrate the legacy system piece by piece to our new architecture. For the sake of simplicity, think of the Strangler Fig pattern as migrating features from one application to another, one by one. In this case, we replaced one application with another, but we could also use the same patterns to split an application into multiple smaller applications (like microservices). I left a few links in the further reading section in case migrating legacy systems is something you do or simply if you want to know more about…
-
In this scenario, we have a legacy application to decommission and a microservices system to which we want to connect some existing capabilities. To achieve this, we can create one or more adapters to migrate all features and dependencies to the new model.Here is a representation of the current state of our system: Figure 19.37: The original legacy application and its dependencies The preceding diagram shows the two distinct systems, including the legacy application we want to decommission. Two other applications, dependency A and B, directly depend on the legacy application. The exact migration flow is strongly dependent on your…
-
The Microservice Adapter pattern allows adding missing features, adapting one system to another, or migrating an existing application to an event-driven architecture model, to name a few possibilities. The Microservice Adapter pattern is similar to the Adapter pattern we cover in Chapter 9, Structural Patterns, but applied to a microservices system that uses event-driven architecture instead of creating a class to adapt an object to another signature.In the scenarios we cover in this section, the microservices system represented by the following diagram can be replaced by a standalone application as well; this pattern applies to all sorts of programs, not…
-
This section explores some advantages and risks of separating a data store’s read and write operations using the CQRS pattern. Benefits of the CQRS pattern Potential Risks of using the CQRS pattern Conclusion CQRS helps divide queries and commands and helps encapsulate and isolate each block of logic independently. Mixing that concept with serverless computing or microservices architecture allows us to scale reads and writes independently. We can also use different databases, empowering us with the tools we need for the transfer rate required by each part of that system (for example, frequent writes and occasional reads or vice versa).Major…
-
The message broker is also the event store in the preceding diagram, but we could store events elsewhere, such as in an Azure Storage Table, in a time-series database, or in an Apache Kafka cluster. Azure-wise, the datastore could also be CosmosDB. Moreover, I abstracted this component for multiple reasons, including the fact that there are multiple “as-a-service” offerings to publish events in Azure and multiple ways of using third-party components (both open-source and proprietary).Furthermore, the example demonstrates eventual consistency well. All the last known location reads between steps 1 and 4 get the old value while the system processes…