Thanks to a few technologies that have become, coincidentally, cheap, tiny, and widespread at about the same time, you are now able to bolt on sensors, computers, and communications to houses, cars, shoes, and anything else you can dream up.

As with the rise in web traffic, the rise in "thing" traffic will create a burden on infrastructure and development. The past 10 years have seen the management of cloud-scale hosting and applications improve to cope with traffic, and this will be mirrored in the next 10 years as we see more than 10 times that level of traffic added to already busy servers and sys admins.

These levels of growth always sound absurd when peddled by analysts. Cisco predicts 50 billion devices by 2020 compared with 12.5 billion in 2012. To get some intuition about this number, consider the devices per capita rather than the total number. In 2010, we had 1.84 devices per person, which is easy to see: At the moment, you have a phone, maybe a couple of tablets, a laptop, and perhaps a desktop computer. That's five things if you're geeky, so the global average being 1.84 makes intuitive sense.

Now imagine you hook up sensors to your house for security. Your fridge, washing machine, and dishwasher start talking to the web; and your car is online – so is your heating and air conditioning. All the doors in your house are, as well (so you know what you left open). Your kids also have five or 10 toys that are intelligent, online, and talk to apps on their tablets.

And that's just for starters. Add in the potential devices in hospitals, city councils, and industry, and it's easy to gauge the scale intuitively.

The fact is that lots of Internet of Things (IoT) use cases are still hypothetical or just commercially unproven. Your car could talk to the city parking space, which could tell your doctor that you've arrived, and the prescription you get from the doctor could remind you to take the drugs via your phone. The point is, this huge influx of data is coming and, with it, another heap of data and application challenges.

If you're dealing with app or website traffic at the moment, or even harvesting data from business systems, then visualizing this data is going to take some adaptation. The IoT is going to be like moving from a low-traffic website to a real-time app with a gazillion users. It's going to be different.

Steps Toward the Internet of Things

To begin, a definition: The IoT is a world in which ever smaller devices are ever more connected. Sending and receiving data, these devices will be the consumer electronics devices around us but will also be the inanimate objects. Toys, clothes, cars, and water meters are all in the running to become plumbed into the Internet.

It takes several steps to getting a dumb device connected:

• A device that probably has some kind of processing power on it
• A connection
• Somewhere to store and manage the data

Although the device and connection aspect are interesting, with a growing number of ever easier and cheaper ways of getting data from a thing to the web, I'm going to focus on what you do once all that data is in the air heading toward you.

Once connected, you can think of a device as any other provider of data – like a server or a user. First, the device needs to identify itself in some way. Second, it needs an account against which to log its data – which is what a number of IoT platforms provide.

With the device sending data to your central database, you can build reports and apps that consume the data and then perform actions that send responses to actuators. This architecture of device {{ARROW-RIGHT}} API/app {{ARROW-RIGHT}} device is going to become one of the main architectural patterns of the IoT; other patterns will include direct machine-to-machine communication.

This setup might sound like all you're getting is a database with an API, and in many ways, that's all you are getting. Both platforms here, and many similar IoT platforms, simply corral the data from the "things" into a form that can be used; however, in doing so, they deal with the problems of connections, identification, and, of course, scale. If you're building an IoT product, one of these solutions can save you a few weeks of development, allowing you to get your product to market sooner.

Carriots

Carriots bills itself as a tool for building amazing products and services by connecting objects to the Internet. The Carriots platform is used to build the applications that, like all elements of the IoT, can be anything that receives data and reacts to it.

The steps Carriots and most platforms like it take are: Connect the device, collect the data, manage all that data, and build an app to consume that data. This workflow is going to become as familiar as the deploy-to-sever workflow of web apps, so in a moment, I'll walk you through the process.

To create a free account, go to the Carriots website [1] and punch in your details. To start, create a project within Carriots and then add devices to which the incoming data is attached (Figure  1). The Carriots interface supports a lot of standard sensors and types of devices, giving you a bit of a kickstart with GPS trackers, cameras, and Raspberry Pis, for example.

Figure 1: The Carriots homepage takes you through the steps to set up your devices.

Each device has an identifier like dummy@carriots. Although you can create the device records through the interface, it's probably going to be more useful if you create them programmatically through the API.

Carriots provides listeners, which, like most other languages and frameworks, are simply pieces of code that run when a given event occurs. The event model is a really strong way of architecting apps because you can record all the data coming in from all the devices but react to only a little of it. These listeners can be triggered when data is received or when the device's data is changed, which is a more useful use case if you're waiting for changes in temperature, movement, or other small, tell-tale fluctuations in state.

The listener wizard can help you create some simple listeners, such as the following script that sends the entire payload from the device by email:

import com.carriots.sdk.utils.Email;
def email = new Email();
email.to="dan@example.com";
email.subject="Carriots Listener sends email";
email.message="Context Data: "+context.data;
email.send();

Listeners belong to the project or the device, meaning you could be listening to 20 temperature sensors or just one.

Carriots has two other ways of getting data out: REST APIs and triggered pushes. These methods allow you to hook up huge and growing numbers of devices and sensors but pick out only those events that matter to your application. Devices generate data all the time – temperature changes, doors opening, pictures being taken – but very little of it matters. That's getting data out, but what about getting it in?

Carriots provides a couple of SDKs for prototyping platforms such as Raspberry Pi, but these ultimately call a RESTful API. For example, the call in Listing 1 returns a list of the devices registered to your account, with similar calls for adding, editing, and posting data to devices.

Even if you're only starting with a few devices, this can give you a head start by letting you gather all the data possible but only working with a little of it and – at the very least – give you a prototyping platform or possibly the backbone to your production system.

The case study provided on the Carriots site is to gather data on beer consumption by using flow records sent to Carriots and displaying the measures on the Carriots dashboard. If you've done any integration, you'll know how important logs and debugging tools are, so it's good to see these baked into the product.

Evrythng

Evrythng bills itself as "a platform for powering applications or services driven by dynamic information about physical objects." Like Carriots, you're given a database structured around things with attributes ready to operate at scale. The version you can sign up for is small compared with the customized version, but again, this platform can be a head start in getting the data of your devices into a useful and usable form.

The use cases that Evrythng suggests include the usual IoT ideas, but they also add digital profiles for existing products that include warranties, manuals, and other data that isn't part of the traditional digital footprint of a product. For manufacturers, this presents a much faster way into the IoT by bolting on digital stuff to existing products – potentially for products already sold.

For example, a "medicine bottle that reminds you when to take the pills" actually requires 99 percent of the cleverness to be built in the cloud using the knowledge of what's in the bottle rather than changing anything about the bottle itself.

The workflow for Evrythng [2] is similar to that of Carriots: You start by creating a free account and then start up your first project. Devices, or "thngs," are given a geographical display by default, but any attributes can be added to them, so your app could organize devices by size, cost, warranty period, or any arbitrary property.

The management interface for Evrythng is cut down compared with Carriots and doesn't expose all of the objects to the database stores. For example, the UI doesn't display products available via the API [3].

Both platforms allow you to provision devices on the fly, which is useful if you have many hundreds of thousands of devices to deploy. For example, if you were shipping refrigerators, you might call the API when the fridge leaves the shop to initialize it (Listing 2). With the device sitting in the Evrythng database, you can begin to attach data to it. Once you have devices in there, you can pull them out with a similar API call (Listing 3).

The properties are NoSQL-like, so if you're familiar with adding properties to MongoDB records, this is the same behavior: You add them when storing, and they're just there – you don't have to declare them anywhere. This makes development really easy and removes any need for structure management in the code or deployment; however, it puts a greater burden on your application code, especially if you have a weakly typed language. Creating deviceWarranty is not the same as devicewarranty.