>> At Microsoft, we aim at
building tools for developers, and in that case,
we're aiming at building tools for device developers or
IoT developers and.Net is not less than a site.
On the contrary, Abhipsa's here on
the IoT Show today to tell us everything you need
to know about a new version of the.Net SDKs for Azure IoT,
and that's immediately right now on the IoT Show.
[MUSIC]
Hi everyone. Welcome to The IoT Show.
I'm Olivier, your host, and today we have Abhipsa to discuss
the v2 of the.Net SDKs for Azure IoT. How are you Abhipsa.
>> I'm doing good thank you how are you?
>> I'm fantastic. I'm great. Welcome to the show.
That's your first appearance,
and note will not be last because you are working on
very interesting topics and
a set of tools for developers out there,
which is the SDKs for.Net developers.
First of all, before we jump into that, who is Abhipsa.
Who are you? How long have you been at
Microsoft and what are you doing these days?
>> I'm Abhipsa Misra,
I work on the IoT SDKs team,
and I've been in Microsoft for almost five years now.
>> Awesome. Well, it's good to have you.
Tell us about this v2.
We are releasing a major new version for the.Net
SDKs for developers to build apps
on devices that connect to Azure IoT,
as well as apps that will allow you to
manage your Azure IoT Hub instance.
v2, big deal, major release.
Why are we doing it?
>> We've had these SDKs around for a while now,
and we've received a lot of feedback from
customers about their experience using these SDKs.
Things that they would like changed,
things that they would like added.
We've incorporated a lot of those changes over the years,
but some of those changes would require a major rehaul of the SDK,
but those would be breaking changes
and we do not take breaking changes lightly.
Finally, we've reached a point where we've gathered
enough feedback directly from
customers through addressing issues
that come to us through site events.
Now, we have a list of things that we would
like to change in our SDK so
that the overall experience of using
the SDK would be better for the customers.
It wouldn't be faster for them to ramp
up and then get the most out of the SDK.
>> I love that. I think
it's an important thing that I wanted to stress,
we discussed that just before getting started here.
You guys are doing lots of studies is not just about
fixing issues are reported
by the users to developers using our SDKs,
you actually go all the way down to do
usability studies on the SDKs.
>> We've done usability studies with a couple of users of the SDK.
We've also worked through
incidents that come to us from customers,
and we've done those live coding sessions
where we've seen how they user SDK,
what issues trap them
over and guides them down the path that we don't want them to go.
We've taken all of that feedback from customers,
and that's been the main inspiration for this.
>> Cool. Let's look at
some examples of these main changes and what triggered them.
Let's look at the device client to start with.
>> The device client, as you know,
is going to be a long living client.
Generally, in scenarios you would initialize a client,
have it communicate with the service,
and that client would exist for a really long period of time.
It's really important that you are able
to definitively know what state your client is in,
how to recover from any exceptions that you might encounter.
Those were the two main things that we tried
to revamp in this v2 of the SDK.
Going into exception handling,
previously with the SDK,
there are a variety of exceptions that the client could encounter.
When you're trying to code up your application to handle those,
there would be a whole host
of catch blocks that you'd have to write,
and I can show you an example
that we have over here on the screen.
In here, we're trying to send
a telemetry message through a device client,
and then as you can see here,
you are catching different types of exceptions.
You also have to incorporate some logic in here to
see what exception you are handling or encountering.
>> That's the v1 way of doing things?
>> Yes. We've tried to consolidate all
of these exception types into a single type in
the v2 SDK and incorporate all of
the additional information about the exception within that.
We have a single exception and it tells you if this is transient,
if you should retry this operation or if this is terminal
and some user input is required in order to recover from this.
It really makes the code a lot more simpler,
you just have to handle the scenarios that you are aware of.
There's no unexpected exception that's popping up from
somewhere underneath some third-party
dependency library that you're using.
It makes this experience a lot more cleaner [inaudible]
>> I like that. It definitely goes along
with the modernization of.Net development,
where we are pulling up,
and it's not because it's IoT and it's good for device or
for applications to manage
IoT services that has been niche for a long time,
that's becoming more and more mainstream,
and so we have one more.Net developers coming,
and it's like this is not very elegant and not very practical,
so we are basically going along
with the way.Net is evolving as well.
>> Absolutely. There's one type that you are made aware of,
you're informed that these are
the things that you should expect your API to throw and
then it's easier for you to code your application around
it and not run into unexpected scenarios.
>> There's another scenario I'm hearing
developers talking about which
is the connection status changes events.
Things that allow to know when the connection is lost for device,
so are the things changing there?
>> Yes. The connection's status change, again,
since this is a long living device,
you would need that information to know,
is my client ready to be used right now?
Should I be waiting?
Should I close? What should I do?
We've had this connection status change call back,
but then as you can see on the screen here,
there was like a whole host of statuses and reasons that you
need to be aware of in order to figure
out exactly what you needed to do next.
We have that information out there in our docs and in samples,
but that's not what we want to present to users,
as having to discover this
in order to figure out how to write that application.
>> In the v2 SDK,
we now have something called a RecommendedAction that tells
you what the SDK recommends that you
should do based on your status of the client.
It tells you that I am ready to be used or I am done,
you need to close me and then dispose and then be done with it.
That's something that we share as this RecommendedAction.
You are not required to follow it.
If your application follows a different logic,
say that you have
a whole host of connection strings that you can use for
your device client for connecting to
service and then one of them
expired and then you want to roll over to a different one,
even though the RecommendedAction would tell you that this is
a bad credential and I cannot recover on my own,
you can modify your application to
use a different connection string that you have cache.
You can definitely override
this RecommendedAction but then
this is something that we present to you.
>> Yes. It talks to the intuitiveness
of these new set of APIs here.
One thing you alluded to in the beginning
saying that the main focus has been on a couple of
things around the handling the exceptions as
well as handling the lifecycle of the client itself,
because it's long living client.
What happens in the area of the lifecycle management of client?
>> These clients, generally,
you would initialize it then run it throughout
the lifetime of your application as you expect,
and then once you're done with that you'd close and then
dispose and that would ensure that all
of the transport layer resources are gracefully shut down and
then resources are disposed
so that you don't have any memory leaks.
With this v2 version of the client we've made it
easier for you to reopen clients after closing it,
so you do not need to
reinitialize the whole thing and start from scratch.
It also makes it easier for you to reestablish connections
because you're just closing the client and then reopening it,
you're not disposing all of
your resources and then recreating them.
>> That's interesting because that's something that especially
people were not super familiar was IoT assume,
which is the fact that devices are permanently
sending all the telemetry data up to a connection.
But then when you build an actual project,
most of the time you realize that that
data does not need to be sent every second.
You need a client that is able to send something,
shut off basically,
say nothing and then reconnect and send again.
But that connection is expensive in time,
in battery if you're on a battery-run device.
I like this change actually I
think lots of developers will love that.
This is some of
the many things that are changing the device client.
What about service clients? Anything there?
>> Service client is also getting
the same exception handling revamp
that we've done on the device client.
Again, it's going to be a more
simplified exception handling structure.
You are not getting a whole host of unknown exceptions there.
We're using the same pattern that we follow for the device client.
We've also made some improvements with how you're
initializing clients and discovering the APIs within those.
In the v1 version the SDK there were
a whole host of
different clients that you
had to initialize for the service client.
There was one for managing identities and other for running jobs.
Whole other one if you wanted to invoke methods on your clients.
Now, everything is consolidated
under the single client and then you
just have to discover the
separate sub clients are underneath that.
We are hoping it's going to make it easier for people
to find what they're looking for,
instead of having to go through a whole host of docs.
>> That makes sense. You mentioned
that we're not for breaking changes,
but that's a major release.
That means that they are breaking changes, right?
>> Yeah. As I said,
this is a major release so that
definitely a whole host of breaking changes.
When you take a dependency on this SDK for the first time and
if you use the v1 SDK before
you are definitely going to see a whole lot of errors,
but without a migration guide that guides you step by
step on how to consume the v2 version of the SDK.
It tells you this is
the previous version of the API that you were using.
This is what it's in the new SDK.
If something is been removed,
which I know is a touchy topic
and people don't like that when stuff is removed.
But we've taken customer feedback,
we've taken a look at the numbers to see what makes sense,
and then we've removed some things that
did not make sense for this whole IoT space.
One example of that being HTTP transport.
MQTD is the industry standard for all IoT devices.
That's what we've tried to put front and center.
That's going to be the default transport protocol
when you initialize any of these clients.
You also have the option of using AMQP transport.
HTTP, on the other hand,
since it follows request-response pattern
that isn't a topic that you can subscribe to,
there are links that you are opening.
It didn't really have feature parity across the board.
There were a lot of APIs that were
simply not possible to be implemented over HTTP.
There wasn't a whole lot of usage.
That's something that you've decided to
remove in the v2 version of the SDK.
That being said, we are open source.
We are driven based on customer feedback.
If we do hear from customers that HTTP
is something that they do need that is a case for it,
then that's definitely something that will revisit.
>> The v1 is not going anywhere.
>> Yes.
>> It's not no longer in the mainstream of the maintain versions,
but still if you're using it today,
and worse for you you don't have any reason to
change your code on the device that are in production.
That's something that people-
>> V1 is going to live for a while.
We are still going to put in security fixes in there.
It's still going to be there.
Unless stuff part of NuGet,
but then we would definitely encourage people to move to
v2 SDK and benefit from all of the new features in there.
>> Another last important point here is that
these changes are about the client SDKs and not about the service.
If you're using your own library for
MQTT and connectivity and
securing your connection to Azure IoT Hub,
for example, there's nothing that changes from
the hub APIs or interface perspective.
>> Absolutely. Nothing is changing on the server side,
this is just the client SDKs that
are trying to make the user experience a little bit easier.
Hopefully, people who have used this v1 version of
the SDK will find that they have a better experience with v2.
People who've been very often to
v1 SDK for some reason that they founded a little bit
difficult to onboard or else
they did not find some feature that they were
looking for will hopefully also
have a better experience with the v2 SDK.
But yes, nothing's changing on the server side.
>> Awesome. Bibsha,
great overview of these changes.
I'm sure people will be more than curious to go and check it out.
You can go and read the blog post that the team has
put together where you have all the details about these changes.
Feedback is more than welcome,
because you work based on feedback.
We say that it's the beginning.
>> Yes. Absolutely, we are 100 percent feedback-driven.
>> What's the best way? Is it GitHub or
developer should go and file issues and provide feedback?
>> Absolutely. We do have an open discussion
on our GitHub page about
all of these new changes that we brought onto v2.
Definitely if you have any feedback once you try it out,
let us know and then we'll get working.
>> Awesome. Well, you know what you have to do?
Thanks for watching this episode, Bibsha.
Thanks for coming to the show again.
>> Thank you.
>> Looking forward to see you again.
>> Thank you.
>> Thanks all. Bye.
[MUSIC]