eShop on Dapr: build microservice applications the easy way

[Music] [Applause] [Music] [Music] hi and welcome back we've seen some accent sessions today and together with barbara i'm going to uh host the last couple of sessions we're healed here till i think quarter past 10 maybe some time after it because we're running a bit late but that will be okay i think i'm very excited to be here i'm roland i've been a developer for about 20 years i'm very passionate about cloud and i'm very excited to host these sessions with you with barbara yes hi my name is barbara forbes and i'm an i.t consultant and a microsoft azure mvp and i'm very excited as well great there's some great sessions coming up yeah and i'm really looking forward to the next session because i'm a developer and the next one is about dapper distributed application runtime from some amazing speakers it's actually one only session with two speakers today so let's try if that works as well um you can post your questions in the chat um we still have the skills challenge so the link is down below so definitely check that one out um and are edwin and sunder in the call already yes we are hi welcome so much for having us most definitely yeah thanks it's so great he could be here and i always have a knack for ruining people's intro slides so i'm trying not to do that this time but you're both principal architect you both work at info support you're both microsoft mvp how can we tell you apart well i'm an azure mvp and i i'm not sure whatever kind of fb edwin is but i'm just developer technologies but i also do a lot of azure but i'm not the azure mvp that's so much oh yeah there's a little bit little distinction between us so that's what we can't tell which mpp you are right so well you have to see tonight i think for your session so if you're ready just take it away yes i shall share my screen let me see and please let me know if you can see that yep yes screen up pretty cool okay so yeah um we're going to talk about dapper today and we're also going to look a little bit at eshop on dapper which is a reference implementation and that's basically the eshop on containers that you might know that's a microsoft reference application and we've basically ported that to dapper and we're going to use that as we talk about a couple of examples that we're going to show today so um without further ado let's first look at what is dapper well dapper stands for distributed application runtime and that's exactly what it is it's a runtime that you can use as a developer to build distributed applications and that's a very broad concept of course and what we see when we see people building these kinds of cloud native distributed applications or microservices applications we often see a lot of infrastructure being used so you have message brokers for pops up messaging you have you know state stores you have maybe some discovery servers for finding services all these kinds of infrastructural components and this is exactly what debra can help you with because basically debra is there to hide all these complexities of all these infrastructural components so you can focus on building your application and not focus on all the infrastructure goo so to speak that you have to maintain so that's where dapper comes in um so let's look at how dapper does that so the dapper runtime offers a quite extensive set of building blocks and here you see a couple of them um but most of them we're going to look into a little bit more detail later on in the session but i will uh walk through them quite briefly now first of all you have services service invocation or service invocation and this is basically for calling other services in your microservices application without knowing where they live that's basically what it's all about then there's state management and this is for storing some key value pairs or some contextual information in an outside store so you can basically build stateful services so you can rehydrate this state when you later on need it then there's a publish and subscribe building block this is for pops up asynchronous messaging quite well known i think and there's also some resource bindings and triggers and these resource bindings and triggers can be used to integrate with all kinds of different external systems and we will also go a little bit into more detail later on um next to that there's also a virtual actor model that dapper offers so you can build also actor model based applications um and dapper offers you built-in observability which is very cool so you can see what goes on within your system and you can monitor your services finally there's also a secret building block and this is for handling you know stuff that you don't want to publish things like passwords or connection strings or certificates and there's a whole suite of tools around that and debra can abstract that for you and then there's the last block it says extensible because the whole dapper ecosystem is basically completely open source and we think that more building blocks will come as time progresses so that we will see multiple building blocks be added in the future um well the cool thing about dapper is that all these building blocks can be called using standard http or grpc communication so that also means that you can leverage dapper from basically any platform or language in which you can do http or grpc communication yeah which is probably from everywhere of course there's also a more convenient way of working with dapper because there are several sdks available um for different languages so there's one for go for java 4.net for node.js and this offers a more intuitive way for you as a developer to use these building blocks instead of through the raw http or jbc api and then there are a couple of other frameworks that debra also nicely integrates with for instance asp.net core or azure functions or azure logic apps um well there's a lot to tell about dapper that's all not in this presentation so we're going to focus on a couple of the building blocks and tell how these work and then finally what's also very important is that you can or basically anywhere so you can run it on your own laptop or your desktop when you're developing but you can also run it in the cloud in azure in aws well basically anywhere on a cloud or edge infrastructure so that's pretty cool um so how does dapper do that well deeper leverages sidecar architecture and this is a well-known pattern because the dapper building blocks are offered by a side card is basically running alongside your application code so in this case there's several ways of running dapper in this case we're running in a standalone mode you just have your application code in a separate you know os process and then the dapper sidecar is run alongside that and your application communicates with the deposit card to leverage all the building blocks pretty straightforward another way of running dapper is in the kubernetes cluster and then the dapper sidecar is basically deployed as a separate container within the pot of your application code and it runs alongside your application and because in a pod these containers can talk to each other it is very easy for them to talk to each other and communicate between each other so that is how this works when you're running kubernetes um like i said we have used dapper in eshop on debra and sumner is now going to tell us all about how we did this to port eshop on containers and work with dapper so somewhere maybe you can share your screen yes i will share my screen i just got a note from the production that my video isn't showing i hope that at least my window is showing because that's actually the important part so i can see it but i don't know if it's in the live stream okay well if you can see my window i will assume it's also in the live stream um so yeah we are going to look in the middle of this session into some of the details of these building blocks see how they work how they can improve an existing application and as adrian already told you at the beginning of the session for that existing application we are using eshop on containers so eshop uncontainers is a simple.net core reference application created by microsoft and it's basically implementation of a web shop that lets you buy some cool.net merchandise and now also some cool dapper merchandise and it uses a simplified microservices architecture with darker containers so let's have a look at the architecture so we've got a front end here which consists of a single base application which is written in angular and back-end requests from that front-end are handled by an api gateway and this gateway is implemented using envoy which is an open source edge and service proxy and enfoy will forward the requests to a number of back-end services and there are many different back-end services in eshop and they are the services that really provide the core functionality such as the catalog of items the tracking of the items in your baskets the entire ordering process etc now most of the calls from the eshop frontend can be directly routed to a single backend service by the api gateway however there are some scenarios which require multiple back-end services to work together to complete a more complex request from the front end and in these cases eshop uses an aggregator surface which is called a web shopping aggregator to mediate that work across those different surfaces and then finally back-end services can also communicate with each other and that is done using messaging to keep them nicely independent and loosely coupled so this is the original eshop on container solution and then we started to add dapper to it now for the dapperized version of eshop each surface now has a dapper sidecar and that makes it possible to use all those nice dipper building blocks and what you can see here is that we not only added a sidecar to each.net service but we also added a sidecar to the envoy api gateway and that enables us to use the dapper service implication building block to call the backhand services from the unvoiced proxy so that everything is stepperized so now let's look at some of those building blocks in more detail and see how we've actually applied them to eshop and we will start with um serve simplification so service invocation enables services to communicate with each other using either http rest or grpc protocols and i'll also talk a little bit about observability because that's one of the benefits that you get from using the service information building block so i've shown you the overall architecture of the eshop solution but let's zoom in a bit and look at an interaction between the web shopping aggregator servers and the basket api so in the original solution when a user adds or changes an item in a basket the aggregator service calls the basket api to store the updated basket and this is a direct service call to that service so now let's see how we change this to work with dapper service information so first of all if you use dapper dapper takes care of service discovery for you so instead of calling the endpoint of the basket api directly you now make a call to your device sidebar and here's an example of making such a call using http rest but you could also use grpc to communicate with sidecar so that url they see right there it contains the application id of the surface to call and which is basket api as well as the method to info which is api v1 basket using the application id the device sidecar does all the search discovery for you and then forwards the request to the sidecar of the basket api servers and that sidecar in turn will make the final request on the actual surface and then the response will flow back the same way now because these calls now flow through side cars dapper can inject some very useful cross-cutting behaviors so for example dapper can automatically retry calls when they feel when when there are trenching failures involved dapper can also make calls between services more secure using mtls authentication and it also includes automatic certificate rollover you can add access control policies to control exactly what operations clients can do on services and dapper can automatically capture traces and metrics for all those calls between services to provide you with some insights and diagnostics so i think it's time to look at some code so let me switch over to visual studio so as you can see here i've got this complete solution upwards up here in visual studio code this solution is completely open source it's failed on github so we'll share the link with you after the session so that you can play with it yourself you can see here we've got docker compose um files so i'm using docker compose here to run eshop locally which is called self-hosted mode in dapper terms but we also added some scripts to the repository to run in kubernetes and kubernetes is actually the preferred way to run depth priced applications in production so if i go over to the container step right here you see a lot of containers are running so my application already up and running so i should be able to go to my web browser and show you the shopping front end so welcome to our store we've got some great products in here um as you can see we just received some new dapper swag so for example let's say i want to buy uh this nice gap and let's let's store in a dapper hoodie as well and if i scroll back to the top you can see my my basket here which now has two items in it and if i click on that you can see the items maybe i want to buy even some more caps buy some form of friends and then you can check out basket all fairly basic webshop stuff you enter your shipping address you enter a payment method and you can place your order and then you will see this pop-up notification because now there's an ordering process that process that has been started and you will be kept up to date on the progress of that through signalr notifications so that is basically the whole eshop functionality in a nutshell now let's go back to the code so in the previous slide i talked about that aggregator surface making a call to the basket api to save the updated basket and if we look at the code of the aggregator so the aggregate code is here in this aggregator's workshopping http aggregator folder and here we find this basket service class which is responsible for communicating with that basket api now this call uses step service information and because eshop on containers is completely written in hd sharp we really wanted to use the debit.net sdk to make that call to have a more natural.net experience so using the sdk we get this nice dapper client object which is injected into our constructor and we can use that dapper client to basically call all the different depth apis on the sidecar now for this specific call all the magic happens here in this update async method so this will get the updated passcode and here we use the dapper client invoke method async method to make the call to the basket api and give it that current password and that method takes a couple of parameters so first i need to give it the logical name the application id of the servers i want to call which is stored in this constant here so the actual value is basket api i give it the name of the method or route if you will to call i give you the payload to send which is the updated passcode and lastly because the basket api is protected i need to send along an authorization header containing an access token so note here how we use this http extension object to pass along that http header and you can also use this object to specify other http details whenever you are calling a surface that has an http rest endpoint so uh things like query string on the http firm which is post by default by the way so i don't need to specify it here for this post call now let's have a quick look at the other side of the notation because this is the caller side and calling the basket api so let's see what that looks like so let's go to services basket and there's actually not much to tell you because this is just a plain old asp.net controller so this receiving end of the equation doesn't need to know anything about that but it just gets called so the call will go to this update basket and that will take the updated basket and use this repository pattern uh to store it in the in the database and we actually use the debug state management block for that as well but i will show you that later on in this session so now that eshop uses that research information one of the benefits is that dapper will ultimately collect those traces and metrics i've talked about and we've configured zipkin or reconfigured dapper to export all that telemetry data to sipkin so if i now go back to my browser and show you the zipkin dashboard and run this query you can see all kinds of tracing information for the stuff i just did in the eshop red frontend so this is very nice it's basically we are getting this for free just because we are using service information and we can a lot of observability by that as it can also has this very nice dependencies page where you can get a very nice surface map of all your surfaces because it can get that information from the traces because yet again everything is running through sidecars and this is zipkin but there are other things you can use such as a jaeger application in size for meteors uh the depth team is currently adopting upper telemetry so basically everything that works with optometry you can send your tracing information to and with that let's move to the next building block and look at some asynchronous messaging so take it away edwin yes let's look at publish and subscribe um if you look at eshop on containers then all the services that are in there we're communicating asynchronously using an eventbus abstraction and this event bus abstraction there were two implementations for that created for eshop on containers one for rabbitmq and one for azure service bus and this is of course pretty handy because you could use rabbitmq for your local development and test workload and then use azure service bus once you go to production for instance so you can switch between them but because this is an abstraction there were also two implementations and there were several classes created for creating a connection to the message broker and also the behavior of the message broker like sending and receiving messages and this is quite an elaborate set of code that was created by the creators of the eshop on containers um besides that being quite a lot of code which is all infrastructural stuff that we basically don't want to be bothered with we want to you know build business code and add business value also when using these building blocks if you look in the startup class of one of the services this is also quite elaborate piece of code so first of all you have to figure out whether you're running with azure service bus or rabbitmq and then also use the particular implementations of these two implementations so it is yeah quite a bit of code and there's also quite a lot of knowledge that you must have around these uh these two message brokers in order to use them and this is quite cumbersome well this is exactly where the pub sub building block from dapper can help you so let's look at how that works um first of all what you can do is the dapper sidecar it offers an api for you to publish messages so in this case we are looking at the ordering api which is one of the services within eshop and dapper and it can just call the depopper sidecar using a well-known endpoint and in this case it's the publish endpoint um and there are several things that you can do first of all this is a post because you're sending a message and you need some sort of payload and in this case it's sent as a piece of json so that's just basically the event or the message that you want to send in the url you also see several things back one is the component and we will talk about components a little bit later how you can configure this because a component basically implements the building block so in this case we use a component that we call pubsub and that is the one that we want to use for sending this message next to this component we also have to specify the topic that we want to send the message to and a topic is basically like a mailbox that you can send messages to and then other services can subscribe to these messages on a certain topic so this is how i can send these messages and when i call this api and like we said before you can do this using http or grpc or using one of the sdks and in eshop on dapper we use the.net sdk once we have called this api the debra sidecar will eventually call the actual service broker and deliver the message to the service broker so this is why there are several choices here so i could be using redis i could be using nets or azure service bus dapper abstracts that's for me on the subscribe side there are also debra side cars for the receiving end and these stepper sidecars will create subscriptions for the topics that you're interested in as as an application so let's uh here we see two side cards so we have two services in this case that's the catalog api and the payment api they are both interested in these order status changed messages so a subscription was created on this topic and then once the message is sent to the message broker the dapper sidecar will pick up this message because it has a subscription on it and it will call a certain endpoint on your application and deliver the payload so this is how this works if you look on an api level so how can you configure this well if you're using net and eshop on containers uses.net obviously there's a really convenient way of doing some asp.net core integration of dapper what you see here is the two web api methods so these are two different controllers with a method on it status change and status update and these are just plain web api calls and what i can do to make sure that i have a subscription on a certain topic and that this certain api is called when a message comes in on that topic i can add a topic attribute to it so this is something that comes from the net sdk from the asp.net integration package and you can just put the topic on top of it and then you specify again which component you want to use in this case pops up and what the name of the topic is that you want to subscribe to and when you do this the dapper sidecar will pick up all these topics and will create subscriptions accordingly so that's pretty pretty easy to do also there are some other stuff that you need to do in the startup of your application or your service and there are also some convenience method to add dapper to the application in this case you can call add dapper on the services.add controllers that you already have there for your asp.net core mvc pipeline and this will add the services to dependency injection that are needed to use dapper also in the configure method of the startup class you see two calls one is use cloud events and this is because dapper uses the cloud events formats this is the standardized format for sending messages so when the message is received it can be you know uh unpacked and it can be read by you by the application and by then by the sidecar and also the map subscribe handlers that you do in the in the endpoints part this will make sure that all the subscriptions for all the topics that you have added will be created when the application starts so this is all you need to do and then you automatically start you know reacting on method messages that come into the certain topic that you have configured so that's pretty easy so how do you configure a component in this case a pub sub component well you create a kind of like these are these resemble you know kubernetes manifest files so you can create depth configuration files and there are several parts in there so first of all you name the component and as we saw in the sample before the name was pops up but this is something that you can provide and you can also have multiple configurations each with their own name and this way you can switch between different configurations there's also always a type in there so in this case it is a pops up building block and the component it uses is nets streaming which is one of the message brokers that is supported out of the box and then finally each type of message broker has some specific metadata that you can add to it so this will differ message broker and by adding this configuration file and giving that to your depot sidecar it knows how to interact with the pops up building block so this is how that works so let's quickly look at an example in eshop on container just as saunder just showed the application this is eshop i already have some orders in here and let me see i have a message in teams let me see what goes on here oh that someone wants to get in that's not for me um so what i can do now is look at all the topics that were created when the application was started so what you see here are all kinds of topics and these are in a redis cache so i'm using my redis cache as my pop sub component and when the application starts and all these services start up they will create certain topics that that are used for sending messages and as you can see now there are no messages in these topics now but when i for instance order a cool dapper sticker and a dapper cap for instance and i check this out so i buy this then what you just saw in the demo that saunders showed um in the background some you know ordering process is being simulated so there are all kinds of events flying around between the services and if i now go back to the redis commander and look inside the redis and refresh this then we can see that all kinds of events come in so this is a user checkout accepted event or an order stat started integration event and as you can see here on the right these are just plain json files or json payloads that contain all kinds of ids and and stuff like that and this is also according to the cloud events format so that is how that works so with that let's go on to the next topic and that is state management so take it away somewhere yes i'm going to switch screens again be online now so yeah state management so state management in dapper provides a key value-based api for persisting state um you can use it to create stateful services and it's really meant to store some contextual data not to store your entire relational database in it so if you look at the original issue on potential solution that uses a variety of data stores many of the services use sql server and they use entity framework to access the database and that's perfectly fine because entity framework is very good for that and the entity framework already provides support for many different databases such as sql server mysql customersdb so that already gives us a level of portability for relational data now there are also some services in each of the use other data stores an example of that is the basket api so the basket api stores its data in reddit and to make that work it has a dependency on stackexchange.radish which is a third-party sdk which you would need to learn to be able to use it and we changed that implementation to actually use the dapper state management building block and as a result of that we've now got many more different backing stores to choose from without having to learn any other sdks so let's see how this works with devastate management you can store and load the state in the key value store by simply yet again making calls to your sidecar so if the basket api wants to update the basket it could simply do a post request like this with the data it wants to store and then the debit sidecar will persist that state to the configured banking state store whether that's a customer sdb a ready scales or some other store and then to read that value back from the store you can do a cat request and in that request you specify the key you want to query the dab aside card will look it up for you from the backing store and return it so let's see what that looks like in code now eshop already used this repository pattern to access the data store so for example if i go to the basket api then in infrastructure rebuff stories we've got this data basket repository now of course in the original solution this wasn't called dapper basket repository it was called redis basket repository and we changed that name and that implementation to use the dapper state management and let's start at the top so as you as you can see we again use that debit client we get it injected in the constructor and that allows us access to all those nice state apis and as you can see here those state apis are pretty simple so if you want to delete something we can simply call the lead state we can retrieve state by calling cat state here we use cat state entry which makes it possible to get something from the state store change the value and save that back to the store so in this way we can do an update now the uh state store that actually does the persistence is configured in a component file so let me go over to the component file and as edwin already showed you that's just a yaml file looks very similar to kubernetes manifest files and here you can see that we are currently storing our basket state in table storage and this file also makes use of another dapper building block which is the secrets building block because i don't really want to store my storage account key in this file because this file will get sent off to github in source control so instead i'm storing secrets in azure key fault and i'm telling dapper using this secret key ref and this configured secret store to get that account key from azure key fold now let me quickly show you that this also actually works so let me go back to the um shop you can see right now we just placed that order so my basket is empty so now if i go to store 64 and i go to the storage account my table should be empty because there's nothing in my basket and i'm currently the only user of this instance of the application so as you can see there's no data in the um backend store yet now let's add something so let's say i want a.net dot black hoodie now we've got something in the basket if i switch back to storage explorer and refresh then now you can see if i click this open look at the details just to prove it to you you can see that there's now a dotnet bulk black hoodie in my backing store so that's a very easy example um just to show you how it really works but realize that you can now very easily change or switch back and stores just by chasing that configuration um you do have to be aware though of subtle differences between implementations so for example with table storage a single value you can store in a table search column has a maximum of 32 000 characters so if you're switching between a store that has such a limit and a store that lets you basically store unlimited sizes of blobs then maybe you run into some problems with your applications where one store cannot um can install the data that you want you gain a lot of portability with this layer of abstraction but you still need to pay a little bit of attention to the actual implementations and then i do think we still have got some time to talk about bindings edwin yes so let me share my screen thanks um resource bindings are basically a way to integrate with different external systems and this is very broad aspect of course and you could argue that also pops up for instance is a way of integrating with different external systems but there's a quite a small difference there because this nut does not only focus on message brokers and sending events and and doing asynchronous messaging but it also has all kinds of bindings for instance for twitter and twilio sendgrid and azure storage so it is basically a way of getting events from certain systems for instance when a file is dropped into an azure blob storage or whatever and then get an event into your application or if you want to do something you want to call some you want to send an email or whatever there's also a way of integrating then for instance with twilio cent grid to send this email without knowing how twilio sandgrid works so you do it through the dapper building block the resource binding there are two types of bindings there are input bindings or they're also called triggers and they react to events and you have also external um or output bindings that can that you can use to do outbound communication like the twilio sand grid thing also i have to stress that because these are just dapper building blocks you can use them through http or grpc for calling them r2d the sdk so how does this work well here i have an example of an input binding and i'm going to use a twitter example so i have my service running and i have my debra sidecar running and this debra sidecar has a configuration file it interprets when it starts up and in this case it's a binding an input binding for twitter specifically and as you can see in the configuration file i give this thing a name tweet and this is very important i will show you in a minute why that is and also you see the type bindings.twitter and you see some specific metadata in this case it's some credentials to connect to some quick twitter feed and there's also a query in there that's one of the um the functionalities of the twitter binding you can specify a search term and when a tweet is sent that has this term in the text it will um will be picked up by uh by the binding so once dapper has read this configuration file it will connect to twitter and it will start looking for tweets with dapper in the in the text and once the tweet is is detected it will pick that up and it will call your service on a certain endpoint and here you see that the name is again really important because this name is used as the endpoint that is being called on your application so in this case the service is running on port 5000 and you have to have an endpoint that listens to slash tweet and it will get the payload with all the information of the tweet and you can handle that whichever you want to do with this tweet and then you can send back a 200 okay to tell dapper that this message was handled successfully so this is how you can use an input binding the output binding is quite similar so again i have a service with adapter sidecar and now i have configured an output binding in this case it's a twilio cent grid binding and i call it send mail and now what i can do from my application and this is what we actually use in eshop when we start sending emails for instance when an order has been completed from our servers we can call a binding endpoint and we use the same name as we have used in the configuration for this output binding we give it a payload and then the debra sidecar will actually invoke send grid and send the payload over there so the email has been will be set so this way i only need to know the dapper api and i can send emails from my applications without knowing how cent grid actually works i only have to provide some api key or something in the metadata uh so debra can connect to uh to this service so that's pretty cool um as i stressed before dapper is completely open source so all these components you can write them yourself and you could also of course write uh bindings for all kinds of different systems that are not already out there you have to do it in go because dapper is built in go but there is a possibility for you to build your own bindings input as well as output bindings for your system or some other servers that you want to use from your application so that's pretty cool so and with that um yes of course dapper will send you uh 200 okay when uh when the message has been sent with that um we are through the stuff that we wanted to show you so uh thank you for listening thank you for having us it was great being part of the virtual as a community day there are some resources up here there are some links to the documentation and to the eshop on dapper [Music] project on github and if you want to see more of us you can watch our netflix video channel and i don't know if there are any questions in the chat i think we have a little bit time for questions uh well we we i have a question myself if you if can we expect to to see this in the wild at the moment well we're still in uh there is now a release candidate version and we're working closely with the team and i think that somewhere well first quarter next year there will be a 1.0 release that is actually generally available so 2021 we can expect to see this out there yeah so cool it was such a great great clear explanation of dapper um even i understand so that's usually a good sign uh thank you so much um for this amazing session yeah thanks for having us yeah it's great thanks thank you have a great rest of the conference everyone thank you thank you yeah awesome so

Channel: Azure Thursday

Views: 2,209

Rating: 5 out of 5

Keywords:

Id: ecK6FTp7ra4

Length: 41min 28sec (2488 seconds)

Published: Tue Dec 15 2020