Implementing an IoT project is costly, but there are ways to save during the process. We look at cost optimization when setting up BlueBeak beacons.
In the previous blog of this series, we examined a real-world Internet of Things (IoT) project called BlueBeak. This framework leverages various cloud components to deliver location-based services for several industries, including healthcare and retail. Recall from the previous blog that IoT is all about data, specifically:
- Capturing the data generated by devices
- Making real-time decisions based on the data
- Storing the data for later use
- Analyzing the data to gain operational insights
In this final installment of this IoT series, we’ll take a look at the costs that drive a typical IoT project and how to optimize those costs. To get started, let’s take a look at the Cloud components used for the original BlueBeak solution.
Evaluating the Cost
The table above reveals most of the costs in this solution come, not surprisingly, from the application, database, and website services. These cost drivers guided the process of rearchitecting the next version of BlueBeak. Below, we take a look at how we improved each stage of the IoT application.
Data Ingestion
Much of the cost and computational overhead in BlueBeak comes from the ingestion and processing of the incoming data. A process running on Docker container running in AWS Lightsail must always run to handle the incoming data. However, a closer analysis of the Docker instance showed that it was mostly unused. That is, the CPU usage on the instance was low, only spiking when incoming data needed processing.
This event-driven architecture is much better suited to a newer technology, generically called Serverless computing. With Serverless computing, we don’t require dedicated instances. Instead, an event triggers the provisioning of resources needed to perform a computational process.
AWS calls its Serverless platform Lambda and gives it the tagline “Run code without thinking about servers. Pay only for the compute time you consume.” Using a very lightweight Elastic Compute Cloud (EC2) instance + Lambda functions, we were replaced all of the Lightsail and Docker instances with small, Serverless microservices.
Data Decisions
Just like the section above, we replaced the Lightsail and Docker instances that implemented the business rules of BlueBeak with Lambda-based microservices. For example, one Lambda function determines when a beacon is in a room long enough to trigger a “visit.” Similarly, another Lambda function determines when a beacon leaves a room. There are two key reasons for leveraging Lambda for these business rules:
- The code only runs when an external event triggers the business rule (i.e., the code does not require a server that is always running).
- We can implement the business rules with small, self-contained, stateless code segment: a perfect candidate for a microservice.
Data Storage
For our initial implementation of BlueBeak, we used Couchbase, an open-source, distributed NoSQL documented-oriented database. While Couchbase allows us to store data directly as JSON, there are a few downsides that come with using Couchbase:
- Licensing costs associated with Couchbase
- Export and Query limitations associated with Couchbase
- Additional compute needed to host Couchbase
Without going into details on each of the above challenges, the cost of maintaining and scaling Couchbase was a major factor in migrating the Data Storage component of BlueBeak over to a different database solution. After considering both NoSQL and relational database solutions available on AWS, we ultimately chose AWS Relational Database Service (RDS).
More specifically, AWS Aurora, a MySQL-like, multi-region database. The Aurora database master sits in the primary AWS region with the Dashboard. An Aurora Read Replica sits in an alternate availability zone for fault tolerance.
Data Display
We deliver the original BlueBeak Dashboard as a responsive website using Angular and NodeJS, hosted in the AWS Lightsail. Since the Dashboard requires a website at all times, we can’t replace it with Serverless technology. However, AWS does offer a comparable solution for websites that do not require dynamic content generation, such as ASP.NET or Apache.
We can store these so-called static websites in AWS Simple Storage Service (S3) and host these as a public or private website using AWS infrastructure. This process results in dramatic cost savings and makes the deployment of the Dashboard in BlueBeak straightforward.
Data Insights
The Machine Learning component of BlueBeak works well with AWS SageMaker. Since SageMaker is relatively new and not much of a cost driver in BlueBeak, we opted to continue using SageMaker in the optimized solution.
Bringing it All Together
We left no stone unturned in our effort to optimize the costs of our IoT implementation. Starting with data ingestion and focusing on data processing and storage, we reduced the operational costs of our IoT solution, and we improved the reliability, scalability, and performance of the solution. The table below shows the optimized BlueBeak platform and the associated cost savings.
*The first 1 Million calls in Lambda fall under the AWS Free Tier. The next 1 Million calls cost $0.20.
**Hosting a static website on S3 falls under the AWS Free Tier. If the storage of the static website exceeds the Free Tier, the typical cost for a hosting a static website on S3 will cost $1-$3 per month.