In the second example implementation, we presented the problem, drew a high-level design, and directly proposed the solution unlike the way we drilled the first implementation. One reason for this is that this problem is simpler than the previous one; the other reason is that by now, we have already learnt a lot about the underlying architectural principles.
Let's just have a quick end-to-end roundup of this Azure-based serverless implementation architecture.
We have a home hub device connected to the Internet, equipped with some microchip based OS, most likely a Linux distro, running our engine written in C language, and talking to us over an Azure cloud. This HH device acts as a gateway allowing the consumer to control other home smart electrical devices. It uses the Azure IoT gateway, SDK, allowing it to communicate with the IoT Hub in both directions. From the IoT hub, we trigger an Azure Function, which saves data to a NoSQL PaaS database: DocumentDB. Data stored here can be used for various purposes at a later stage, but is not part of our problem now. Real-time stream data also flows from the IoT hub to Azure stream analytics, doing some calculations, like warning users that all of their light bulbs have been switched on for the last 12 hours; these results are stored in the Azure blob. Saving it auto triggers our event-based function, which then sends the calculated warning over to the user on his smartphone to alert them using the Azure notification hub (which is capable of sending notifications on Android, iOS, and Windows). The user can see the alert information on his smartphone, and can take an action like sending a control message to switch on or off the smart device appliances. It does so by sending an event to an Event Hub which is capable of receiving messages from smartphones. Note that, here, we could have also used IoT Hub instead of Event Hub. After receiving a control message on Event Hub, another Azure function is automatically triggered, which passes on the notification to an IoT Hub, which then passes on the control message to the devices' gateway, that is, Home Hub. HH is able to switch on or off the individual devices, as it's connected to them over low-energy Bluetooth. We could have also let our smartphone directly connect to the home hub by implementing another interface dedicated for smartphones, and then, after getting the control message and acting on it, the device gateway could send this update to the Azure cloud. But then we could not have controlled the smart devices at home when we are outside the home, and we would've needed to make our HH even more complex. These trade-offs let us decide which option is more viable for us to take, and then we go in that direction given all the practical limitations and possibilities.