I've been playing with this thing recently called Dapr (you can blame @marcduiker for me finding out about the project).
For those wondering what the heck Dapr is, you'd be right it does sound like it's dapper and means you need a fancy hat.
But it's also a cool open-source project that is part of the CNCF, you can check out the GitHub to go and investigate. What it's great at is acting as a common API and system for distributed event-driven applications.
For what reason could I have been interested? Well, like most of us, I've been building a side project or two between contracts. And the one I'm most interested in finishing (feel free to ask me about it) is a distributed app across multiple vendors. I have a selection of the application in Railway doing responsive quick things and handling anything I'd need to worry about being highly available, and then the big static data crunching bits in containers on Digital Ocean. Each one handles its queues and pub/sub, and to communicate with each other they have "private" APIs to send and receive stuff.
Wouldn't this be so much easier with something like Dapr acting as a common API to do service invocation of HA to long processes? Or pub/sub for anything that needs to be done immediately. Would you be happy to pass it back and forth for the user?
Unfortunately for me, I haven't had the time to work out how to stand up and secure Dapr between the two vendors so it got left behind.
But the title gives it away, Dapr is an open-source open-core technology. And as some of you may know, I love open-core tech.
Mike Elsmore on LinkedIn: The greatest thing about Open Core projects is being able to produce the…
The greatest thing about Open Core projects is being able to produce the MVP on completely open tooling like Novu or configuring OpenTelemetry before having to…
linkedin.com
One of the organizations behind Dapr is called Diagrid, and they have a managed service product for running Dapr workloads on Kubernetes called Conductor. But what I'm excited about is what they announced the other day, the public beta for Catalyst (read about it here https://www.diagrid.io/blog/announcing-catalyst-public-beta).
This is exciting in my specific use case of multi-vendor IaaS & PaaS without having to manage it myself. That means I can probably replace my RabbitMQ instances in each vendor with Catalyst, as well as use its state management tooling as its key/value storage to handle data being shared between long-running processes without a shared database.
You can see what Catalyst is currently capable of in this diagram. 
It even has a diagram explaining how I could use service invocation rather than "private" APIs to handle triggering services across vendors
Ignoring that the diagram is Lambdas rather than Railway to Digital Ocean, this would mean me removing a lot of retry boilerplate!
If you're interested, I'd read about the capabilities of Dapr in general. And I'd jump on to the public beta to try it for yourself.
Top comments (0)