name: inverse class: center, middle, inverse layout: true .header[.floatleft[.teal[Christopher Biggs] — IoT at Scale].floatright[.teal[@unixbigot] .logo[@accelerando_au]]] .footer[.floatleft[.hashtag[YOWData] Sept 2017]] --- name: callout class: center, middle, italic, bulletul layout: true .header[.floatleft[.teal[Christopher Biggs] — IoT at Scale].floatright[.teal[@unixbigot] .logo[@accelerando_au]]] .footer[.floatleft[.hashtag[YOWData] Sept 2017]] --- layout: true template: callout .header[.floatleft[.teal[Christopher Biggs] — IoT at Scale].floatright[.teal[@unixbigot] .logo[@accelerando_au]]] .footer[.floatleft[.hashtag[YOWData] Sept 2017]] --- template: inverse # IoT at Scale ## or, "From Little Things, Big Data Grow" .bottom.right[ Christopher Biggs, .logo[Accelerando Consulting] <br>@unixbigot .logo[@accelerando_au] ] ??? Hello everyone, I'm Christopher. And today I want to tell you about how I do Data Mad Science with IoT. --- layout: true template: callout .crumb[ # Prelude ] --- # Who am I? ## Christopher Biggs — .teal[@unixbigot] — .logo[@accelerando_au] * Brisbane, Australia * 20+ years in IT as developer, architect, manager * Founder, .logo[Accelerando Consulting] * Accelerando is a "full service" consultancy - chips to cloud * ***IoT, DevOps, Big .sup[†] Data*** .bottom.right.tiny[ .sup[†] Actual bigness may vary] ??? First a little about me. I've been building gadgets since I was a teenager. I've you've seen the movie war games I was basically that kid... except I didn't have a girlfriend. I worked for a network equipment vendor during the first dot-com boom, and then I spent some years at an internet security startup until the global financial crash fell on it. After that I led a team of 60 developers doing e-commerce websites, until a about a year ago I started my own consultancy specialising in the Internet of Things. We've just moved into a mixed use facility in Brisbane, where we have space for startups to come in for a day or a week and work in a comfortable office environment but also with a huge range of parts and tools at their reach downstairs in the Mad Science Zone. --- # From little Things, Big Data Grow ## "Internet of Things" (IoT) At Scale * .yellow[**Why Even IoT?**] - my personal motivation * .yellow[**Chips to Cloud**] - the journey from sensor to senses * .yellow[**The Air Gap**] - connecting wireless devices to the Internet * .yellow[**Data Tributaries**] - follow the data from droplet to ocean * .yellow[**Making sense of it all**] - Managing and visualising IoT data ??? Today I want to talk to you about the big data aspects of the Internet of Things. By that I mean how to start thinking about devices by the thousand or even million. It's absolutely fabulous how easy it is to build internet connected devices today, but there are are bewildering array of tradeoffs to consider when you want to scale up your fleet. --- layout: true template: callout .crumb[ # Prelude # Overture ] --- template:inverse # Overture: Why Even IoT? ??? But first, I want to ask what's the point. Why would we want to fill our homes and cities, and even our bodies with connected sensors and other devices. --- ### *"Don't ever **invite** a vampire into your house, you silly boy. It renders you powerless."* .right[-- "Max", *The Lost Boys*] ??? I mean, there are some drawbacks. To some people, the idea of surrounding ourselves with cameras and sensors that are always connected to the internet, and over which we have only partial control sounds frightening. It's like that future where the location and behaviour of everyone is being tracked at all times. (**Hold up phone**) --- ### *"The '**S**' in **IoT** stands for '**Security**'."* .right[-- Absolutely Everyone, *The Internet*] ??? Look I won't argue that there's some awful security out there. I did a presentation at Yow West and elsewhere this year that goes into this in all the scary details, and to coin a phrase, the crap is out there. But teething troubles come with every new technology, and I do think that things are improving, so lets look ahead to the benefits. What is the internet of things For? --- # What is IoT For? ??? Well, in my opinion IoT is for transforming our reach as individuals. IoT lets us ignore the known knows and learn the known unknowns. That is it frees us from having to worry about trivial things, and it lets us observe and control the things we care about. From anywhere. --- .fig40[ ] .spacedown[ # It's for **not this**] ??? We don't have to send kids down coal mines any more. Well, we never did, but much of history is about the folks with the biggest stick using it to get someone else to do the dirty jobs. --- ## People who shouldn't have to do crummy jobs: # Children ??? But it's not just children who history handed the crummy jobs. --- ## People who shouldn't have to do crummy jobs: # People of Colour ??? Long ago the idea of enslaving the different looking people from the other side of the mountain occurred to history's very first asshole. --- ## People who shouldn't have to do crummy jobs: # Women ??? Even today, when you look hard our homes and offices are full of tedious jobs, and a disproportionate amount of these fall to women, still. --- ## People who shouldn't have to do crummy jobs: # Immigrants ??? The developed world tends to implement equiality by hiring an immigrant from a poorer country to do the drudgery. Not really a fan of this approach. --- ## People who shouldn't have to do crummy jobs: # Foreigners ??? Or maybe you offshore the whole thing. Now offshoring isn't always bad, I think the key point is dignity. Never outsource a job you wouldn't ask your neighbour to do. --- ## People who shouldn't have to do crummy jobs: # Robots ??? So, we arrive at the final solution, lets invent intelligent robots and get them to do all the dirty boring jobs. Well, the way I see it this process can end two ways. Either we succeed or we fail. If we fail, we need to find a way to make our world more comprehensible to nonintelligent stewards. --- # Wait, what? ### "Aren't crummy jobs what robots are *for*?" ??? But what if we succeed. How intelligent is too intelligent to be doomed to do a dirty job forever. Ant equivalent? Parrot? Dog? Ape? Human? Cat? --- ### *"Do you want a war of extinction? Because that's how you get wars of extinction"* .right[--Malory Archer, nearly] ??? So I give you this thought experiment - is an artificial intelligence that is smart enough to solve complex problems in fact too smart to be ethically forced to solve them? Should we be paying our dishwashers a living wage? OK, I am being slightly facetious here, because intelligence is not the same thing as consciousness. Maybe. We're not really sure. --- # Artificial nonintelligence ??? So what I'm looking for is artificial Non Intelligence. --- ## Doing all the things **no** intelligent being should have to be bothered by. ??? I propose machines meeting intelligence in the middle. And this is my definition of IoT, making inanimate things smarter, in order to relieve thinking minds from unpleasant tasks. --- .leftish[ Give me your tired-of-doing-that,<br> your poorly done jobs,<br> your harried masses yearning to be stress-free ] .right[-- Emma Lazarus, kind of] ??? All of which has very little to do with what I want to tell you today, but quite a lot to do with why I want to say it. --- template:inverse # IoT's Trinity ??? This philosophical argument informs my whole approach to IoT. I once joked that IoT is the new name for embedded systems that don't work properly. But it's more than that. IoT is the synergy of ludicrously inexpensive embedded computers, ubiquitous communications, and data science. I'm pleased that Lynn and Denis and J spoke so passionately about the possibilities of machine learning this morning, because it means I don't have to. --- # Things ### Start with the simplest parts... ??? So I can geek out over hardware instead. These are the things I'm talking about. Computers costing a few dollars with processing power equivalent to your last phone. Or to put it another way, equivalent to the kinds of supercomputers that used to take pride of place in university data centres back in the shoulder pad age. --- # Internet ### ...connect them together... ??? But these days a computer that isn't networked is pretty much just a warm rock. So we add a communications interface. Either built in like this bluetooth beacon, or this wifi module, or off board like this cellular modem. --- # Of (i.e. context) ### ...to form a synergystic whole. ??? Finally, we reach, as J so captivatingly explored, the moment of creation. We infuse our synergy of computation and communication with meaning, through the medium of data. --- # My Three Laws of IoT * Devices must cooperate for the benefit of humans * Devices must communicate, and obey instructions * Devices must be as simple and reliable as possible ??? I like threes, I never met a problem I couldn't shoehorn into a three-phrase format. So I give you my three laws of IoT * Devices must cooperate for the benefit of humans * Devices must communicate, and obey instructions * Devices must be as simple and reliable as possible If you squint a bit they look like Asimov's laws. That's not really profound, it's just a bit of fun. --- ## *OK, end of setup* .right.tiny[-- "Ford Fairlane", (not just a car, but a really awful movie)] ??? All right, that's my hipster impression, now I'm going to revert to type and go all technical. --- layout: true template: callout .crumb[ # Prelude # Overture # Communications ] --- template: inverse # Communications ## Crossing the Air Gap ??? The biggest problem in IoT is reliable communications. And battery life. Okay, amongst the problems of IoT are communications and battery life. So lets look at the ways you can do this. --- # Fast, Cheap, Battery-efficient. ## Choose any two. ??? Mad science is full of tradeoffs. We totally could have gotten away with world domination if it wasn't for those pesky laws of physics. --- # PoE (Power-over-Ethernet) ## Fast, no-battery, expensive wires. ??? If you can afford the wire, ethernet, especially with power over ethernet is a perfectly fine technology. It's easy to retrofit existing wiring for power, and pretty easy to install new wiring in existing structures. --- # EoP (Ethernet over Powerline) ## Cheaper wiring, not so fast. ??? Or you can turn the problem around. You've probably heard of systems that run iffy ethernet over your home power wiring, but you can do it over DC too. One of my projects is to do with traffic monitoring, and we selected this technology to bridge the gap from in-road sensors to the roadside uplink. But even with unlimited money, there's only so much copper in the earth's crust. And it doesnt help with devices that move. --- # PoDS (Plain ol' Dumb Serial) ## Please, no. ??? Before I go on, you'll also see traditional building automation systems using RS-232 serial and proprietary protocols. In my opinion these are dinosaurs. They violate the one of the three laws of IoT - vendor lockin is antithetical to cooperation. --- # WiFi ## (Wireless Made-up-Acronym) ??? Do you remember life before wifi? The first time I encountered wifi was at a conference I attended in 1999. Before that we all had to pay attention. Fortunately, wifi runs your battery down really fast, so some of you are still having to listen to the speakers. The first time I made a wifi IoT device I was stoked, I could detect the first drops of rain and make it to the clothesline in time to rescue my washing. For about an hour. Then the battery ran out. It turns out if you're careful you can get a couple of weeks out of a decent sized lithium battery on wifi, if you spend most of the time offline and wake up every five minutes or so for half a second. So hey, human, it started to rain four minutes ago, thought you might want to know. --- # Bluetooth ## (Don't chew on that Biro) ??? This is why I like Bluetooth Low Energy. The early versions of bluetooth were battery killers too, but the latest major version added a whole new way of working that means a button battery is good for ages, or that same battery that gives me two weeks on wifi can last all year. The next version of bluetooth is going to have an official mesh mode built in, which is super exciting news. I'm working with a startup in brisbane who installs a building wide mesh network using bluetooth radios where the nodes can go a year between charges. --- # ETPH ## You know, telephones ??? I stopped trying to remember the acronyms for mobile phone data layers about five years ago. I just call them all ETPH now. That stands for ET Phone Home. It used to be really easy to buy a cheap cellular modem and squirt out data at need. Then Australia pulled the plug on its 2G networks. I'm currently on the hunt for appropriate 3G and 4G modems. You have to pay a lot of attention to what radio bands they support, and what radio bands the telcos use here in Australia. The first round of devices I evaluated work fine in the city, but go dead in the bush where we use a different frequency. --- # LoRa ## Telephones from 1978, but without the wires. ??? The new kid on the block is a technology called LoRa. It's kind of like what you get if you twiddle the tradeoff sliders on bluetooth, to get much longer range, but much lower data rate. I'm talking about a range of 10km or more, but with 1970s modem data rates. However if you only need to send a small amount of data, it's compellingly cheap. But what's really exciting is that the happening cities in Australia are installing municipal lora gateways that are free to use. I'm talking about hip places like Launceston, Ipswich and Wollongong. Oh yeah, Sydney too. --- # IPoSUV ??? People keep joking about IP over carrier pigeon. In the 90s there was even a standard for IP over Avian Carriers published as an april fools day joke. In the naughties someone implemented it. Recently some folks in south africa showed that strapping a USB stick to a pigeon was still 100 times faster than the upload speed on their DSL. Sounds like they need an NBN. Or maybe IP over SUV? One application of the traffic monitoring project I'm working on is detecting vehicles that enter remote areas like national parks and don't make it out again. But what if there's no cellular coverage at the measurement station. Well if the custodians drive a daily patrol route, then we can piggyback our data on the patrol vehicles, by squirting it over wifi as the vehicle passes the sensor station, then uploading it when back in town. --- # Comms Recap * If you have wires, use 'em * PoDS is not IoT * If you have the power budget for WiFi, great * How about a bluetooth mesh? * "Low-power" equals "really bloody slow" ??? So that's communications. --- layout: true template: callout .crumb[ # Prelude # Overture # Communications # Scalability ] --- template:inverse # Structuring for Scalability ??? Now I want to lurch briefly on topic and talk about data. --- # Insert magic cloud here ??? Cloud is magic right. --- # Nope ??? Even the cloud vendors realise you can't have ten million devices all phoning home to one point. So there's a couple of things you can do here. Well, you can add multiple cloud servers. A content ingestion network, that works. --- # Edge Computing ### aka "Not the cloud but we've spent so long plugging cloud we can't possibly admit that" ??? Second, you can add local tiers. Instead of having every light switch connecting direct to your cloud, have a building level, or a city level hub. --- # Web API ## HTTP is awful on slow links ### HTTPs is aw-overflowing ??? How hard can this be, right, microservices are hip, we'll just add another one for data ingress and shard it. Well, you can do that. But if you're on a low data rate connection then HTTP sends a lot of data just to push up a sensor reading. Persistent connections help a bit, but a better solution are message buses. --- # Message buses ## long-lived connection, lightweight messages ??? If you're the last person in the world who isn't on the pub-sub bus, the idea is you maintain a semi permanent connection to a message broker and you send short messages whenever you need to communicate, and you have the option to receive messages the same way. --- # Retrofit ## Websockets ??? Hey, websockets are message based. A cloud compute server, a websocket connection and you have the essentials. The MVP for one of my startup clients worked just like that. --- # Build your own ## A bit of orchestration, a bit of docker, a bit of time ??? Next level of sophistication is to run your own message brokers. MQTT is the protocol of choice here. It's dead easy to spin up a broker in a docker image. It's relatively easy to provision a public key infrastrucutre to secure it all. I have a project on github to do this, there's a link at the end of these slides. One advantage of doing it yourself is you can replicate your message architecture into your development and continuous integration systems. --- # Owning an architecture is a big responsibility ## Maybe you should start with a puppy. ??? The disadvantage of doing it yourself is you have to actually do it yourself, and keep doing it. --- # Don't build your own ## Oh, look, google, amazon and microsoft already did it ??? It turns out that the IoT ecosystems from Amazon and Google and Microsoft are all based on MQTT. Thank you, gods of sanity. I've moved some of my projects over to Amazon's IoT and I'm finding it really good. --- # Well, they announced it ??? But you have to watch out for toxic vapours. None of the cloud vendors have a complete picture in place yet. --- # Microsoft ## Messaging in place, provisioning "coming soon" ??? Microsoft have the basic messaging platform. They announced a device curation platform in May, but I haven't heard any news since. It's still "coming soon" according to their website. --- # Google ## Messaging in place, management in private beta ## Device platform (Android Things) supports two vendors only. ??? Google are going hard at this. They rolled out a whole IoT platform this year based on Android. The drawbacks are that they only support two hardware devices after Intel helpfully pulled the plug on their entire IoT line, and also Googles device management component is only in early beta. --- # Amazon ## Messaging, device management function-provisioning in place. ## No news on device provisioning. ??? Amazon have been in this space the longest. They have messaging and device curation, and with the recent launch of Amazon Greengrass this edge computing offering integrates with the device curation. The drawback here is there's not anything in place for device provisioning. This isn't too much of an issue for me, because I wrote my own. --- # So, tell me again about rolling my own? ### (I'll tell you on Thursday) ??? I don't have time to go into many details of my provisioning system here. I spoke about it at NDC last month, and I'll talk about it at Yow Connected later this week. If you want to know more do get in touch. --- # Give me a hint? ### Saltstack. Mosquitto. Docker. ??? The one slide precis is I use the Saltstack orchestration tool to bootstrap my Linux devices, and for communication I use either saltstack's own Zeromq message bus, or MQTT depending on data volume. My application logic is in docker containers, and I use saltstack's docker modules to pull those containers down to the devices. Yes, docker runs just fine on a tiny linux machine like this. --- # Leveraging saltstack * ZeroMQ message bus transport * Tree-structured hierarchy * Top level master (or multiple) * Intermediate "syndicate masters" (optional) * Leaf-node "minions" ??? I will say some more about why I chose saltstack over its peers such as puppet and ansible. The handy thing about SaltStack is that it uses a message bus fabric, and the connections originate at the devices. That makes firewalling much easier, I don't need to modify any inbound firewalling at the remote sites, and there's only two TCP ports to use outbound. --- # Playing nice with MQTT * Message broker federation (one- or two-way) * Lots of implementations * Mosquitto in Docker ??? MQTT is similarly convenient, you can run the connections over SSL or websocket, and you can build up as many levels of hierarchy if you need. Pretty much everything implements MQTT, including lots of low end microcontrollers in the two dollar range. My lightbulbs run it. --- # What do you mean you want it reliable? * MQTT QoS options (but not end-to-end) * Apache Kafka * Amazon Kinesis ??? But there are instances when you might want something more heavyweight. MQTT does have guaranteed delivery options, but these break down in a multi-tier arrangement. The way the more advanced messaging systems do crash recovery is with a persistent queue. The items in the queue are retained for some time (24 hours on Amazon) and a reader can restart simply by remembering its last known offset in the queue. Apache's Kafka and Amazon's Kinesis are both good options here. --- layout: true template: callout .crumb[ # Prelude # Overture # Communications # Scalability # Interlude ] --- # Case study 1 - MQTT and Kinesis * Sensors transmit to on-site MQTT broker * Cloud MQTT broker federates on-site brokers * Cloud ingester writes to Elasticsearch * Cloud ingester forwards certain events to kinesis stream * AWS Lambda functions handle kinesis event * Problems: no recovery of missed messages ??? So lets look at a real world example of how I'm using MQTT and Kinesis. I can't say too much about this application but it's essentially geolocation of mobile points of interest. The monitoring sites each connect to a message broker, with each broker serving several regional sites. My cloud ingress pipeline runs a broker on Amazon EC2, which connects out to the regional brokers and subscribes to their firehose. I then use logstash to consume and process the location events, and feed them into Elastic search. My logstash processing involves correlating to other resources, and I cache these in elastic search. When there's a cache miss, I drop a message onto a kinesis stream, which triggers a lambda function to go and fetch the needed resources, and backfill the event records. It also updates the elasticsearch cache. --- # Case study 2 - Saltstack and Elasticsearch (fleetvalid.com) * Sensors connect to on-site saltstack gateway * (Potential store-and-forward for disconnected sensor stations) * Saltstack gateway connects to cloud 'master' * Event 'engine' on master relays events to Elasticsearch data store ??? This second example is from the vehicle tracking ecosystem we're consulting on for a multinational license plate manufacturer. The under-road sensors use powerline ethernet to connect back to a roadside hub. The roadsit hub then uses a fiber trunk, or Cellular data, or IP over SUV to connect back to AWS. I'm using saltstack to control and monitor the devices, and also carry the sensor data back up to the cloud. We haven't written an IP over SUV transport for saltstack yet, but I'm definitely looking forward to it. I also use a plugin on my saltstack masters to subscribe to bus events and push the relevant ones into elastic search. --- # Case study 3 - Meshes and AWS IoT (evacmate.com.au) * Sensors create a mesh network over bluetooth * One or more gateway nodes have 3G uplinks * Data streamed to cloud over websocket * Gateway nodes managed with AWS IoT ??? One more example, this is a startup in brisbane called EvacMate. Their application is tracking the progress of evacuations in medical facilities, and recording which rooms have been checked by wardens and which ones not. This allows emergency staff to go right where they're needed. Each room has a sensor that reads staff cards, and the sensors all connect via a bluetooth mesh. The mesh gateways are ARM linux boxes with cellular modems. Everything has to run on battery backup for as long as possible. This product started out using websockets, but is moving over to Amazon IoT. --- layout: true template: callout .crumb[ # Prelude # Overture # Communications # Scalability # Interlude # Interpretation ] --- template: inverse # Making sense of data ??? The common pattern here is multi-tier architectures, using the cloud vendors' systems where possible, and custom solutions where necessary. Once the data reaches your data lake, you treat it much like any other cloud data, and Lynn, Denis and Sau Sheong have covered that very well today. I will talk some about the kinds of data and some realtime analysis though. --- template: bulletsh4 # Layers of data * Device health * Population health * Application data ??? I divide my IoT data into three categories -- information about the devices themselves, aggregate information about the system, and application data. Saltstack has a number of modules that will transmit system metrics up the message bus, so this saved me a lot of effort. --- # Put it all in a data bucket ??? My approach with performance and health data is to just throw it into a data store, and let it pile up. --- # But don't look at it ??? I don't even really bother to build visualisations initially, beyond some basic availability monitoring. --- # Except when you do ??? When the wheels come off, you'll now what you needed to know then. Now you can start thinking about how to detect this class of problem next time. --- # Artificial nonintelligence ## Machine learning for "this is fine" ??? Sau Sheong spoke after lunch about using neural networks to detect anomalies. I cannot say enough about how awesome this is. When I worked in e-Commerce we spent years trying to codify all the system behaviours to detect anomalies. When you're working in an industry with a natural 500:1 transaction rate variability, it's really hard to tell an anomalous spike from a normal spike. Well, machine learning can. --- # Machine Learning in Elastic Search ## "this is **not** fine for 10am on Tuesday" ??? Elastic search has an easy to use machine learning anomaly detection, given a week or so's data it will learn the patterns and alert on exceptions. You can absolutely use googles much more sophisticated ML tools if you have the need or desire. --- layout: true template: callout .crumb[ # Prelude # Overture # Communications # Scalability # Interlude # Interpretation # Reaction ] --- template: inverse # Managing your things ## Big data bassackwards ??? Ok the last thing I want to cover is fleet management, which is kind of the reverse of big data. --- # Addressing the fleet ## Saltstack - rich syntax for addressing sets of devices ??? Once again my go-to tool here is saltstack. I can perform an operation on one system, or all systems, or some subset. I can define groups, or infer them based on properties such as application roles, architecture, software versions, what have you. Salt has a nice enterprise administration console, and a rich api that lets you hook your own systems in if that's the way you want to go. --- # Addressing the fleet ## MQTT comms - bidirectional messaging but little structure ??? The way that Amazon do device management is over MQTT. They define reserved topic names for system operations, and use the same fabric as for your application data to carry management operations. This is a good approach. You can even build what Fred George calls "Asynchronous Microservices" by doing request-response over MQTT. --- # Addressing the fleet ## Broadcasts - IP or otherwise ??? What if you have disconnected devices? I usually advise against one-way channels, but this is a case where they have a use. It takes a lot less power to run a receiver than a transmitter, so you can have devices just listening for commands in low power mode, and wake up at need. The EvacMate system uses devices that check in with the gateway every seven seconds, and only go into full-power mode when instructed. They run for a year on the battery intended for a samsung galaxy. No not the explodey one, starting fires with your fire evacuation system would be very silicon valley. For the vehicle tracking system we're looking into satellite broadcast, to wake up devices in very remote locations. --- # Reactive architectures ## Rule based response to events. ??? One more thing. Lets talk about reactive architecture. With saltstack you have a rules system called reactor which lets you respond to events, so if a new device appears or reports a problem, you can act on this. You can push pending operations to your disconnected devices when they connect, if you like. Amazon has a rules engine too, so you can have MQTT messages from your devices trigger lambda functions or auto-gateway onto other message fabrics. --- layout: true template: callout .crumb[ # Prelude # Overture # Communications # Scalability # Interlude # Interpretation # Reaction # Coda ] --- .fig30[  ] # Coda .nolm[ * IoT (for me) is about relieving Future Shock * IoT's trinity: Hardware, Comms, Data * Crossing the Air Gap * Flowing to the sea * Case studies * Making sense of it all * Knowing when to run ] ??? This brings us full circle. The promise of reactive architecture and artificial nonintelligence is having our systems look after themselves, so that we don't have to. Why can't my damn wheelie bin put itself out on bin night. I call it Laziness as a Service. --- # Homework * Make your systems amenable to cooperation * Try out Amazon GreenGrass - lambda functions on your Raspberry Pi * Keep an eye on beta offerings from Google and Microsoft. * Use a message fabric to instrument your distributed systems * Try out Elastic or Google ML for anomaly detection * What cool things can **you** do with LoRa and 300bits per second? ??? So what are your takeaways. --- # Resources, Questions ## Related talks - [http://christopher.biggs.id.au/#talks](http://christopher.biggs.id.au/#talks) ## Me - Christopher Biggs - Twitter: .blue[@unixbigot] - Email: .blue[christopher@biggs.id.au] - Slides, and getting my advice: http://christopher.biggs.id.au/ - Accelerando Consulting - IoT, DevOps, Big Data - https://accelerando.com.au/ ??? All right, thats all I have for you today. Thanks for listening. I'm happy to take questions in the few moments remaining and I'm here tomorrow if you want to have a longer chat. These slides will go up on my website and on the conference site soon. Over to you. --- # Links * [Open source Bluetooth Mesh](https://github.com/mwaylabs/fruitymesh) on current hardware * Future Standard [Bluetooth mesh networksing](https://www.bluetooth.com/what-is-bluetooth-technology/how-it-works/le-mesh) * [Public access LoRaWAN](https://www.iotaustralia.org.au/2016/07/20/iotnewanz/meshed-offers-free-access-lorawan-network-sydney/) in Sydney * The '[mosquitto](https://mosquitto.org/)' MQTT broker: * Example of [how I use SaltStack to provision MQTT](https://github.com/unixbigot/kevin) * [Asynchronous Microservices](http://www.youtube.com/watch?v=J1eTutzcGFQ)