.Net Foundation On .NET, 17 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Service Discovery with Steeltoe

Description

Service discovery essentially is trying to find an answer to the question of what services are available and how do I get to them.

In this episode, we chat with Tim Hess and David Dieruf from the Steeltoe team to learn how to setup Service discovery in an ASP.NET Core application with just a few lines of code.

[02:40] - What is Service Discovery?
[04:08] - Comparing Service Discovery and DNS
[06:10] - Setting up service discovery with Steeltoe
[13:28] - Configuring the discovery client
[21:10] - Inspecting services in Eureka
[23:30] - Benefits of Service Discovery
[26:52] - Getting start resources

Steeltoe Homepage
https://steeltoe.io

Service Discovery with Steeltoe
https://steeltoe.io/service-discovery

.NET Microservices with Steeltoe
https://channel9.msdn.com/Shows/On-NET/NET-Microservices-with-Steeltoe

Steeltoe on GitHub
https://github.com/steeltoeoss

A

Service discovery is such a key component to building microservice applications and in this video, we're going to have some folks on from the steel toe team who are going to show us how we can add service discovery to our.net.

A

A

Hi, everyone welcome to another episode of the on.net show and in the next series of videos, we're going to take a look at the steel toe framework which is going to show us how we can build microservices in our.net applications. Now before we start getting into it. I want to introduce some gentlemen from the team I'm going to have david and tim talk to us. So why don't you two introduce yourselves really quickly, so we can know a little bit about who you are and what exactly do you do.

B

Sure, thanks cecil, I'm uh david dariff uh longtime.net advocate uh I work on the vmware team in uh tenzu product anything.net. uh Pretty much falls on my plate. Over there. I sleep and breathe. It.

C

Hi, I'm tim s, I'm an engineer on the steel tower team. I've been working on this project for about three years been in the dot-net space for well over 10 years.

A

All right, so why don't we just go ahead and get into it right? Tell me a little bit about what exactly is steel toe? Why should I care about it? You know what what kinds of problems exactly does it solve for me.

B

Thanks diesel, so let's talk about sealto and how developers build net microservices, so the sealtel framework was created in 2015.

B

uh It was donated to the dotnet foundation a few years after it's an open source project that enables.net developers to bring resilient best practice microservices to the cloud another way to put it is it makes your net coding quicker, easier, safer, speed, simplicity, productivity, all the good things. You know that you would normally hear about things.

B

This is the key. uh Steeltoe is not replacing.net at all right. This is the net runtime, so much goodness in there. What it does, though, is dotnet has to cover a lot of different areas as a runtime right, uh console, apps, microservices web api, pleaser stuff. You know all of that, specifically in the microservice world, asp.net steel toe, helps. You add some cloud opinion in that right. We know the environment we're going to be running in here.

B

We know that we're running web apis, so we can deliver some ready to run patterns in a pretty darn, stable, uh good way.

B

As far as service discovery goes right when we're talking about those microservices we're talking about delivering those baked in patterns, so, first of all, a service registry, think of it as a phone book for your microservice each service registers itself and tells the registry things like here. I am here- are the different hosts that I'm going to be on the ports that I'm going to run on things like that right, like a phone book, uh and then you also have clients who come in and ask the registry look. I have this name of this service.

B

Can you tell me it's address? It's a uri and it's a port number and things like that. We can also pack in some other metadata and things like that. But the the basics here of service discovery are the uri and the port for it. uh We can also do some other fun stuff uh with it uh the architecture.

B

uh Basically, in a microservice architecture, your instances are always on the move right. Your application is relying on all these services to be available, though, so you got to create some sort of mix there between the two, some sort of uh solution, and the service registry removes the complication of. I don't actually have to remember where all these different services instances, maybe different data centers could uh is running.

B

All I need to remember is the name of the app and I can be told or possibly, load balance uh for all these different instances and get one.

A

So david, a lot of what you've said about service discovery reminds me a lot about dns right, particularly that phonebook analogy right, because we think about dns, as the phone book of the internet right is, is service discovery very similar to that is it built on top of dns or is it something completely different.

B

No it it actually that's an interesting analogy uh because in some respects it is uh to tell you the truth.

B

The the thought that pops into my head, though, is dns, is a very long living thing and and really doesn't change that often right the assignment of a name to an address really doesn't change that often, and the microservice world is constant, and so a service registry uh is similar in respect to the phone book and dns and that sort of thing but uh different, because it is very resilient to change and it gives you specific features for look. I know this thing probably isn't going to be in the same place tomorrow.

B

So give me ways to overcome that and adapt okay.

A

And that makes sense- and I think also from a micro service world perspective. One of the reasons that we do want to have service discovery is because, like you said, the service is a little bit dynamic right like I can have one or many over one particular type of service, and then they come up and they you know they create and destroy themselves very quickly. So I need to know like: where are they are they healthy? How can I reach them?

A

What is their address and these types of things right and and that's a non-trivial thing for us to do and that's where these registries come in to kind of help us solve some of those problems.

C

And building on top of that, um once you're using a service registry, your application is able to know where all these instances are and use its own load balancing pattern. So we provide some some patterns out of the box like a random load, balancer and round robin, but you can write your own.

A

Cool that sounds pretty good. I know you guys have a demo. Why don't we move forward and take a look and see what it actually feels like to create? One of these.

C

So, like any good demo, we are going to start completely from scratch with a brand new project and we're going to do all of this.

C

The fun way, though, not the most reliable way here we go uh we're going to make a uh weather api is our background source that the plan for this is we'll make a weather api in the background and we'll have a weather website in the front, and we will call this backend project, our weather api and I'm going to change the solution name because I hate having the same name for the project in the solution.

C

And while this is spinning up our web api project, I am going to go ahead and use docker to spin up a eureka server, which is what we're going to use as our service registry, and we say docker run, and I want to remove it when I'm done and I'm going to do some port forwarding here so that I can um rely on the defaults.

C

um Eureka listens on port 8761 by default, and I'm going to pull down a skeletal provided image. That's great for doing any local development, but probably not intended for use in production.

C

Let's go ahead and start that eureka server in the background.

A

And so, like you said before, eureka is just one of a few different options that are available for registry and its sole purpose is to be that phone book right like these are the services I have, and this is where I can find them.

C

Absolutely um so eureka is powering up in the background. um We have our web api project here, I'm going to switch the debugger on this to use the project directly because I don't want is express getting in our way at all.

C

I'm going to go ahead and add our other project right off the bat and it's going to be another asp.net core application, and this will be our weather website.

C

And it is going to be an mvc.

C

C

And now we have two applications: it's exciting! um I'm gonna go ahead and plug our nougat packages in um right away, so that that is out of our way, and there are three of them that I'm going to be adding. Today, I'm going to start with a steel toe common hosting package which doesn't do a whole lot for us, but it does make it easier to specify the port that an application is listening on.

C

This is relevant for local instances. It makes it easy to switch support that it's listening on, so that if you have two brand new templated applications, you're not trying to fire them both up on port 5000.

A

Yeah that sounds very helpful.

C

So then, I'm going to add the discovery, client core package which currently knows about all the discovery, implementations that we work with and I'm going to add that to both the api and the website project, so they both will be able to to get wired up and talk to the discovery. Backend server and the third package, I'm going to add, is just to help with the deserialization of the weather api responses.

C

When I make calls from the front end. So that's the assistant.http.json package.

C

Get that guy in there and then this should be all that we have to do with nuget packages. For today. Okay, I'm gonna make that same startup change on the website, so that we get the next little console windows for both of them.

C

I'm gonna go into the program cs file in the web weather api.

A

Go ahead, could you make that font size just a little bit bigger.

C

A little smaller.

A

Yep that looks good. Thank you.

C

All right, the common hosting package includes this extension for use cloud hosting, I'm going to run the weather api on port 80 because everybody loves weather services running on port 80., um and that's it for for setting up that port binding and what this does when you deploy it to environment. The two cloud platforms that provide a custom port for any given instance is it will read that environment variable and it will listen on that port instead of this port. So this parameter is only.

A

C

When it's running locally, okay got it. The next step, of course, is to configure the services that we want to be providing in our dependency injection. So we want to go ahead and add our discovery. Client here and we'll give it our configuration.

C

And then we want to make sure that that is activated when the app starts up.

C

So that it begins registering I'm in this case with the eureka server, and I am going to turn off this https redirection for right now, just because that can sometimes cause issues and we don't need any surprises.

A

Okay, so so far, what you've done so you've installed some new get packages you've inside of the configured services, you've added, um you've, injected the discovery, client, and then you also added it to the pipeline inside of configure services. So I'm guessing I'm assuming now. What this will do is based on whatever configuration we have it'll register this api with the registry. I feel, like I'm saying, register on a whole bunch, but it'll add an entry to the registry to be like. This is where I am. This is where you can find me.

C

A

C

So um what this does is, it doesn't actually um do anything with the http request pipeline, but it provides a nice convenient place for us to start a background thread so periodically. It'll report its health to the service registry and make sure that the registry information is up to date.

C

B

The last thing that we have to do.

C

With the weather.

B

C

Is provide some configurations so that steel toe knows which service registry we want to use and because I have a terrible memory, I can't remember all of our configuration keys. So I like to plug in a little json schema here to get some intellisense and help me remember uh what the configs are.

C

So we have the steeltoe config at sealcode, io, slash, schema, slash latest slash, dot, json.

C

And that should make it nice and easy to plug in our eureka. Configuration.

C

And I know that in this case we want we need to tell eureka what the service is called, and so we configure our eureka instance app name as the weather api and that's it. The rest of the defaults should work just fine for this setting, so I should be able to go ahead and close out everything in the weather api and then just to make communications easier between the two services I'm going to go ahead and copy this weather forecast class from one or the other.

C

Ideally, in a real world situation, we put that somewhere else and use a nougat feed to keep them up to sync, or you know.

B

Some other some.

C

Other pattern there, but this will work for us today, um so I'm gonna repeat that same set of changes. I'm gonna go into the program cs file in the website api. We will use our cloud hosting here and this time we'll give it 481, thereby avoiding collision, we'll go into our startup file. We'll add our discovery. Services again.

C

And we'll make sure that that client is activated.

A

So essentially, you're doing the same thing in both places right so you're allowing the website to be discoverable and you're. Also allowing the api to be discoverable.

C

Yep and there's some configurations.

A

C

So that we can, we can, if we want to turn off the the registration of the web front end because theoretically nothing's going to be looking for it um unless we have something else in play like a spring cloud gateway, um but we're not dealing with that. Today.

C

um Again, I'm going to turn off this https just to avoid any conflicts there, okay um and then now we've got these services hooked up and fired, but um there's there's gonna be some http communications for us and um I like to use the http client factory, um and I can configure that in here. So I'll go ahead and do that as long as I'm already in this file and then that way the http client will be configured for us later when we need it.

C

So we'll add a client we're gonna name it weather, and we know that all of our weather interactions are going to have the same base address um so go ahead and configure that right here as well.

C

C

Think all right, so this is going to say this is where we put the service name. So we registered our weather api as weather api, and then we know that all of our requests are going to go to a service named weather api and something in the background is going to resolve what that actually means for us down the line right.

C

But in order to actually activate the discovery components on this particular http client. We need to add our service discovery right here and now that http client has a base address weather api across the board, and it will always use service discovery to resolve it.

A

Oh, that's: cool, okay,.

C

A

C

A

That was doing too is it was adding an http handler, I'm guessing in the background just wire up into so that like when that client makes that request, the handle would fork out and talk to eureka or whoever we're using for our registry to get that information. Absolutely.

C

Got it all right so app settings again, you know what I'm actually just going to copy this one out from the other one. So I don't have to retype the whole thing.

C

um In this case um we don't need to set the app name, um I'm just going to go ahead and tell it not to actually register with eureka and we'll use the rest of the defaults.

C

So we'll configure our urea.

C

C

Okay: okay, that's it for the app settings!

C

So now we have all of those pieces. We still.

B

C

Wire up something to actually make that call out to the weather api, I'm just going to go ahead and plug that into the home controller. Here, we'll inject the http client.

C

C

C

C

And then inside of our index, we will go ahead and we'll retrieve that that client, that we configured, which we named weather all right, so we'll go ahead and continue getting our weather forecast here, uh which comes across from the api as a list, because it's actually the forecast for. I believe five days.

A

So I think what could be supposed to be really great about this is just with that little bit of configuration you added, and it really wasn't a lot. This hdtv client factory now is going to be able to go out and dial into the phone book right and it's going to be like hey.

A

Can you give me something that knows about weather right like give me some information about it um and then now you can start making requests and you're not going to have to hard code urls- and you know some of these other types of of things that we usually have to do.

C

Right, yeah and our code is extremely simple and basic and clean, and so that that's pretty fantastic all the way around all right.

B

So now, we've got honestly that that cecil is, is one of the benefits really with steel toe that we found with a lot of developers. Is they take a point of view of simple few lines of code? You get a heck of a lot of bang for those few lines of code, and this is this is a great example.

A

Right so now now we've gotten that data I'm guessing. We have to show it on the page. Somehow, yes, inside of this razor view, so.

C

Our model is going to be a list of weather forecasts.

C

And then we'll just update our welcome message.

A

Nice welcome to the best weather website. I love it.

C

I gotta tell them what we're gonna show them here, so here's forecast and we're putting the table because everybody loves tables.

C

Give it a little bit of style and then we're gonna need some headers. So we know what we're looking at and for for each forecast item. It's gonna be a day of the week here and I believe it comes with a summary as well and we'll go ahead and display the temperature.

C

C

C

Let's do your simple data dump onto the page.

C

Okay, anybody want to say best and whether that works.

A

uh Yeah that looks good to me so again, we're gonna call into the registry. This time we just happen to be using eureka um instantiate that htcp client factory we did inside of the controller. You know we got some weather items back and now we're doing what we usually do in dot net right like we're for itching over a model which is, is nothing different or out of the out of the ordinary from what we usually do.

A

So the code looks again very familiar right, even though we're doing something a little bit different in terms of like using service discovery to get that information.

C

All right, I am going to fire up uh the eureka dashboard just so we can take a look and see that there's nothing there right now.

A

C

So that dashboard comes out of the box with that docker image, I'm running on port 8761, and this is where the instances would show up and there's nothing registered right now.

A

C

So we'll go ahead and start the weather api.

C

And this is where I was supposed to check a box or uncheck a box. When I started from the template.

B

C

So hopefully, there's nothing remaining that gets in our way here looks like it started up just fine and it registered.

A

ah Awesome so there's there's the api.

C

So by default it used my machine name and then the the name that we provided and then a new import.

C

So we'll go ahead and turn the website on and we'll see if it knows how to connect all the dots.

A

All right and then I remember you said you did not set the website to register itself, but even though the configuration that's there will still allow it to be able to use the registry, even though it itself is not a registered service. Correct, okay,.

C

It's just one less operation that the website application needs to perform over time. So you know this is up and running now it hasn't registered and we should be able to hit vocaloid stage one and.

A

Get some weather and there's the weather boom. So it's working it's great yeah. I don't know what happened to the temperature, but.

C

That's fine yeah, um so yeah! You can see right here that the original request started as weather api and then it was resolved to the host name.

B

There's your dns right, the the analogy back to a phone book and dns inside uh you know it always comes down to that.

C

B

C

In this particular case, it does actually resolve via dns as well, so it does, it does the registry, and then it does dns, which makes sense in some scenarios where you've got distributed, scenarios and and the dns lookup still makes sense. um Typically, what you would do is have this prefer the ip address and talk to the ap address.

A

Instead, so that was a really interesting demo about how we could use service discovery and eureka to kind of get information back from, like you know, some distributed services that we have running in our architecture.

A

um Why don't we head back over to the slides, really quickly and dive into like some a little bit more information about like some of the things that we could do and some of the benefits of using service discovery all right, so.

C

Why would you want to use steel toe service discovery? Well, we provide some abstractions on top of the base layer. We have our own eureka client, but we also have an overlay so that you can, through configuration just swap in hashicorp console or you could use a native kubernetes option. We do have some other really basic options.

C

There is one that I wrote for unit tests actually, but you can use your configuration to actually like, through your eye, configuration infrastructure right out your your services, if you've got an extremely simple use case where maybe eureka is overkill and you've got something where you still want to use the pattern, but it's a bit more static.

C

This tooling also has logging and health checks built in. So when you're using something like eureka, we will automatically inject health contributors, so you can have instant reporting of how the health is between your application and the service registry as well again. The registering and discovering of services is made super simple, with just a few lines of code, so the the registries that are currently supported. um Eureka is the one that we've had around the longest, and so it's got the most functionality.

C

It's the most tried and true um after that, we added console which has very similar functionality, there's a couple of places where it's a little bit newer, but it's still quite capable, and then the newest is is kubernetes native, which is very new and is not nearly as built out but again you're you're, relying on your underlying platform infrastructure. So there's not as much that needs to happen in that space um digging in a little bit deeper.

C

I briefly, we touched on the request, load, balancing functionality, that's baked into this stuff, and we talked about random and round robin and the.

B

Round robin.

C

Provider actually uses the eye distributed cache infrastructure. So if you have a redis server, that's shared between whatever front-end instances you're using you can make sure that it very fairly round robins even across multiple front-end instances, so that the the back-end services get hit very very, very fairly, or you can take this load balancer infrastructure and do virtually anything with it. It doesn't have to be used just in http. um If you wanted to load balance between days of the week, you could use it to do that in your own applications as well.

C

um Some of these registries support high availability. We do as well the discovery first strategy is something.

B

C

Very commonly used in java and spring worlds- and the idea here is that you can deploy your application to an environment and provide it just the address of the registry and from that your application can get a config server setup and it'll go find the configuration that's relevant to that environment and really all you're doing when you deploy is provide one piece of information and then it can discover the rest.

C

Additionally, azure spring cloud is available and it will be launching with net support with steeltoe later this year. So where do you want to go next? There's all kinds of stuff we can go. You know read more in the service discovery page on sealto.io, there's getting started guides.

A

So I've always been a really big fan of service discovery, and even just looking at your demo like it's really clear like there's, some really interesting benefits there. So for me, as a.net developer, it didn't look like there was a lot of configuration again. The tooling and the familiarity with my general workflow doesn't feel like it was disrupted at all right and then I have the ability to know that I could start discovering services and I'm not necessarily coupled to these services right. So, if I'm understanding correctly, I could change my configuration.

A

I could just point to different registries and I don't have to install you know another client. I don't have to do another di thing right. All I have to do is just change configuration and all these things would kind of just light up and work for me which for me, that's what I want right. I want to focus on my code and like have the infrastructure, do what it's supposed to do and have that that confidence that you know it's just going to work right. So that's kind of how I feel about steel tool.

A

When I see you do like really cool demos like these.

C

Absolutely and then one of the other things that's cool about the kubernetes world is you'll, be able to deploy your app to kubernetes, and if you want to start with the service discovery infrastructure, that's provided out of the box. You can do that and then, if at some point it isn't meeting your needs and you need to discover services outside of your kubernetes cluster. You can swap that out for eureka or console and have instantly upgraded.

A

Capability, great right, hey! Thank you both for coming on. uh This is a really exciting episode, and I know we have some more that we're gonna have recording in just a little bit. So thank you both um david and and also you tim, and thank you all for watching. This has been another episode of the on.net show, and we've had some folks from the steel toe team come on to show us how we can do service discovery in our.net core.

A

A