>> A brand new SDK that will work for Azure Table Storage
as well as Cosmos DB that follows all the
latest and greatest C-sharp conventions,
check out the new Table Storage API on ON.NET.
[MUSIC]
>> Hello and welcome to another episode of ON.NET.
I'm Jeremy Likness.
I'm a Program Manager for .NET data.
On today's show,
we're going to talk about a new SDK for Azure Table Storage.
I have with me Christopher from the Azure SDK team.
Welcome Christopher.
>> Hi.
>> Can you tell us a little bit about
what you do with your team and
then we'll jump in and talk about Table Storage.
>> Sure. We work on
the client SDKs for a number of Azure services.
My team in particular work on the .NET SDKs,
but we have teams that work on
a suite of the more popular languages like Python,
JavaScript, Java, C++, etc.
We work on what we call the new Azure SDKs,
which are the latest
and greatest version of our SDKs that conform
to our latest set of guidelines and design principals.
>> Awesome.
That's what I was going to mention
as I've understand, these SDKs are being rewritten
based on a new set of guidelines to make them more,
I guess, idiomatic with C# and easier and fluid to use.
That's really what we're going to talk about today is that
SDK specific to Azure Table Storage.
Can you tell us, as a developer,
I might be able to use SQL server.
I might want to use Cosmos DB,
I might want to use Table Storage.
What is unique about Table Storage
and what scenarios would I use that for?
>> Table Storage is a service
that's been around in Azure for quite a long time.
It's a simple example of a NoSQL database essentially
where there's no defined schema
that you have to stick to for a given table.
Any generalized storage
that you want to store tabular type of data,
Table Storage is a great solution
and it's generally popular because it's readily available.
It's pretty simple to work with and it's fairly cheap.
>> Awesome.
What are some of the highlights of the new SDK?
>> In the new SDK, one of the highlights that we added
recently is the ability to do AD authentication and authorization,
which for as long as Table Storage had been around,
it never previously supported that.
That's something we recently added
specifically when you're targeting the storage endpoints.
It doesn't yet support that for Cosmos,
but that potentially will happen in the future as well.
Now you have the ability to use,
in the Azure SDK we have an abstraction called token credential,
which is a consistent,
unified way to deal with that AD credentials and
authorization across all clients that are
built according to the new design guidelines.
It makes it simple and consistent
no matter which client you're working with.
You have a very familiar way to deal with Azure AD Authentication.
>> That's a good point that you brought up.
There's two different flavors.
I've actually worked with Table Storage in the past.
I made a link shortener,
that uses it and I loved the interface.
But there's basically Azure Storage
that has Table Storage as a feature.
Then there's Cosmos DB that has a Table API as a feature,
and this SDK will work with both
except for the authentication piece.
Is that correct?
>> That's correct.
There are some other minor differences
that you can find in the documentation with regard to features
that are only relevant for storage.
But generally speaking, in terms of
the actual table operations dealing with entities in the table,
the APIs are identical.
When you're using the storage or when you're using the Table SDK,
the difference between them is totally opaque, essentially,
depending on which connection string you use
or how you're addressing natural resource,
that's the only difference that you would note in your code.
In the example of you wanting to target one or the other
and you may say you want to start with storage tables
because that's cheaper and easier for you,
and then you want to upgrade to some of the premium features
and performance benefits you get from Cosmos later,
you can do that without changing
anything in your code except for the connection string.
>> Very nice.
Do you have any examples of what
using the SDK looks like or how we would approach that?
>> Yeah. I can show some sample here that shows you
generally the auth mechanisms that you're used to
and then showing you what it looks like
when you deal with the token credential authorization.
These are samples which are available in
our GitHub repo and also on the dark side.
But essentially, this is what most people are used to
when they're dealing with Table Storage
is dealing with a connection string
where you're having to deal with storing secrets
or configuration in your hosted instance
and then shared key credentials
similar to that where you have
just a key secret that is combined with your resource,
your I2 to authorize yourself to the table.
Then SaaS is the other one that's familiar
where you want to delegate permissions to a third party
where they don't have your secret,
but they have essentially a time-boxed token
that allows you to have access to the table with
whatever restrictions you want to impose in terms of timeframe,
permissions, granted, that sort of thing.
Then token credential here you can see the code is much simpler.
Essentially, if you were to use say,
our default Azure credential,
which is one of the popular default
Getting Started options for Azure Identity,
which is another library we own as part of the SDK team,
you essentially use this credential.
If, for example, you're in a development environment,
it would by default fallback to credential
such as CLI credential or Visual Studio Code.
If you're login to Azure through those apps,
it would automatically work in a developer environment.
Then if you're in, say,
a managed identity environment on a hosted app,
you would automatically default
to that as your Azure auth provider.
It's really ideal for A,
you don't have to ever deal with connection strings
or secrets in your code
and never have to worry about say,
accidentally shipping your secret
if you're working with it locally,
like say uncommenting it to do your development work
or debugging work
and then later on you deploy it
and everyone's had that scare
where they think they've checked
and they actually have.
Now you don't have to worry about that,
and it just works in both environments seamlessly.
>> That's very cool.
This will just think capsulated however,
you're going about logging in and getting the token,
and then it's just managing the token
and carrying it through, I guess.
>> Exactly. If I just follow that link
to the Azure Identity library documentation,
and on this page you can see an example
of the credential flow that default
Azure credential offers where by default
this is the ordering in terms of credentials that'll be tried.
The first one that's exceeds essentially
is the one that will be used.
There are options in terms of being able to disable
certain ones of these and have different effects on the behavior.
But generally speaking,
this is the default progression of which credentials will be tried.
>> It should enable my code basically to be reused
between my development machine.
It'll be valid in CI/CD
and then it can be valid in the target environment
if I have a managed identity, for example, setup?
>> Exactly.
The nice thing about the way these credentials work is,
for example, if you're doing Azure CLI authorization,
you just drop to the CLI
and login with whatever account you want to log in with,
using whatever secrets that you have
locally or any cache credentials,
and then you can easily switch
between trying different identities and so forth.
Then once you deploy it,
you're using typically managed identity,
which would be controlled by your environment,
so you don't need to think about that
in terms of how you write the code.
>> Anything else you wanted to share about this new SDK?
>> The only thing I would like to share is
if you're coming from the old version of the Table's SDK,
we do have a migration guide
and that migration guide is available
across all the major languages we support.
I'm showing here the example of the .NET migration guide.
If you're coming from microsoftazurecosmos.table,
this shows you some of the common scenarios.
What the equivalent code would look like
from one versus the other.
If you're looking to make that migration,
we'll try to make it as easy as possible for you.
>> If I have something like my link shortener,
which I don't think I've touched the code in probably two years.
Is that something I should be concerned
about migrating to the new SDK
or is this more for making it easier
if I'm doing ongoing maintenance
and working with it on an ongoing basis?
>> Generally speaking,
you shouldn't need to worry about upgrading it
if you're not actively developing the application.
If for example, you're doing something and you thought like,
I'd really love to eliminate secrets from my app
and not having to store secrets
or deal with Key Vault to store my secrets,
that maybe a motivator for you to upgrade so that
you could use the token credential authorization method.
But generally speaking, I'd say if you're starting a new app,
you'd want to go with our latest package.
Then if for developers that may be familiar with the old syntax
in the Cosmos package, it's not uncommon.
I've been working with some various teams
that are doing this migration,
and they've asked questions like,
this is the way it used to work,
but this is the way this code used to look in the old package.
How would I do this in the new package?
There are some definite differences that we think are better.
But if you're not familiar with the new package,
you may want to refer to the guide,
to determine what does that code look like
when you make the change.
>> Very good.
Well, the reason why I use this for my link shortener is
because Table Storage is easy to set up,
it's easy to use,
it's easy to code against.
It's exciting to see that there's a new SDK that supports
both the storage option as well as the Cosmos DB option.
We will place a link in the show notes so that
you can refer to that migration documentation and grab that.
Christopher, thanks for coming on
and sharing your new SDK with us.
>> Thanks for having me.
>> Awesome.
[MUSIC]