MMS • Mark Fussell Yaron Schneider
Thomas Betts: Hey folks. Before we get to today’s podcast, I wanted to let you know that InfoQ’s International Software Development Conference, QCon is coming back to San Francisco from October 2nd to the 6th. At QCon, you’ll hear from innovative senior software development practitioners, talking about real world technical solutions that apply emerging patterns and practices to address current challenges. Learn more at QConsf.com. We hope to see you there.
Hello and welcome to the InfoQ Podcast. I’m Thomas Betts and today I’m joined by Mark Fussell and Yaron Schneider. Mark is CEO and Yaron is CTO of Diagrid, a developer focused startup. They’re both co-creators of the Distributed Applications Runtime Project, Dapr. For the last couple of years, Dapr has been on the InfoQ Architecture and Designs Trends Report. This year was part of the discussion around design for portability and cloud bound applications. Today we’ll be talking all about Dapr, from its creation in 2019, through its adoption by the CNCF and where it’s currently headed. We’ll cover the use case of Dapr and help you determine if it might be a good fit for your projects. Mark and Yaron, welcome to the InfoQ Podcast.
Yaron Schneider: Thank you so much for having us.
Mark Fussell: Wonderful to be here.
What is Dapr? [01:06]
Thomas Betts: So let’s start at the beginning. What is Dapr and what problem is it trying to solve?
Mark Fussell: Dapr is a developer productivity suite of APIs, so effectively enables developers to build distributed applications in half the time they would do normally. And effectively what you have with Dapr is APIs that codify the best practices for building distributed applications.
What this means in practice, is that we’ve seen developers struggle to build on top of platforms, even ranging from single VMs, but particularly around Kubernetes. To run and build applications that codify, like event-driven architectures, or messaging between services, or orchestration of applications, and particularly around microservices architecture. So instead we took all the learnings from that, understood the problem space, and when you get down to the complexities of these applications, there’s many things you have to think about. So we took all that, codified it into a set of APIs that you can access from any framework of your choice, whether it’s the language of your choice or framework of your choice over HTTP or GRPC, to be able to use these APIs to productively create distributed applications.
Thomas Betts: And then how does Dapr compare to other ways? You mentioned you’re codifying, the ways you’re implementing, say event-driven architecture or microservices architecture. Is this just in comparison to building all of that from scratch? Is that the only other option?
Yaron Schneider: Yes, mostly we see developers write all of these functionality themselves, and so they end up with these huge chunks of boilerplate code they then need to maintain sometimes for years to come. And all of this code becomes even more complex if they run in a multi-cloud environment. So they have multiple code bases for different environments they’re running in and Dapr provides them with these abstractions that allow them to, in a multi-cloud world, run very easily on top of different clouds.
But it’s also a lot more than that. For example, if you need a workflow engine or encryption between your services or pub/sub, you might take three different technologies to do that and then you need to learn different SDKs and how to secure and make them reliable. But with Dapr, it’s all a one-stop shop where you can take one API and incrementally adopt others, or you can just use it all together, but the developer experience stays the same. And so it’s very, very consistent in terms of security, reliability and the productivity gains the developer get when using it.
Sample use case: Storing secrets [03:25]
Mark Fussell: I would dive into a little bit on the problem space again, and that is when you actually build these applications, let’s just take a simple example of just getting hold of a secret that you need to talk to a database. We see this time and time again, that I had to get a hold of a secret that I need to manage and get a hold of it to talk to a database or some other resource and things like this. And there’s many different places where you store those secrets. And so what happens is that Dapr has this concept of an API that you can call as a developer. It’s a very straightforward API of HTTP, but behind the APIs we have this concept of components that allow you to map the infrastructure into that API. So you can map HashiCorp Vault, or one of the cloud providers like Azure Key Vault, or GCP Secret Store into that API.
So now you’re able to keep your code consistent, call the API in exactly the same way, but retrieve secrets from numeral different types of infrastructure in order to say, talk to your database and things. So that abstraction layer, but the plugability of having this backend infrastructure makes your code very portable. You can develop things locally, take it to the cloud, have multi-cloud deployment, change your choice of technology, and yet your code doesn’t change and remains consistent. And so what happens is it allows you to have a decision or an understanding across your team about how you access secrets in a consistent way, whether you’re a Python developer or a Java developer, it doesn’t matter.
Yaron Schneider: Yes. I think you touched on a really great point here, Mark. I think Dapr really simplifies the common design patterns that developers today are looking for in systems. So for example, a developer needs to grab hold of a secret, use that to connect to a database or a pub/sub, then write some state to a database and once that states been written. They will want to communicate some business event that occurred and that’s a very, very hard problem and there’s lots of boilerplate infrastructure code they need to write and maintain.
But with Dapr, you actually do that with literally three lines of code and one or two YAMLs. And so this is a really, really big aspect of Dapr, just simplified developers’ lives and as Mark correctly mentioned, not hijack their infrastructure. So Dapr can actually connect to their existing infrastructure and meet operators and developers where they are, instead of having to have them change their core infrastructure model and just use something that does only that specific part.
Dapr is not just for greenfield development
Thomas Betts: I want to say that point you said, it doesn’t hijack your infrastructure and meets people where they are. That sounds like this isn’t just for Greenfield applications, so I can add some Dapr in, because I need to do a new connection to a key vault. I need to have my secret store and instead of saying, “Well, let’s just write a connection to the key vault, I’ll call Dapr to find that we’re using key vault behind the scenes and then my .NET code works and my Java code also has a very similar interface to that.” Is that simplifying it pretty well?
Yaron Schneider: Yeah, spot on.
Mark Fussell: Yeah. And in fact, the whole adoption of Dapr is very much a brownfield approach. You can use one API, two APIs, it’s not expected in any way that you throw away your code and start to use Dapr as the sole framework, it’s very incrementally adopted. In fact, that’s the most common use case we see, that people first just use an API to retrieve a secret. And then they decide they’re taking their monolith and splitting it into microservices and now doing service communication between them or event driven between them. And now they adopt the service invocation API, that allows them to securely call between two services, or they need to talk to a completely different external system and just send a message to it that has got nothing to do with Dapr, and they can do that over the pub/sub APIs. And so incremental adoption and integration with other systems is a key tenant of Dapr.
Dapr can help ease the transition from a monolith to microservices [06:57]
Thomas Betts: So that monolith to microservices adoption, there’s a lot of people who struggle with that and trying to find the right size service. Is it a monolith? Is it a 100 microservices? Is it something in between? You’re basically saying, Dapr can fit in whatever your architecture is and if you’re making a transition, can it help smooth that transition from one to the other?
Yaron Schneider: Exactly, yes. We see people using Dapr from complete monoliths. They have a huge code base, it’s run on one huge machine. They use Dapr there because Dapr gives them other security and reliability benefits. But when people really get to the nitty-gritty details of breaking down the monolith architecture into separate services, that’s where Dapr really, really shines, because it gives you these microservices best practices really from out of the box.
So for example, in the microservices architecture, you want to have each service manage its own state, and that’s really hard to code to, but Dapr does that out of the box. So it’ll actually do data segregation between services and make sure that they’re all secure, that they’re all encrypted based on the identity of the service calling it. So when you transition to microservices, Dapr basically takes all of the infrastructure boilerplate that you’d need to write and lets you focus on what you as a developer really want to focus on most, which is your business logic.
Architectural trade-offs [08:08]
Thomas Betts: And what are the architectural trade-offs? So if I’m looking at bringing Dapr in, how do I say this is a good place where we can add Dapr and what am I trading off if I were to go on, I guess traditional code path of not using Dapr?
Yaron Schneider: I would say what you’re trading off are specific features from the underlying infrastructure that you’re using. So because Dapr gives you a consistent API, you need to adhere to that API and not every feature from, let’s say Kafka, or Redis, or whatever system you’re using is going to be there, but most of the time if you’re missing a feature, you become a part of our big community. You go to GitHub, you’re raising an issue, you ask for the feature and most chances are it’ll get added. But if you’re really using esoteric specific features from some implementation that you really rely upon for your hot path, Dapr might not be the best fit there.
Mark Fussell: Dapr also runs in a sidecar model as well, which runs next to your process and that’s actually quite important, because it actually segregates out your code from Dapr’s runtime code. It allows you to determine and you have very, very, very low latency and Dapr is highly performant in terms of end-to-end calls, but because you have that separation of Dapr runtime code from your code, I think it also helps with understanding debugging and where responsibility lies.
Benefits for developers [09:20]
Thomas Betts: Well, and that gets to my next question. So we talked a little bit about architecture. How does this change for developers? And you’re saying it simplifies what they have to debug, because the Dapr runtime is not something you’re dealing with. It’s almost like the infrastructure is not something you have to deal with, that you just focus on your code and your code has less infrastructure built into it then.
Mark Fussell: One thing Dapr provides, it does, is not only just these APIs, but it provides cross-cutting concerns. So it provides end-to-end observability of all your calls, it provides end-to-end resiliency policy in your calls, and it also provides zero-trust security in many cases and I think these are also key things that developers have to build. So for example, let’s take observability. Dapr, by taking hold of the observability and having calls through the pub/sub API and service invocation uses W3 tracing combined with open telemetry. So you can see calls that go through pub/sub, service invocation and you see this complete picture. And so when you take Dapr and run it in the production service, you’re now able to push all that telemetry data into any observability tool of your choice and now see a full picture of how your application is running. I think the same with resiliency as well, is that you have these resiliency policies that help make your calls between services more reliable, retries, timeouts, circuit breakers and make sure that you can run resiliency at scale.
Yaron Schneider: I think one more thing that Dapr does really well, is extend all of those features that Mark just mentioned, from service to service calls. Which is something you might get with something like service mesh, for example, like Istio or Linkerd and Dapr really extends that to your entire infrastructure stack. So Dapr can not only secure and make reliable calls between your different services, it can also do that between your services and their database, or configuration store, or secret store, or workflow engine. And so Dapr really takes the concept of zero trust security and layers it holistically across all of your infrastructure stacks.
Benefits for platform engineering teams [11:12]
Thomas Betts: I want to go back one little bit. You said that you lose the flexibility of having all of the features brought up. Is an analogy to this, Terraform is a way to write your infrastructures code, but it’s cloud-agnostic. Like you wrote, I need a new service, I need a new pub/sub, but it can work on Azure, it can work on AWS. And so you may not get those individual features that Amazon or Microsoft provides you, but you get the commonality and Dapr sounds like the same thing. You get all the best common features and you said it’s the best practices. So what are you losing and what are you gaining by making that trade-off?
Yaron Schneider: So you’re losing the specific features that we talked about earlier. If you need very specific esoteric implementations, you’re probably not going to find it immediately. But then again, if you go to a community and you ask for it, there’s a good chance that someone will pick that up and add it in the future. But what you’re gaining are consistent APIs in a very consistent way architecturally to do security and resiliency, and also observability between your services. And if you’re in a multi-cloud world, then it greatly simplifies your entire development endeavor going forward.
Mark Fussell: We’ve seen Dapr being adopted by a lot of internal developer platform teams and the reason why they’re doing it, and in fact it’s written into a CNCF paper, if you look at the CNCF paper. But the reason why they’re doing it is because they can provide these consistent APIs from a platform team to the application teams consuming it, along with the underlying infrastructure that they have as well. So they can define infrastructure that you have, but then well, how do they surface up that infrastructure? Dapr can provide that sort of consistent set of APIs in platform teams, to multiple application teams who are consuming platforms as well. We’ve seen this happen particularly well in pub/sub, for example, with large organizations who want to bring existing legacy applications and new ones together under a single umbrella of APIs.
Yaron Schneider: It’s also worth mentioning the Dapr isn’t strictly a lowest common denominator, but in many cases it actually adds features that you don’t find if you were just going straight into the default implementation. So one example of that is Kafka in topic authorization. With Kafka open source, you don’t get to decide which applications can subscribe or publish to very specific topics, but if you pair up Dapr and Kafka, you suddenly get that. And these type of features that Dapr just adds, that weren’t there before it, are many. So you can pair up Dapr with different technologies and it’ll just add on top of what you would’ve been getting.
Dapr is the golden path for writing cloud native distributed applications [13:34]
Thomas Betts: You mentioned the platform teams use this, and that’s why I was wondering who is responsible for managing Dapr and using Dapr? And it sounds like it’s not the individual developers writing their business application, it falls onto that platform team. So it’s the platform team, instead of writing everything by hand, they’re now using Dapr to make their lives easier, which then makes the developer’s lives easier as well.
Mark Fussell: Well, I would start with developers still. It’s still a developer centric set of APIs. It’s just that anything that runs in platform teams, there’s a control plane services that Dapr installs. For example, in Kubernetes where it does things like deploy certificates or issue certificates to all of the running services that you have, in order to do secure communication. So there are operational aspects of it that you have to have when running in a production environment, but it’s still a developer-centric thing. So it crosses those boundaries as Yaron talked about earlier.
Thomas Betts: So when I’m writing my code, I need to know the Dapr interface, or is there a opinion that my platform team can interject and say, “My company decided we’re going to put a layer of abstraction on top of Dapr and this is how we, as a company talk about these things?” Is that something you build in or does everyone talks to Dapr API in their code?
Yaron Schneider: Yeah, usually it’s the former, everyone talks to Dapr API. That’s what we normally see, but we’ve also come across companies who wrap Dapr inside of their own abstractions. So we see both really.
Thomas Betts: I guess it’s all a matter of, again, the trade-offs of what your team and how big your services are and how complicated your platform is, whether you think it’s beneficial to add that layer of abstraction, or to provide that to your customers that are the developers.
Yaron Schneider: Yeah, that’s a fair assessment.
Mark Fussell: But Dapr is designed as a set of APIs that you can use directly. And going back to the essence of it, again, we just saw time and time again, common best practices that you have that are written about extensively everywhere in the internet and the like. Here’s how you should design systems that do event processing, here’s how you communicate between services, lots and lots of guidance, but very little practical implementation of those. And if they were, they very isolated and it was very small pieces of libraries you had to stitch together yourself and there wasn’t a cohesive single platform or runtime that you can bring together. And that’s what Dapr does, it take all that experience that’s written about, put it into a set of APIs that work well together and help develop and solve all the problems they’ve experienced, so that they can get to building their application. And we’ve seen that people who use Dapr, 20 or 30% more productive getting their application done in time in terms of the productivity they get from using it, as opposed to having to stitch it together themselves.
Thomas Betts: I think if you see companies that have a really good platform engineering team that says, “Here’s the platform we build on.” They understand the developer experience and how you can have that 10x effect of I can create one thing and then we have a codified way that we as a company build this. And you’re saying you don’t even need to define it yourself, we have Dapr, which defines it for us.
Yaron Schneider: Exactly. I think a major piece of any platform engineering team is to provide golden paths for the developers and Dapr is the golden path for writing cloud native distributed applications.
New features are continually added to Dapr [16:36]
Thomas Betts: So you’ve mentioned a few things, and I’m sure there’s a whole list we can point to on the website, but things like it can abstract away Kubernetes and individual services, microservices architecture. You mentioned event-driven architecture, secret stores and is there all of those little pockets of domain knowledge. Is this something that Dapr is continually adding to and we’re adding new features that say, “Oh, we don’t support this yet, but we’re working on it?
Yaron Schneider: Yes. I think we’ve added around three new APIs in the last year alone, and there’s more up and coming. For example, recently we’ve added workflows and the cryptography API that we didn’t have earlier. And on a roadmap, we have proposals for things like document APIs, SQL APIs and others. So the Dapr committee is always thinking ahead about what are the next developer challenges that the project can help solve?
Mark Fussell: Yeah. And one of the APIs I mentioned until now is a configuration API. You see a lot of systems that need feature flagging type approach, where they deploy things and they want to turn on/off features at runtime while the application is running. That provides a configuration API that does exactly that feature flagging in a dynamic application. So those are sort of things that have been added, that up until then you’d have to go and find a library, build it yourself, things like that. So Dapr very much is about discovering those APIs, finding the problem space that they solve, integrating them with a huge range of different infrastructure options as they exist, but helping you be productive, whether it’s communication, or feature flagging, or secrets management. That’s what added, then as you alluded to it, I think an amazing one that’s coming down the pipeline is workflow.
The Dapr origin story [18:10]
Thomas Betts: Let’s go back to the beginning. So Dapr, as far as I know, started at Microsoft. Is that correct?
Mark Fussell: Yes.
Thomas Betts: And did both of you come from Microsoft before you went to Diagrid? So give me a little bit of the backstory, what’s the origin story of how did this come about? Why did Microsoft decide to build this? And I guess I really want to know, why is it not just Azure specific? Why is it not just .NET specific?
Yaron Schneider: So Mark and I both worked at a team called the Azure incubations team, which reported to the Azure CTO, Mark Russinovich. And in that team we were looking at how we can improve developers’ lives running cloud native applications, because we saw Kubernetes really as the way to inject these defacto APIs for hosting apps, but application developers largely went ignored.
So we went on this research path, Mark and I both came at it from different directions, and then we got together and we basically brought together a prototype that demonstrated how developers can build applications easier on top of platforms like Kubernetes. And we really decided that in order for that to really change the industry, it needs to be open source, vendor neutral, and driven by the larger community. So we’ve decided consciously not to make it a Microsoft Azure specific thing, because the vendor neutrality of the project would mean that you’re inclusive to all developers coming from all clouds, and this is really what’s needed to make something like this really become an industry changing piece of technology.
Dapr runs anywhere [19:33]
Thomas Betts: And so it plays well on any cloud. Can you also run it internally on your own infrastructure if you want it to?
Yaron Schneider: Yes, definitely.
Mark Fussell: Oh yeah, totally. I mean, one of the original Dapr goals was you can run it as a process, you can run it as a container, so it’s not bound by that. You can integrate it with any underlying host infra platform. So Dapr will run happily today on a set of VMs, it runs on your local machine. Of course, the main deployment environment we see is Kubernetes in terms of production, but you could integrate it with any other distributed systems platform of your choice. Of course, Kubernetes has become to dominate in the world nowadays and the likes of Mesosphere, that don’t really exists anymore. But I mean, there’s no reason why Dapr couldn’t run on any of those platforms, it’s not just bound to Kubernetes and so that’s its flexibility. In the end, it’s a set of APIs that can run anywhere, but of course, Kubernetes in production, local machine for development. But that’s the idea and that was one of its original goals.
Yaron Schneider: And it’s really easy to run Dapr, it just runs as a single binary that executes and starts up in less than 10 milliseconds on every VM, including your own personal developer machine, whether it’s Windows, Linux, or Mac.
Mark Fussell: And it’s super lightweight as well. So you get all of these huge benefits in a very lightweight process that runs next to your machine.
Dapr is written in Go [20:47]
Thomas Betts: And how did you get it to be that efficient? I believe it’s written in Go, is that correct?
Yaron Schneider: Yes. Go’s allows us for really good network primitives and high concurrency, while retaining a small binary size and low memory usage. So Go fits perfectly within that usage model for things like Dapr.
Mark Fussell: So going back to your origin story, Yaron and I sat down and went like, no one does anything for application developers. So we thought about, how is it you have a world of best practices, APIs running on any platform, independent to vendor, that allows you to singularly adopt APIs and that you’re not having to say, “Throw away all your code and rewrite this whole brand new framework.” And that was exactly his original goal, and what’s happened is it’s achieved all those goals and more.
I mean, we’re just surprised by the enormous success of Dapr, how it’s grown, the community, the contributors, the organizations and it’s accelerated since it got donated to CNCF. So it’s gone far beyond our expectations that we ever thought it will do.
Dapr is currently a CNCF incubation project [21:47]
Thomas Betts: And so it started at Microsoft and you said it was open source from the beginning and not cloud specific, not language specific, anyone can use it. And like you said, it runs as a sidecar, so it’s not in your process, it’s just sitting next to it. Once it left the Microsoft sphere, what happened to it? I know it’s a CNCF project. Can you tell me more details about that and how it’s currently being supported?
Yaron Schneider: Yeah. So Dapr actually had a steering committee running the project before we joined CNCF, and those same four vendors that started out with driving the project direction are still there today. Those companies are Microsoft, Alibaba Cloud and they are running Dapr at scale inside of their own internal infrastructure, Intel and today, Diagrid. So these are the four vendors running the project and as I said, it was out there before we joined CNCF, but of course this plays really well with the CNCF concept of vendor neutrality. And since we’ve joined, we’ve seen lots of contributors coming from any other companies, helping contribute to the project to make it better for both their use cases and for our use cases of other developers, who are just telling us what features they need on GitHub publicly.
Mark Fussell: In terms of the size of the project, Dapr is the 10th largest project in terms of numbers of contributors for its project inside CNCF, as measured in the CNCF Velocity Reports that come out. And so that is something that’s an indication of its success as well.
Yaron Schneider: Yes, today we have over 2,850 contributors to the project.
Thomas Betts: Wow, that is definitely more than I expected.
Dapr should become a graduated CNCF project soon [23:12]
Thomas Betts: So it’s in an incubator status right now, where does it go next? I’m not fully up to speed on how the whole CNCF adoption process works.
Yaron Schneider: Yes, we are looking to graduate the project of course, because that’s the CNCF expectation of any project that goes into it after two years, and so it’s going to be two years this September. So we don’t have the official decision to graduate just yet, but I think you can surmise from what I’m saying about what’s going to come next.
Mark Fussell: Yes. Graduation with inside CNCF is an important direction for the project, it shows and validates its maturity. Dapr can achieve that, because it shows a huge amount of end user adoption, as CNCF calls it, it has a huge number of contributors. The project continues to grow, has a great collaboration across many companies. Those are all the indicators they look for success, because graduated projects are there for the long-term, for not only because CNCF want them to succeed, but they want to continue to show that they’ve got mass adoption and mass contribution. And everything in Dapr points to success of doing that in the next year as well, or probably less.
Thomas Betts: As the main point of having that graduated CNCF status to give a stamp of approval, that people who may have been waiting, that they weren’t the innovators and early adopters, they’re like, “We need to have a little bit more validation before we pull it in.” That’s saying, “Hey, this is good to go and saying you can trust to be there for a while.”
Yaron Schneider: Yeah, definitely. It’s going to help a lot of the late adopters and enterprises out there.
Mark Fussell: We also work quite hard with CNCF, publishing case studies as well. So if you go to CNCF and you look up Dapr case studies, we published one recently there from a company called DeFacto, which is the largest clothing retail inside Turkey and they deployed a huge cluster on top of Red Hat OpenShift. It was running Dapr, it was 200 plus services that they were running on top of Dapr. And it’s just a great case study of how they built something that dealt with the scale of their orders and in their retail world of things. And we’ve got more coming along in terms of financial, IoT, and a whole range of different types of industries that Dapr gets used in.
Thomas Betts: And that just speaks to, it’s not meant to solve one specific business problem, it’s meant to solve a platform-level problem. And every industry has these challenges, especially when you get to a certain scale these make sense to use.
Mark Fussell: Yeah, that’s exactly right. It’s industry agnostic, anyone who’s building these backend distributed systems, whether you’re in healthcare, medical, manufacturing, IoT, retail, they’re all building teams. Many of those are on top of Kubernetes today, as Kubernetes grows, Dapr grows with it, but that’s the goal. Make developers productive, stop you having to stitch together a thousand different technologies yourself. Just allow me to use a consistent set of APIs that integrate with my infrastructure and let me go while and get my project done.
Getting started with Dapr and running locally [25:51]
Thomas Betts: So some of our listeners are like me and want to just get their hands dirty and start using this. What’s a good hello world, how do I get started?
Yaron Schneider: We have amazing tutorials and quick starts. So I suggest you go to docs.Dapr.io and in there there is a getting started section, which will guide you exactly on how to get started. It’ll also point you to our tutorials and samples page, you can just fire those up, you can get started with Dapr in less than five minutes really.
Thomas Betts: And you said I can run all this on my local machine, I don’t have to have it deployed to a cloud yet, and I can just experiment around and see what it does.
Yaron Schneider: That’s correct.
Mark Fussell: Yeah. In fact, that was one of the key goals of Dapr, was install the CLI locally, install a developer environment that you can run, build everything locally, test it locally. You can have a great experience and as we mentioned before, the beauty then is that you literally switch out component infrastructure from local state stores. For example, running an old machine, to the state store that you use in the cloud and none of your code changes. So the local developer experience with the CLI is very straightforward. In fact, that’s one of the key benefits we hear from many, many developers, great local development and I can move to the cloud and none of the friction between them all, and it’s been one of its key success points.
Thomas Betts: And that’s something I’d be interested to know more about is, so am I running everything locally or is it all just mocked out? You said there’s things like a local state store instead of whatever store I’m using and Dapr locally knows, is it just YAML configuration to tell it what to do in those situations?
Yaron Schneider: It’s a YAML configuration, and when you use the Dapr CLI, we install Redis on your local machine, just because Redis is also lightweight and it can run anywhere. So we use that as the default dev tool. But then if you want to change it to something like AWS DynamoDB, if you’re later deploying to a cloud environment, all you need to do is really change that Redis YAML into an AWS DynamoDB YAML, but your code actually stays the same.
Mark Fussell: And the same with service invocation, for example, you can build and deploy multiple services on your machine. You’re talking between them like your order processing, say to your other services, receiving orders and you just communicate between them all. And then you take that code and you deploy it on, say your Kubernetes cluster and nothing changes. Other than that you just have to annotate in a YAML deployment in your Kubernetes YAML deployment, make sure this piece of code runs, has a Dapr sidecar instantiated next to it all, and that’s all you have to do. So the ability to move code, particularly to a Kubernetes environment is seamless.
Thomas Betts: And so that’s something I just put into my CI/CD pipeline that says, swap this out and use these configurations, and here’s our production environment versus my local development environment.
Yaron Schneider: Yes. Dapr is very configuration driven in that sense.
Connecting with the Dapr community [28:24]
Thomas Betts: Well, I think that covers everything I was hoping to get to. If you want to follow this and know what’s coming for Dapr, and you mentioned the docs, where else should they go to stay up to date?
Mark Fussell: Oh, yes. We should talk about the fact that we have a Dapr Discord community. So there’s a Discord server, that’s the place that you really should go to for all your questions. We have a community there of 6,500 Discord members on Dapr Discord, so it’s kind of growing and has a huge community, that’s the place you can answer your questions. Of course, come to the repo as well. The repo is a place where we outline the project goals, but also what’s in a project milestone, so you can see what’s being developed inside that. And between those two, as well as many calls, actually every two weeks we have a Dapr community call as well. In fact, we have one this Wednesday, but every two weeks on a Wednesday we have a Dapr community call and you can join up tonight and ask questions and see demos.
Yaron Schneider: We also have a growing YouTube channel with almost 4,000 members, one of the biggest in CNCF actually.
Thomas Betts: That just speaks to this very much being an open source project. Sounds like you’re trying to get feedback from everybody and get contributions and just keep the whole process very open.
Mark Fussell: We love our community calls, because what happens is we are forever trying to reach out to end users and say, “Come and demo something that you’ve built, a project you worked on.” Just to keep that excitement going, so people see what other people are doing with it. And it’s very inspirational actually, because you see some amazing projects that people build with Dapr, ways that it gets used that you wouldn’t have imagined.
Thomas Betts: Well, I think that’s about it for today. I want to thank again, Mark Fussell and Yaron Schneider for joining me today on the InfoQ Podcast.
Yaron Schneider: Thank you so much.
Mark Fussell: Thank you for having us.
Thomas Betts: I hope you’ll tune in again very soon. Have a good day.
From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.