Let’s take the example of an application that ingests MQTT messages from IoT devices and hosts a dashboard that allows a user to browse the current state of these devices. This could absolutely be built using Mosquitto running on Ubuntu inside an EC2 instance. The dashboard could then be built on top of Grafana running on the same instance:
Figure 14.1 – Simple non-cloud-native IoT application
The preceding diagram shows this arrangement. From the perspective of cross-cloud portability, this is great. However, this design is not ideal when looked at from the following perspectives:
Resilience – What if the EC2 instance crashes or its configuration is mistakenly deleted? The devices cannot send messages, nor can the user view the dashboard – not until the server is restored somehow. If that specific Availability Zone (AZ) is unreachable temporarily, you would have to manually restore the server to another AZ or Region. If you aren’t in a position to do that in an automated fashion, you might be forced to wait until a problem you have no control over is fixed.
Scalability – This architecture might be OK for dozens or even hundreds of devices, and a handful of users polling the Grafana dashboard. However, if demand on either side increases too quickly, the server might well crash under load it is not sized to sustain. Maybe you could fix this by increasing the EC2 instance size for a while – but at a certain number of devices, that is simply not going to work anymore
You will then need to fundamentally redesign your application to support horizontal scalability across multiple instances. How will you maintain a common state for the dashboard then? How will you balance devices between the instances? These are just the tip of the iceberg of things you now have to worry about.
Response time – What if your application does really well in the market, and you start getting customers from around the world? If this is running in us-east-1, will a customer in Australia be happy with the additional 200+ ms latency incurred when they access the dashboard? Will the devices time out trying to get their payloads to the broker
At this point, you wouldn’t just need to scale horizontally – you’d have to do it across multiple geographies. Questions about how you maintain a common state or ensure messages aren’t missed or delivered multiple times become far more complex.
New features – Let’s say you want to run some kind of analytics on the messages or do some kind of normalization of the data before it reaches the dashboard. You would need to implement additional application components – perhaps a NoSQL database such as MongoDB – and insert it between the existing elements. Probably not an easy change to make.
Troubleshooting – What if there is some difficult-to-pin-down issue such as messages from the devices randomly being lost with no obvious pattern? You will need to implement some form of instrumentation within the application to analyze historical data flows when such problems arise.
Compliance – Assume you wish to service customers in the EU, and the data being gathered is Personally Identifiable Information (PII). This would make your application subject to GDPR. Now, you need to somehow ensure that the data gathered on EU data subjects is specifically tracked and kept within the country of origin. That is a complicated thing to do if you refuse to use a cloud-native service that is already aware of such things.
Security – How do you handle authentication for the devices or users logging in to the dashboard? A simple local Privileged Access Management (PAM) database on the server won’t scale and will get hard to manage really fast. What if a compliance regime you are subject to insists you identify IoT devices by client-side certificates? How do you distribute them to a fleet of thousands or millions of devices?
Cost – If you wind up deploying EC2 instances around the world, how do you optimize for cost? Native services such as AWS IoT Core charge per message received, but each one of your running EC2 instances charges per hour it’s turned on – whether it’s being used to its full capacity or not.