Building blocks of ThingHz IoT serverless architecture
Lately, In our series of blogs. We have discussed in detail about:
To create a robust IoT infrastructure we need to look at it from many aspects depending on the range, frequency, communication protocol, and many more. So to cover most of the use cases using IoT, We need to design our IoT architecture in such a way that it could support our present needs as well as new features rolling up in the future.
In this blog, we will be featuring the IoT cloud architecture that we have used in ThingHz. We are using AWS serverless approach. AWS provides many microservices that can be knit together to form a robust and scalable infrastructure. I had prioritized some criteria for my cloud before choosing serverless which are as follows.
- Robust: My IoT infrastructure should be robust. It should be designed in a way to handle thousands of requests at a time
- Scalable: My IoT infrastructure should be scalable. It should be designed in a way to scale up automatically. It should be able to withstand any serge.
- High Throughput: My IoT infrastructure should have high throughput. It should be able to process a large number of reads and writes at a time without a long delay
Wire diagram of ThingHz IoT serverless architecture
The figure shown below shows the IoT architecture using different AWS microservices. AWS microservices shown in the wiring diagram are the building blocks of my serverless architecture.
let's get in detail about these microservices:
AWS IoT
AWS IoT handles all the device-side requests. It receives all the MQTT requests and processes them. AWS IoT is used for device provisioning and device management. It gives some initial analytics about the device's health. We are using the MQTT protocol. device publishes metadata, and device payload to AWS IoT, and then AWS IOT uses rules to relay these requests to Lambda.
AWS Lambda
We are using the AWS Lambda function as a set of our code blocks. In our case, AWS Lambda serves a variety of functions.
- Parsing MQTT data from AWS IoT and storing it into database.
- It is used to send push notification
- It is used to handle mobile and web HTTP requests.
- Handling device OTA
AWS Timestream
AWS Timestream is our timeseries database to store incoming data from devices. It can handle incoming writes precisely with nanoseconds frequency. In some cases, ThingHz devices send the data every second. To handle such a huge amount of requests timeseries database was the best option.
AWS API Gateway
AWS API gateway handles all the HTTP requests from mobile and web. it reads and writes all the HTTP requests from a client. AWS Lambda functions are used as the code block to handle all the API Gateway HTTP events.
AWS Dynamo DB
AWS Dynamo DB is a fully managed, serverless, NoSQL database. We are using Dynamo DB to store device metadata and user information. All the reads and writes for mobile and web apps are taken care of by dynamo DB.
AWS Grafana
AWS Grafana is an analytics and dashboard tool. We are using AWS Grafana as our web application to monitor device data. It gives us a variety of analytics tools, charts, graphs, etc to visualize our data. It lets you query, visualize, understand, and receive alerts about your metrics.
AWS SNS
AWS Simple notification service is a notification platform. We are using AWS SNS to send push notification alerts and emails.
AWS S3
AWS S3 is a data storage platform that can store and process a large amount of data. We are using AWS S3 for Over the air firmware update for IoT devices. We are also using AWS S3 to host our static website.
Conclusion
I hope this blog gives you a clearer picture of the IoT architecture that we are following in ThingHz. It serves our operation very well. But still, every architecture has some pros and cons. AWS serverless architecture also comes with pros and cons. It is a highly scalable, fully managed architecture and it has served me very well. but integration with different microservices still needs many permissions and programming which makes it difficult to handle and shared architecture makes the requests slow which adds up to some of the cons.
I would also like to know about your architecture and what components are you using to make your scalable and robust IoT architecture.