From cars, to thermostats, through media players and embedded controllers, devices are being connected to the Internet at a furious pace. This session will discuss and demonstrate and coding practices from live Azure customers.

4. 


http://en.wikipedia.org/wiki/Internet_of_Things

6. https://pbs.twimg.com/media/Ak5nLs2CIAA1ypg.jpg
https://twitter.com/hashtag/ipoac

7. 





10. Option Upside Downside Common examples
Battery (primary) Device can operate in a mobile
environment for extended
periods of time.
Device now has a current / wattage
budget (CPU cycles are not free).
Efficient and safe battery charging
requires sophisticated circuitry
(you won’t do it in firmware).
Mobile brains phones
Battery (secondary) Device can sustain function
through transient power
interrupts
Efficient and safe battery charging
requires sophisticated circuitry
(you won’t do it in firmware).
May have to add additional
circuitry to run while charging
Laptops
Main power (primary) Device can leverage all available
computing power (barring
thermal constraints)
Device functionality susceptible to
interruption during power supply
events
3D printer
Main power + backup Device can leverage all available
computing power (barring
thermal constraints), and
operate at reduced capacity
during power events.
Additional power management
circuitry. Need to reduce current
load during loss of main power.
NEST thermostat

11. Option Upside Downside Common examples
Ethernet Cheap, easy to install. No hard
bandwidth or framing
limitations.
Requires hard wired connection
provided by end-user. May require
additional configuration or security
enhancements to route through
firewalls, etc.
Industrial PLC (programmable
logic controllers)
WiFi Readily available on more
sophisticated microcontrollers
and embedded devices.
Requires ambient WiFi network,
and method of managing security
keys and access (including
rotation).
May require additional
configuration or security
enhancements to route through
firewalls (commercial).
NEST thermostat.
Cellular Self-contained; plug and go. Communication heavily metered –
cost of operations (CoGS) borne by
service operator.
3rd party car data logger
Local (Bluetooth,
Zigbee, etc)
Minimal cost and power
requirements.
Short ranged, require field gateway
or other “smart” edge device to
proxy connections.
iBeacon

12. 




14. 








http://contextis.com/resources/blog/hacking-internet-connected-light-bulbs/

15. Option Upside Downside
UDP • Simple; datagrams require no framing.
• Efficient on bandwidth metered links.
• Impractical to secure channel.
• Need faith or out of band acknowledgement mechanism
for reliable transfer.
• Cannot reliably support ordered data streams.
• Challenging to implement return-channel (cloud to
device) for commands
TCP/IP • Simple; minimal code footprint for RTOS
class devices.
• Can use TLS to secure channel
• Bi-directional channel for notifications and
commands
• Need to handle framing on both sides of connection (or
hard code avoidance of MTU limits from end to end)
• Firewall traversal is challenging
HTTP/S • Straightforward firewall traversal, use of SSL
for channel encryption and signing
• Built in framing, can leverage semantic
conventions (REST) to publish data
• Inefficient for Signal-to-Noise ratio of bytes on wire
• Heavy device stack footprint to implement general
purpose HTTP client stack
AMQP, MQTT • Bi-directional channel for notifications and
commands
• Efficient use of bandwidth (batching,
efficient framing, etc)
• Firewall traversal is challenging
• Client stack may not fit on smaller devices
• Evolving standards and implementation levels

16. Option Upside Downside
XML • You have more money than you know what
to do with. Enjoy another mojito on your
yacht.
• Extremely inefficient for both serialization/deserialization
time and wire encoding.
JSON • Self-describing (“tagged”) format requiring
no type identifiers. Readable by
convention.
• Need to handle framing on both sides of connection (or
hard code avoidance of MTU limits from end to end)
• Firewall traversal is challenging
Tagged /
Untagged
“standard” Binary
(Protobuf, Thrift,
etc)
• Highly efficient wire protocol with broad
range of encoder bindings for various
languages
• Can use common IDL (definition) to
generate device and cloud code
• Built in support for protocol versioning
• Implementation may not be compatible with RTOS class
device BSP (board support packages)
• Until you’ve lived through the mistake, you probably
won’t use the versioning features.
Custom Binary
(roll your own)
• You can put “wrote yet another custom
protocol” on your resume
• High degree of control over bit packing,
ordering, etc.
• Can support any device.. Since you wrote it
for that device 
• Very few implementations use code generation from a
common definition (result -> divergent implementations
with subtle differences)
• Rarely incorporate version management, self-describing
type and version fields, rich variable support (arrays,
maps, etc)
• Take on a life of their own, generating support burdens
with inertia

18. 









19. 






21. 








22. 





23. 


24. Microsoft Confidential.
Delivering on Collection
Challenges and Physics
60
50
40
30
20
10
0
1 2 3 4 5 6 7 8 9 10
80
60
40
20
0
1 2 3 4 5 6 7 8 9 10

25. 

Set-AzurePublicIP –PublicIPName webip –VM MyVM -
IdleTimeoutInMinutes 15
http://azure.microsoft.com/blog/2014/08/14/new-configurable-idle-timeout-for-azure-load-balancer/

26. 


29. 




30. 






 http://azure.microsoft.com/en-us/
services/event-hubs/


31. 




32. 




33. Focus on
optimizing these
message handlers These, probably
not.

35. 


 http://www.microsoft.com/windowsembedded/en-us/
intelligent-systems-service.aspx



http://channel9.msdn.com/Events/Build/2014/3-633

http://channel9.msdn.com/Events/Build/2014/3-634