>> In this episode of the ON.NET show,
we're going to have some folks joining us from
the Azure SDK team to show us how we can make use of
these new SDKs they're building to
leverage Azure services and some of our apps. Check it out.
[MUSIC]
>> Hey, everyone. Welcome to another episode
of the ON.NET show and
today I have some special guests with me from the Azure SDK team.
So why do we start off with you folks just
introducing yourselves and let me
know what exactly it is that you do on the team.
>> I'm Adrian. I'm a Program Manager for
the SDK team dealing with architecture.
>> I'm Alex. I'm leading manager on
the.NET side of the SDK for Azure.
>> Got you. So your team specifically not only just does.NET SDKs,
but your team is responsible for all the Azure SDKs.
So we're talking about .NET,
we're talking about Python,
Java and JavaScript like all of
those things are underneath that umbrella, right?
>> Yep. Pretty much every single
language if it's got an Azure SDK,
it will fall into
our group eventually, but right now you're right.
Those four languages are what our focus is.
>> Got you. Okay. So we that
SDKs for Azure for a long time, right?
But I'm sure you guys are here to talk about some new SDKs.
So what do we talk about firstly one,
why did you need to create these new SDKs, right?
Because I'm wondering what's wrong with the old ones.
>> So we went out to a lot of customers
and we talked to them about the problems that they were having,
the issues and how we could improve,
and we came up with certain things
that were fairly universal across them.
Firstly, there wasn't a one-to-one relationship
between what service offered and the individual languages.
So a feature might be available in .NET,
but not in Python, for example.
So we wanted to unify the experience so
that it didn't matter which language you wrote in,
you would get the same experience.
The second thing was that there were a lot of
niggling issues in the.NET world
for example, dependency management.
One SDK would use Json.NET of
one version and a different service
SDK would use a different version,
and reconciling that was problematic for people.
So those were the biggest reasons
why we did this and what we did was we came up with a plan
to produce a unified Azure SDK so that if you used
a service SDK or service client library
as we call them now from this unified Azure SDK,
you would get the same experience
across all the services that were in that set.
>> Got you and what I really love about that
is in modern day software development,
what I always find from our customers is there's never usually
just one programming language in a solution or in a company.
>> Right.
>> I've worked with folks that have been
using Ruby and Python together or using
PHP and C# together or.NET and Python together.
We always want to find a way that we could have
that common knowledge shared back and forth between the two.
So it sounds to me like if I'm a Python guy or if I'm a Java guy,
and I have the knowledge of the SDKs,
I can assume that very similar patterns
would exist between these different SDKs.
So the time that it takes me to ramp up to be
productive would be a little bit less, right?
>> Yeah. Even across services
there's certain things that you
do regularly like paging, for example.
You shouldn't have to learn a new paradigm
every single time you go to
a new service just for what is in essence a list operation.
>> Got you. Sure that makes sense.
So I know earlier we were talking about
a couple pillars of areas of focus for these SDKs.
Can we talk about those a little bit?
Can you touch on those a little bit?
>> Yeah, absolutely. We've actually got a set of guidelines.
There's a set of general guidelines that we use
to develop per language guidelines.
Then we've got guidelines for every single language that translate
those general guidelines into
the language of choice to make sure that it's idiomatic.
>> Got it.
>>.NET of course, has
very strong idiomatic sense
of what it takes to produce a good library.
>> Sure.
>> Aside from the idiomatic usage,
we have approachable as
a big pillar and that really means that as a developer,
you should be able to get started and you should be able to
understand the concepts from the service relatively easily.
So that really translates into
a great documentation experience
starting from the QuickStart that you
use to learn how to integrate the library all the way through
to how do I do this thing that I'm doing in the code.
>> Yeah.
>> To be able to translate
the concepts from one library to another.
So the paging one is the one I always come out to,
but streaming data or how do you do error handling,
how do you do logging, those should
common concepts across the library.
>> That makes sense because and as a developer,
these are things that I have to write over,
and over, and over again.
So it's really good to hear the framework and
the libraries just have this built-in,
so I could leverage the work and also to have
that consistency across these different SDKs that you're building.
>> Yeah. So the second pillar is dependability and
this really comes down to one core tenant that we have.
We are doing the final breaking change
to end all breaking changes,
and we are committing to know breaking changes from this point on.
>> That's a big one.
>> So that means when you're using the unified Azure SDK,
you can write it with one library,
you can upgrade the library for all of
the security updates and keep up to date and we won't break you.
>> Awesome.
>> So when you think about how important that
is for people to actually get
those security updates just by a recompile of their program.
>> Sure.
>> That becomes a seriously big effort.
>> Right. That's awesome. I know, again,
for a lot of folks that think about just keeping up to date,
and upgrading, and those types of things,
it becomes a process, right?
Because now I got to put this through my CICD environment.
I got to have QA look at it,
I got to make sure that I can verify
the software before we put it out to our different customers.
>> Right.
>> So just the fact that we can have
that reassurance that I
don't know what these Microsoft folks are going to do.
They got to change some stuff and all hell's going to break loose.
>> Yeah.
>> So just knowing that we have that
consistency is extremely important.
>> Yeah. We've all been there when new library
has broken and we just died on the vine.
>> Got you. I know there
are some other things that we wanted to talk about through for
instance the consistency and
also the ability to diagnose some of these things too, right?
With those core tenants of what we
or what you talked about whenever you built this library.
>> Yeah. Absolutely. As Adrian mentioned,
one of the first things we did is we developed a set of
guidelines that we wanted to follow
and those guidelines were going to help people
understand our product and be able to use it
across in a consistent way.
We also wanted to take some of those guidelines and
codify it in a way that our developers can
build SDKs and configure them in a way,
and to do that we've created this core library.
We call Azure.Core that
implements some of those guidelines and code.
Things like we try logging and distributor
tracing are all coded in the library
and it is the library
that makes the communication
between the other code and the service code,
and handles all the heavy lifting for the SDK.
Another thing that we heard from customers that is
very pinpoint is authentication.
Setting up your authentication is not trivial thing to do.
>> Sure.
>> We took this opportunity to create
a library called Azure Identity that has
abstracting that away from our customers and makes
the customers use the SDK without having to think too
much about authentication and we have talks going into
more details for both Azure Core and Azure Identity coming up.
So another thing that we wanted to
do is in the same line of consistency,
we have all the packages that we have.
The agents that were coming up in your packages.
We want to make them in a consistent way.
So all the packages will have
the same prefix, all start with Azure.
and you can go and search on NuGet or
your other package manager and they
all look the same and it's easy to find.
>> Sure and you had a slide about that too, right didn't you?
>> Yeah.
>> Didn't you want to show us really quickly?
>> Sure. So this is our slide where you can find.
>> Our guidelines are all open source.
They're all on open source, everything is on GitHub.
We have design guidelines where we can go and read
about how we've designed an introduced our packages.
You can get packages on nuget.org which is
the default Nuget package manager for.NET.
Our source code and docs are all available in the open as well.
I have a demo that I'm going to show later and you'll be
able to look at the source code for that as well.
>> Sure. That sounds great.
>> I'll come back
to the coding part of this thing where I wanted to show how
some of these guidelines can transfer directly into the code
and how we can make it so much easier
for customers-student to use these libraries.
So I'm going to show you a small
ASP.NET core app that we wrote
that is basically a Cloud clipboard.
You can type some text in here,
you save it, and then it
will have a list
of clips that you can share with your friends and do all that.
So let me jump into the code and show you
how this was all put together.
>> Yeah, that sounds great.
>> I'm going to contrast the before and after,
how we used to have to do this
before our libraries come in and how you could do it later.
The setup of this library
is MVC application and you have to figure out,
how am I going to make my service client
available inside the application to be used in the code.
So in order to do that,
you had to create an AzureServiceTokenProvider,
retrieve a token from that,
create a token credential using that,
pass that to a storage credential, finally,
create a CloudBlobClient and
then add that as a singleton in your application.
That's the code that you had to do and write for
your application to authenticate
with Azure and retrieve all the information.
With the new version of our libraries,
now that becomes a single line of code.
What it does is, it says,
please add a Azure server client,
and this is the add a blob service client,
and configure it with this service URI.
In the background, what we do is,
we use the default Azure credential object that's part of
Azure identity to discover the right credentials for you to use.
You'll be able to write this code
once and you'll be able to run it on
your local def box as well as in
production without making any changes to this.
The code behind Azure identity will take
care of figuring out
the credentials from the environment that you're in.
>> Got you. So what you're showing us right now on
the screen is at the top when we're looking at V11,
that is the current or
the currently released version
of the SDKs that are available today,
that people are using already.
Then what we're looking at now at line 46 is the new hotness,
the easier mode that we're enabling with
these new set of SDKs that I believe are in preview today.
>> Yes.
>> Got you. Okay.
>> Another consistency part that we wanted to address
is making sure that the code that you
write is taking advantage of
the rights or the latest set of features that are available
in your language to make you more productive
and make you write less code.
>> Sure.
>> So as Adrian mentioned,
iterating and paging over a set of items is a pretty complex task.
As you saw in the beginning of the demo,
I was listing out the blobs that are
available on the storage and the container.
So the code that I had to write in the V11 of it
was this code, get the service,
find the container for
this particular user and have two nested loops;
one that iterates over
the pages and one that iterates over the items in the page.
So this is a non-trivial amount of code
and it's easy to get wrong.
>> Sure.
>> So taking advantage of
the Async iterators in the new language feature in C Sharp,
we can collapse those lines to these few lines
where you get Blob Container client,
which there's a container and then you iterate in
a Asynchronous fashion over the items and you return them.
This is available across all of
our libraries that support paging, and it's again,
part of our consistency model for how we get
the same features and same behaviors in the product.
>> Got it. So I'm guessing
these libraries are targeting a certain version of.NET standard,
so are these.NET Standard 2.0 libraries?
>> Yes, they're.
>> Got it.
>> One of the other things that I
like to mention, there are two more things.
One is, all of
this code is using our Azure core library as a core library,
and that library will handle retries
and a bunch of other heavy lifting underneath it,
and also does the distributed tracing efforts.
So when you're looking at your application and you
make a call to a service,
that service might make additional calls in the background,
and with the distributed tracing,
you can get a feel for what call did it end up making.
If we look at a simple example,
this is how you would look at your application.
This is a request for the blobs that we just saw.
You can drill in as a customer.
As a developer, you can drill into it and understand or
figure out what is taking so long.
You have information here to come up
with who called what and what responses that I got,
how long it took, and I can further diagnose
my library on my application.
>> Got you. So what you're showing us right now on the screen
is Azure Monitor, right?
Again, one of the services that we have inside of Azure today.
Is there anything special that I had to do to wire up inside of
my SDK or inside of my code for us to
collect this or this just happens automatically?
>> It pretty much happens automatically.
You do have to wire up the standard Azure Monitor exporter.
The distributed tracing is based on open telemetry,
which is an open standard now.
The way that works is,
you emit in your library or your application.
You emit spans which say,
this is where this operation started,
this is where it ends,
and you get this hierarchy of spans,
and may just get emitted to the open telemetry system.
>> Got it.
>> Then there's an exporter that says,
export the data that I'm receiving to my store of choice.
So it doesn't have to be Azure Monitor,
it could be whatever you choose to
do and Azure Monitor supports open telemetry.
>> Okay. That's awesome. Because I know,
in terms of ASP.NET applications,
I'm pretty familiar with using
something like Application Insights and
then I'd have an instrumentation key and now,
it instruments my code,
what is my page views or my service course,
my dependencies and these types of things.
So you're saying now with this,
I don't really have to do a lot of that stuff,
it will just automatically happen to
me or would I still have to give it the key?
>> You still have to give it
a key to do the exporter to the right place.
>> Got it. Okay. That makes sense.
>> But all of this is wired across
our SDKs and you can even use or user code can
participate in the same
spans that can get exported to Azure Monitor.
>> Okay. That sounds pretty good.
So really quickly, just to summarize,
so we spoke about these new SDKs that are coming,
where we spoke about some of the reasons
why we've created these new SDKs.
We've seen some really cool and interesting demos to
just really quickly about how these things might work.
One thing you may want to know about is,
Azure has tons of different services that are there.
Are we doing new SDKs for all of these services or
do we have a core set that we're trying to focus on right now?
>> We have a core set that we're trying to focus on right now.
They are storage, Event Hubs,
the new app configuration service.
>> Cosmos.
>> Cosmos is important.
>> Cosmos is important, yes.
>> Key Vault.
We'll be expanding that list over time.
>> Got you. Sounds great. Awesome. Hey, thank
you-all for coming on the show, I really appreciate it.
I think what we'll do is, we'll make sure
that all of these resources and
any blog posts or to-dos or GitHub repository,
we'll make sure to add them to
the show notes so that everybody could check them out.
>> Thanks a lot.
>> Awesome. Thank you-all for watching.
This has been another episode of the ON.NET Show.
We've learned how we can take advantage of
these new Azure SDKs for.NET that this team is building for us.
[MUSIC]