S01E05 dapr-compass – But why Dapr?

If you missed the previous episodes of the season, here’re the links:

• S01E01 dapr-compass: how the story begins
• S01E02 dapr-compass - how we organized the work
• S01E03 dapr-compass – The Front End API interface
• S01E04 dapr-compass – No actor is an island

We originally described how this project was born and why we decided we wanted to play with Dapr (in one word, because it’s beautiful!), but some of you might be asking (and indeed, already asked) why we decided to test a real-life scenario with possible implementations, other than the fact that the lockdown left us with lots of free weekends?

Well, we have more than one answer to this question.

First, we all work, as they say, “in the field”, meaning we work with global strategic customers in the daily operations and choices of cloud computing. I think it’s fair to say we have a decent vision of what are the struggles for our customers: migrating old applications, refactoring code that nobody knows anymore, integrating new cool stuff with old dinosaurs and, most of all, the complexity of running distributed microservices applications in a non-distributed microservices world. We saw dapr as something that could really make our customers’ life easier in many ways. Also, Dapr is an openAPI specification, using gRPC for sidecars communication, and for clients and application code native communication.

The public cloud got us used to embracing variety and freedom of choice, and this is probably one of the most powerful revolutions of cloud computing. It’s ok when developers choose their own flavor of tools, programming languages, methodologies: diversity is a successful way of nature to trigger growth, and so we celebrate and nurture and respect it. Every developer makes their own decisions based mostly on what we call “computer science religion”: yes there are logical and technical reasons, but everyone has their own and will hardly change their mind just based on those. The choice of Dapr to use HTTP as the common ground for everyone seems very fair and simple. No developer can deny that a POST or GET request to a REST API is a simple ask that can be easily fulfilled. This means HTTP is the basis of Dapr interoperability across all programming languages.

Programming models tend to constrain developers to avoid issues and mistakes, but this has the counter-effect of cutting complexity and forcing developers to create weird uses of the models. There is no such thing as an error-free world, and as we often say in native cloud discussions, embracing faults is the first step of self-consciousness that leads to scalable and reliable applications. The state manager offers “optimistic concurrency” by default relying on ETags, and particularly in this moment in time, we feel optimism is a pretty good start.

Flexibility is also a key point of Dapr, allowing to represent the same method with different languages and infrastructures, including all the public clouds, but also on-premises workloads, and the freedom of moving a service from container to serverless, from stateless to stateful with few lines of codes and regardless of the underlying tool. Incidentally, the runtime is really lightweight and fast to load.

Here’s our self interview to give you some additional personal insights:

Q: What's your "why Dapr"?

Davide: "Dapr combines a solid actor model implementation with capabilities typically found in service meshes like service discovery, pluggable bindings. An overall solution can be built upon Dapr at different degrees of integration: each team is able to leverage a language specific SDK or sidecar HTTP endpoint”

Giulio: "Dapr lets you focus on your business logic, and lets you choose your preferred language in a coherent ecosystem, enabling a seamless scale-up of your workload.

Jessica: "Dapr simplifies developers’ lives when they have to deal with the most common challenges in microservices development. In particular, I really appreciate the way it handles state and data stores in a plug-and-play mode, allowing applications to be more flexible and agnostic with respect to the underlying infrastructure"

As for me, I am optimistic by nature and I love new, cool stuff: I cannot miss a beautiful architecture with optimistic concurrency. Life is good. Have a nice holiday and we'll be back in September with lots of experience on the load testing!