{"id":27253,"date":"2019-06-25T09:21:37","date_gmt":"2019-06-25T13:21:37","guid":{"rendered":"https:\/\/centricconsulting.com\/?p=27253"},"modified":"2023-08-18T13:19:07","modified_gmt":"2023-08-18T17:19:07","slug":"optimizing-iot-costs-while-using-bluebeak-beacon-technology","status":"publish","type":"post","link":"https:\/\/centricconsulting.com\/blog\/optimizing-iot-costs-while-using-bluebeak-beacon-technology\/","title":{"rendered":"Optimizing IoT Costs While Using BlueBeak Beacon Technology"},"content":{"rendered":"
In the\u00a0<\/a><\/span>previous\u00a0<\/span>blo<\/span>g\u00a0<\/span><\/a>of<\/span>\u00a0this series, we\u00a0<\/span>examined a real-world Internet of Things (IoT)<\/a> project called BlueBeak<\/a><\/span>.<\/span>\u00a0<\/span>This framework leverages various cloud components to<\/span>\u00a0deliver<\/span>\u00a0location-<\/span>based services<\/span>\u00a0for several industries<\/span>, including healthcare and retail<\/span>.<\/span>\u00a0<\/span>Recall from the previous blog that IoT<\/span>\u00a0is all about data, specifically<\/span>:<\/span>\u00a0<\/span><\/p>\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 <\/a><\/p>\n 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.<\/strong> Below, we take a look at how we improved each stage of the IoT application.<\/p>\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 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 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 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 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\n
Evaluating the Cost<\/h2>\n
Data Ingestion<\/h2>\n
Data Decisions<\/h2>\n
\n
Data Storage<\/h2>\n
\n
Data Display<\/h2>\n
Data Insights<\/h2>\n