An OEM's take on "build versus buy" for data stream networks

In part one, I discussed some of the challenges I encountered while trying to build a data stream network (DSN) for a simple (so I thought)  thermostat I designed.

As part of my continued research, I spoke with Atif Noori, CEO, and Kevin Rohling, Product Manager, both of Emberlight, a company that produces a hardware device that turns a light into a smart light. You screw a lightbulb into Emberlight and the Emberlight into a socket, and it connects to  or Bluetooth so you can control your lights from anywhere in the world with a phone. Emberlight also includes additional features like setting timers to turn lights on/off and access control features that allow guests in your home to manage the system too.

The Emberlight application consists of several components from an engineering standpoint, including the physical hardware, the firmware that runs on it, a backend, and a mobile application (iOS and ). They also use PubNub for all their real-time data streaming needs, and when speaking with Atif and Kevin I found out they went through the same build versus buy analysis for a real-time network as I did, which proved very interesting.

Why does Emberlight require real-time communication?

Emberlight needs the ability to maintain persistent socket connections to the lights to ensure they can be controlled instantly using a smartphone. The ability to upgrade the firmware on the Emberlights from anywhere in the world in an instant is another reason secure real-time communication is needed.

What was Emberlight’s experience when making the build versus buy decision
for a DSN?

Emberlight went through the same analysis as I did to figure out how to implement the real-time functionality of their application. They understood the complexities of building a DSN themselves, and so did a good amount of homework to analyze the different companies providing the infrastructure. “Building a hardware product is really hard, why make it harder?,” Atif and Kevin told me. With the resources they had, they wanted to focus on their application logic (hardware, software, and security), and not on building and maintaining a real-time network.

How did Emberlight choose their real-time DSN provider?

Since building a real-time solution was out of the question, the folks at emberlight did intensive research on which provider to go with. PubNub was their platform of choice on several fronts.

“We weren’t willing to compromise on reliability, speed, and network uptime, and PubNub really did a good job of providing everything we were looking for in a real-time network,” they said. “It was the only company that provided real-time support for our memory-constrained embedded devices in a secure manner.”


At the end of this little experiment of mine, I learned a lot about real-time DSNs and the pros and cons of building it from ground up versus buying an existing infrastructure. This is my two cents: building a real-time DSN in-house is like buying a boat – the two best days of a boat owner’s life are the day he buys it and the day he sells it.

Even if you build the network, maintaining and scaling it is an ongoing process that requires a lot of brainpower, time, and money. Building your prototype is fairly simple, but there are a lot of challenges before you take that same prototype to mass production. Using a pre-built network, on the other hand, lets you focus on your application logic. You can get started quickly, scale the application to several million users without breaking it, and take advantage of the built-in security. Several companies providing real-time networks as a service are easy to get started with, and have attractive options to help developers to get their IoT project off the ground. This is exactly the model I am going to use for my project. As the Emberlight team stated, building a hardware product is difficult, so why not take all the help you can get?

Bhavana Srinivas is a developer evangelist at PubNub.




Topics covered in this article