DEV Community: Diagrid

Durable Execution, Now Built for Agents

Marc Duiker — Tue, 28 Jul 2026 15:38:38 +0000

Durable execution has become an expectation for agent workloads. If the process dies halfway through a refund, the run resumes at the last completed step instead of re-issuing it. What it does not give you is proof. Replaying a run is not the same as proving what ran.

The missing piece is verifiability

Verifiable execution is a record of what ran, in what order, and what it produced, where every LLM call, tool call and decision is cryptographically signed and traceable to its source. Durability keeps work alive. Verifiability makes it checkable by someone who was not there.

More autonomy, less reproducibility

In a deterministic workflow the steps live in your code. You can diff them and point at the line that made a decision. As you hand control to the model, that structure moves out of the code and into the run itself. The model picks which tools to call and in what order, so two runs on the same input can take different paths, and nothing in your repository records which path a given run took.

Most teams make that trade on purpose. The flexibility is what lets an agent settle a messy dispute that no if-statement anticipated. The cost arrives later, when someone asks why a particular refund was denied. A stack trace tells you what your code did. It cannot tell you why the model chose one tool over another, and re-running the agent produces a fresh set of decisions rather than the ones you need to account for.

So the structure you take out of your code has to reappear underneath it, as a record rather than as more branching logic: every call the agent made, in order, with the inputs and outputs that led to the next step, each entry signed so it can be verified later.

What Catalyst is built for

Declarative workflow engines, where the flow lives outside your code, do not integrate natively with agent frameworks. Code-first engines integrate, but leave the run unverifiable, so you can resume it without being able to prove it. Agentic durable execution takes a third route: keep the framework you already use and make its execution durable and verifiable.

That is what Diagrid Catalyst is built for. Add a package to LangGraph, Microsoft Agent Framework, Google ADK, AWS Strands, OpenAI Agents SDK or CrewAI, and you get durable and verifiable execution through workflows, attestation, cryptographic signing, and SPIFFE-based workload identity.

Durable execution is becoming table stakes for agents. Verifiable execution is what makes them trusted.

Read the full post on diagrid.io to learn more.

Durable execution for LangGraph agents: resuming from the exact failed step

Marc Duiker — Tue, 28 Jul 2026 13:30:22 +0000

LangGraph checkpointing lets an agent resume from saved state. In production that leaves a gap: when a model call times out or a tool fails mid-run, something has to notice, decide where to restart, and finish the run. That is usually code you wrote.

Where checkpointing stops

A checkpoint records what the graph completed before the failure. It does not retry the failed step, know which side effects already ran, or restart a process that died. That logic becomes your own layer of retry wrappers and status flags.

What durable execution adds

Diagrid Catalyst records each step durably, so the runtime owns recovery:

the run resumes at the failed step, not at the start of the graph
completed steps are not re-executed, so you skip repeat model calls
every step lands in a signed record you can audit
one reliability layer covers cloud, edge, and on-prem

What the webinar covers

On Aug 11 we take a working LangGraph agent, force a failure mid-run, then add Catalyst and trigger the same failure. This time it resumes and finishes.

Save your seat at www.diagrid.io/webinars/durable-langgraph-agents

Temporal vs. Diagrid Catalyst: Which Durable Execution Approach Fits a Long-Running AI Research Agent?

Marc Duiker — Tue, 28 Jul 2026 12:59:17 +0000

Getting a research agent to call three tools in a demo is easy. The hard part starts when the seventh tool call times out and the first six have already spent money and changed state somewhere.

So this is a question about recovery, not about AI frameworks. Temporal and Diagrid Catalyst both do durable execution, and both position themselves for AI workloads. What separates them is what each one asks you to build and operate around your agent.

Start with the failure contract

Say your agent searches internal documents, calls an external research API, asks an LLM to synthesize the evidence, and then waits for a human to approve the result. Before that design goes to production, you need answers to four questions:

Which completed steps will not run again after a crash?
How do you stop non-idempotent tool calls from firing twice?
Can the agent wait for hours without holding a process open?
Can an operator reconstruct what the agent did, and why?

Temporal treats failure-prone work as activities, coordinated by durable workflows. It persists workflow state and rebuilds it by replaying history. You can self-host Temporal or use Temporal Cloud, and Temporal's current materials cover agentic applications and framework integrations directly.

Catalyst builds on Dapr Workflows. Your agent runs as a durable workflow, and Catalyst ships runners for established agent frameworks. Diagrid's documentation describes a shared runtime layer that handles durability, workload identity, policy enforcement, and operational visibility across agents, workflows, MCP servers, and applications.

Where the approaches diverge

Temporal fits when you want your application logic written in its workflow-and-activity model. The conceptual model is mature, language support is broad, and there is a large body of distributed-systems guidance to learn from. The cost is fluency. Someone on your team has to understand Temporal's execution semantics well enough to reason about replay, and you still decide separately where agent identity, access policy, and platform governance live.

Catalyst fits when your agents already exist in LangGraph, CrewAI, Microsoft Agent Framework, Google ADK, OpenAI Agents, or another supported framework, and you want to keep that choice. It sits underneath those frameworks as a shared execution and governance layer rather than replacing them.

That difference grows with the number of agent teams you have. A single research-agent project can standardize on a workflow SDK and be done. A platform team supporting Python, .NET, and TypeScript agents at the same time will care more about a framework-agnostic layer and policies it can set in one place.

What I would take to architecture review

Pick Temporal if workflow-as-code is the application model you actually want, you are willing to build around its abstractions, and its ecosystem and operating model match your platform strategy.

Select Catalyst if keeping your agent-framework choice matters, if you need workload identity and policy applied to tool calls, or if you have to govern agents across several deployment environments.

Neither choice saves you from designing idempotent side effects or deciding when a human gets pulled in. Durable execution changes what happens after a failure. It does not make a dangerous tool call safe.

Then run an experiment with either platform. Kill the agent after an expensive model call but before a state-changing tool call, and look at what resumes, what runs twice, and what evidence is left behind. Whichever platform makes that behavior easiest to explain to your developers, your operators, and your security reviewers is the one to pick.

Official sources

A free, open-source Dev Dashboard for local Dapr development

Marc Duiker — Mon, 20 Jul 2026 15:25:25 +0000

Developing Dapr applications means you're dealing with multiple apps and sidecars, looking at several terminals for log output and component files. There is now a free, open-source Dev Dashboard that brings it together in one live view. It runs as a single binary and auto-discovers apps started with dapr run, .NET Aspire, Docker Compose, or Testcontainers.

See everything Dapr at a glance

The dashboard shows your running apps with health, ports, and process IDs, plus their loaded components, actor types, and pub/sub subscriptions. You can also tail sidecar and application logs in the same window, with level coloring and keyword highlighting.

Debug workflows without guesswork

For Dapr Workflows you can list executions across your apps, inspect event history and input/output per step, and terminate or purge instances. The data is read straight from your local state store, so you see the real state rather than a copy.

Build components and policies in a UI

Two guided builders generate Dapr component and resiliency YAML from the full catalog, so you can skip hand-editing files.

Download & Install

You can view the project on GitHub: https://github.com/diagridio/dev-dashboard

You can install the dashboard directly via the terminal:

Install (macOS / Linux)

curl -sSL https://raw.githubusercontent.com/diagridio/dev-dashboard/main/scripts/install.sh | sh

Install (Windows, PowerShell)

iwr -useb https://raw.githubusercontent.com/diagridio/dev-dashboard/main/scripts/install.ps1 | iex

Give it a try when you're developing and testing your Dapr applications. Once you have it running, come share how it works for you in the Dapr Discord. If you hit a bug or have an idea to make it better, open an issue on the dev-dashboard repository.

Making Microsoft Agent Framework agents durable with Dapr Workflow

Marc Duiker — Tue, 07 Jul 2026 15:48:50 +0000

LLM calls are slow, costly, and non-deterministic, so a multi-agent app that crashes halfway through wastes time and money re-running everything. Dapr Workflow turns a set of MAF agents into a durable, fault-tolerant app that resumes from saved state and replays completed agent calls instead of hitting the LLM again.

There's a new free Dapr University track uses PrDigest, a .NET Aspire app that triages open Dapr PRs. You'll inspect the AppHost configuration, MAF agent registration, and the agent orchestration.

Try the track here.

Keep your Dapr Agent's answers current with a Tavily web search tool

Marc Duiker — Tue, 16 Jun 2026 13:46:15 +0000

LLMs are frozen at training time, so they return confident answers that may already be out of date. This free, self-paced Dapr University track shows you how to close that gap in Python by giving an agent access to the live web.

You'll build an expert agent with Dapr Agents that calls a Tavily search tool to fetch current information, then reasons over those results through the provider-agnostic Dapr Conversation API. Combining tool calls with agent reasoning keeps answers grounded in today's data.

This university track requires an OpenAI API key and a free Tavily key.

Start the free track here!

State of Dapr 2026 report is out

Marc Duiker — Thu, 30 Apr 2026 09:18:52 +0000

The 2026 State of Dapr report is out. Workflow API usage doubled year over year. 34% of developers are building AI agents on Dapr, 28% already in production. Durable workflows and reliable agents on one runtime.

Download the report now to get all the insights: https://www.diagrid.io/reports-and-ebooks/state-of-dapr-2026?utm_source=dev-to&utm_medium=social

Webinar: Build Reliable Agentic Apps with Aspire, MAF, and Catalyst

Marc Duiker — Tue, 28 Apr 2026 16:23:18 +0000

TL;DR: Register here for the webinar on May 7th.

Join Marc Duiker and Whit Waldo for a live webinar on building reliable agentic applications in .NET.

Agentic apps look impressive in a demo, but most struggle the moment a tool call fails or a long-running task needs to survive a restart. The Microsoft Agent Framework by itself does not solve this. In this session you will see how three tools work together to close that gap: Aspire for local orchestration and observability, the Microsoft Agent Framework for building agents, and Diagrid Catalyst for durable execution and state.

If you are a .NET developer exploring agentic AI, this webinar will give you a clear picture of the moving parts.

📅 May 7th
🕑 8:00 AM PDT / 17:00 CEST

Register here

Who should attend
This session is for .NET developers who are building or planning to build agentic applications and want to take them beyond the demo stage. No prior experience with Aspire, MAF, or Catalyst is required.

What you will learn
By the end of the session you will understand:

Where reliability tends to break in agentic apps, including failed tool calls, timeouts, and long-running tasks that need to survive restarts
How Aspire improves local development and observability for distributed .NET apps
How the Microsoft Agent Framework helps you define and compose agents in .NET
How Diagrid Catalyst adds durable execution so your agents keep running through crashes, retries, and deployments
How the three fit together in a single project

Registration is free. Everyone who signs up will receive the recording after the event.

Join the Diagrid Catalyst AWS Hackathon!

Marc Duiker — Mon, 29 Apr 2024 08:13:50 +0000

We are excited to invite you to the Diagrid Catalyst AWS Hackathon—a four-week, virtual event where you can unleash your creativity and showcase your coding skills by building or modernizing a cutting-edge application using the powerful Diagrid Catalyst platform. Get ready to collaborate, compete, and win cash prizes! Register now.

What is Diagrid Catalyst?

Diagrid Catalyst is a Developer API platform providing a brand-new approach to distributed application development. Using the Catalyst APIs, powered by the Dapr open source project, developers can overcome the complexity of rewriting common software patterns and achieve higher productivity by offloading infrastructure concerns from their code to Catalyst.

Say hello to making API calls from any platform, in any language to build modern, cloud-applications with ease. This hackathon is your chance to explore the potential of Diagrid Catalyst while bringing your solution ideas to life! For more on Catalyst, watch our most recent webinar for a platform overview and API deep dive.

Why Participate?

Join the Diagrid Catalyst Hackathon to:

Innovate with an Emerging Product: Explore the ways Diagrid Catalyst can expedite your development process by building an application to solve real-world challenges.
Collaborate with Peers: Connect with fellow developers, designers, and entrepreneurs. Collaborate, share ideas, and learn from each other's experiences.
Enhance Your Skills: Sharpen your application development and architecture skills using the coding languages of your choice and deploying your solution on Amazon Web Services.
Win Prizes: Compete for impressive cash prizes! We have rewards lined up for the most exceptional projects and for providing product feedback. ‍ All participation is evaluated based on the criteria in the Hackathon Rules, Terms & Conditions.

What to Build?

Build or update an open-source microservice-based software solution utilizing at least two Diagrid Catalyst APIs. The solution should be composed of multiple application services and either be newly written or significantly enhanced to utilize Diagrid Catalyst. The solution should be architected using AWS infrastructure and hosting services. The solution must align with one of the areas below:

Polyglot compute/ Cross-platform service discovery: Application services are deployed to different AWS hosting platforms, which interact via the Catalyst APIs.
Stateful business process orchestration: Application services are instrumented as part of a Dapr Workflow using the Dapr Workflow authoring SDK paired with the Catalyst Workflow API.
Serverless architecture: Application services are optimized to run on AWS PaaS/SaaS services, which abstracts infrastructure concerns and enables high-scalability.

Hackathon Timeline

Registration Open: April 19th 2024
Project Submissions Open: May 10th 2024
Feedback Submissions Open: May 24th 2024
Registration Closes: May 17th 2024
Project Submissions Deadline: June 7th 2024
Feedback Submissions Deadline: June 14th 2024
Location: Virtual Only

Catalyst Reference Apps

Looking for inspiration? See below for a couple of sample projects we’ve built using Diagrid Catalyst. More samples, including an AWS-specific reference, will be available to participants on the Hackathon site.

Tetris Game

The classic “blocks falling from the sky” game! The solution consists of two services:

A Python Flask user service which serves the JavaScript/HTML front-end for the user sign up and leaderboard and handles user state management and leaderboard updates.
A game service written in Go, which serves the JavaScript/HTML frontend for the game itself and manages the game session lifecycle.

These two services need to manage state and communicate to ensure games are started with the appropriate users, and user profiles are updated with the game results. The service interaction and data storage is all implemented using the APIs provided by Catalyst. Read the blog post.

Pizza Store Management System

A distributed pizza store with Catalyst APIs. The solution comprises two .NET microservices, two serverless JavaScript functions and a Vue front-end. The applications depend on Diagrid Catalyst as the serverless API layer to connect to the underlying data and messaging infrastructure. Read the blog.

How to Participate?

Participation is straightforward:

Register: Submit a registration request form for the hackathon. Eligible participants will receive a direct invite to the Hackathon site, hosted on Devpost. Accept your invitation to Devpost and click the blue “Register” button on the Hackathon landing page to register.
Create a project: Create a project to frame out your hackathon solution ideas for others to see and potentially join in to help execute. You have a few options when it comes to projects:
1. Create a closed project to participate as an individual.
2. Create an open project to enable other Hackathon participants to join you in your mission. You can even choose to invite people to participate in your project.
3. Join an existing, open project if one is available and intrigues you.
Learn: Join our ongoing Catalyst webinar series or watch on-demand.
Build: Develop your application using Diagrid Catalyst. Let your creativity shine, and don't forget to integrate innovative features.
Submit: Submit your project with the required deliverables by the deadline, June 7

For more information on resource access, project requirements and judging criteria, view the Hackathon Rules, Terms & Conditions.

Prizes

We have exciting cash prizes up for grabs! Prizes range from a Grand Prize of $2000 to Runner-up Prizes of $1000 each and Bonus Prizes from $250-$500! Get swag for participating & provide valuable product feedback for the chance to win another $100.

If you participate in the hackathon, you are also eligible for a $100 referral bonus for spreading the word! Share the Hackathon details with your friends and encourage them to sign up. The participant with the most referrals wins!

Get Ready to Hack

Don’t miss this unique opportunity to explore Diagrid Catalyst, build innovative apps, and compete for cash prizes. Whether you're a seasoned developer or a curious beginner, the Diagrid Catalyst Hackathon is your time to shine.

Building a distributed pizza store in .NET with serverless Dapr APIs

Marc Duiker — Thu, 01 Feb 2024 10:57:11 +0000

Intro

When developers build distributed systems, they need to think about cross-cutting concerns such as security, observability, and resiliency. Developers also write a lot of glue code to orchestrate services, create long-running and durable workflows, and connect to external resources, such as message brokers and state stores.

Dapr, the Distributed Application Runtime, is ideal for building distributed systems since it has built-in support for cross-cutting concerns, and it offers a suite of APIs for communication, state and workflow, that make developers more efficient. According to the State of Dapr Report, 95% of Dapr developers claim that Dapr saves time, and 55% of the developers surveyed claimed it saved them more than 30% of development time.

The usage of Dapr is also increasing thanks to a growing number of platforms that support the Dapr APIs. Dapr is no longer limited to running as a sidecar in Kubernetes, as is described in Dapr Deployment Models. In this article, Diagrid Catalyst, a suite of serverless Dapr APIs, is used to orchestrate services with Dapr workflow, and interact with message brokers and key-value stores.

Throughout this article, you’ll be using the following to configure a distributed system:

Two Dapr services (.NET)
Two serverless functions (JavaScript)
A front-end (Vue)
A key value state store
A pub/sub message broker
Diagrid Catalyst as the serverless API layer to connect everything

TLDR: Check the code on GitHub and join the Catalyst early access program.

Diagrid Pizza Store

The demo that is used in this article revolves around an online pizza store, where the user selects pizzas, orders them, and follows the progress of the order in realtime. It’s a simplified example where the durable workflow focuses on the inventory of ingredients, and communicating with the kitchen. The source code is on GitHub.

Architecture

The solution includes:

Two Dapr web services written in .NET, PizzaOrderService and KitchenService. In this demo, they’re running locally, but these can be hosted in any cloud that supports ASP.NET services.
The website (based on Vue) and two serverless functions written in JavaScript, getAblyToken and placeOrder. These are hosted on Vercel.
Ably as the realtime communication component between the PizzaOrderService and the website.
A key/value store to manage inventory (managed by Diagrid).
A pub/sub message broker to communicate between the PizzaOrderService and the KitchenService (managed by Diagrid).
Diagrid Catalyst that offers serverless APIs for communication, state, and workflow powered by Dapr.

Workflow

The PizzaOrderService contains a Dapr workflow that orchestrates the activities for checking the inventory and communicating with the KitchenService.

The workflow also contains activities for sending realtime messages to the website, these have been omitted from the workflow diagram to keep it concise.

Running the Pizza Store locally

Prerequisites

The following services, tools, and frameworks are required for this demo:

Diagrid Catalyst account (sign up for early access) and the Diagrid CLI
Vercel account (hobby) and the Vercel CLI
Ably account (free)
.NET 8 SDK
Node 18

All the code for the website, serverless functions, and back-end services is available in the catalyst-pizza-demo GitHub repository. This repository contains a devcontainer configuration that has the following preinstalled: .NET 8, Node LTS, Vercel CLI, Diagrid CLI.

You can use this devcontainer locally in VSCode (requires Docker Desktop) or directly in GitHub Codespaces. The npm install and dotnet build commands described in this article can be skipped if the devcontainer is used.

GitHub

Fork the catalyst-pizza-demo and clone it locally, or use GitHub Codespaces (recommended).

Ably

Ably is used as the serverless realtime messaging component. There is a default Ably app when you sign up for an account that can be used for this demo. Alternatively, you can create a new Ably app.

Log into the Ably portal.
Using the Ably portal: copy the Root API key from the Ably app. This will be copied later as an environment variable for both Vercel and Diagrid.

Vercel

The Vue-based front-end and two JavaScript functions are hosted on Vercel. The Vercel CLI is used to configure and run these resources locally.

Open a terminal in the root of the repository and login with the Vercel CLI:
```
vercel login
```
Go to the front-end folder and run:
```
npm install
```
Go back to the root of the repository and set up the Vercel project by running:
```
vercel
```
Follow the CLI prompts, and select the following options:
- Setup and deploy: Y
- Scope: <account name>
- Link to existing project: N
- What's your project's name? catalyst-pizza-project
- In which directory is your code located? ./front-end
- Want to modify these settings? [y/N] n
- Wait for the deployment to complete.
An environment variable is used in the getAblyToken function to generate a token for the website to communicate with the Ably realtime service. Add the Ably API token variable by running vercel env add:
- Variable name: ABLY_API_KEY
- Variable value: Use the Ably API key obtained from the Ably portal earlier
- Select Development as the environment.
Another environment variable is used in the placeOrder function to send a request to the PizzaOrderService that will start the workflow. Add the WORKFLOW_URL variable by running vercel env add:
- Variable name: WORKFLOW_URL
- Variable value: http://localhost:5064/workflow/orderReceived
- Select Development as the environment.
Run vercel pull to pull the configuration from Vercel to your local environment.
Run vercel build to build the website and the serverless functions to ensure there are no errors.

Diagrid Catalyst

Diagrid Catalyst provides serverless Dapr APIs that enables developers to quickly build distributed applications with workflow, pub/sub messaging, service invocation, and state management capabilities. Diagrid also provides managed infrastructure for storing data in a key/value store, pub/sub messaging, and workflow, which are all used in this solution.

The Diagrid CLI is used to configure the resources and run the .NET services locally.

Open another terminal in the root of the repository and use the Diagrid CLI to log in to Diagrid:
```
diagrid login
```
Create a new Catalyst project named catalyst-pizza-project and use the Diagrid managed pub/sub broker & KV store, and enable the managed workflow API:
```
diagrid project create catalyst-pizza-project --deploy-managed-pubsub --deploy-managed-kv --enable-managed-workflow --wait
```
To set this project as the default in the CLI run:
```
diagrid project use catalyst-pizza-project
```
Create a new App ID for the PizzaOrderService:
```
diagrid appid create pizzaorderservice
```
Create a new App ID for the KitchenService:
```
diagrid appid create kitchenservice
```
Before continuing, check the App ID status to make sure they are ready:
```
diagrid appid list
```

Create a pub/sub subscription for the KitchenService to receive messages from the PizzaOrderService:

diagrid subscription create pizzaorderssub --connection pubsub --topic pizza-orders --route /prepare --scopes kitchenservice

Create a pub/sub subscription for the PizzaOrderService to receive messages from the KitchenService:

diagrid subscription create preparedorderssub --connection pubsub --topic prepared-orders --route /workflow/orderPrepared --scopes pizzaorderservice

Verify that creation of the subscriptions is completed:
```
diagrid subscription list
```

Run diagrid dev scaffold to create a new local dev environment file. This creates a yaml file, named dev-.yaml with the following content:

project: catalyst-pizza-project
apps:
- appId: kitchenservice
appPort: 0
env:
    DAPR_API_TOKEN: diagrid://<dapr_api_token>
    DAPR_APP_ID: kitchenservice
    DAPR_GRPC_ENDPOINT: https://<grpc_endpoint>
    DAPR_HTTP_ENDPOINT: https://<http_endpoint>
workDir: kitchenservice
command: []
- appId: pizzaorderservice
appPort: 0
env:
    DAPR_API_TOKEN: diagrid://<dapr_api_token>
    DAPR_APP_ID: pizzaorderservice
    DAPR_GRPC_ENDPOINT: https://<grpc_endpoint>
    DAPR_HTTP_ENDPOINT: https://<http_endpoint>
workDir: pizzaorderservice
command: []
appLogDestination: ""

This file is gitignored since it contains secrets from Diagrid Catalyst. The appPort, command, and workDir attributes still need to be updated as follows:

Update the appPort for the kitchenservice to 5066.
Update the appPort for the pizzaorderservice to 5064.
Update the command arguments to ["dotnet", "run"] for both apps.
Update the workDir argument to point to back-end/KitchenService and back-end/PizzaOrderService respectively.
Update the appLogDestination to console.
Add an ABLY_API_KEY environment variable for the pizzaorderservice appId and set the value to the Ably API key obtained from the Ably portal.
Save the changes to the file.

Update the key/value store to allow shared state

The two .NET services share the same state in the key/value store to manage inventory and orders. Since this is not the default usage of state stores and services when using Dapr, an attribute needs to be set to enable this. The default behavior is that a key is prefixed with the app ID of the service that is using it. In this case, however, the keyPrefix is set to name to make sure both services use the same keys.

Run the following command to update the managed key/value store:
```
diagrid connection apply -f ./infra/kv.yml
```
This will upload the kv.yml file to Diagrid and update the configuration of the kvstore connection so keyPrefix is set to name.

Inspect the DaprClient configuration

The two .NET services use the Dapr .NET client SDK for workflow, state management and pub/sub messaging. The DaprClient is configured to use the endpoints provided by Diagrid Catalyst in the Program.cs file:

var apiToken = Environment.GetEnvironmentVariable("DAPR_API_TOKEN");
var grpcEndpoint = Environment.GetEnvironmentVariable("DAPR_GRPC_ENDPOINT");
var httpEndpoint = Environment.GetEnvironmentVariable("DAPR_HTTP_ENDPOINT");

builder.Services.AddDaprClient(options => {
    options.UseDaprApiToken(apiToken);
    options.UseGrpcEndpoint(grpcEndpoint);
    options.UseHttpEndpoint(httpEndpoint);
});

To use service invocation with the HTTP API, the HttpClient is configured with the DAPR_APP_ID and DAPR_API_TOKEN environment variables:

var appId = Environment.GetEnvironmentVariable("DAPR_APP_ID");
var apiToken = Environment.GetEnvironmentVariable("DAPR_API_TOKEN");

builder.Services.AddHttpClient(
    "daprEndpoint",
    client => {
        client.BaseAddress = new Uri(httpEndpoint);
        client.DefaultRequestHeaders.Accept.Add(new System.Net.Http.Headers.MediaTypeWithQualityHeaderValue("application/json"));
        client.DefaultRequestHeaders.Add("dapr-app-id", appId);
        client.DefaultRequestHeaders.Add("dapr-api-token", apiToken);
    });

Running & testing the solution

Open a terminal in the root of the repository.

To restore and build the .NET projects run:

dotnet build ./back-end/PizzaOrderService
dotnet build ./back-end/KitchenService

Run diagrid dev start to start the PizzaOrderService and the KitchenService.
Using another terminal in the root of the repository, run vercel dev to start the website and the serverless functions locally.
Navigate to the URL provided by the Vercel CLI to view the website.
Select some pizzas, place an order, and watch the progress of the workflow in realtime.

Using the Catalyst API explorer

You can use the API explorer in the Catalyst web UI to interact with the APIs. If you want to retrieve the order item from the key/value store that has just been processed, follow these steps:

Open the developer tools console of the browser that is running the demo (a pizza order must be started or completed).
The order is logged to the console as a JSON object. Copy the OrderId property value.
Navigate to the Catalyst web UI. Ensure you're in the catalyst-pizza-project project.
Select App IDs in and click on the API explorer tab.
- Select the State API.
- Select the pizzaorderservice as the app ID.
- Select GET as the API operation.
- Select kvstore as the state connection.
- Enter Order- as the key, where is substituted with the value copied from the developer tools console.
Click Send. The response should show the state of the order item.

What’s next?

Congratulations! You’ve now used the Diagrid Catalyst serverless Dapr APIs for workflow, pub/sub messaging, service invocation, and state management. The ability to use these APIs from anywhere, without the overhead of managing Kubernetes clusters, brings great flexibility to developers on any platform to build distributed applications. The Dapr applications used in this demo can be hosted on any cloud. The demo uses the Diagrid managed infrastructure for key/value storage and pub/sub messaging, but these can be swapped out for other cloud-based resources, similarly to switching open-source Dapr components. You can extend this demo with an alternative pub/sub broker or state store by configuring other infrastructure connections.

Any questions or comments about this demo? Join the Dapr Discord and drop us a message in the #diagrid channel!

Dapr as the Ultimate Microservices Patterns Framework

Bilgin Ibryam — Wed, 27 Sep 2023 09:06:20 +0000

In the world of software development, microservices architecture stands out as the industry benchmark. This architectural style segments applications into distinct services, each deployable independently and organized around specific business capabilities. Such a design ensures flexibility, scalability, and resilience, with each service typically overseen by a specialized team. However, while this approach offers numerous benefits, it also introduces complexities. To navigate these challenges, developers turn to patterns, drawing parallels to time-tested design patterns from traditional software development, providing solutions for building robust distributed systems. For those seeking a comprehensive guide on these patterns, Chris Richardson’s microservices.io stands as a trusted repository, rich with insights and best practices from industry experts.

A pattern language for microservices by Chris Richardson

However, understanding patterns is just one part of the equation. Implementing them in real-world scenarios requires tools and frameworks. Positioned as a premier microservices chassis, Dapr is crafted for creating distributed applications that are secure, resilient, scalable, and observable. It doesn't merely align with the microservices patterns; it amplifies their potential, refining and simplifying their real-world implementation.

In the subsequent sections, I'll go through the patterns outlined in microservices.io, shedding light on how Dapr helps implement each. While numerous frameworks aim to address the cross-cutting concerns inherent in microservices, Dapr distinguishes itself. Its polyglot nature, sidecar operational mode, and non-restrictive stance on application architecture make it a unique and invaluable asset in the microservices toolkit.

Microservice Chassis

When embarking on the development of an application, developers often find themselves investing significant time in addressing cross-cutting concerns such as security, externalized configuration, logging, health checks, metrics, and distributed tracing. While these elements might seem straightforward, defining a curated set of dependencies that will be used in tens or hundreds of services can be a complex endeavor. The challenge amplifies when adopting a microservices architecture, given the multitude of services and the frequent creation of new ones. The Microservice Chassis pattern offers a solution by proposing the creation of a framework that serves as the foundation for microservices development. This chassis provides reusable build logic and mechanisms to handle these cross-cutting concerns, streamlining the development process.

As a polyglot framework, Dapr seamlessly handles cross-cutting concerns, allowing developers to focus on core functionalities without getting entangled in complexities. It provides built-in mechanisms for security, configuration management, logging, and more. With features like the Access Control capabilities for security, Configuration API for externalized settings, and health API endpoints for monitoring, Dapr ensures that these foundational concerns are seamlessly integrated, allowing developers to focus on core business logic without getting mired in the intricacies of these concerns. Unlike other frameworks, Dapr doesn't impose constraints on the application, granting developers the freedom to choose their preferred language, runtime, and programming style. In essence, Dapr transforms the theoretical benefits of the Microservice Chassis pattern into tangible results for real-world applications.

Sidecar

In microservices, there's often a need to augment services with additional capabilities without modifying the core service logic. The Sidecar pattern addresses this requirement. It involves deploying components of an application into separate processes or containers to provide a modular and scalable architecture. The main service runs in one container, and the sidecar service, which extends or enhances the main service, runs in a separate container but in the same network namespace. This ensures that the main service and the sidecar can communicate as if they are in the same process while being isolated from each other. The primary advantage of this pattern is the ability to separate concerns, modularize your application, and ensure that each component is focused on a specific responsibility.

Dapr is among the most popular implementations of the Sidecar pattern. When integrated into a microservices environment, Dapr runs as a sidecar alongside your service, providing a plethora of additional capabilities without requiring any changes to the main service. This includes features like state management, service-to-service invocation, pub/sub messaging, and more. By leveraging Dapr's sidecar architecture, developers can augment their services with powerful features, ensuring a robust, scalable, and feature-rich microservices ecosystem.

Service Mesh

As the number of services grows, managing inter-service communication, security, and observability becomes increasingly complex. A Service Mesh is a dedicated infrastructure layer built to handle service-to-service communication in a transparent and technology-agnostic manner. It provides features like load balancing, service discovery, observability, and security without requiring changes to the application code. By offloading these concerns to the Service Mesh, developers can focus on building business logic, while the mesh ensures that services can securely and efficiently communicate with each other.

How Dapr and service meshes compare

Dapr operates as a lightweight service mesh, providing a network layer that facilitates service discovery and ensures secure service-to-service interactions. While there are overlapping capabilities between Dapr and traditional service meshes, Dapr distinguishes itself by being developer-centric, focusing on building blocks that simplify microservices development. Unlike service meshes which are primarily infrastructure-centric and deal with network concepts like IP and DNS addresses, Dapr offers service discovery and invocation via names, a more developer-friendly approach. Beyond the common features like mTLS encryption, metric collection, and distributed tracing, Dapr introduces application-level building blocks for state management, pub/sub messaging, actors, and more. This ensures that developers gain a comprehensive toolset, not just for networking, but for holistic microservices development.

Saga

In the world of microservices, ensuring data consistency across services can be a challenge, especially when each service has its own database. The Saga pattern provides a solution to this challenge. Instead of relying on traditional distributed transactions, the Saga pattern breaks the transaction into a series of local transactions, each executed within its own service and database. These local transactions are coordinated in a specific sequence to ensure overall data consistency. If one local transaction fails, compensating transactions are executed to revert the changes made by the previous transactions. This approach offers a way to maintain data consistency without the need for distributed transactions, which are often not feasible in microservices architectures.

Dapr workflow overview

Dapr offers a concrete solution to implement the Saga pattern through its Workflow API. This API allows developers to sequence local transactions, or implement other stateful workflow patterns ensuring that data remains consistent across services. Dapr Workflow API serves as a foundational tool in this regard, streamlining the process and ensuring reliability.

Transactional Outbox

In microservices architectures, a common challenge arises when a service command needs to update aggregates in the database and simultaneously send messages or events to a message broker. The goal is to ensure atomicity - if the database transaction commits, the messages must be sent; if the database rolls back, the messages must not be sent. Traditional distributed transactions (2PC) are often not feasible or desirable due to various constraints. The Transactional Outbox pattern addresses this issue. It suggests that the service stores the message in the database as part of the transaction that updates the business entities. A separate process then retrieves and sends these messages to the message broker. This ensures that messages are sent only if the database transaction commits, preserving data consistency and order of operations.

Dapr provides a robust solution to this challenge with its Outbox feature in StateStore API. This feature allows for atomic updates to the database while also sending messages to the designated broker. By utilizing the StateStore API, developers can seamlessly integrate the Transactional Outbox pattern into their microservices, ensuring data consistency and reliable message delivery across large number of databases and message brokers.

Messaging

In the realm of microservices, reliable asynchronous communication between services is paramount. Instead of services communicating directly with synchronous calls, they exchange messages via message channels. This asynchronous mode of communication decouples services, allowing them to operate independently. It ensures that even if one service is slow or unavailable, others can continue their operations without being directly affected. This approach enhances the system's resilience, scalability, and flexibility.

Dapr's PubSub API is tailored to harness the power of asynchronous messaging for inter-service communication. By leveraging this API, developers can easily implement messaging patterns in their microservices architecture. The PubSub API ensures reliable message delivery, supports multiple messaging brokers, and abstracts the complexities of direct broker interactions.

Request/Reply Interaction

Remote Procedure Invocation (RPI) is a communication style that enables services in a microservices architecture to communicate with each other by invoking methods in a remote service. The primary advantage of RPI is its straightforwardness, allowing for direct, point-to-point communication between services. However, it's essential to manage the associated challenges, such as service discovery, reliability, encryption, to ensure the system remains resilient and secure.

Dapr addresses the challenges with its Service Invocation API. This API provides an RPI-based protocol tailored for inter-service communication in a microservices setup. By abstracting the underlying complexities, Dapr ensures that services can communicate synchronously without getting entangled in the intricacies of direct service-to-service calls. Moreover, Dapr's Service Invocation API offers built-in features like retries, error handling, and traffic control, ensuring that communications are both reliable and secure.

Circuit Breaker

In a microservices architecture, services often collaborate to handle requests. However, when one service synchronously invokes another, there's a risk that the called service might be unavailable or might exhibit high latency, rendering it essentially unusable. Such scenarios can lead to resource exhaustion in the calling service, making it unable to handle other requests. This can further cascade the failure to other services throughout the application. The Circuit Breaker pattern addresses this challenge. It functions similarly to an electrical circuit breaker. When consecutive failures cross a certain threshold, the circuit breaker "trips." For a set timeout period, all attempts to invoke the problematic service fail immediately. After this period, the circuit breaker allows a few test requests. If these succeed, normal operation resumes; if not, the timeout period restarts.

Dapr offers a concrete solution to this challenge with its Resiliency policy. This policy ensures that when the failure rate of a call exceeds a certain threshold, the call fails immediately, preventing resource exhaustion and potential cascading failures. By leveraging Dapr's resiliency policy, developers can implement the Circuit Breaker pattern efficiently, ensuring that their microservices architecture remains robust and resilient against unexpected service failures or latencies.

Access Token

In the intricate landscape of microservices, ensuring secure communication and access between services is paramount. The Access Token pattern involves issuing tokens to clients, granting them limited access to a service. These tokens encapsulate the information required to determine whether a client is authorized to perform a given operation. The primary advantage of using access tokens is that they provide a way to ensure that only authenticated and authorized clients can access services or specific operations within those services.

Dapr secure communications architecture

Dapr provides a robust mechanism to implement this pattern through its Access Control capabilities based on SPIFFE Ids. With Dapr's Access Control, developers can define and enforce policies that restrict what operations calling applications can perform on the called app. This ensures a fine-grained control over service interactions, making the system more secure and resilient against potential threats.

Service Instance per Container

The Service Instance per Container pattern deployment strategy, places each service instance in its own container. Containers, being lightweight and isolated, provide an environment where the service can run with its dependencies, ensuring consistency across different stages of deployment. This approach offers several benefits: it ensures isolation, making each service instance independent of others; it provides scalability, as new instances can be spun up quickly; and it enhances portability, as each service containts its built-time dependencies.

Dapr aligns perfectly with this deployment model as it is designed to operate best in containerized environments. When a service is deployed with Dapr, a Dapr sidecar container runs alongside the service container, enhancing its capabilities without intruding into the service's operations. Dapr's deployment model, ensures that each service instance, along with its Dapr sidecar, remains isolated in its container, benefiting from the inherent advantages of the Service Instance per Container pattern such as scalable, and resilient microservices deployments.

Service Instance per VM

In certain deployment scenarios, especially when dealing with large-scale applications or when containers might not be the optimal choice, deploying each service instance on its own Virtual Machine (VM) becomes a viable strategy. The Service Instance per VM pattern emphasizes this approach. By allocating a dedicated VM for each service instance, you ensure that the service has a dedicated set of resources, leading to predictable performance. This isolation also means that failures or resource contention in one service won't directly impact others. Moreover, VMs provide a higher degree of isolation compared to containers, which can be crucial for certain security or compliance requirements.

Dapr is versatile and can be seamlessly deployed in a VM-based environment. Whether you're deploying Dapr on its own dedicated VM or using Dapr Ambient to share its capabilities among multiple Pods, Dapr ensures that microservices can communicate and operate efficiently. This flexibility means that developers aren't confined to containerized environments and can leverage Dapr's capabilities in VM-based deployments, ensuring that the benefits of Dapr, such as state management, service invocation, and pub/sub messaging, are available regardless of the deployment strategy. Dapr's deployment documentation provides insights into how it can be integrated into various environments, including VMs, or the real edge.

Service Discovery

In microservices architectures, the dynamic nature of service instances and their locations, especially in containerized environments, presents a challenge: how does a client of a service discover the location of a service instance? Two prevalent patterns address this challenge: Client-side Discovery and Server-side Discovery. The former involves clients querying a Service Registry to discover the current locations of service instances, ensuring they always communicate with available and healthy instances. On the other hand, the Server-side Discovery pattern simplifies client code by routing requests via a knowledgeable router, often a load balancer, which interacts with the service registry.

Dapr's sidecar architecture adeptly addresses both these patterns. While the sidecar operates alongside a service, akin to a client, it isn't embedded within the application. This unique positioning allows it to query a service registry, discovering other service instances' locations, and also act as a router for inter-service calls. By offloading the intricacies of service discovery to the Dapr Service Invocation API, developers can ensure reliable service-to-service communication, even in environments where service locations change dynamically.

Service Registry

In dynamic microservices environments, the locations and number of service instances can frequently change. This poses a challenge: how can clients or routers be aware of the current available instances of a service? The Service Registry pattern offers a solution. It proposes a centralized registry where service instances register themselves upon startup and deregister upon shutdown. This registry acts as a database of services, their instances, and their locations. Clients or routers can then query this registry to discover the current locations of service instances.

Dapr offers a seamless integration with the Service Registry concept, providing a unified interface to various service registry implementations. Dapr's pluggable name resolution components used in Service Invocation API cater to diverse hosting platforms, from Kubernetes, which utilizes its DNS service, to self-hosted machines using mDNS or even HashiCorp's Consul in varied environments.

Self Registration

The Self Registration pattern ensures that services can discover each other in inter-service communication. When a service instance starts up, instead of relying on an external agent or system to register it with a service registry, the service instance itself takes the responsibility of registering. This ensures that the service registry always has the most up-to-date information about available service instances. By automating the registration process, the Self Registration pattern reduces manual intervention, potential errors, and ensures that the service registry is always current.

When a service with a Dapr sidecar is deployed, the Dapr sidecar takes the initiative to register itself with the service registry. This automated process ensures that the service is immediately discoverable by other services in the ecosystem. This not only simplifies the deployment process but also enhances the reliability and efficiency of service-to-service communication in architectures built with Dapr.

3rd Party Registration

In some microservices architectures, not all services or endpoints are created or managed by the same team or entity. There might be third-party services or endpoints that need to be integrated into the system. These third-party services might not follow the same registration patterns as internal services. With the 3rd Party Registration pattern, instead of the service registering itself (as in Self Registration), an external agent or system is responsible for registering the service with the service registry. This ensures that third-party services, which might not have the capability or permission to register themselves, are still discoverable and can be integrated seamlessly into the system.

Dapr offers flexibility in this regard too. Even non-Dapr 3rd party endpoints can be registered within the Dapr runtime, ensuring they benefit from service discovery, resiliency, and observability features that Dapr provides. This means that developers can integrate third-party services into their Dapr-enabled microservices architecture without those services being Dapr-aware. This allows a more cohesive and resilient microservices ecosystem, irrespective of the origin of the services.

Externalized Configuration

In the world of microservices, applications often interact with various infrastructure and third-party services. Examples include service registries, message brokers, databases, payment processors, and more. A significant challenge arises when trying to ensure that a service can run across multiple environments (like dev, test, staging, production) without any modifications. The Externalized Configuration pattern recommends externalizing all application configurations. This ensures that the service remains environment-agnostic and can adapt to different setups without any code changes.

Dapr secrets stores overview

Dapr provides a robust solution to this challenge with its Secrets and Configuration APIs. These APIs allow developers to externalize configurations, including sensitive information like database credentials. Instead of hardcoding configurations or placing them in easily accessible files, Dapr ensures that they are securely stored and can be fetched dynamically when needed.

Health Check API

In a microservices architecture, ensuring the health, availability, and self-healing of service instances is paramount. The Health Check API pattern proposes that each service should expose an API endpoint (e.g., HTTP /health) that indicates the health status of the service. This endpoint performs various checks, such as the status of connections to infrastructure services, the health of the host (e.g., disk space), and any application-specific logic. By periodically querying this endpoint, monitoring systems, service registries, or load balancers can determine the health of a service instance. This ensures that alerts are generated for unhealthy instances, and requests are only routed to healthy service instances, enhancing the reliability and efficiency of the system.

Dapr elevates the health check pattern by conducting periodic health checks on your service, ensuring its optimal functioning. Once app health checks are enabled, the Dapr sidecar routinely polls the application. If a health issue is detected, Dapr takes proactive measures: it unsubscribes from all pub/sub subscriptions, halts all input bindings, and short-circuits service-invocation requests, ensuring they aren't forwarded to the application. This comprehensive approach ensures that any potential issues are swiftly identified and mitigated, fostering a robust and resilient system.

Distributed Tracing

In complex microservices architectures, understanding the flow of requests across multiple services can be challenging. The Distributed Tracing pattern involves instrumenting services with code that assigns each external request a unique identifier. This identifier is then passed to all services involved in handling the request. By doing so, it becomes possible to trace the journey of a request across various services, recording information such as start time, end time, and other relevant metrics providing invaluable insights into the behavior of the system.

Dapr distributed tracing overview

Dapr automatically takes care of creating trace headers and ensures they are captured and forwarded appropriately. With Dapr’s observability capabilities, developers don't need to manually instrument their code for tracing; Dapr handles it seamlessly. Moreover, Dapr integrates with popular tracing systems, ensuring that the traces can be visualized and analyzed in a centralized manner.

Application Metrics

Application Metrics are a set of quantitative data points that provide insights into the performance, behavior, and health of an application or service. By collecting and analyzing these metrics, developers and operations teams can identify bottlenecks, detect anomalies, and optimize the performance of their services, enabling proactive monitoring and ensuring optimal system health.

Dapr automatically gathers a wide range of networking metrics, capturing data related to request rates, error rates, and latency, among others. Dapr ensures that these metrics are delivered to a centralized metrics service, allowing for comprehensive monitoring and analysis. This means that developers and operations teams can have a unified view of the system's performance, irrespective of the number of services or their complexity.

Serverless Deployment

In the evolving landscape of software development, the need for scalable, and cost-effective deployment solutions is growing. Serverless Deployment refers to a deployment infrastructure that abstracts away any concept of servers, be it physical, virtual hosts, or containers. The primary advantage is that developers can focus solely on their code, without concerning themselves with the underlying infrastructure. The serverless platform automatically scales services based on the load, ensuring optimal resource utilization.

Dapr is gearing up for the serverless era too. Soon, developers will be able to access Dapr's rich capabilities as serverless APIs. This means that the vast array of features Dapr offers, from state management to messaging, will be available in a serverless context, ensuring developers get the best of both worlds. By integrating Dapr into serverless environments, developers can ensure more robust, scalable, and feature-rich applications without the complexities of managing the Dapr infrastructure. For the updates on this pattern, follow @diagridio on Twitter and you can be among the first to try it out.

Summary

Patterns play a pivotal role in software development, serving as a shared language to communicate common challenges and best practices. They encapsulate proven solutions to recurring problems, ensuring that developers don't have to reinvent the wheel with each new project. However, while patterns provide a conceptual blueprint, they remain abstract ideas. Historically, the challenges of building reliable applications and the implementations of these patterns were addressed using application servers, service buses, and microservices frameworks like Spring Cloud, among other language-specific solutions. But to truly bring these patterns to life in the modern era, we need cloud-native frameworks and chassis like Dapr. Dapr tackles these common engineering challenges by presenting patterns as polyglot APIs, aligning with the cloud-native philosophy and offering benefits to the whole organization. This ensures that developers can leverage best practices across multiple languages and platforms, streamlining the development process and enhancing application resilience and scalability.

Top 20 Must-Read Software Trends Reports for 2023

Bilgin Ibryam — Thu, 20 Jul 2023 09:14:09 +0000

In the rapidly evolving software industry, keeping up with new trends, tools, and best practices can be time-consuming. With so much information available, where do you start, and what sources can you trust? I've curated a list of reports that I follow to stay informed and ahead of the curve. These provide insights into everything from programming languages to DevOps, cloud strategy, and security. If you're interested in the latest trends and fascinating posts I come across, follow me or check out my latest writing on industry trends over at the Diagrid blog. I share anything I find insightful and worth reading in the world of cloud and distributed systems.

Here are the top 20 reports for 2023 (in no particular order) I came across so far:

While these reports offer valuable insights, it's important to keep in mind that they can be opinionated. The key to effectively leveraging these resources lies in cross-verifying trends from multiple sources and using them only as a guide for direction rather than absolute truths.

Are there any reports that should be on this list? Tag me on Twitter and I'll include them, subject to my checks I'm always keen to explore new sources! Found this list helpful? Go ahead, share it.

Call to action: Are you a Dapr user? Your experience is valuable! Contribute your insights and shape the State of Dapr Report.