NICK GREENFIELD: Hi, everyone.
My name is Nick Greenfield,
and I'm a Senior Program Manager at
Microsoft working on the Dapr Project.
I'm also one of the Dapr maintainers
of the documentation repo.
Today, I'm going to talk to you about Dapr.
We'll cover what it is, how it works,
and I'll demonstrate how Dapr enables
portability in your microservice applications.
I'll also show you how you can use
the new AKS Dapr extension as
a way of provisioning Dapr on your AKS clusters.
Let's first get started by taking
a look at what Dapr is and
what it offers developers who
are building distributed applications.
Dapr stands for Distributed Application Runtime.
And it's an open source project that's part of
the Cloud Native Computing Foundation.
It's a project that's aimed at offering
developers with a set of building block APIs
that ease implementation of
common patterns found in distributed applications,
at the same time addressing the complexities that
are often encountered when implementing those patterns.
The Dapr APIs are available through
sidecar processes that run
in tandem with your applications.
As long as your applications leverage
HTTP or gRPC protocols,
you can call the Dapr APIs.
These APIs provide generic abstractions over
the underlying tech that
your applications integrate with.
For example, if your app is
leveraging PubSub for message passing,
your app only needs to know how to communicate with
the Dapr sidecar via the generic PubSub API,
and it's up to the Dapr sidecar
to know how to integrate and
communicate with the PubSub
message broker of your choice,
so whether that's Kafka, Redis, RabbitMQ,
Azure Service Bus,
or any of the other supported PubSub message brokers.
These integrations are configured
through a YAML file called
components that's passed to
the Dapr sidecar when it
starts alongside your application.
You can easily swap out and exchange these components for
other components without having to
modify any of your application code.
This removes the requirement of having to take
dependencies on Cloud specific SDKs or libraries.
Additionally, the Dapr APIs have
industry best practices built in.
For example, how
your application handles security between
service-to-service calls or
your application's ability to detect,
mitigate, and respond to failures.
Dapr has security, resiliency, and reliability built-in.
Lastly, Dapr's incrementally adoptable.
These APIs can be used as the need arises.
You can use one, several,
or all of them to develop your applications faster.
At the end of the day, the Dapr APIs help developers keep
their microservice code simple,
portable, resilient, and secure.
Now let's take a look at one of
the Dapr sample applications that I have running locally
on my dev machine and deploy it to
an AKS cluster running up in Azure.
During the deployment, I'll
demonstrate the process of swapping out
lighter weight components that I
use when developing locally for
Cloud services that are more
appropriate for this type of app that I'm building.
I'll then use the AKS Dapr extension to easily provision
Dapr on my AKS cluster
with some smart default configurations.
I'll accomplish all of this without having to
make any application code changes.
But before we jump into the deployment,
it's worth spending some time on
the sample application and how it's leveraging Dapr.
This is the Dapr Twitter
sentiment sample application that
I have running natively on my development workstation.
You can find this exact example in
the Dapr samples repository on GitHub.
The purpose of this application is to run
a sentiment analysis on
newly published tweets that contain a particular keyword.
These little emojis here on each individual tweet show
the results from the sentiment scoring.
Smiling emojis mean the sentiment
of the tweet is positive,
sad or angry means there's
a negative sentiment, and so on.
In this example, we are running a sentiment analysis on
new tweets that contain the keyword Dapr dev.
So, et's give this a try by
tweeting with the keyword Dapr dev.
Alright, so, as you can see, my tweet was
pulled into our application via
a Dapr input binding and you
can see the results in the sentiment scoring.
Let's take a look at the architecture of this application
and how it's leveraging the various Dapr APIs.
This application is made up of three microservices;
the Twitter provider which handles the incoming tweets,
the sentiment processor which connects to
an Azure cognitive service and is able
to analyze the sentiment of a tweet,
and the front end tweet viewer,
which is where the tweets are being streamed in live.
Each of these services is accompanied by
a Dapr sidecar where you can see
the different Dapr APIs that are being used.
First is the Twitter input binding,
which is responsible for bringing in the tweets
that contain the keyword Dapr dev.
Then the provider service is using Dapr service and
vocation to call the processor service
to have the tweet sentiment scored.
Once the tweet is scored,
it's persisted into a local Redis instance via
the state API, and lastly,
the tweet is published as a message to Redis where
the front end viewer service is
subscribed and is showing the tweets come in real time.
Now I want to demonstrate to you how easy
it is to take this application that I have
running natively on my development workstation
and deploy it to an AKS cluster while swapping out
the components that I use when developing
locally for Cloud services such as Azure Service Bus
and Azure Storage and how I can
accomplish this without making
any application code changes.
One of the first things that's needed,
assuming you have an AKS cluster
already provisioned and ready for deployment,
is to add the necessary Dapr annotations
to your Kubernetes deployments.
In this example, I had the deployment
YAML for the processor service and I've added
the Dapr annotations to ensure that
a Dapr sidecar is injected alongside my processor service.
I'm also providing a unique app ID for the service.
This is how the Dapr sidecars
know how to communicate with each other.
Each of the three services will need similar annotations.
The next step is to switch out components.
As mentioned earlier, I plan to leverage
the existing Azure services
that I've already provisioned.
To demonstrate this, let's
look at the PubSub component file.
This is where I'll switch out the component
that I use when developing
locally with a more appropriate service
for the deployed environment.
For example, Azure Service Bus.
We're going to switch out the component type
from Redis to Azure Service Bus
and add the necessary connection details
to that instance as metadata.
Notice that the name of the component doesn't change.
It's still tweet-PubSub.
That's because our application references
these components by their name as shown in this example.
We instantiate the Dapr client and we use
the PublishEventAsync method while
passing in the name of the component,
the topic, and the event data.
This is one of the key elements
to Dapr that helps ensure that
our code is portable and agnostic
to the technologies that it integrates with.
Once our application is ready for deployment,
we need to provision Dapr on our AKS cluster.
We'll do this by using the AKS Dapr extension,
which is currently in public preview.
The Dapr extension is the easiest way to install Dapr on
an AKS cluster as no specific Dapr tooling is required,
just the Azure CLI.
With the extension, you have the option of opting into
automatic upgrades where you can
offload versioning of the Dapr runtime.
Additionally, the extension supports all need of
Dapr configurations as command-line parameters.
Lastly, the Dapr extension is an extension of AKS.
Therefore, you can expect
the same support policies as other AKS features.
So, let's use the extension to install Dapr on
our cluster and deploy our sample application.
Let's use the address CLI to
install Dapr on our bare cluster.
So, I'm pasting in the CLI command
to create the Dapr extension.
This process usually takes a minute or two,
so we'll come back to it as soon as it's completed.
Great. The extension was added and Dapr has
been successfully installed on our AKS cluster.
If we inspect the Dapr system namespace,
we can see that the Dapr
control plane resource have been created.
The extension installs Dapr with
some smart defaults to ensure availability.
Here we can see that Dapr was
installed with high availability and mode enabled.
Now that Dapr is installed,
it's time for us to deploy our application.
Once the deployment is successful,
we will confirm the application is
functional and that our components have been
swapped out for the Azure services we've
specified in our component YAML files.
So, let's run a script that uses
Helm to deploy our application.
Perfect. Our application is
deployed and is running in our AKS cluster.
Let's navigate to the public IP of our app and test
the functionality to ensure everything works as expected.
Okay, so here's our application running in
AKS by hitting our public IP,
and if I tweet deploying Dapr dev applications, awesome.
I can see that the tweet is showing
up and the sentiment has been scored.
Now let's confirm that the correct
components are being used.
One way to do this is to use the Dapr dashboard.
So here we can see the three services that we've deployed.
And if we go to the Components tab,
we can see that our PubSub component is now leveraging
Azure Service Bus and
our tweet store is now using Azure Table Storage.
To recap, we learned what Dapr is and what it offers
developers who are building distributed applications,
we took a look at a sample application that
leverages multiple Dapr building block APIs,
and we walked through the necessary steps to
deploy that sample from a local environment
to a deployed environment while switching out
development components for Cloud components.
We were able to accomplish this without having to change
any application code, just configuration.
We also used the AKS Dapr extension
to provision Dapr on our AKS cluster.
I encourage you to take what you learned
here today and try it on your own.
The Dapr project has many comprehensive quick starts
and samples for you to try.
You can also find more information regarding Dapr on
AKS as well as quick starts that
get you hands on with the Dapr extension.
Thanks for tuning in and see you in the next one.