How BISSELL migrated to a new IoT platform using AWS Connected Device Framework

Introduction

BISSELL is a family-owned business with over 145 years crafting premium cleaning products that exceed consumer expectations. BISSELL offers a full range of floor care and air treatment products. Connected vacuum cleaners – particularly robotic vacuums – are a growing segment of their business. BISSELL has 1 million registered vacuum devices in their existing IoT Platform powered by AWS IoT, and currently 25% of those devices are connected in the field. With increasing adoption of connected vacuum cleaners around the world, BISSELL is expecting 1 million devices to be connected in the field in the near future. BISSELL wanted to ensure its IoT platform could scale with this rapid expected growth across product categories.

BISSELL’s home-grown legacy IoT platform on AWS included a suite of REST APIs that enabled different members of their IoT ecosystem to access platform data. The legacy platform worked and performed well, but BISSELL anticipated future pain points scaling the platform with new products and users.

In this blog post, we show how BISSELL worked with AWS Professional Services to improve their legacy REST APIs as part of migrating their IoT platform to a new architecture based on the AWS Connected Device Framework (CDF). We identify pain points of the legacy REST API architecture and then describe how we redesigned it using CDF’s micro-services approach of grouping related REST APIs into a single Lambda with proxy integration. Next, we highlight how the new architecture contributed to improving the scalability, performance, and cost efficiency of BISSELL’s IoT platform.

Legacy architecture challenges

The serverless REST APIs on BISSELL’s legacy IoT platform were built using BISSELL’s Onion Architecture, which is a serverless design pattern comprised of multiple concentric layers of Lambda functions interfacing with each other towards the data access layer in the core. BISSELL decided to create the Onion Architecture due to high code re-usability.

The domain layer of the architecture contains a set of Amazon API Gateways, and each Amazon API Gateway serves REST API requests originating from a specific domain. These domains represent clients of the BISSELL IoT platform such as a mobile app or a web portal. Underneath the domain layer is the service layer of the Onion Architecture that is comprised of Lambda functions, each of which are dedicated to service a specific REST API request. Finally, the data access layer of the Onion Architecture contains an additional set of Lambda functions that implement Data Access Object (DAO) interfaces. The data access layer Lambda functions access IoT data stored in Amazon DynamoDB tables using the DAO interfaces. The following image shows the different layers of the Onion Architecture.

When a client invokes a REST API, the Amazon API Gateway first initiates the Lambda function in the service layer that handles the requested REST API operation. Next, this Lambda function invokes a set of Lambda functions in the data access layer as needed to complete the requested operation. Finally, the Lambda functions return results back to the calling Lambda function in the service layer, which constructs and returns the final response to the Amazon API Gateways.

The Onion Architecture promotes a highly reusable code base by allowing the service and data access layers to share Lambda functions. However, it also presents challenges when trying to add features and scale to hundreds of thousands of devices. First, maintaining more than 500 Lambda functions made it difficult for BISSELL to perform rapid and frequent updates to scale the existing REST APIs. Second, the growing chain of invocations between individual Lambdas coupled with inconsistent database design negatively impacted the platform’s performance and cost efficiency. Furthermore, debugging issues became challenging with developers having to look across multiple Lambdas to find root causes.

Migrating to the new architecture

BISSELL and AWS Professional Services decided to migrate the legacy platform to a new solution developed using the AWS Connected Device Framework (CDF). CDF is an open source framework for building an enterprise IoT platform. It provides a set of production-ready micro-services called CDF modules, all architected and implemented using native AWS services and best practices. The CDF modules form a layer above the AWS building blocks as shown in the following architecture diagram.

The team began by addressing the inner-most data access layer of the Onion Architecture. The legacy IoT platform lacked a clearly defined device registry to manage a large fleet of devices and their relationships to other resources within the platform such as users, device types, and firmware. In the legacy platform, data for devices and other resources was scattered across multiple Amazon DynamoDB tables. This issue, coupled with both static and dynamic data coexisting across tables, led to increased system complexity, stale data, and cost inefficiency. For instance, BISSELL had to create a series of Amazon DynamoDB queries across multiple tables just to construct a list of devices owned by a particular user. This operation consisted of the following steps:

1. The Data Access Object (DAO) first need to query the “Users Table” using a user ID as the sort key to obtain all groups that are associated with the user.
2. From the returned groups, an array of device IDs is constructed by pulling out device ID from each group.
3. The DAO iterates over each device ID, having to query multiple tables to construct a complete device object on each iteration.

The diagram following illustrates this issue through a mock scenario.

BISSELL and AWS Professional Services used the CDF Asset Library to build a comprehensive device registry defined as a single graph database using Amazon Neptune. During the re-implementation phase, the team migrated infrequently changing or otherwise static data (for example, device-friendly name, user email address) to the Asset Library. On the other hand, frequently changing data, such as device usage metrics, was maintained in Amazon DynamoDB tables. This resulted in a simplified data access layer that allowed the team to improve performance and cost of the upstream data consumption.

The diagram following illustrates how the CDF Asset Library is able to reduce the number of DynamoDB queries from the multiple queries required with the legacy setup to a single Neptune query.

After optimizing the platform’s data access layer with the CDF Asset Library, the team worked on migrating from the legacy Onion Architecture to a new architecture based on CDF’s micro-services design paradigm. BISSELL migrated their legacy REST API architecture as part of the CDF Application Layer, also called the CDF Facade layer. The Facade layer is an application layer that contains BISSELL’s unique business logic and orchestrates the underlying CDF Core modules. The CDF Core modules are implemented as a Lambda with proxy integration, which groups dispersed sets of Lambda functions into a single Lambda function for handling a common service such as the CDF Asset Library. The open source [AWS Serverless Express] Node Package Manager (NPM) package allows you to easily build serverless REST APIs using the Express framework on top of Amazon API Gateway.

BISSELL’s CDF architecture provides a Lambda configured with proxy integration that serves as a single point of entry for all API requests made by common clients such as the mobile and web applications. For instance, BISSELL’s mobile application sends all requests to a dedicated Amazon API Gateway. From there, Amazon API Gateway uses proxy integration to route any requests to a Lambda dedicated to handling all API operations for the mobile application. The Lambda itself breaks down into three layers. When the Lambda is invoked, the API request first enters a controller, where it determines what service to call based on the request’s endpoint. The service then calls the Data Access Object (DAO) to access the platform’s databases hosted in Amazon Neptune and Amazon DynamoDB.

By migrating to the CDF architecture, BISSELL reduced the number of Lambda functions in the platform by 90 percent. The new controller, service, and DAO design consolidated the code base and reduced troubleshooting efforts. Another key benefit was the ability to deploy the Lambda as a local Express server, which contributed to speeding up development and troubleshooting issues even faster. This solution provided the BISSELL development team the ability to quickly deploy and test the API execution on a developer’s local machine.

Conclusion

BISSELL successfully migrated their legacy serverless REST APIs to a new architecture based on a micro-services design paradigm presented by the AWS Connected Device Framework (CDF). BISSELL now has a more scalable, performant, and cost efficient solution for their IoT platform on AWS.

The migration resulted in a 90 percent reduction in the number of Lambda functions. Post migration data showed a 90 percent reduction in Lambda costs and a 50 percent reduction in Amazon API Gateway latency. Furthermore, the migration provided BISSELL a platform that supports agile business expansion with the ability to scale features and devices rapidly and reliably.

To learn more about AWS IoT services and solutions, visit AWS IoT or contact us. Also, learn more about BISSELL’s new IoT Platform in the first post of this series.

About the Authors

Jay Chung is an IoT Architect working in the IoT Global Specialty Practice in AWS Professional Services. Jay loves engaging with customers to build IoT solutions that help customers solve their business challenges. Prior to joining AWS, Jay spent over a decade serving multiple roles in the automotive test tool industry including software development and product management.

Babu Papanna is an IoT Architect working for IoT Global Specialty Practice in AWS Professional Services. Babu is passionate to analyze, design & turn customers complex business challenges in to valuable solutions. Prior to joining AWS, Babu worked in optical telecom, connected devices, IoT, MSP, Wireless & device management business verticals.

Ramesh Chinnasamy is a seasoned leader for Global IoT practice within the AWS Professional Services Global Specialty Practice. He leads IoT solutions for our customers as well as develop best practices & packaged IoT solutions. He helps our customers and partners to deliver end to end IoT solutions from the edge through to the cloud to achieve business outcomes.

Aaron Pittenger is a Lead Software Engineer at BISSELL, leading the full-stack IoT software development efforts across mobile and cloud. Before joining BISSELL, he lead teams in aviation and delivered innovative digital solutions for civil and military applications. He is also worked cross-functional roles in IT, business development and program management. Aaron is interested in utilizing the latest technologies to solve some of life’s most difficult problems.