Course Content
Introduction
0/5
Mindset Going In
Community Access
SDK Versions, Visual Studio Community, and SQL Express
The Source Code
Welcome to the Course!
Evolution to Microservices
Throughout our first chapter, we will gain a shared understanding of what a Microservice is, and cover some of the main benefits as well as drawbacks. Finally, we’ll explore some of the situations where we would want to choose a Microservices architecture compared to a monolithic application.
0/6
What Is a Microservice?
Understanding Microservice Architecture
Benefits of Microservices
Microservice Drawbacks
When to Choose Microservices
Comparing Monoliths and Microservices
Designing Our First Microservice
Now that we have a shared understanding of microservices, including the benefits and drawbacks, let’s dive into creating our first microservice. We’ll start by setting up our environment, and covering the domain we’ll be working in throughout the rest of the book. From there, we’ll scaffold our first microservice and implement the business logic to allow other microservices to communicate with it.
0/7
Environment Setup
Appendix 1: Local Environment Tools
The E-Commerce Application
Basket Microservice
Running Our Microservice
Extending Basket Microservice API
Recapping Basket Microservice Implementation
Communication Between Microservices in .NET
So far, we have implemented a Basket microservice as part of our e-commerce application. However, this is only one component of an e-commerce application, so we need to introduce more functionality, which we achieve by creating new microservices. In this chapter, we will cover communication methods between microservices, introduce our second microservice, and implement communication between it and our Basket microservice.
0/7
Understanding Synchronous vs Asynchronous Communication
Extending our E-Commerce Application
Events
Communicate With RabbitMQ From Docker
Consuming Events
Introduce Publisher/Subscriber Pattern
Recapping Microservice Communication
Cross-Cutting Concerns
In our previous chapter, we introduced some duplicated code around the connections for RabbitMQ. Duplicated code isn’t the end of the world, but as developers, we must ask ourselves whether code can be re-used. Throughout this chapter, we are going to discuss duplication of code in the realm of microservices, as well as some common concerns that affect all microservices.
0/10
Is Duplication Bad?
Extracting Duplicated RabbitMQ Code
Distributing Shared Library
Consume Shared Library in Order Microservice
Consume Shared Library in Basket Microservice
Test Microservices With Shared Library
Extend Shared Library For Event Subscribers
Remove Hosted Service From Basket Microservice
Test Shared Library Event Subscribers
Cross-Cutting Concerns Knowledge Check
Data Ownership
Our e-commerce application is starting to take shape. We have a Basket and Order microservice, along with events that allow for asynchronous communication between the two. However, we currently use an in-memory store for both microservices. This is not reflective of a production microservices environment. Whenever we write applications, be it a monolith or a microservices-based architecture, data is a core component. Without data, most of our applications wouldn’t be very useful. So, throughout this chapter, we are going to understand data ownership in the context of microservices, exploring the replication of data to build more efficient and robust applications.
0/9
Which Microservice Owns What Data
Implement Product Microservice With Persistent Datastore
Running SQL Server With Docker Compose
Create Database Schema
Seed Product Type Information
Product Microservice Functionality
Test Product Microservice
Use DTOs for API Responses
Knowledge Check on Data Ownership
Extend Basket Microservice Functionality
Now that we’ve introduced a new service, the Product microservice, to our E-Commerce application, we can extend the functionality of our Basket microservice. We want to be able to display product price information in our baskets, so we need to consume the new ProductPriceUpdatedEvent we introduced in the previous chapter. At the same time, we can introduce a persistent data store for our basket microservice, and tick off another part of our overall architecture.
0/7
Add Functionality for Product Price Updates in Basket Microservice
Add Redis Cache to Basket Microservice
Add Product Price to Baskets
Persist Customer Baskets in Cache
Publish and Test ProductPriceUpdated Event
Assignment: Order Microservice Data Persistence
Extend Basket Microservice Functionality Recap
Testing Distributed Applications
At this stage, our E-Commerce application is starting to come together, with quite a few moving pieces. However, any time we introduce a new service or change some functionality, we need to manually run tests via Postman or curl, which isn’t very efficient. Furthermore, we cannot easily automate this type of testing, so whenever we get to a stage of continuously deploying our microservices, we’ll be slowed down by this manual testing. As developers, testing is something we should be very comfortable with doing and implementing. Throughout this chapter, we’ll briefly cover the types of tests we can write, focusing on our microservices, as well as implementing various levels of tests to ensure we can continuously add new microservices and functionality to our E-Commerce application.
0/4
Levels of Testing
Unit Testing Our Basket Microservice
Assignment: Rounding Out Basket Unit Tests
Testing Wrap-up Quiz
Integration Testing With Order Microservice
So far, we’ve covered the base of the testing pyramid with unit tests in our Basket microservice. The next level we need to cover is integration testing, which we’ll pick up with our Order microservice. It is worth noting that we previously asked you to implement a data store for the Order microservice, so things may differ slightly. Of course, the source code is available with an SQL implementation, so feel free to follow along using that configuration. We’ve already covered the scope of integration testing in the previous chapter, so let’s waste no time getting into the code!
0/5
Scaffold Test Project
ASP.NET Core Test Server
Testing Order API
Integration Testing With RabbitMQ
Assignment: Add Integration Tests to Product Microservice
Application Observability
Throughout our journey of building an E-Commerce application using microservices, we’ve composed quite a complex system. So far, we’ve got 3 separate microservices, each with its own data store. Furthermore, we’ve got an external message broker (RabbitMQ) that allows us to communicate asynchronously between microservices. We’ve been able to test each microservice individually, both manually via Postman or curl and in an automated fashion with unit and integration tests. All of these processes are great to help us during local development and provide confidence whenever writing new features, but what about whenever our application is in production? Right now, if we deployed our application and allowed customers to use our E-Commerce platform, we’d have no insight into the performance of our application. We’d also have no idea how data flows through our application beyond what we have tested ourselves. This is where observability comes into play.
0/7
Observability
Tracing Requests With Product Microservice
Manual Instrumentation of Event Publishing
Trace Visualization With Jaeger
Instrumenting End-To-End Event Workflows
Knowledge Check on Observability
Assignment: Add Tracing to Order Microservice
Monitoring Microservices With Metrics
In the previous chapter, we started considering how to monitor our microservices whenever deployed in a production environment. The first telemetry component we covered was tracing, which gives us contextual information for our microservices and external infrastructure. This information is useful when we need to dive deep into a problem, but it doesn’t provide an easy-to-understand overview of our service’s performance. This is where metrics come into play, which we’ve already gained an understanding of, so let’s waste no time implementing metrics in our Order microservice.
0/3
Add Auto-Instrumentation of Metrics
Custom Metrics
Visualize Metrics With Prometheus
Building Resilient Microservices
So far, we’ve designed a system that provides us confidence when releasing new features thanks to testing. We’ve also gained insight into how our application performs when deployed with the help of OpenTelemetry tracing and metrics. With this last component, we’re likely to see recurring failures between microservices and our external infrastructure such as SQL or RabbitMQ.
0/6
Transient Failures
Designing Resilient Services
Building Resilient SQL Connections
Retrying Event Publishing
Data Consistency
Assignment: Order Microservice Resiliency
Securing Microservices
Throughout the development of our microservices, every request we executed was unauthenticated. However, this needs to be revised for a production-level E-Commerce application. Although we can allow anonymous access to create baskets and add products to them, we cannot allow everyone access to create products or update product pricing. Therefore, we need a mechanism to secure certain endpoints, which we’ll achieve by introducing two new services to our system. Let’s start with an understanding of the different components of security.
0/6
Authentication and Authorization
Auth Microservice
Securing Our Microservices
Securing Microservices With Roles
Implement API Gateway
Assignment: Add Basket And Order Microservice to API Gateway
Microservice Deployment
We’re now at a stage where we have a pretty sophisticated system, with many components, tests, and features. The next logical step for any application, microservice-based or not, is to tackle deployment. We need a solution to help us with microservice deployment complexities. But first, let’s briefly touch on the differences between monolithic and microservice deployments.
0/5
Monolith vs Microservice Deployments
Container Orchestration
Running Kubernetes
Deploying Microservices With Kubernetes
Assignment: Deploy Basket and Order Microservice in Kubernetes
Microservices in .NET

We’ve already begun to design our microservices in a resilient fashion. To start, none of them talk directly to each other via HTTP, so if one microservice crashes, other microservices can continue to function in isolation until the crashed microservice restarts. Furthermore, each microservice owns a separate data store.

Currently, we use the same SQL server for our Order and Product microservices, but we can separate these into completely separate servers so there is no chance of a SQL server outage affecting both of our microservices. However, it’s not perfect. What happens if our RabbitMQ service crashes and our microservices can’t publish events? Or what happens if our SQL server crashes and we attempt to read data from our database?

As things stand, our microservices themselves would crash, which is known as failure propagation. When one service or component fails, we don’t want this to prevent other services from continuing to function. Instead, we need to introduce a mechanism by which our services retry the execution of the event publishing or the SQL read when we encounter an issue.

Retry Mechanisms

If our microservice fails to publish an event to RabbitMQ or reads some data from SQL, we may want to retry the action as we could have encountered a transient issue. However, it isn’t as simple as continuously retrying the event publish or data read until it succeeds. First and foremost, if the issue is a more severe one, such as our RabbitMQ server being offline, retries will not help. Secondly, the act of retrying a request puts extra stress on the receiver. This extra stress can therefore be compounded if we continue to retry, and grows exponentially when we have multiple services retrying requests. Let’s take the example of our RabbitMQ service, with multiple publishers:

If the RabbitMQ server is already struggling due to a lack of compute resources, retrying requests is going to add more load to the server and eventually cause a complete outage, which we want to avoid. To combat this, we need to be smart with our retry mechanisms. First, we can use an exponential backoff mechanism, whereby the interval between retries grows larger:

This ensures we don’t add extra stress on the server and increase the chance of the request succeeding. To take it a step further, we can introduce a circuit breaker mechanism, so that after a certain number of retry attempts, we stop retrying the request and assume the server is in a crashed state and any number of retry attempts won’t make a difference. This is a common strategy with HTTP requests. If 3 attempts fail, it’s unlikely the 4th or 5th will succeed, therefore we design for this and stop retrying after the 3rd attempt:

How we determine and implement the retry mechanisms will depend on the component we are sending requests to. Our retry mechanism for publishing events to RabbitMQ will differ from how we retry SQL connections, but the fundamental principle remains the same. So with that, let’s begin implementing some retry mechanisms in our microservices and improving our resiliency.

Previous
Next
0% Complete