Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2021, 29 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Microservices Made Easy! - Donovan Brown & Jessica Deen, Microsoft

Description

Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Microservices Made Easy! - Donovan Brown & Jessica Deen, Microsoft

Have you made the jump to microservices only to discover the development experience is less than ideal? We get it, microservices can be HARD, but they don’t have to be. In this session we will help you simplify your developer interloop and boost your productivity. We will focus on Dapr and Bridge to Kubernetes, both open source, and geared towards simplifying your life as a developer. Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless, and stateful applications using any language, targeting any cloud or the edge. Bridge to Kubernetes uses Envoy to extend the Kubernetes perimeter to your development computer allowing you to write, test, and debug microservice code while connected to any Kubernetes cluster with the rest of your application or services. The bridge to microservices harmony can be messy, but a technical deep dive powered by the open-source tooling will have you looking Dapr in no time.

A

Hey everyone, I'm donovan brown.

B

And I'm jessica dean today we're going to be talking about how to make writing microservices easier with an open source project called dapper.

A

We will start by covering the landscape of microservice development and how to get started. Then we will show how to extend an application by adding additional functionality.

B

Finally, we will cover how to debug and deploy your adapterize apps all while employing devops best practices.

A

Thanks jessica, don't worry jessica will be back later, but now, let's talk about the landscape of development, no matter what industry we are in writing. Software has common patterns. We reduce costs by only using the resources we need and scaling out when additional resources are required.

A

Applications are being broken down into units of functionality, each exposed as a service. We want to focus on adding business value and not managing infrastructure. So we leverage serverless platforms and use devops best practices and the number of programming languages seems to never stop growing and we should use the best language for the task at hand.

A

On the surface. Microservice development seems simple. It is a micro or small service, not a giant scary monolith.

A

However, there are limited tools and run times to support distributed development in many of the frameworks are tightly coupled to a language or development stack. A typical microservice application might look like this. Several small purpose-built services all talking to each other. Some of the services also talk to external resources, to store state or ingest events.

A

Getting an application like this up and running and keeping it running has proven to be challenging to address these challenges. The cloud native community has developed dapper, which is a set of building blocks, to ease distributed application development.

A

The goals are to take years of best practices and experience and make them easy to use from any language and on any stack. It is driven by standards and provides a consistent, portable and open api that can be extended and used on any cloud and on the edge dapper is community driven and completely vendor neutral at its core. Dapper is a set of building blocks, including service to service invocation, state management, pub sub bindings and secrets management, with support for the actor model and observability out of the box.

A

We can use as much or as little as we like if we have already solved service to service invocation, but need help with state management, we can just use the state management building block or if we are starting from nothing, we can use it all, allowing us to focus on adding business value.

A

Any language that can send a http or grpc request can use these building blocks. Not only can applications that leverage dapper use any language, they can be run on any infrastructure.

A

Dapper is implemented using a common sidecar pattern, where a second process runs alongside your main application. The main application uses http or grpc requests to call into the dapper sidecar to take advantage of the desired building blocks. Here's an example: application with two services: a and b notice. Each of them also has a dapper sidecar when service a wants to call service b. Dapper does all the arduous work of discovering where service b is and securing communication between the services.

A

This slide also shows the plugability of the component model without having to change our code. We can change where our state and secrets are stored, where events are published and even where our telemetry is sent.

A

When developing locally, we can use a redis container then switch to a different backing service. When we move to the cloud, the components are: the magic behind dapper, switching from redis to cosmos db or from rabbitmq to azure service bus requires no code changes. We just update our configuration and our code stays the same.

A

If we do not see a component, we need, they are all open source and we can add whatever we need by submitting a pull request at this point, let's focus on the different building blocks and demonstrate how to use them. Let's begin with service to service invocation that lets one service call another.

A

When one service wants to call another service, it must know its address port and the number of instances that are running the service could be running anywhere. Dapper takes care of locating and securely calling the service with a post request. We can ask dapper to invoke the new order method on service. A and dapper takes care of the rest.

A

Observability gives us tracing across all the services in our application with dapper we can configure where we want our telemetry sent. This slide shows the same information visualized from application, insights and zipkin. As a developer. We don't have to write any special code by running our application with dapper. We get this for free.

A

What I'd like to do now is a demo to show you how to get started with dapper people told me: do not do a net demo. When I asked why they said you have to use an open source language that works on mac, os windows and linux. Okay, got it open source works on mac, os windows and linux, so I decided to do a dot net demo. For those of you that don't know, net is fully open source and works perfectly on mac, os windows and linux.

A

Let's go first, I want to show you the docs site at docs.dapper.io, so you know how to get started, simply click getting started and then click install the dappercli.

A

This page will show you instructions for installing on mac, os windows and linux. Now that you know how to get started, let's see some code, I'm going to switch over to visual studio code, where I'm inside an empty folder to get started. We're going to create a new web api using the.net new command.

A

What's cool is we can dapperize an application without changing a single line of code? We can start to use dapper immediately by running our application with dapper with this command. We are giving the service a name telling dapper what port the app runs on, what port we want to access dapper on and how to start our application.

A

Dapper will build and start our application and then launch the sidecar and wire everything up switching to a web browser. We can still access the application on port 5000. This allows us to incrementally adopt dapper, because all existing clients can still access the application on its original port.

A

The real power starts when we have a client that uses dapper to access the service. If we access the service via dapper, the results are the same but notice we are now using dapper on port 3500.. This will never change, even if we change the address of the backing service or the number of instances.

A

This is saying: hey, dapper. We need you to do something for us. We don't know the address of the other application. We don't know where it is on the network. We don't even know how many instances there are, but we know its name is my app and we need you to go invoke the weather, forecast method, dapper locates, my app and securely calls the weather forecast method for us, but wait there's more because we're using dapper, we are getting observability for free switching over to zipkin.

A

We can query all the telemetry dapper was automatically collecting for us. We can see when calls were made, how long they took and what services were involved. We can drill in and see detailed information without dapper. We would have to write code to get this information. This information is invaluable when you need to debug a problem and we get it for free by just running our application with dapper.

A

Now I'm going to stop the application and return to the slides to discuss more building blocks. Next, let's examine state management which allows us to create long-running stateful applications with a post request. We can store a key value pair into any state store to retrieve the value. We use a get request with the key, because the components are pluggable. We can switch from redis to cosmos db without changing our code to build a scalable distributed system that reacts to events. Publish and subscribe is a powerful way to accomplish.

A

This dapper supports both publishing events and subscribing to them. The application does not have to take any hard dependency on a particular implementation or sdk.

A

We can swap out redis in this example for any supported pub sub component dapper also supports input triggers which enables our code to be called when a specific condition is true, for example, call our code whenever a tweet is sent that contains a specific string output bindings, allow our code to write to external systems without taking any hard dependencies.

A

Finally, secrets management gives us a consistent way to access connection, strings and other sensitive information. Now, let's return to the code, we are going to pick up right where we left off and start using some of the other building blocks. To do that, we add the dapper package to our application.

A

This is an optional step, as the dapper functionality can be accessed via the built-in http client of any language. Adding adapter sdk will make using dapper fill more natural in some scenarios, we're going to add three lines to the startup.cs file that will enable dependency, injection and pub sub support.

A

First, we add a call to add dapper on line 29 to enable dependency injection of the dapper client class into our code. Next, we instruct our code to use the cloud event standard, which is a specification for describing event data.

A

This middleware will unwrap requests that use the cloud event structured format, so receiving methods can read the event payload directly. The final line of code adds a dapper subscribe endpoint that allows us to subscribe to events with attributes with just three lines of code. We have everything in place to turn this into a stateful event driven service.

A

Let's add some new functionality to this service using dapper out of the box. This code generates random weather data in a real app. This data might come from events published from weather capture systems, so we're going to add code that gets run for each event and stores the data.

A

Let's open the weather, forecast controller class and add a post method to receive the events. We don't need a special route, so we can delete this code. We're going to accept the original weather, forecast business object and return it when we're done to have this code called each time an event is published. We can use the topic attribute.

A

This tells dapper to watch the component name pub sub and when events are sent to the new topic call this code with the data we get the name pub sub from the component definition.

A

When we initialize dapper it created a default pub sub and state store component. Let's open the pub sub component, this component is named pub sub, which is why we used it in the attribute on line 6. It shows this is configured to use. Redis later we will move our code to the cloud by defining new components.

A

We also have a component named state store which we will be using next, let's close these and return to the code. Thanks to the call to add dapper in startup.cs, we can use dependency injection to get a dapper client with the adapter client. We can start using the building blocks, calling save state async. We can store our weather forecast object in our state store. The first parameter is the name of the component.

A

The second parameter is the key, and the final parameter is the data that is all the code. It takes to respond to an event and store it. Instead of returning random data, we want to return the data we just stored in the state store to demonstrate incremental adoption of dapper. We will not change the return type of this method, as we did before. We will use dependency injection to get a dapper client.

A

Next, we replace the code and return a list of weather forecast objects from our state store to retrieve state. We can call get state async passing in the component name and key, because this method is not async. We return the result and we're done. We should test the code to make sure it works as expected. So let's set a breakpoint on lines, 40 and 31..

A

Let's generate the assets to build and debug our code. Next, we use the dapper extension to take our launch configuration and start our dapper side card. Whenever we press f5 to debug, we will use the dot net core launch configuration, let's name our service, my app and we can keep the default port of 5000..

A

What this did was create a new configuration based off the dot-net core launch configuration that can start and stop dapper for us, let's select the new configuration and look at it notice. This configuration has a pre-launch task that starts dapper, because our service has no ui. We can remove the lines that start a browser.

A

Now we can see there is also a post debug task that stops dapper for us. Let's close this file and press f5 to start debugging our code in the terminal, the extension is running commands to start our application and the side card with the debugger attached.

A

While the code starts, let's open an http file with request, we can use to test our code. The first request uses dapper to post an event to the new topic of the pub sub component. Sending this request, we hit our first breakpoint.

A

We can have a great f5 experience, even with a dapperized application, let's press f5 to continue and send the get request to read from the state store. Just as before, sending the request we hit our other break point. So we can step through our code, pressing f5. We see the output is the weather forecast we stored now that we know that code works? Let's stop it and move our code to use resources in the cloud, because we're using dapper moving from on-prem to the cloud is as easy as defining new components in the azure components.

A

Folder are definitions that use azure service, bus for pub sub and azure storage for our state store notice. The names of the components are the same as our original components, so our code does not have to change. We just need to tell dapper to use the components in this folder instead of the defaults.

A

We do that in the tasks.json file that was created by the dapper extension. We just add a line that tells dapper to use the azure components. Instead, with that change in place, we can press f5 to start debugging when the code starts this time, it will point at the components in azure. We can use the same http file pointing at localhost and port 3500, but our components are now in azure.

A

Let's start by running the get request first, which should return null as we are no longer pointing at the redis running locally, sending the request we hit our breakpoint as before, pressing f5. We get null back as expected when we send the post request to publish our event to the new topic. Our other break point is hit.

A

Finally, let's run the get request again to confirm our weather forecast was saved. The weather forecast returned was read from azure storage.

A

Let's jump over into the azure portal to see the value in our storage account using the storage explorer. We can navigate to the weather table and see the item. This demo shows how easy dapper makes it to turn any service into a stateful event driven service and move it from your dev machine to the cloud.

B

Awesome thanks donovan. What I want to do now is build on what donovan has shown you. I want to switch over to a more real world, microservice application and show you how you can continue to take advantage of what dapper gives you out of the box and add another tool to your tool chest to help make developing microservices even easier. We have a simple microservice application designed to process and grade the sentiment of tweets. There are three main microservice apis.

B

You have your twitter handler, which we call the provider api, your sentiment, processor or the processor api and the tweet viewer or the viewer api. All three of these components connect to a twitter binding using dapper. Instead of having to go fetch the twitter, sdks or figure out what the twitter api even looks like. We also store state inside of azure, but you could store it in redis, mysql or wherever you prefer. We also have pub sub, so the data can move freely between our different microservices.

B

The best part is dapper simplifies all of this. Now, let's complicate this just a little. What happens if you need to debug one microservice in the context of your larger application or in the context of abstracted services running in kubernetes? Have you ever wished? You could just take your computer and put it in the cloud and debug, just as you would locally, especially if you're only debugging one small part of your app. I want to demo something called bridge to kubernetes, which is going to let you do exactly that.

B

We've all been there. We've all made changes that we were 100, confident in we've, linted, we've tested and all that jazz. Our local checks passed. We commit push and open a pr, our pr workflow fire is off, and everything is green approvals happen and we hit merge a new workflow fires off and successfully deploys out to a development environment, but at some point in the process after we have merged our changes, but before those changes deploy to production, we noticed something broke, oh gosh, uh oh did we just merge broken code into our main branch?

B

Wouldn't it be great if we could visualize our changes prior to merging to main it turns out, we can you'll notice. I have a pr open and I've utilized a github actions task to add a comment to my pull request between the comment, bot and kubernetes. I can take advantage of things like role-based access, control and namespaces to create an isolated deployment environment for my pull request in my development cluster. Let's take a look at these changes now.

B

uh Okay, that's odd. I'm supposed to see tweets here with sentiment, scores going to have to debug this, but the problem is. I only made a change to a backend api, my twitter handler or what I call my provider, I'm going to flip over to my preferred editor of choice, visual studio code.

B

You can see that I already have my provider code up now. If I want to debug this locally, I know I could stand everything up. All three services connect to our state store and pub sub and get everything to work. But, honestly, I don't have time for all that, when our pr workflow fired off our app was deployed into a separate, dedicated namespace for these changes. Only this allows me as a developer to use that namespace as a kind of sandbox for my development.

B

I'm gonna in essence put my computer in the cloud, so I can debug in real time in an isolated fashion. Now you may be wondering how exactly are you going to do that? I am so glad you asked. I installed an extension called bridge to kubernetes that allows me to replace the provider code currently running in kubernetes in my private namespace, with code on my system. Best part is, I don't have to deal with helm, charts or docker files to do it once I have the extension installed on my system. It's very simple to use.

B

All I have to do is hit command shift p because I'm on a mac, but if you're on windows you would hit ctrl shift p and from there search for bridge to kubernetes I'm going to opt to configure now. As long as I have access to my kubernetes cluster, I'm working in and the namespace I've deployed to this extension is going to connect over to my application currently running in that kubernetes cluster. I'm going to choose the service, I want to redirect traffic for again.

B

This is going to allow me to replace the broken service with code. That's living currently on my system, so I can debug natively you'll notice. We have several different services here that have dash dapper at the end.

B

All of these services have a dapper sidecar, but I'm still able to debug my individual application with a native f5 experience without interfering with dapper whatsoever, I'm going to choose my provider service since that's the one I want to debug, and I know my application is listening on port 3001, because I can see that right here on line 12. next, I'm going to choose launch program.

B

This is going to launch the same configuration that I would use to debug locally, but it's going to launch it with an additional task and that additional task will be what connects to my kubernetes cluster, I'm going to say that I want to redirect all incoming requests in my machine, including those from other developers, and the reason why I'm okay with this in this instance is this- is my own, isolated namespace that I'm working on for my pull request.

B

You would never want to redirect code in a production, environment or something that could take down whatever you're currently serving to your end users. Now what that did is update. My launch configuration with a new configuration to allow me to debug using kubernetes. You saw a similar example of that in donovan's demo, where he showed you his launch config with dapper. Only now I can keep my previous debug configurations and add another for connecting to kubernetes. Now I can go over to my debugger.

B

Make sure that my launch program with kubernetes is selected and hit f5 from there. The bridge to kubernetes extension is going to do all the magic. For me, it's going to redirect the service provider dapper to my computer and a better way to visualize. This is exactly what I've said several times now.

B

I am literally putting my computer right now in that namespace in my kubernetes cluster in the cloud this application, as we saw earlier on our slides, has dapper components, has our viewer api, our processor service and our provider, which is the only one I need to debug.

B

Let's set a break point right here on line 66 great, I'm gonna go ahead and refresh our webpage to force the processor to begin looking for tweets.

B

uh Oh boy, this is awkward demo fail, I'm not hitting my break point. um You know I'm gonna check zipkin and I'm gonna see if there are any tweets that can be traced, nope no dice. Something else must be wrong. Let's take a look at the oh gosh turns out. I cannot spell. I spilled tweets wrong. All right, I'm gonna fix that. I'm going to restart my debugger bam. I just hit my break point all right, I'm going to go ahead and step through.

B

We should see a tweet show up on our viewer awesome and I can see that I even have access to intellisense, which means I can see the full body of the request right here in visual studio code, just as I would if I were running all of these services locally without kubernetes, helm or docker, all right, I'm going to remove the breakpoint and then I'm going to check zipkin again real, quick yup. I can now trace the tweets being processed as well.

B

By the way, thanks to dapper, I get this observability and logging through zipkin all for free right out of the box. I can track every single one of these tweets from the moment it enters our application to every microservice insider application, all the way towards being shown in our viewer. I knew something was wrong when zipkin didn't have anything to trace, of course, not tweets weren't, even hitting our provider service, which is the beginning of the path that each tweet has to take through our application.

B

Now, thanks to bridge to kubernetes, I am 100 confident this is going to work. Let's get this checked in and I'm going to stop my debugger all right, I'm going to head on over to github and I'm going to check out to see what's happening with our pull request. Awesome. It started our pull request. Workflow now, while that's running I'm going to take a look at a previously completed, pull request, so I can see the steps that this workflow is running through. You can see that we start with the obvious.

B

We check out code from our main branch. Then we log into azure cli, because that happens to be where our components live. I have my azure storage. My secret shares my service bus and, of course, my kubernetes cluster. I'm making sure that, as a part of this pull request, it's deploying out our infrastructure using bicycling, because after I merge this pr, all of that infrastructure is going to get cleaned up and this way I'm not paying for anything. I don't need now.

B

Here's what's also cool it's going to install dapper if it's not already installed, and to do this, it's using a native github actions, setup dapper task. Next, I'm going to build and push that single provider image up, I'm not touching any other component or image or anything. Okay, I'm going to generate a valid namespace for use with this pull request. This is the name that is I'm going to use for my isolated environment or namespace. For me on this development cluster, finally notice I can use helm just like.

B

I normally would only this time I'm using it to deploy a dapper app, I'm going to install this pr using my charts directory and that's going to deploy out any dependencies that it needs, but it's only going to update again the service and image for the provider api. The last little bit of magic is adding a comment or a dash of confidence, as I like to call it to the pr with a link to go view. These changes again. This saves us from accidentally checking in broken code to our main branch.

B

Let's flip back over to our pull request and take a look at the conversation yep sure enough. I can now see that I have a new comment with the same exact link as earlier: I'm going to go ahead and click that fantastic.

B

I can see that I have tweets properly coming in now, and I'm going to do a quick sanity check and run a query in zipkin, perfect everything looks good. This is working exactly as expected. Thanks to bridge to kubernetes and dapper. This has made building and debugging microservices, so incredibly easy.

A

Thanks jessica, great job, the community momentum around dapper is incredible. We released 1.0 in february and it was submitted to the cncf in march. It is also great to see the support from organizations around the world if you'd like to join the community, you can use any of these links. You can also follow us on social media and check out the dapper ebook. Thank you so much for spending this time with us and we hope to see you building incredible cloud native applications with dapper.