- \n
- Captur<\/span>ing<\/span>\u00a0the data\u00a0<\/span>generated by d<\/span>evic<\/span>es<\/span>\u00a0<\/span><\/li>\n
- Mak<\/span>ing<\/span>\u00a0real-time decision<\/span>s based on the data<\/span>\u00a0<\/span><\/li>\n
- Stor<\/span>ing<\/span>\u00a0the data<\/span>\u00a0for\u00a0<\/span>later use<\/span>\u00a0<\/span><\/li>\n
- Analyz<\/span>ing<\/span>\u00a0the data to gain operational insights<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
In this\u00a0<\/span>final\u00a0<\/span>installment of this\u00a0<\/span>IoT series, we\u2019ll take a look at<\/span>\u00a0the costs that drive a typical IoT project and how to optimize those costs<\/span>.<\/span>\u00a0<\/span>To get started,\u00a0<\/span>let\u2019s take a look at the Cloud components used for\u00a0<\/span>the original\u00a0<\/span>BlueBeak<\/span>\u00a0solution<\/span>.<\/span>\u00a0<\/span><\/p>\n
Evaluating the Cost<\/h2>\n
![\"BlueBeak](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2019\/06\/BlueBeak-Chart2-62019-1024x445.png\")
<\/a><\/p>\nThe 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.<\/strong> Below, we take a look at how we improved each stage of the IoT application.<\/p>\n
Data Ingestion<\/h2>\n
Much of the cost and computational overhead in BlueBeak comes from the ingestion and processing of the incoming data. A process running on Docker<\/a> container running in AWS Lightsail<\/a> must always <\/strong>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.<\/p>\n
This event-driven architecture is much better suited to a newer technology, generically called Serverless computing. With Serverless<\/strong><\/a> computing, we don\u2019t require dedicated instances. Instead, an event triggers the provisioning of resources needed to perform a computational process.<\/p>\n
AWS calls its Serverless platform Lambda<\/strong><\/a> and gives it the tagline \u201cRun code without thinking about servers. Pay only for the compute time you consume.\u201d 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.<\/p>\n
Data Decisions<\/h2>\n
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 \u201cvisit.\u201d<\/strong> Similarly, another Lambda function determines when a beacon leaves a room. There are two key reasons for leveraging Lambda for these business rules:<\/p>\n
- \n
- 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).<\/li>\n
- We can implement the business rules with small, self-contained, stateless code segment: a perfect candidate for a microservice.<\/li>\n<\/ol>\n
Data Storage<\/h2>\n
For our initial implementation of BlueBeak, we used Couchbase<\/strong><\/a>, 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:<\/p>\n
- \n
- Licensing costs associated with Couchbase<\/li>\n
- Export and Query limitations associated with Couchbase<\/li>\n
- Additional compute needed to host Couchbase<\/li>\n<\/ol>\n
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.<\/strong> After considering both NoSQL and relational database solutions available on AWS, we ultimately chose AWS Relational Database Service (RDS<\/strong>)<\/a>.<\/p>\n
More specifically, AWS Aurora<\/strong><\/a>, 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.<\/strong><\/p>\n
Data Display<\/h2>\n
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\u2019t 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.<\/p>\n
We can store these so-called static websites in AWS Simple Storage Service (S3)<\/a> 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.<\/p>\n
Data Insights<\/h2>\n
- Mak<\/span>ing<\/span>\u00a0real-time decision<\/span>s based on the data<\/span>\u00a0<\/span><\/li>\n
![\"BlueBeak](\"https:\/\/centricconsulting.com\/wp-content\/uploads\/2019\/06\/BlueBeak-Chart1-62019-1024x495.png\")
<\/a><\/p>\n