.Net Foundation On .NET, 26 Nov 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Understanding the Azure.Core library

Description

Azure.Core on NuGet https://www.nuget.org/packages/Azure.Core?WT.mc_id=ondotnet-c9-cephilli

Azure SDKs for .NET https://github.com/Azure/azure-sdk-for-net?WT.mc_id=ondotnet-c9-cephilli

Azure SDK Design Guidelines for .NET https://azure.github.io/azure-sdk/dotnet_introduction.html?WT.mc_id=ondotnet-c9-cephilli

Azure for .NET and .NET Core developers https://docs.microsoft.com/en-us/dotnet/azure?WT.mc_id=ondotnet-c9-cephilli

In this episode, we joined by Microsoft Azure Software Architect, Jeffrey Richter, who gives us a thorough overview of the Azure.Core library and its HTTP pipeline implementation.

[01:10] - The HTTP pipeline
[05:58] - Extending the pipeline
[07:55] - Creating custom policies
[16:00] - Future potentials for the HTTP pipeline
[17:11] - Why didn’t we use HttpClient and DelegatingHandlers?

#azurecore #dotnetcore #dotnet

A

In this episode of on.net show,, I'm going to have jeff from the azure sdk team join us to talk about some of the core features that are in these new sdks.

A

In this episode of the on.net show,, I'm joined by jeff from the azure sdk team.

A

he's going to talk to us about the azure core sdk.

A

So jeff,, why don't you tell me first of all a little bit about who you are and what exactly it is that you do.

A

sure.. So I have been in.net for a long time,.

B

I've wrote a bunch of books and videos and things like that.

B

now,, I'm a software architect on the azure sdk team,.

B

Helping to architect these sdks, since they have a high degree of consistency with any language and even across languages.,.

A

In a previous episode,, we had some other folks on and they talked to us a little bit about,. Why do we have these new sdks and what are some of the core goals of these.?

A

This particular one, we're going to talk about the core sdk.

A

So my understanding is that this is essentially features,.

A

Like cross-cutting features that span across these different libraries for all of these different services that we have and just give us some common patterns and techniques that we might want to reuse across the board. yes. yeah, okay.

B

Yes,, so I begin. so in some previous team that I was in,.

B

We noticed that there are some core cloud-native fundamental features.

B

That you really want every distributed application to have.

B

when you're using one of our client sdks,.

B

You are building a distributed app because your client is talking to some of the azure services..

B

So we created this thing called an http pipeline which is extensible.

B

the way that it works, I'll demonstrate with this animated slide.

B

So in most of our sdks, you'll be creating some client, like a blob, client, or a container client, or event hub, client, or so on. on those clients,. There's various methods that you call., those methods ultimately end up, creating an http request. Object.

B

That's going to go to some transport in.net.

B

It's http client, but this works in other languages. Too.

B

Then the http client is going to send the request over to.

B

The particular azure service that you're trying to communicate with and that's going to send a response., then we're going to do some processing there and send it back as the result from the method.

B

well,. We want to have some certain behaviors that are specific method. Agnostic.

B

That is,, these behaviors are the same method, regardless of which method you're calling.

B

So we've created this thing called a pipeline and the pipeline,.

B

The definition of it is it's an ordered set of policies,.

B

And we have a bunch of policies that are pluggable into the pipeline. for example,, one of the policies that we have,- and this is in that azure, core library,.

B

The whole implementation of the pipelines is in the azure core library.. One of the policies we have is this client request, id.

B

So when the http request object is moving down through the pipeline,, this goes and adds a header to the http request with a unique client request id. So you can track the request.

B

Then it would move to another policy in the pipeline, like the authentication, one. now,. I know in the previous episode, adrian and alex talked about our credentials and our authentication in azure identity, library.

B

In the next episode, scott's going to present more about that., so he'll talk about that in more detail., but we have lots of different ways of doing authentication and how that affects the http requests, as it's flowing through the pipeline is impacted by this policy..

B

Then we have a logging policy,, where we can log, the outgoing requests has occurred and what time it occurred, and then we can see the response when it comes back in..

B

So we can see how long it took for the operation.

B

Then distributed tracing,, which I know in the previous episode, was also discussed about a lot too.

B

Where you can wire in a mechanism here so.

B

You can go and send it to azure, monitor or some other storage system..

B

So the request travels down through all of these policies and then ultimately makes it across the wire.

B

When the service replies,, it gives back an http response and the http response flows.

B

Backward through the pipeline going through these policies in reverse order., so it would hit the distributed tracing..

B

So now the distributed tracing knows that this has completed and then it can go report it and it can go and hit logging and to log that the result has come. In.

B

Some of these policies don't do anything with the response, like authentication or a client request id, and then the response would eventually make it up to your application. Code. now,. We have a few other policies that we put into the pipeline.

B

One is called a "buffer response"..

B

This is used for http responses that return a payload,.

B

That's usually json or xml., unlike blobs, which is binary data..

B

The buffer response policy will read all of the data.

B

From the service and load it into memory.

B

So that when we get to the top of the pipeline, we can de-serialize that into model objects that we then return back to the customer. Code.

B

Another policy that we have, which is the most.

B

Complicated of all the policies really is the retry policy.

B

So if, while making a request, something causes a failure,.

B

Then the retry policy would catch that exception and then it can loop around and it can actually issue the request again and send the http request message back through the policies that are below retry..

B

So another way of saying it. Is, everything between retry in the transport will execute once per try and everything between the method call and before retry will execute once per method. Call.

B

So we have some optimizations there. That's happening.

B

Also, for this buffer response., when we're reading the data from the service,, it's possible that the connection might die..

B

If that dies,, then an error happens in the buffer response, policy,.

B

That error will be caught by the retry policy.

B

again,. I can reissue the request to re-download the data.

B

So what we're trying to do with this mechanism is make it so that your applications for a very reliable and robust to failure, even without you having to do anything as the customer, you just get it for free by using our client classes.

B

Now, I mentioned at the top left of the slide that this is an extensible http pipeline.

B

by that, I mean that you as the customer,, you can actually create your own policies and you can plug them into the pipeline.. We have two places where you can plug them. In.

B

we have a place called "per-call policies", where.

B

Whatever policy you create, that derives off some base class and overrides a virtual method,, you can insert it here and then it will execute once per method. Call., we have another place where you can plug them in which is "per-retry policies"..

B

Any policy you plug into this location will execute once per-retry..

B

So it's a super-powerful mechanism., it's actually quite simple in its implementation and makes your application very robust, reliable., that's interesting.! So as I'm looking at this diagram,.

A

This animation, you have here.. This reminds me a lot of the asp.net middleware,.

A

Where I have the ability to plug into a pipeline and where I can expect messages coming, in,.

A

I can expect messages coming out,. I could change requests,.

A

I could do logging, and caching, and tracing, on all of these types of things.

A

yes.. Is that similar middleware?.

B

Yes,, this is a very similar type of middleware..

B

This is for outgoing and that's for incoming.

B

got it. messages coming into the service.. This is outgoing from a client. got you.

A

Yes, quite similar., okay. also,, like you, have a lot of built-in features here that I can, like I just don't have to write myself.

B

Yes., when we talk about working in the cloud,.

A

Being able to handle things like transient, errors, for instance, and having into retries or authentication and things of that nature., I really just want to focus on my business case and.

A

Whatever code I'm trying to write, and not necessarily some of these other types of concern.

B

Yes., so it's good for me that I'm.

A

Totally fine with microsoft like doing that for me, instead.

B

Yes, and over the years,, various azure sdks,, some of them have offered some of these features, like retries, and some of them have not., but now we provide them for all these sdks that we're working on and in a very consistent way, with a clean architecture that allows customers to plug into it as well.

B

okay, awesome.. So then that means that I can create.

A

My own custom policy, if I wanted to and plugins somewhere inside of the pipeline.

B

Yes, and in fact, I have a demo where I can show doing. That.

B

show us that. okay., so here in visual studio,.

B

I have some c sharp code where I can show you how to configure the pipeline.. That's just taking the policies that we have and configuring them.

B

But I will also demonstrate what you just asked about, which is inserting a custom policy into it., so first,. I want to start down here.

B

usually,, where customers begin working with our client libraries is that they will create some client.

B

In this example, I'm creating a blob service client and I'm passing it into it, a uri and I'm passing in some credentials. Here.

B

These credentials will end up being used by the pipeline. At that authentication policy, I showed in the slide.

B

You can also pass in some pipeline options over here to go and configure the pipeline.

B

now,. The options are optional., so you don't have to pass them, and a lot of times. Customers don't,, in which case when you knew up this client underneath the covers it is creating a pipeline., that's all with default configuration, like default, retries and so on..

B

But I do want to show here that you can customize that.

B

So here in "main",, I'm going to new up a blob client options. Structure.

B

Then I'm going to go and initialize some of its fields., so there's a retry section in there..

B

I can go and set the "maxretries" to some number.

B

here, I'm setting it to 10. the maximum delay for each retry. I'm setting this to three,.

B

And there's various other options in here.. I do encourage you to explore with them, and look at them, and read the documentation..

B

Then here,, I'm turning the logging on because it defaults to off for diagnostics..

B

So now, once I've created this options, object and I've initialized it,.

B

I can then pass that to the blob service client.

B

But before I do that, to demonstrate what you asked me about, on the "options", I can also call this function. "Addpolicy".

B

To this method, I pass into a some policy object and I have defined one down here. Below.

B

This class called "simpletracingpolicy",.

B

It derives off a base class which is in our azure core library.

B

Then I override this virtual method, "processasync".

B

This method will be called as your http request goes through. The pipeline.

B

You get to execute some code upfront.

B

here, I'm just going to call "console.writeline" to prove that we made it to here and you'll see something in the console window..

B

Then I call "processnextasync", that's a method I had heard from the base class and I pass the message down and the pipeline onto the next policy in the pipeline.

B

Then,, when the http response returns,.

B

The code after this will execute. again,, I'm just going to do a console.writeline, so we can see the response that has come back..

B

So you can see how really simple it is to go and define your own policy, just to override the one method, and then the code can be whatever you want it to be, and then just forward it on to the next thing in the middle.

B

cool.. So now, when I call this add policy method, I'm newing up an instance of that class,.

B

And then I have to tell the method whether I want this to go in the per-call section, or the per-retry section in the pipeline.

B

here, I'm saying per-call,, so it will execute. Only once per operation has to pose to per-retry, which would execute once per try.

A

So let's talk about that.

B

Sure. part for a little bit. okay., so I can just re-picturing that diagram.

A

You showed us a little while ago., so we know that retry. It happens at a certain point within that pipeline. yes.. So essentially what this call is doing. It's saying,! I want this to happen.

A

so right now what we're looking at here in the diagram.

A

yes., like it's going to happen at that point.

B

So I added it here in the per-call section., so it will happen here at the very beginning.

B

or I could have added it in the per-retry section,.

B

In which case it would happen to this location., but those are the two very.

A

Specific extensibility points that we have.

A

that's right.. It could either be one of the first ones that get called,.

B

Or it could be, again,.

A

Post-Authentication in within that retry section., that is correct. okay.

B

Now,, you can call the method, multiple time,, so you can add multiple policies in the per-retry section,.

B

Or multiple policies in the per-call section.

B

sure., so I another question: too.

A

Yeah. again, just thinking about how at most middleware pipeline and things work., do I have the ability to circumvents the flow of the messages?.

A

Can I shortcut the messages and say, hey,? I don't want you to continue.. You can always insert a policy,.

B

And just not forward it on to the next policy in the pipeline,, and then you can just return.. So that would be a useful thing to do. If you wanted to create a policy, for example, to do fault injection, and pretend that the service you're trying to talk to his down,, you could easily insert a policy that maybe one out of every 10 requests. It just returns a failure.

B

sure.. Then you could build your application to be robust against those problems.. That might also be.

A

An interesting scenario when we are talking about testing.

B

Absolutely, yes. a mock response, for instance, or some sort,.

A

And so, instead of going through the entire pipeline, and doing retries and often all these types of things,, I could start mockups and responses and say in my integration, tests, or my unit test, or whatever the case is,. I could have some deterministic responses that I could reactivate.

B

Yes, definitely true.. Other examples are things like you could put a circuit, breaker policy in there for those people who know how that works, or client-side caching mechanism..

B

So you might look locally to see if I have the data and return it rather than making a call to the service..

B

So there's numerous ideas of why the extensibility can be useful to customers.

B

great, sounds good. all right.. So now that I've created the options, and I've set up some of the values, and I've added my own custom policy, I'll now new up the client passing in those options.

B

So now this client-object has the uri and the pipeline associated with it,.

B

And now I will go and make a call to do something with this client,.

B

But every call to do something with the client goes through the pipeline.. So when I hit f10 to execute, this, you'll see that in the console window, here it is right. Here,.

B

That our custom policy got the request,.

B

It was an http get request, and here's the url, and you could look at other things about the requests like headers and query parameters and so on..

B

Then, when the response came back in from the service,- and this is all live,, it's actually doing this., then we see that we've got an http 200 back and it was the get with the same urls,.

B

What we got the 200 back, from. yeah.. Another thing I'd like to demonstrate, which is very cool if you ask me,- is that if you have a client object like this service, client,.

B

And then you call a method on it to go and create a child client from it,.

B

If you were to create another client from it., so here I'm going to create a blob container client.

B

For a blob, that's in this blob, container,.

B

And this is the name of the container. when you do this,. The new client object that you create will actually inherit the same pipeline as the parent.

B

So all the retries and all the custom extensibility,.

B

And everything is now on this new client object, the blob container client.

B

to demonstrate that,. I will go to the container and tell it I wish to delete it, and when I hit f10 on that, if you come back over here, you'll see that my custom policy did get invoked. Here,.

B

You can see the delete, operation came in, and we got a 202 back from the service., that's interesting., so for the child's clients,.

A

Can I have a customized pipeline.

A

From a child as well, or is it just using the example one?.

B

You can,, but then you have to create the child client out of thin air.

B

A

Don't create it from a parent.

B

Got it, got it.

A

Whenever you create a client,.

B

You always get to pass in the options, and then you're configuring, a specific client, or specific pipeline for that client..

B

If you create a client from another client, then it inherits the parent's client.

B

yeah, that makes sense. got you,.

A

And then you're saying, though, all of our sdks,, like you, were saying before behave, this way.

B

That's correct. so we're talking about storage, queues, or something else.

A

Yes. key vault, or whatever the case is.. The programming pattern is fairly similar.

B

Yeah,, it would be pretty much, so since this is an azure core,, the.net version of azure core works identically across all of our sdk, or client libraries, for.net.

B

So we hope that people will start to learn some of these concepts,.

B

And then, once you.

B

Learned it from one sdk, you can apply that learning to all the others, and even if you switch programming languages,, the concepts were still there, and they work in a very similar way. sure., just idiomatic to that language.

A

This makes me think about comments. I hear from a lot of our customers, which is,.

A

How can I mock out azure services?, so it feels this sdk is a good step within that direction.

A

Yes., because when you think about it, a lot of our services have no local version..

A

B

No local version,, no local, emulators or whatever,.

A

But it sounds like now. This is a good opportunity for either us, or community, or some other folks to create some defaults,.

A

Mocking mechanisms,, so that, now that we could work with our things locally,, we would work with it offline, and eventually, when we reconnect to the internet, or reconnect to the major the ability to just use the sdks the same way, we don't have to change.

B

Yeah,, definitely that's true., aside from the emulation part which is complicated,.

B

The pipeline makes it easy to maybe redirect to a local ip address, rather than the remote one.

A

Awesome., so I have one last question: I've been dying to ask.

A

Go ahead. so I'm looking at this http pipeline,.

B

And it's just reminiscent of.

A

So many other things that I've seen before., so we already have http client, when they have delegating handlers, and all these types of things.. Why didn't we just use that?? Why do we need a new pipeline mechanism??

A

So I would say the main reason is that.

B

The delegating handlers are attached to an http client,.

B

So if you wanted to modify the options,.

B

We would have to create a different http client, and the best practices for .net, is that there's one http client for your entire application, and then you're just re-sharing, that connection pool that it has.

B

So that's why we did not use delegating handlers underneath the covers to do this,.

B

We built this on top of that.

A

Got it. it's more efficient, really,.

B

We're using resources more efficiently.

A

So you'd go ahead and managing that lifetime for us,, and that's just one concern that me as a developer,.

A

I don't really have to worry about too much. yes. cool, that sounds good. all right., so again, just like before in a sec we always did,.

A

I want to make sure that anybody that watches this video, we're going to have some of these code, samples that are available, and make sure we direct them to the right, github, repos, or the right blog posts and samples,.

A

So that everybody could go ahead and check them, out. yes. again, these sdks,.

A

These libraries are available, today., all right,, so you can go and you get, you can download them for.net specifically,.

A

But if you look into any other languages.

B

Other languages- too, yeah. absolutely.- you can do that too. yes. awesome. thank you, jeff.. I really appreciate it.

A

I'm glad to help.. Thank you all for watching.. I hope you tried these libraries,.

A

Try it on sdks for azure, and then let us know what you think. leave a comment down. Below, make sure you share and like this video with your friends..

A

Thank you for watching this episode of on.net.