What is the Kubernetes for IoT?
I’ve been working in IoT for more than half of my career. At Nest, I had the unique opportunity to be on the board of the Thread standard group and bring OpenThread to market. At Particle as the first product hire I learned all about designing hardware, embedded software, and brought my passion for developer experience by creating professional-grade developer tools. Most recently, I worked on cloud services for WeWork’s global physical security platform, providing real-time access to buildings, elevators, and doors across WeWork’s global fleet of 600+ buildings. Throughout all of these years, I have observed three areas that I feel are ripe for innovation:
- IoT cloud backends
- Security
- Developer Experience
Year after year, the opportunities in these 3 areas have gnawed away at me and I’ve spent the better part of the past year identifying patterns and validating opportunities in this space. I’ve been talking to a bunch of folks from hardware startups to Fortune 100 companies. I’m now on a mission to build the Kubernetes for IoT, based on a culture of security. I hope to improve the developer experience along the way.
The rest of this post will touch on a few of the major high-level problems I see worth addressing, and why I think that now is the perfect time to solve them.
The Cloud
There are hundreds of IoT cloud providers with a wide range of differences. They span the gamut, including:
- Big cloud providers (AWS / GOOG / MSFT) to startups (Losant / Balena)
- Batteries included (Samsara / Particle) to à la carte (PubNub / C3)
- Enterprise (ThingWorx / Ayla) to open source (Eclipse IoT / Node-RED)
Yet there isn’t one de facto solution that everyone can use to build their connected products. I’ve spoken with 100s of companies and developers and most start with something like Amazon IoT, Particle, or Ayla, but end up building a lot of software and backend services on top. On the other end of the spectrum, larger companies might skip a provider altogether and build an IoT platform from scratch, spending millions of dollars before getting to a V1.
The question many ask is, “where is the Linux for IoT?” Linux as an operating system (OS) provides the base system to run a computer and commodity services like working with files, graphics, and networking. The OS for IoT would provide a similar foundation for all the commodity cloud features in a backend, like device messaging & software updates, that enables product companies to focus on their core competencies. The last decade of companies marketed themselves along these lines, claiming they were building an “IoT Operating System.” They started by building out each core service one by one in an attempt at becoming a full end-to-end service provider. Ironically, that’s not how OSes have historically created value, but more akin to the route that SaaS providers take. OSes provide low-level primitives and create a two-sided marketplace. OSes could be services (like the app store) or software (like Windows) but they are about ecosystems.
I believe an “IoT OS” is the wrong goal. Rather, as an industry, we need common infrastructure. The analogy should be more like the “Kubernetes for IoT.” Over the last year, I’ve been exploring what that might look like, instead of a collection of SaaS services or an OS.
Security
There’s a joke in the industry, “The ‘S’ in IoT stands for ‘Security’.” The pun is poking at the fact that there isn’t an “S” in IoT and similarly no security in it. Analysts have been begging to see an improved posture around IoT security for as long as I can remember and consumers are even starting to vote with their feet by paying premiums for products that are more “secure” and built by recognizable brands. As an industry, practitioners continue to approach security with what I call, “the dirty dishes problem.” It’s a chore and you have plenty of other problems to work on but you only get to it when you run out of forks.
Kidding aside, there genuinely doesn’t seem to be a lot of positive improvement in the state of security as it relates to IoT. Part of the problem is that there is no definition of “secure” as it is a difficult outcome to quantify and not a binary thing. In software, we have a mature practice of Threat Modelling to identify potential threats and propose specific mitigations based on those threats and the constraints of the system. While there are ongoing efforts to define best practices and standards for security, translating those into implementations is actually hard. As much as we wish we could “buy” security, it has to be designed into every aspect of an IoT product, and the ongoing processes used by every company involved with its creation. You might remember the Bluetooth-enabled teddy bear that could be hacked to listen in on children or the Dyn DDoS attack that installed the Mirai botnet on IP cameras and DVRs, taking down some of the largest sites on the internet.
I call this a “culture of security.” At Nest, I watched the development of the latest product go from “basic security” in the lab to a finished product on the shelves that I would trust in my home. Unfortunately, many products look more like a bench prototype. Creating culture, heck defining culture is hard, but I think it is possible to create and spread since I’ve seen it done before.
Developer Experience
We’ve heard the adage, “hardware is hard!” and while that’s still true, it has never been easier to build hardware. The cost of components has plummeted because of the economies of scale for processors, memory, sensors from the smartphone & automotive markets. Manufacturing at scale is accessible to anyone (thank you China), and once proprietary tools and software like the GCC compiler & Zephyr RTOS are now free. Yet, the experience of developing hardware is roughly the same as it was 30 years ago. Conversely, the developer experience of creating software has seen a Cambrian explosion and evolution during that same time.
Admittedly, the tools for the “atoms” like electronic and mechanical design automation have improved, but mostly in performance and doing more complex designs, not the experience. The “bits” (all the software and process components) genuinely feel archaic and almost laughable to someone who has any experience working with modern-day software stacks.
Developer Experience is intangible and subjective but I’ve been studying it for more than a decade. I have some early ideas on tackling programming languages for IoT, the development code-flash-test cycle, and security (there’s that word again!) to bring low-hanging fruit improvements to the industry.
I’m working on something new
So after thinking about these problems over the last year and talking to as many folks as I can, I’ve started on my mission to build the Kubernetes for IoT, based on a culture of security. And I hope to improve the developer experience along the way.
If you’re interested in working on something like this, or at least intrigued, I’d love to talk to you! Or if you’ve been looking to build something with IoT, I’d be happy to help you on your journey.
Many thanks — and don’t forget to do the dishes!
