 So before we start I'd like to get to know you of the audience a little bit more So my name is Pierre. I'm developer in Azure IoT So we work mostly on the cloud side and I do SDK work so both on the device and the service side to help stuff connect to Azure IoT What do you guys do in general are you more on the embedded side or cloud side? So who's embedded? developer Right low-level bare metal stuff cool What about cloud architects and you do everything cool Okay So more of an embedded ground who is doing well, I guess everybody's doing embedded Linux Anyone never touched them Microsoft embedded thing. Okay, that was a while ago Used to be used to have a pretty That back in the days. No way a window C was was a nice play at some point We do have a thing called IoT corp. That's definitely not the topic of today's talk because Linux crowd Cool shall we get started Yeah, I guess I guess we're gonna get started. All right So welcome. Thanks for Sticking around. I know I'm the last thing before lunch too. So I'll try to finish on time if not early We're gonna be talking about Azure IoT in general. It's going to be another view I will get into a little more of the specifics of that component called IoT hub Which is the thing that you we wish you would connect your devices to and So Basically the agenda is and answer these two questions How are we thinking about connecting devices and hopefully making it easy? If it's not easy enough you got to tell us And the other thing is and that's a question we get from a lot of customers It's like we understand that when we connect things magic happens What's magic and what do we do once we have all these devices connected? So we'll try to cover that a little bit too Let's dive right into connecting stuff and So these little blue squares, let's say these are devices They're gonna have to talk to something and so one of the first components we have been working on are Field gate what we call field gateway and protocol gateway Field gateway the ID is really Your devices are not or cannot connect to the internet Maybe because they only speak Bluetooth or Maybe because you have security concerns or you know, whatever your reasons are so we need an on-premise solution That helps you that that can connect to devices and then be a single point of contact between all your devices and The cloud and so we build an SDK for that the field gateway SDK The second thing we figure is that you might have already have devices Connected to the internet and these devices probably speak some sort of protocol So I'll go in the details of the protocol later with IOT hub with support a few of them, but maybe You have your own you you speak a protocol that we don't support yet And so it'll be ideal if we could have a solution running in the cloud in our data centers that would speak your language and then trend Transform that into stuff that I Azure IOT can understand and that's the goal of the protocol gateway the main thing and I think that keeps me busy every day is Azure IOT hub and this Piece of clouds cloud software is basically a huge data ingestion Mechanism it has endpoints for you to send billions of messages from millions of devices And this is one of the things we do kind of well in Azure. It's a scale We have so so we built Software that scales and allow you to send tons of messages. And so we are going to get all these messages and for and present them to you and your cloud your IOT back end into a more readable and scalable manner And I'll get into the details of that and of course because it's Azure Azure is like a big Lego set for cloud architects We have a bunch of stuff that you can connect directly to Azure IOT hub to Use whatever data you're sending whether it's stream analytics Machine learning things if you have trained model you want to feed sensor data to to you know Do predictive maintenance things like that? So we have a bunch of building blocks that you can assemble together to build your own IOT solution And we'll get into some of the building blocks and some of the stuff we do to help you discover all these building blocks later But we are gonna start at the on the device side and we're gonna talk about the different primitives that we have to To talk to Azure IOT hub All right, so in order to talk to Azure IOT hub the first thing that we need from you is a device identity and and so The device identity for us is basically two things. It's a unique identifier and It's a secret that can be used to encrypt communications between your device and and the cloud and this is one thing We're a little bit strict about Everything has to go over TLS. We do not do I guess this is gonna get a few chuckles, but we do not do unsecure stuff So it has to be over TLS So Whether we use symmetric keys And so you start them in the registry in the device registry and then you find a way to start them on the device For example in a TPM and then you generate a token and you encrypt that TLS connection with the token Or if you're using X5 or 9 certificates We need to share some sort of secret in order to secure the connection And we'll get into the registry a little bit later Now once we have Yeah, one more interesting things We actually don't share one secret. We share two secrets so that if one of them gets compromised you can roll the keys and And and keep using your device without having to taking it offline or worry about About maintenance ascending a technician or something like that Obviously you can you we have APIs so that you can create devices one by one But we do like to brag about scale. So we also have bulk APIs that enable you to Provision, you know as many devices as you want in in in one API call Now now that your device has an identity it's gonna want to connect to Azure And I have a slide later, but I guess I could have started with that we support three different IOT protocols IOT ish HTTP not really IOT, but it's got to be there It's nice because it allows to punch through firewall doesn't scale at all. So You can do HTTP if you want that's not what we Recommend we are much more fans of mqtt and amqp And so whether you're talking one of these three protocols You can connect your device to directly to Azure IOT hub if you're spinning something else I don't know co-app for example, you're gonna need a protocol gateway or a field gateway And once we have this connection So the first and the obvious thing most obvious thing we can do is is get messages from From your devices and it can be any sort of payload. It doesn't have to be structured. It can be binary. We don't look at it so You can send messages and these messages will have a payload and what we call properties and We implement properties in a mqtt and HTTP and different layers of the protocol And these properties will be used to route messages to the different endpoints on the cloud side the other thing we can do is Send commands send messages to the device and basically it's the same message except it goes in the other direction We often use D to C as in device to cloud and C to the cloud to device To refer to telemetry and and and commands Microsoft does love its acronyms You'll see a lot of those So that's the basic stuff everybody does it so we had to add more stuff The another thing we introduced is a primitive called device twin and What the device twin is you can think of it as a document that lives in in in a separate in in a store in the cloud and that has Three sections the first section is known only to the cloud application and its tags It allows you to categorize devices so that then you can query your millions of devices and say give me all the temperature Sensors for example, I'll give me all I don't know the devices on the third floor of the Hilton Portland But that leaves only on the cloud what's really being shared with the device are two other sections called desired and reported properties and Basically the way it works is the cloud can your cloud application can set desired properties and your device will get Notifications. Hey you have a new desire you have a new thing new desired property that changed and your device itself can read these desired properties or get notified for this desired properties and write to reported properties and Then the reported proper when reported properties change your cloud applications get notified and you can see how the device reported something new and The idea is that it complements the telemetry because you're like well things going one way things going Why have two of these well the twin is a document that lives in the cloud Your device gets disconnected the twins still here So you have some sort of last known states that always exist there that you don't have if your device is disconnected And you have to send a message to read something The other nice thing you can do with twins is run queries And the idea is that you want to find so I was saying you want to find all temperature sensors You can do that with obviously tags But then maybe you want to find all the temperature sensors that are reporting a temperature over, I don't know 50 degrees And you can and so we have a query engine and basically this is starting to a no sequel database and and and you can just you know start Looking at all your devices and and finding stuff about them that way So that's twins telemetry commands twin We also have one other thing which is device methods and It's yet another way to talk to devices This way is a is is is a little different from the first two. So basically Whether it's telemetry commands these are message that goes into queues and then the device of the cloud reads from these queues and And and so it's a very very asynchronous Also, you can manage to do bidirectional communication like request response Be with telemetry and commands, but then you have to match, you know, you have to correlate what's going in what's coming out It's not it's asynchronous. You could have hundreds of messages queued before you get your responses. So And same with the twin It's just a document and it gets read and and written to but it's asynchronous the idea between behind device method is I Need the device to execute code right now and give me the answer for my cloud application So it's kind of a synchronous request It's not synchronous because it goes over the network, but it's synchronous request So your device has to be connected and you're like give me the last ten lines of your log file For example, and this goes to the device and in the same age. So in the same HTTP request So your Service is talking to Azure IoT hub sends an a sends an HTTP request to Azure IoT hub and Then wait for the response and during that time IoT hub is going to take the request Send it to the device get the device to execute some code The device will send back the response and you'll get the response in the HTTP response itself So it's like a very direct way. We call them direct methods or device methods It's a very direct way to ask the device to do something But the caveat is it only works is your device is connected So if you want to queue stuff for execution later, you can you can use commands But if you want the device the response right now, you have to have device methods Another thing that you may need or want to do with devices is upload large amounts of data For example, your device has been disconnected for a while. Let's say it was a container on a container ship It's been at sea for six weeks Coming into the point. It has tons of telemetry data You could argue that sending like fifty thousand messages one by one of two hundred and fifty six K Might not be the best way to do that You'd rather upload a big blob of data and that's what the file upload endpoint does for you The device is says I have a bunch of data to upload give me a place to do that Service respond. Hey, here's the place where you can do that and your device sends the data and Then you can read that data that blob of data from from your service And the nice thing that this thing does is that your device doesn't have to store multiple secrets for multiple Endpoints like the place we are going to upload the file and the way you're talking to IOT hub IOT hub is brokering everything for you. That's the device facing endpoints. So I mentioned that MQTT MQP and HTTP and protocol gateway if you need to support something else If you need to support something else, we do want to hear about that though We started with a MQP and HTTP we added MQTT Per customer request and that's one of the fun things with Azure IOT The team I'm a part of is that we're very much talking directly to the customer If you're finding an issue in our github because all our SDKs are open source, of course If you're finding an issue the dev who wrote the code is going to reply to you, which is not always the case at Microsoft Company's changing Now that was the device side, let's move on to the the back end and on the on the back end of course you have kind of symmetrical endpoints to what we have on the device to Get your telemetry get send commands Get feedback from commands. So that's also something we can do So that's only supported with the MQP because that built in the protocol Which is the idea that the device accepted or rejected or abandoned the command that you send The file upload notifications, of course And device management endpoint that allows you to create and change device identities and and change the state of the device twins A couple more things though on the cloud side and by the way, I just I just want to make it clear It's symmetrical, but it's it's presented We can get into the nitty-ditty gritty details if we have more time at the end It's presented in a different way. So if you have a million connect device connected We're not giving you a million of these endpoints, right? We're giving you cues where it's easier to read data from a million different devices That way we do the scaling and you worry about the application Sorry that was side note going back to to these endpoints one thing we added in the in the back end with APIs to schedule tasks that are going to do stuff with your devices whether it's actually Changing desired properties When we're talking about twins or executing device methods and the idea is that Let's say you want All the pressure on the temperature sensors Let's stay on the temperature sensor. You want the temperature sensors to all Reset or accept a new desired property at 2 a.m. two days from now and You can you can you can schedule that and then IOT hub will take care of that job for you connect to all the devices to which this This task is applicable to and and and will make sure this task runs correctly And then it will give you a nice report saying hey, this is all the things that work This is all the things that didn't work. We think that thing is not connected Etc. Um So that's that Time stamping. Yeah, everything's time stamped all the all the messages that go back and forth all the actually methods Won't have a time stamp But all the messages that you get are are time stamped and all the results will have time stamps on them They're UTC time One more thing that we offer on the on the back end of course is something called operations monitoring And what that does is it allows you to monitor everything? So different levels of events Pertaining to what is happening with your IOT hub like hey, there are 50,000 devices with unknown identities trying to connect What's that? or Hey, you're about to get throttled Because you didn't pay for it So we give you alerts of what's going on with your IOT hub whether it's general statistics or just errors that enable you to programmatically scale your IOT hub or Or change configuration of your IOT hub if you need to and you could say hey, what the hell? You told us you are scaling automatically and now you tell me I have to do it and the reason is We don't want some Malleficient person or not Malin not well meaning person to manage to hack some of your devices or connect and just try and deed us your service and Because basically what you're paying for is a capacity to ingest and send messages and so if that guy if if one guys owns your device it could potentially throttle you and so You we don't want to break up your bill and say hey, sorry you got hacked a million dollar, please That would add insult to injury So instead of that we just say hey you're getting throttled you need to watch this And then you can decide how to react to that you're like yeah, this is normal activity Please give me more units or you could say this is not normal Please do not scale and do not bill me for Inordinate amount of money So that's what operations monitoring is for a New thing we rolled out Late last year, so I guess a couple months ago is is the ability to route messages to different things different services in On on the Azure cloud and the reason is before all your telemetry messages We are getting randomly assigned to some what we call partitions Which are basically cues that you can read from and their persistence so that you you can move a cursor and go back and forth in your messages and we were Kind of telling you well read that from the cues and then figuring out figure out where you want to send it You know to stream analytics or to some machine learning thing or to storage our databases And we got the feedback that hey, that'd be nice If we could do some basic routing ourselves and you could configure endpoints and then based on message properties We would do the routing so that you don't have to write code for that. So that's what it is And I've included way more stuff in the presentation links and you can download everything if you want to including sample codes That show all of these primitives and all these things I talked about telemetry twins They're just one line of code API So yeah, we have Bunch of SDKs for devices. I'm going to go back to that you can manage device identities millions of messages Route messages to endpoints upload files store and query device date Execute code monitor operations that that's what IOT hub is for now How did it get started with IOT hub? For you just go to the Azure portal create an account and spin a new IOT hub and the best part of it is it's free as you start the basically what we have it is a SQ system where based on the capacity you want you have to pay more or less money The basic skew allows for a few thousand messages and and I don't remember how many devices I think there's there's a cab, but it's allows you to experiment entirely for free all our SDKs are Free and open source and available in github So you can even if you want to run your own little automate home automation project and it's free go for it As you scale you're gonna start wanting to switch to some more Paying skews, and then you can add You can multiply these skews as you want to scale dynamically. So you really we really encourage you to Start low see what your plan kind of plan for your data the amount of data you're going to send and Pay as you go. That's the cloud ball No, the QoS is the same no matter what you pay so you get you get the best stuff even if you're on the free skew The SDK so I'm part of the team that write the SDKs for IOT hub And obviously we went where our customers are So lots of Android Linux embedded Arto's We do have windows SDKs Now I'm not the one that are giving us the most work But we are where you guys are and I was just talking to the Zephyr Fox earlier and we're going to be looking at that too. So If you go to our SDKs and you are not finding the platform you're using and you want us to build that for you Just let us know on the github As far as languages go our most popular and most portable SDK is of course the C SDK We have very good embedded C engineers that provide Open-source SDKs and by the way the SDKs include AMQP and MQTT libraries. So if you're looking for portable embedded C MQTT or AMQP libraries, you can get that from us even if you're not using Azure IOT hub just say We do Node.js. That's my thing We do Java.net Python If your thing is not on there same thing, let us know we look at building it And the way you get the SDKs is obviously look in your favorite package manager Repository with our 8 10 p.m. Maven APT NuGet if you are into that Or you can clone directly all the source code on github The gateway I mentioned the gateway same thing with our gateway play right now is an SDK We are not giving you a device. We figure you already have that device, but you may want to write code For that connects to devices and then streams everything to IOT hub gateway SDK It's C-based. So it's very embedded embeddable. I would say It's It does have connectors that allow you to write modules for the gateway in Java node And I'm guessing that net yeah.net. It's a sister team from mind. I'm a little less Aware of that. We did have a talk earlier during the conference about the gateway. I included the link at the bottom Now maybe you don't have a device and if you don't have and or maybe you are making a device and you want to make sure or advertise that your device is Can connect to Azure IOT hub so we also have that a Partner program and a device catalog and if you go on that address catalog that Azure IOT sweet dot com You can find literally hundreds of devices that we have tested and we know our SDKs work on those and they can connect If you're building devices and you're interesting in being there, you also have a link to sign up and it's really a quick thing So there you go device catalog now We talked about devices how to connect to these devices We how to connect to IOT hub with these devices Let's maybe does anyone have questions about the first part Let's do a little Q&A first before we jump on that. I did put everybody to sleep That's what I was afraid of So it depends on what you want to so I'm assuming You're talking about the CS DK Okay The it depends on what you want to build the way we built the SDK is we separated the the protocol stacks from the high-level primitive APIs and so Sure, you can build everything and it would take a few kilobytes. I think you can get quite a few kilobytes You could you can cut the protocols you don't need and then it'll be building even less We have been running our SDKs and Arduino's and yes ESP8266 and devices like that. So I don't have the exact number. I know it's a few K's of memory Building the SDK is another thing because we are macro heavy No, it gets it needs quite a bit of memory to build that thing, but once you're deploying it's only a few kilobytes And if you are looking for more precise stuff, let's talk after and I can connect you with the right guys Within the limits of the protocol, it's whatever you want to be I'm gonna say meaning You have an HTTP a device that connects over HTTP every Two days we're going to get your connection every two days and that's it and the request is as small as you want to make it if You give up the device methods in HTTP. Yes If you have an always connected device with a MQP or MQTT It depends on the keep alive you set on in these protocols We do rely on the protocol keep alive the one thing I will say if you want your device to stay connected and I think we're working on changing that any mistake I'm gonna be Purposely Conservative here is if you want the device to stay connected I think the Azure load balancer right now requires you to do something with your socket every four minutes I'm gonna say Because after if you don't get anything after four minutes, we are basically considering your thing has disconnected so we cut the connection Does that answer your question, okay? Yes No the device so Each device has a unique ID Each device should have a unique secret I don't think we're enforcing this So if you want to put the same secret on all the devices is your bad call But no each device should have its own secret And one thing that we are not covering yet for transparency is how to get this secret on the device We're certainly looking at a bunch of things and trying to make this easier for customers But right now it's still the customer's responsibility to provision that secret on the device and to find a secure way to store it on the device We have some demos and And code that shows for example how to store it into a TPM on the Windows IoT core Stuff because we have good TPM support and IoT core If you're working on these topics we have engineers working on these topics too And we definitely want to hear about that, but we don't have anything from C to offer right now for provisioning questions, all right Now Azure I mentioned before it's that big Lego set for cloud architects You have a bunch of different components databases stream analytics machine learning Hosting mechanisms whether it's for VMs or for apps serverless computing if you want So you can really build your own thing connect these Lego bricks together and build your own solution And that's how we started we were not prescriptive about what should be the cloud the IoT cloud application architecture at first we did realize that A lot of our customers had no idea where to start on that and so what we did was Build what we called pre-configured solutions and what pre-configured solutions are is basically a default architecture to solve one One of the many problems the industry would like to solve and so we built two of those one of them is predictive maintenance And the other is remote monitoring The I and I'll get into the details of that Again, if you're like to see some patterns Additional pre-configured solutions we have folks working on that. We want to hear about it But what these guys give you is basically a file that you can upload to Azure and will initialize Everything for you the web jobs the scrim analytics processing the machine learning And the things that you want that you would like to use and we back these with real customers I don't think I remember who is doing remote monitoring the predictive maintenance I like because it's world's Roy's airplane engines and I like airplanes so That was pretty fun. And so what we give you and Understand this might not be very readable from the back but what what it gives you basically is is All it provisions all these components for you so that in a few minutes You can connect devices to these pre-configured solutions and see stuff running in the case of remote monitoring What we have is basically a web app here That's going to present to you a dashboard with the list of devices the data that is being sent by devices and some Stream analytics here that are going to be able to do a normally detection Basically, you're saying hey if this sensor goes over this threshold or if these sensors meshed mashed up together with some mathematical formula get to that point you can raise an alert and then do something with it in your application and And of course in order to store all the data that's being sent we're also provisioning storage And and that will enable you to go back and look at your data in time So that's what the portal looks like You have a bunch of devices you can add rules for the anomalies you want to detect and and that's the dashboard you get With little nice little graphs and a little map. Of course, it's the Seattle area, right? That's where we live and So you get that literally so if you go to azureautsweet.com you click on remote monitoring and 15 minutes later you have all that built for you and you can play with it It is a reference architecture Demo call it what you want all the code source is open source, of course You can customize it the way you want We are not selling this as hey if you want to do remote monitoring Here's how our supported and packed up solution for you, right? This is an example of how you would like to build this thing Same for predictive well same difference predictive maintenance In that case we illustrated how to run machine learning on the data you get so You find the same basic building blocks, right you get devices over there and we provide Then okay, and we we provide a device simulator in case you don't have Devices to connect and that goes through IOT hub you have stream analytics job That allow you to run queries and the data route the data on different endpoints so that you still get You know these nice little graphs But we also use this data into a job that runs the Bruns your the current data on the trained model that you established using the Azure machine learning Component and so and that way you can detect You can detect What are predict what is going to happen based on the sensor data and the established model you have so typically And then of course we have a web app to manage that Database to start the data This is kind of the same as the the remote monitoring stuff and what it looks like is this so you get your nice little graphs and and Here what you probably cannot read is remaining useful life on the engines and basically what we did was we took the maintenance logs for these engines fed that into a machine learning algorithm and Now we're looking at the data of That is coming in real time from the sensors and we're like hey Last time I saw this pattern 20 hours later the engine did that part of the engine failed or performance started degrading or something like that and so We enable Rolls-Royce to detect the potential problems before they happen So Yeah Okay, not the same. That's the Azure machine learning studio. That's where you you define the different components of the machine learning algorithm you want to use and how you Where you upload the model train, etc. To be honest, this is I Wish I was more proficient with that. This is a little far away from my daily SDK development tasks But like I said, everything's in GitHub. So you want to look at how we are doing that just go for it And now we're into not like the end of the talk and announce time and time We did roll out or announce 4 CES a connected vehicle platform And the idea behind the connected vehicle platform is we want to be talking to car makers Because we realized that for many car makers and funny enough the first one with a French one funny for me, I guess the Cloud car manufacturer don't always have an idea of what services and how to Offer customers and how how we can build these intelligent services for customers when it comes to when it comes to connected cars And so we are we said well, let's let's do the thinking together and roll out a partnership We're going to build solutions for connected cars together So that's coming If you want to be a part of it, you know Come see us talk to us on the github or wherever We also hold out a security program Microsoft security very long love hate history The Azure folks learning working in security are pretty impressive if you ask me, but the the idea is that Same thing customers are like hey, you know, we understand. It's a big deal. We watched the news last year How can you help us do that? And so we have a program where we partner with security companies security firms and we develop best practices and White papers and we talk to customers about how to secure the whole IOT solution. I included the links for that To And that's the end I'm actually a little bit early So you guys get a head start for lunch or we can do questions. I'm gonna stay here and do questions Anyway, thanks for your attention and for listening even though I speak in a very monotone voice Um Questions yes Yes Extended the customer absolutely Yeah, yeah, the goal of power be power BI is yet another Kit if you if you will buy Microsoft that enables customers to build dashboards Yes, and And and so yeah power BI can read from very different, you know data sources storage Obviously stream analytics and and so you just configure the power BI solution for that And and it comes pre-configured in the pre-configured solutions Haven't had one Microsoft one job at Microsoft in that talk I cannot believe that well you guys have been an amazing crowd. I've been in the booth all day yesterday and We were very well received. It's really cool Kind of surprised still How does that work? That's kind of the secret sauce What is going to limit well we don't have a bandwidth limit try us Well, that's the thing So so that the question is about is about the price. All right, so Azure has a really Nice tool and I think I may have mentioned the right so the price calculator. I think it was before that Right, we have a pricing calculator and based on and so in that pricing calculator You select IOT hub and you say I want unlimited devices And I don't know four million messages a day and it says that's that much And then you have it's that much per unit and then you can add units. Thank you so you can Yes, like I said try what one Azure is one of the Most under estimated thing at Microsoft One thing I like to say So we understand scale. There are not that many cloud providers Out there that understand hyperscale marketing term the way we do We have more data centers All over the world running Azure and deployed then AWS and Google combined So whenever we're talking about streaming capacity to Ingest I'm like yeah try us We want to find out so that we can scale even even more It counts the way we count that is in Message units a message unit is 4k. I think And you buy them by the million. Yes Yep Well, we're part of the MQTT five working group. So I guess I guess we can say we're looking at that I don't want to announce anything or You know, but obviously we're working with the industry Standard bodies and and groups To be honest We would like the customers to not care about the protocol We think if you want to develop smart IoT stuff, we need to get you To trust us we'll figure out the plumbing for you concentrate on, you know, the higher level primitives where you're gonna build the intelligence We started with HTTP and a MQP MQTT was obviously big feedback We had a bit of an experiment on our first device management beta With LWM2M and a version of co-op that was running over TCP instead of UDP I didn't work out well So I don't know if we can make any plans or commitments or whatever, but we're Obviously MQTT is up there as far as industry is concerned Yes This is going to be a bad answer We let you guys figure this out Bad answer, sorry our software just Runs on the device and assumes that we have some sort of connectivity We are not trying to be smart about punching through firewalls and things like that We use the configuration the parts you give us And that's it. Does that answer your question? So No, it's pretty much on your own. We do have one thing and that might be attached to your question But we do have one thing one little tool called IoT Hub Diagnostics So if you're wondering, hey, am I going to be able to connect from this network or that network? You can just download download this little tool run it and you'll test all the you give it You have to have an IoT Hub so you can start with the free instance you give that tool the connection string, which is the the Configuration basically for your device to connect to IoT Hub and what this thing will do is create a fake device and IoT Hub test all the protocols and Give you a nice little report saying hey AMQP didn't work, but AMQP of our WebSocket work Or and it goes that it does that for AMQP MQTT and HTTP Yeah, did I mention we do WebSockets We do AMQP and MQTT over Regular TCP sockets and over secure WebSockets There I said that reads one minute. I need to change my glasses one minute, right? Three okay, I really need to change my glasses. Thank you Were you expecting something else from this talk? Did I leave questions and answered? Were you surprised at all with anything? Yes, right. Well, I will go back to the Microsoft booth that we have in the sponsor showcase for the Well, I guess it's closing now, but I'll go back there if you guys want to have more of a private talk and Thank you very much