Adding a Little DAPR to Your .NET Microservices
by Cecil Phillip
Why is building microservices difficult?
- Hard to move from a monolithic architecture to a microservice architecture
- Runtimes only target specific infrastructure platforms, for example, .Net only Windows
Use Dapr for:
- Service-to-service invocation
- State management
- Pub-sub
- Resource bindings and triggers
- Actors
- Distributed tracing
- Secrets
Dapr runs as a sidecar and allows service-to-service invocation. The hard part with microservices is to know where the other service lives (IP, Port) –> you can tell Dapr what you want to do, for example, invoke /cart/checkout and Dapr calls the service for you. These calls work with gRPC and HTTP.
Dapr provides well-defined endpoints for caching, for example, you can use /state/store-name to save data in Cosmos DB, Cassandra, or Redis.
Dapr offers Input and Output triggers. Input triggers can be, for example:
- Redis
- Event Hubs
- Kafka
Input triggers allow to invoke something inside your application (your app can react to something from the outside)
Output triggers can be:
- Send something to Redis
- Cosmos DB
- Kafka
- Twilio
You can debug through your application and integrate Dapr with different frameworks like Azure Functions or .NET Core. Dapr is open-source and can be found on GitHub. It is still in beta but V1.0 is coming soon.
Are DAPR, Orleans, and Steeltoe all trying to solve the same problem? Mostly yes, but they solve problems in different ways. For example, Steeltoe is a Nuget package and Dapr is a runtime which is language agnostic
You can find the start of the video here.
A Journey into .NET Microservices with Steeltoe
by David Dieruf
Microservices are going to the cloud. Best practices are:
- Write logs to the console
- Use endpoints for scraping metrics like Prometheus
- Have endpoints for status checks as HTTP 200
- Use Environment and instance queries, for example, to know if you must scale
- Services must be highly available (multiple instances or datacenters)
- Resilient to change, use circuit breakers though they are not easy to implement
A cloud-native Rockstar should know about:
- Pipelines
- External Configurations
- Circuit Breaker
- Authentication and Authorization
- Service Discovery
- Message Buses
- Connections to databases
- Highly Availability
- Resilience to change
You shouldn’t care about these things. That’s where Steeltoe comes in and helps you with that. All you need is attributes and one-liner.
Steeltoe is an open-source project that was created in 2015 (GitHub). It enables developers to build resilient, cloud-native applications and applies best practice microservice for the cloud.
Steeltoe adds to .NET’s cloud opinions with ready-to-run patterns like distributed tracing, discovery management, and circuit-breaker.
Demo
Steeltoe can be installed as a Nuget package (There are many packages, for example, for health checks, logs, and so on). The logging Nuget extends the logger to also log the application name, a span id, and a tracing id. The Nuget for the health check adds a health check endpoint and also additional information like disk space, out of the box without any configuration
You can find the start of the video here.
Orleans at Microsoft
by Reuben Bond
Orleans is another framework for distributed applications like Steeltoe or Dapr. It is built on .NET and running in production at Microsoft for 8 years.
You can find the start of the video here.
Developing and Deploying Microservices with Tye
by Glenn Condron & Justin Kotalik
When you develop a microservice architecture, there are some problems like:
- Service Discovery
- Configure ports
- Hardcoded URLs
- Fragile to change, touch every project
- Dependencies like Redis, SQL, or message queues
Docker Compose may be a solution to these problems. Docker Compose has a steep learning curve to get started and it only solves some of these problems.
Tye
Tye offers the following features:
- Service Discovery via configuration conventions
- Understands .NET project files
- Dashboard for logs, metrics, etc. locally
- Can run Docker dependencies
- Can dockerize and deploy your services to AKS
Service Discovery is done by convention. On startup environment variables are set with the information, there is also a tye.yaml file
After the introduction to Tye Glenn Condron and Justin Kotalik showed a Demo on how to use it.
You can find the start of the video here.