Name: Microservices in .NET
Price: 77.00 USD
Availability: InStock
Rating: 4.78 (18 reviews)

About Course

Microservices in .NET

Design, build and deploy .NET microservices that scale and keep running when parts fail

Course Summary

This course takes you from the basics of microservices to running them in production. You build an e-commerce system as a set of small .NET services, connect them with events, and deploy and scale them with Kubernetes.

You work with the tools real systems use: RabbitMQ for events, Redis for caching, Ocelot as the API gateway, Prometheus for metrics and Kubernetes for deployment.

What Will You Learn?

Decide when microservices are the right choice
Build and deploy your first microservice step by step
Connect services with events over RabbitMQ
Give each service its own data, and share it safely
Add caching, real-time updates and an API gateway
Test, monitor and secure a distributed system
Keep services running when other parts fail
Deploy and scale your services with Kubernetes

Course Description

It is a hands-on text course: every module builds on the same e-commerce system, with practical assignments and quizzes along the way, and source code for .NET 9 and .NET 10.

It is for developers and architects who want to move away from a monolith, or start a new system with microservices the right way.

You can find an entire TOC with preview lessons in the Course Content section below.

Course Content

Introduction

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.

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.

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.

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.

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.

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.

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.

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!

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.

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.

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.

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.

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.

About Course

Microservices in .NET

Course Summary

What Will You Learn?

Course Description

Course Content

Introduction

Mindset Going In

Community Access

SDK Versions, Visual Studio Community, and SQL Express

The Source Code

Welcome to the Course!

What Is a Microservice?

Understanding Microservice Architecture

Benefits of Microservices

Microservice Drawbacks

When to Choose Microservices

Comparing Monoliths and Microservices

Environment Setup

Appendix 1: Local Environment Tools

The E-Commerce Application

Basket Microservice

Running Our Microservice

Extending Basket Microservice API

Recapping Basket Microservice Implementation

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

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

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

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

Levels of Testing

Unit Testing Our Basket Microservice

Assignment: Rounding Out Basket Unit Tests

Testing Wrap-up Quiz

Scaffold Test Project

ASP.NET Core Test Server

Testing Order API

Integration Testing With RabbitMQ

Assignment: Add Integration Tests to Product Microservice

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

Add Auto-Instrumentation of Metrics

Custom Metrics

Visualize Metrics With Prometheus

Transient Failures

Designing Resilient Services

Building Resilient SQL Connections