A DotNet Raider

Dapr - The end

Throughout this series of articles, we have explored the various features and abstractions provided by Dapr, such as service invocation, pub/sub, state management, configurations, secrets, resiliency, and observability. However, it's important to note that there are even more capabilities within Dapr that we haven't covered, including actors, workflow management, distributed locks, and hosting.

Given the extensive nature of Dapr and its continuous growth, it's challenging to capture every aspect in a limited series of articles. To gain a deeper understanding, I encourage you to explore the official documentation, read relevant books, and explore additional online resources like GitHub projects and YouTube channels dedicated to Dapr. These resources can provide you with in-depth insights into Dapr's features and practical implementations.

Before diving into Dapr and incorporating it into your projects, it's crucial to have a solid understanding of microservices and distributed architecture in general. Consider the trade-offs involved and evaluate whether this architectural approach aligns with your business needs. Assess your team's technical skills and expertise, as both development and infrastructure aspects can become complex when working with distributed systems.

In terms of implementation, it's often beneficial to adopt a "Monolith First" approach, where you start with a monolithic architecture or, better, with a modular monolith. This approach allows you to experience the benefits of modularization and gain insights into the specific areas that can benefit from microservices. Eventually, you can decompose the monolith into a full-fledged microservices solution, leveraging the power of Dapr to simplify the development and management of your distributed system.

Thank you for following along with this series, and best of luck on your Dapr journey!

posted @ mercoledì 17 aprile 2024 09:37 | Feedback (0) | Filed Under [ Dapr Microservices ]

Dapr - Observability

Monitoring a distributed system is important to identify potential failures, security issues, bottlenecks and in general to understand how our application is performing to apply remediations (that could be scaling or redesigning some parts). In a distributed system, with several interconnected components, a dynamic environment, and unreliable networks, this becomes challenging.

Dapr, with his runtime running as a "sidecar", is the central point where the instrumentation of monitoring takes place to have distributed tracing, logging, metrics, and health check; as everything in Dapr, we can just configure these features using a YAML file.

In our sample, we'll use Zipkin to collect tracing information, just by specifying the Zipkin endpoint and the sampling rate (0= disable trace, 1 trace all)

apiVersion: dapr.io/v1alpha
kind: Configuration
metadata:   name: daprConfig
spec:   tracing:     samplingRate: "1"     zipkin:       endpointAddress: "http://zipkin:9411/api/v2/spans"1

In the Zipkin UI, we can see both traces and services dependencies

Dapr can produce structured logs in plain text (the default, that also sends it to stdout) or JSON (better for storing them in external services like ELK).

We can also use Open Telemetry Collector, Jaeger, and other tools like New Relic and App Insights.

See you in the next article for the last one of this series.

posted @ lunedì 25 marzo 2024 10:46 | Feedback (0) | Filed Under [ Dapr Microservices ]

Dapr - Resiliency

As we know, in a distributed system we have to take into account more complexity and deal with its fallacies. Since several moving parts could potentially be broken or be unreachable, we must design upfront our application with resiliency in mind, to minimize the impact of bad events and continue operating.

Dapr gives us out-of-the-box features that allow our applications to handle temporary failures.

All we have to do is to create a YAML file where we define policies and targets.

Policies are how we want to handle errors:

• Timeout,  to terminate operations after defined intervals
• Circuit breaking, to 'open' the circuit when there are several errors in order not to flood the system and give it time to restart the failing service
• Retry, to retry failed operations

Targets are where we want to apply such policies:

• Apps, our services (defined in docker-compose in our sample)
• Components, the different building blocks of Dapr
• Actors, the actor operations (not used in our sample)

I won't post the full YAML specification in this article, but I prepared a full example with comments in the GitHub repository.

Check it out here.

Once done, we configure the Dapr sidecar to load the resiliency configuration using the -resources-path argument.

In the next article, we'll see observability in Dapr

posted @ lunedì 5 febbraio 2024 10:27 | Feedback (0) | Filed Under [ Dapr Microservices ]

Dapr - Secret management

Dapr Secrets management is a feature that provides a secure and scalable way to manage application secrets, such as API keys, passwords, and tokens. You can use different cloud providers and environments such as Azure Key Vault, AWS Secrets Manager, HashiCorp Vault, or Kubernetes Secrets.

In our example, we'll use a JSON file (not recommended in production!) to store the following secrets:

"httpbindingtoken": "my auth token",   "ConnectionStrings": {     "SqlServer": "Server=sqlserver;Database=CustomersDb;User Id=sa;Password=admin12345!;TrustServerCertificate=true",     "PostgreSQL": "Server=postgres;Port=5432;Database=ProductsDb;User Id=admin;Password=admin12345;",     "MongoDb": "mongodb://mongo:27017"   },   "MongoDb": {     "DatabaseName": "OrderDb",     "OrdersCollectionName": "Orders"   }
}

We have two way to retrieve them:

• declaratively, in the components spec files
• programmatically, using the Dapr APIs

We had a glimpse of the first approach in the previous article, where we configured the Http Output Binding component.

Quick recall:

apiVersion: dapr.io/v1alph
kind: Component
metadata:
  name: httpbinding
spec:
  type: bindings.http
  version: v1
  metadata:
  - name: url
    value: http://echorestbot.azurewebsites.net/microdelivery
  - name: securityToken
    secretKeyRef:
      name: httpbindingtoken
      key: httpbindingtoken
  - name: securityTokenHeader
    value: "Authorization"
auth:
  secretStore: localsecretstore

Here we are configuring some metadata and you may notice that for the item securityToken instead of directly inserting the value, we are declaring that we want to use the key httpbindingtoken retrieve in localsecretstore.

Localsecretstore is the name of the component for secret management, configured as usual in the YAML file

apiVersion: dapr.io/v1alpha
kind: Component
metadata:   name: localsecretstore
spec:   type: secretstores.local.file   version: v1   metadata:   - name: secretsFile     value: components/secrets.json   - name: nestedSeparator     value: ":"

Here we are basically declaring where we store the secrets (in the file secrets.json) and what is the separator character for nested configuration (colon is the default).

To use it programmatically, we have to add the Nuget package Dapr.Extensions.Configuration in our project and register it with the following lines of code

var builder = WebApplication.CreateBuilder(args)
builder.Configuration.AddDaprSecretStore(
"localsecretstore", 
new DaprClientBuilder().Build(), 
new[] { ":" });

Once done, we can access our secret simply using the standard IConfiguration.

public OrdersRepository(IConfiguration configuration
{
   var clientSettings = MongoClientSettings
                           .FromConnectionString(configuration
                           .GetConnectionString("MongoDb"));    var client = new MongoClient(clientSettings);    var database = client
                       .GetDatabase(configuration
                           .GetValue<string>("MongoDb:DatabaseName"));

   this.orders = database.GetCollection<Order>(configuration
                           .GetValue<string>("MongoDb:OrdersCollectionName"));
})

That's it!

In the next article, we'll see how to leverage the resiliency feature of Dapr.

posted @ venerdì 12 gennaio 2024 15:29 | Feedback (0) | Filed Under [ Dapr Microservices ]

Dapr - Pub/sub & Output Binding

In the last article, once created an order we published a message, called OrderSubmittedIntegrationEvent with all the relevant information.

How can we subscribe to this event in other services?

In Dapr there are two ways:

• declaratively, where subscriptions are defined in an external file
• programmatically, where subscriptions are defined in our code

We're going to use the second method in the Notifications and Shipping microservices along with the Output binding building block

What is an Output binding? It's a way to invoke external resources just by passing a payload and additional metadata.

Let's see them in action!

Notifications microservice

The notification microservice will have just one method that is going to use the SMTP output binding to send an email to inform the customer that the order has been confirmed and what discount has been applied.

Here is the stripped version of the code, check GitHub for the complete one.

[HttpPost
[Topic("rabbitmqpubsub", "OrderSubmittedEventTopic")]
public async Task<ActionResult> OnOrderSubmittedEventAsync(
    OrderSubmittedIntegrationEvent orderSubmittedIntegrationEvent)
{
	var stringBuilder = new StringBuilder();
	stringBuilder.AppendLine($"Hello {orderSubmittedIntegrationEvent.CustomerFirstName} {orderSubmittedIntegrationEvent.CustomerLastName}<br>");
	stringBuilder.AppendLine($"Your order <strong>#{orderSubmittedIntegrationEvent.OrderId.ToString()[..6]}</strong> has been shipped.<br><br>");
	stringBuilder.AppendLine($"Your CRAZY DISCOUNT is <strong>#{orderSubmittedIntegrationEvent.TotalDiscount}%</strong>!<br><br>");

	var message = stringBuilder.ToString();
	var metadata = new Dictionary<string, string>
	{
		{ "emailTo", orderSubmittedIntegrationEvent.CustomerEmail },
		{ "subject", $"Order Shipped!" },
		{ "priority", "1" }
	};
	await this.daprClient
                        .InvokeBindingAsync(
                           "smtpbinding", 
                           "create", 
                           message, 
                           metadata);

	return Ok();
}]

The first thing you can notice is that we're using the Topic attribute to subscribe to the topic OrderSubmittedEventTopic on the rabbitmqpubsub component.

Dapr is going to invoke this method once a new message is published to that topic, and we receive the payload as a parameter (OrderSubmittedIntegrationEvent). We then use the payload to create an email and send it using the InvokeBindingAsync, passing as a parameter the name of the binding component (smtpbinding), the body of the email, and some metadata (subject, mail address, priority).

Of course, we have to configure the binding in the YAML specification:

apiVersion: dapr.io/v1alpha
kind: Component
metadata:   name: smtpbinding
spec:   type: bindings.smtp   version: v1   metadata:   - name: host     value: "smtp4dev"   - name: port     value: "25"   - name: emailFrom     value: "no-reply@microdelivery.com"

For testing purposes, I'm using an email server called smtp4dev hosted in docker to send and check emails.

The smtp4dev User Interface

Now let's see the shippings service.

Shipping microservice

All the logic is in the method OnOrderSubmittedEvent, where we're subscribing to the topic OrderSubmittedEventTopic, and we're performing an HTTP request using the HTTP Output Binding (to simulate a call to an external supplier). Once done, we publish the OrderShippedIntegrationEvent that will be handled by the Orders microservice to mark the order as shipped.

[HttpPost
[Topic("rabbitmqpubsub", "OrderSubmittedEventTopic")]
public async Task<ActionResult> OnOrderSubmittedEvent(
   OrderSubmittedIntegrationEvent orderSubmittedIntegrationEvent)
{
	await this.daprClient.InvokeBindingAsync(
                                    "httpbinding", 
                                    "post", 
                                     orderSubmittedIntegrationEvent);


	var orderShippedIntegrationEvent = new OrderShippedIntegrationEvent() 
                      { 
                        OrderId = orderSubmittedIntegrationEvent.OrderId, 
                        ShippedAtUtc = DateTime.UtcNow 
                      };

	await daprClient.PublishEventAsync(
                                        "rabbitmqpubsub", 
                                        "OrderShippedEventTopic", 
                                        orderShippedIntegrationEvent);

	return Ok();
}]

As in the notifications microservice, we use the InvokeBindingAsync, this time to call the HTTP endpoint, passing the orderSubmittedIntegrationEvent as payload.

The binding is configured with the following YAML specification:

apiVersion: dapr.io/v1alpha
kind: Component
metadata:
  name: httpbinding
spec:
  type: bindings.http
  version: v1
  metadata:
  - name: url
    value: http://echorestbot.azurewebsites.net/microdelivery
  - name: securityToken
    secretKeyRef:
      name: httpbindingtoken
      key: httpbindingtoken
  - name: securityTokenHeader
    value: "Authorization"
auth:
  secretStore: localsecretstore

Here you see that we want to perform a POST request to the URL http://echorestbot.azurewebsites.net/microdelivery (it's a simple API I built that gives you back the request details). We are also passing a token in the "Authorization" header; the value of the token is read by using the secret management build block (more info in the next article).

Here is an example of the request we made to the EchoRest endpoint, where you can see the payload containing the order's detail:

{   "RequestIdentifier": "14085696-218e-42f2-8966-7a0b37b506ea",   "Date": "2023-05-01T20:02:07.2657896Z",   "Url": "http://echorestbot.azurewebsites.net/microdelivery",   "Body": "{\"orderId\":\"307998cc-53c9-46cf-9dca-06df25419496\",\"customerId\":1,\"customerFirstName\":\"Joe\",\"customerLastName\":\"Doe\",\"customerEmail\":\"joe.doe@email.com\",\"orderLineItems\":[{\"productId\":1,\"productName\":\"Tomato salad\",\"quantity\":3,\"price\":8,\"discountedPrice\":8},{\"productId\":2,\"productName\":\"Margherita\",\"quantity\":3,\"price\":6,\"discountedPrice\":6}],\"totalDiscount\":0,\"eventId\":\"823132ef-197a-4fc3-8da4-175966bae8dc\"}",   "Headers": [     {       "Key": "Accept",       "Value": "application/json; charset=utf-8"     },     {       "Key": "Host",       "Value": "echorestbot.azurewebsites.net"     },        {       "Key": "Authorization",       "Value": "my auth token"     },     {       "Key": "Content-Type",       "Value": "application/json; charset=utf-8"     },     {       "Key": "Content-Length",       "Value": "412"     }          ],   "Method": "POST",   "Path": {     "Value": "/microdelivery",     "HasValue": true   }
}

After calling the sample endpoint, we're going to publish an OrderShippedIntegrationEvent that will be handled by the Order's microservice to update the order, just subscribing to that event using the Topic attribute we already saw.

[HttpPost("Ship")
[Topic("rabbitmqpubsub", "OrderShippedEventTopic")]
public async Task<ActionResult> OnOrderShippedEvent(OrderShippedIntegrationEvent orderShippedIntegrationEvent)
{
	var order = await this.orderRepository

                     .GetOrderAsync(orderShippedIntegrationEvent.OrderId);
	if (order is null)
	{
		return NotFound();
	}

	order.ShippedAtUtc = orderShippedIntegrationEvent.ShippedAtUtc;
	await this.orderRepository.UpdateOrderAsync(order);

	return Ok();
}]

In the next article, we'll discuss about secret management with DAPR.

posted @ mercoledì 6 dicembre 2023 16:53 | Feedback (0) | Filed Under [ Dapr Microservices ]

Dapr - Service invocation & Pub/sub

Dapr service discovery & invocation is a feature that allows services to discover and call other services using HTTP or gRPC protocols, providing a simple and consistent way to invoke them.

Communication is also

• secure (with mutual mTLS authentication)
• resilient (with configurable retry\circuit breaker\timeout policies)
• traced and metered (using common protocols)
• controlled (we can use ACL to restrict accesses\permissions to some APIs)
• balanced (using round-robin)

The pub/sub is a messaging pattern where a message is published by a sender to a topic, and all the subscribers who have subscribed to that topic will receive a copy of the message. This allows loosely coupled communication between services, as the sender does not need to know who the receivers are or how many there are, and the subscribers do not need to know who the publisher is.

The pub/sub API in DAPR provides a set of APIs that can be used to implement this pattern and allows developers to use different message brokers like Apache Kafka, RabbitMQ, Azure Service Bus, and many others. The API is platform-agnostic and offers an at least-once message delivery guarantee.

Let's see how we can use both functionalities in the orders microservices.

As always, we have a standard API controller where we inject the DaprClient.

The relevant code is in the SubmitOrder.

Essentially, what we want to do is:

• retrieve customer info (calling the customer's microservice)
• apply the current valid discount (calling the discount microservice)
• retrieve products info
• create and save a new order
• publish a message OrderSubmittedIntegrationEvent

In the next article, we'll see how other services can subscribe to the published event in order to perform their logic.