Presentation: Serverless IoT @iRobot

I help guide and shape our cloud architecture and how we integrate into the Smart home from a technology perspective—we are just about 100% Amazon.

We are also 100% Serverless for our production customer facing application that supports our connected robots and apps.

Our analytics stack uses Spark, but that's separate from our front-end application.

There's no unmanaged EC2, there's no Docker, no Kubernetes - all the computation is happening and Lambda. Then we stitch that together with about two dozen AWS services, really fronted primarily by AWS IoT to enable the connections for our robots.

When we launched our first connected Roomba in 2015, we had a full solution IoT cloud provider, that even before launch we knew didn't really scale the way we needed it to, and didn't really have the extensibility to do the sort of integrations and data platform plays that we had in mind.

We knew that we had to migrate. We looked across a bunch of Cloud providers, and settled on AWS IoT our connection layer and then AWS services behind that. iRobot is an established device manufacturer; we have a history of networked robotics and we've built telepresence robotics, but those were sort of single tenant enterprise systems where when you bought it, there'd be some servers installed in the rack somewhere for you. So we didn't have the background in scalable, elastic cloud infrastructure. Instead of having to go through the pain of learning how to do everything, going Serverless using Lambda and an AWS IoT and all these other services has enabled us to really stay lean and launch.

The goal is to communicate the benefits of how the Internet of Things is right when you're producing connected devices, and that Serverless is a natural fit there - both from a technology perspective that Serverless is often very event driven - and so is IoT. I’ll also talk about organizationally our ability to do all this in a very rapid and lean fashion.

I think it's a cross between architect and CTO because there's a lot of organizational benefits. The operations become simpler but they also become different - and there's a lot of important expectations to set. So in ingoing Serverless, it's the notion of there's no cloud, there's only somebody else's computer. AWS is operating all of these servers for us and providing a very high level interface to it. It means that we don't have control, and so then operationally it becomes much more opaque. So when there's a provider incident your ability to remedy that is basically zero - and your visibility into when that starts and how the remedy progresses can be very limited - and it's very frustrating in the moment. You have to set expectations around what we're going to be able to know in our organization and also to sort of keep your eye on the ball of as a total cost of ownership if we had built this ourselves not only would it be costing us more but we would be building it worse. We would be having more incidents even though we'd have more control over what was going on.

So we decided that for this product we didn't need to do high availability pieces. High availability can be difficult with existing Serverless offerings - the concept of an availability zone and in Amazon where you're still within the same data center or region essentially but you can fail between these without your cost spiking way up. Lambda doesn't do that. Lambda you have a big lever to pull and then switch everything over to another region, and setting up the data replication and everything that goes along with it is both expensive and complicated.

Another downside is that it may not do exactly what you want it to do. It's a service and it is what it is. I'm never completely satisfied with the lack of control over partitioning, the DynamoDB has to it hot partitions and there's not much you can do about it. But at the same time if I was going to say OK we're going to ditch that for Cassandra, that's a huge amount of overhead that I have to take on. So I'd rather deal with the DynamoDB rough edges: so that's like buying the “hairless yak”, but it may only have three legs.

I think it's a couple of things. One is that Serverless is really powerful in accelerating the pace of innovation, being a full force multiplier for your organization - that we've been able to do all of this with very few people, and that it requires a mindset change it's a paradigm shift in a way, that comes with pluses and minuses that really require a big picture view to make sure that you know that what you're doing is the right thing. Because it's different enough that the individual pieces can sometimes seem like a jarring transition.

All of the all the rough edges of Serverless. How it goes from being each of these services doesn't necessarily have everything you need. And we're still not to feature parity so there's a number of things we're missing in the security space in the operational space, and in the application space. Sort of service discovery for service components is not really a solved problem. Security monitoring is not a solved problem. People are working on it, but there's a lot of these pieces that just aren't all quite there. And so the technology problem that keeps me up is how quick do we get to maturity in all those spaces?