Simon Bisson
Contributor

Microservices made easy with Dapr

analysis
Oct 29, 20196 mins
Cloud ManagementMicrosoft AzureSoftware Development

Use common microservice design patterns with Microsoft’s new open source, cloud-native framework

miniature figurines on a circuit board amid binary code / hardware / development / microservices
Credit: Alfexe / Toni Vaver / Getty Images

If you want to get the most out of cloud-native applications, you need to think very differently about how you build your code. Scaling depends on stateless microservices, using APIs for interservice communications. Technologies such as Kubernetes help manage microservice scaling by monitoring resources or using KEDA (Kubernetes-based event-driven autoscaling) to trigger scaling based on events, whereas HTTP-based technologies such as gRPC are the foundation for treating APIs as method and function calls.

Building distributed applications often seems like reinventing the wheel, building new tools to do the same thing, time and time again. That’s finally starting to change. As an industry we’re putting together a pattern language for distributed applications, along with the first generation of tools to take advantage of these patterns and practices. Announced at the same time as OAM (Open Application Model) and Rudr, Dapr (the Distributed Application Runtime), is a tool to build and run microservice-based distributed systems.

Introducing Dapr

Available on GitHub and open for community participation, Dapr is a language-agnostic and vendor-neutral framework with a focus on building event-driven microservices, so you can use it with your choice of languages, or even with a mix of different languages. It runs as a sidecar, so you don’t need to include any Dapr libraries or runtimes in your application. All you need is an API.

This approach simplifies installing Dapr, as it’s a logically separate process from your application. If you’re using Kubernetes it’s simply a matter of installing a Dapr container alongside your application containers in a single pod. You can deploy it from its own CLI, choosing the type of deployment. Currently you’re limited to local and Kubernetes deployments, but the development team’s road map includes other distributed application frameworksm such as Azure’s Service Fabric.

Installation scripts are available for Windows, Mac OS, and Linux. Once you’ve installed the bootstrap tools, use the Dapr CLI to initialize a local copy on your development machines, downloading the framework binaries and running services.

Implementing design pattern building blocks

The first release of Dapr supports six key microservice design patterns, which Dapr implements as “building blocks.” These APIs work with your code to provide the core services required by a modern cloud application. Instead of writing custom state management or service invocation code, all you need to do is call in to Dapr, using its implementation of the features you need to use. It gives you standard APIs, so you have one way to call specific functions no matter how Dapr is hosted and what applications or services it uses to deliver key microservice behaviors.

Your microservices should be inherently stateless, but your application will need to manage its state. Normally that requires choosing a storage platform, usually some form of key/value NoSQL database, and then writing state information to the store so that user transactions can be resumed in the event of service failure. With Dapr one API manages overall application state, which can be connected to your choice of supported components.

If you prefer to use a cross-platform store such as Redis, then configure Dapr with its Redis plug-in. Or if you’re intending only to use Azure services, you can choose a Cosmos DB plug-in. There’s no need for a developer to know anything about the service used—only the Dapr APIs. As more components are added, you can switch them out for more appropriate tools for the cloud you’re running on, with a comprehensive road map that includes tools like AWS’s DynamoDB.

Many cloud applications take a more loosely coupled approach, using event-driven architectures where messages from both inside and outside your application are processed, generating responses. Dapr supports three different approaches to event-driven applications: a publish and subscribe system like that used by Azure EventGrid; a way to bind events to specific resources, much like Azure’s IoT Hub or Apache Kafka; and a virtual actor model similar to Microsoft’s Service Fabric and Microsoft Research’s Orleans.

Finally, Dapr adds tools for distributed tracing, helping you debug and manage running distributed applications. It uses familiar W3C tracing APIs, so you can hook your Dapr apps to your choice of monitoring tools, including performance analysis systems. Distributed tracing is an important tool, since in a microservice architecture composite applications can share services, so you’re able to tie a trace to an application, allowing you to see which applications affect which services.

Cloud applications get portable

There’s a lot to like in Dapr’s portable application model. You can choose an appropriate microservice architecture and use Dapr to wire it together with managed service method calls or via publish and subscribe messaging. If you need to move from Azure Service Fabric to Kubernetes, all you need to do is set up a new set of components and then redeploy your app. Developers no longer need to be subject matter experts in a specific application framework; instead you’re building a bank of cross-cloud framework operations skills, using a similar model to OAM with a separation between developers, application operations, and cloud infrastructure operations.

Having standard APIs is key, with Dapr offering HTTP or gRPC APIs. You’re likely to use HTTP to deliver events and gRPC to call service methods. The resulting code is clear and readable, with logical structure to the Dapr APIs. To publish an event to subscribing services, just call the appropriate Dapr end point and it will deliver the message to all subscribers.

As well as the HTTP or gRPC APIs, there are language-specific SDKs for most common developer platforms, including JavaScript, .Net, Python, and Go. Integrating Dapr with the languages you’re most likely to use helps you take advantage of it in other development frameworks, allowing you to pick and mix the services and features used in your code. For example, using the .Net SDK in ASP.Net Core you can have Dapr integrate your front-end code and services with Dapr-hosted events and messages.

Moving to the public cloud, especially to services like Azure, isn’t a matter of lifting and shifting your existing applications. If you want to get the benefits of cloud, especially its scalability and reliability, then you need to develop cloud-native applications. That means working with event-driven microservices and event-driven scalability. Dapr and similar tools aim to reduce the complexities associated with developing microservices and with using them on popular distributed computing platforms. If you’re not already looking at them, you should start soon—before your competitors get a head start.

Simon Bisson
Contributor

Author of InfoWorld's Enterprise Microsoft blog, Simon Bisson prefers to think of “career” as a verb rather than a noun, having worked in academic and telecoms research, as well as having been the CTO of a startup, running the technical side of UK Online (the first national ISP with content as well as connections), before moving into consultancy and technology strategy. He’s built plenty of large-scale web applications, designed architectures for multi-terabyte online image stores, implemented B2B information hubs, and come up with next generation mobile network architectures and knowledge management solutions. In between doing all that, he’s been a freelance journalist since the early days of the web and writes about everything from enterprise architecture down to gadgets.

More from this author