What we did in last the 11 chapters has always been painted as a hazy picture by many—only to prevent people from taking charge and building their own platform as they deemed fit. As any sane person would do, we started by learning the landscape of the Internet of Things and then slowly delved into the specifics of it.
By Chapter 3, we had a fair idea of what is required to build our own IoT platform, and we created a detailed version of the requirements in the subsequent chapter. It becomes much simpler to execute a plan once the goals and directions are clear. So, we were able to swiftly move through that phase of building our own platform’s core.
Understanding a few topologies and technologies, such as MQTT, has been a key to development, which we did in Chapter 6. Knowing more about MQTT not only helped with building the message broker for the platform, but it has also opened many other opportunities for live, two-way communication across several systems, applications, and devices. This can open doors to many new applications and solutions.
In subsequent steps, we built various APIs and microservices, and we addressed the security aspects as we progressed. Ending with the interactive documentation, we accomplished the task of building our own IoT platform.
The process by itself would have taken less than 24 hours to build the platform and get it up and running. This is contrary to what many would tell you when you ask, “How long will it take to build my own IoT platform?” Although we are not boasting a full-blown, massive IoT platform, the developed version is just a few steps away from being one, and this is a significant stepping stone.
Increasing Security for the Cloud Instance
While we have established a firewall, SSL, and many other things, securing the cloud instance is a separate exercise. The principles that you should apply in securing a cloud instance are the same as those you would apply in securing any other operating system, whether it is virtual (cloud) or real (in-premise).
Enabling and reviewing audit logs is one of the best practices that you can follow, and it does not require anything to set up explicitly. The stacks we have installed are already taking care of it.
For the entire process, we utilized the root access of the system. This does not have to be that way, however; you can disable the root access permanently if you want to.
One of the many annoying things you notice while maintaining your own cloud instance is bots! There are several programs that constantly scavenge for open ports or access and install malware or exploit another free machine. Our firewall restricts these bots from accessing important resources; however, a few essential ports cannot be closed. Ports such as SSH, MQTT, and other web-facing APIs need to be open.
A clever strategy that people deploy in securing an SSH port is to change the default port from 22 to something conspicuous. Although many experts would advise that this is not the best strategy, believe me, it works because it adds one more hurdle to nuisance creators. Combine it with SSH keys, and you are good to go.
Some people would go a step further and introduce the port knocking mechanism, which makes it extremely difficult (and near impossible) to break in via SSH access.
Adding programs like fail2ban or mod-security is also a helpful strategy for improving security. These programs monitor log files and detect potential attacks. Based on the rules you set up, these programs can blacklist attacking IPs or ban or rate limit them for a short period of time.
In addition to securing a cloud instance, you may also consider encryption of data (in flight or at rest) as a potential strategy. This has clear overheads involved, such as encryption/decryption while storing and retrieving data, which may also increase the packet size in transit. However, a pragmatic decision has to be made, and then this strategy can be put in place on the top of the core platform infrastructure.
In general, no security strategy is enough for an ever-changing and evolving cyber world; however, you must start somewhere, and that depends on what you want to achieve from your infrastructure. It absolutely depends on each situation.
What About SQL Injection Through APIs?
Remember that security is a very vague term. Just because we have a secured API with SSL and authentication does not mean it is secure. Adding some type of encryption on both ends (sending and receiving) hardens it further. However, this is something beyond the scope of this book, as we are only establishing a core platform for that exchange. What is exchanged is still open. The platform exchanges encrypted messages just the same as non-encrypted messages without any fuss.
In the preceding snippet, code that is marked in bold are new additions. We have already installed a MySQL package. The code block calls it from global context of Node-RED and captures it in another variable called mysql. We are then simply using the mysql.escape function to escape user input, which is one of the many standard practices for avoiding SQL injection.
Save the file and restart Node-RED to put this change into effect. Now, when you deploy the flow with changes in the create-query functional node, SQL-escaping will be effective. The same change can be applied to all the query blocks on our API flow sequence.
Should We Have Used MongoDB Instead of MySQL?
Quite frankly, we had to start somewhere, and MySQL was a stable choice. MongoDB can be used in place of MySQL too, which will call for changes in the data schema and some of the code structure.
However, as far as the architecture of the core platform is concerned, it will not change at all. There are several tutorials and blogs that compare MongoDB and MySQL. These articles explain features and function-level differences and discuss where to use these databases. Interestingly, the IoT platform is an application that sits at the crossroads of many of those suggestions. You could go either way and still be right.
In a nutshell, start with MySQL and then include MongoDB as you grow. This will not break things later, and it will be a one-time exercise to change over.
I strongly believe that a lack of features is not a lack of functionality. What we have built is absolutely essential and mandatory, without which it will not be an IoT platform. Anything else, that we wish to add can be regarded as a feature that can be added on the top whenever required.
Some Experts Might Still Try to Talk You Out of This
Let them! That is all I can say at the outset; however, think deeply about why others are trying to talk you out of building your own IoT platform. What is their argument? If you clearly understand the argument behind the suggestion to buy an off-the-shelf platform rather than build your own, then it will make better sense. Off-the-shelf platforms are popular and have cool features, and big companies are behind them—but these are weak arguments.
One of the key problems with freemium and off-the-shelf platforms is a lock-in . Even if it claims to be easy to detach and go elsewhere, in practice, it is far from easy to do this. You would be better off building your own than carrying the risk of being locked in. There is also the threat of having a legacy lock-in; that is, you will find it extremely difficult and expensive to change the underlying technology in the middle. Once you are set, that is it: no changes until you upgrade. This is not a good choice in my opinion.
But, if you are not interested in the ongoing maintenance of your own platform, no matter how small that may be, you may want to think twice.
If your business needs a high level of control and high levels of security over the data and overall infrastructure, building your own is the best option. Let the experts know this.
The amount of money that you want to spend on building your own platform vs. the amount that you can save by buying off the shelf or by subscribing is a classic argument. Many experts do not account the total cost of ownership (TCO). This builds up over time, and at the outset, justifies the contrary decision. And the argument that managing your own platform consumes valuable time, while a managed platform gives you time to do other business is a fallacy. You end up managing managed platforms in one way or another without realizing it. So, the proposition is not so different after all. If you are having second thoughts, do the cost-benefit analysis over a longer term, like seven to ten years, and then see what makes sense. If the subscription or buying option is still lucrative, make the move.
See who these experts are and check where their vested interests lie. Seek independent opinions, do the objective evaluations, and then make the call.
How Is Our Platform Different from AWS, Google, and Azure?
AWS, Google, and Azure are fundamentally cloud services—IoT as well as others, whereas what we have is a purpose-built IoT platform core.
Cloud computing is a majority part of the others’ offerings; whereas in our case, the IoT core is the central function and cloud computing is the support function.
The other platforms are essentially built as jack-of-all types. We have a vertical-specific IoT platform that is intended to be service or product specific upon extension.
The other platforms mainly boast various features and add-ons, which are “good to have” things on the IoT platform but may not be required for all IoT products or services. On the other hand, we have exactly what each IoT product and service needs at the minimum.
All of the others are managed platforms, whereas we are managing our own (or you can outsource it). From a price standpoint, they are all about the same when compared in parity.
Offerings like instant provisioning, autoscaling, compliance, security, and overall management are at par whether you build your own or buy.
Our build has the benefit of being purposefully built, it can be low power, and it is very customizable. It is not inherently multisite nor does it have redundancy, as the cloud services do.
There may not be like-to-like comparisons with the scale or size of the platform; however, if you are looking at it from the perspective of your own requirements, the comparison is simpler.
There Is a New Version of MQTT
The MQTT version used to build our IoT platform is 3.1.1, which was the latest version at the time of my writing this book. MQTT version 5.0 was released in October 2018. Although the specifications were released, brokers and client implementations were not yet available.
While version 3.1.1 is still the most stateful and scalable IoT protocol, with millions of simultaneous connections as a benchmark, the newer version is designed to make it easier to scale to immense amounts of concurrent connections.
Enhancements in scalability for large-scale systems
Improved error reporting with negative acknowledgments and error codes
A capability discovery mechanism to let clients know what a broker is (and is not) capable of
Request-response behavior with the publish/subscribe mechanism
Shared subscriptions among multiple clients (cluster of clients)
Time to live (TTL) for messages and client sessions (such that a retained message could expire after a specified time)
The Eclipse Paho project is driving most of the development to bring MQTT v5.0 clients and brokers, along with many other (open source and other) players. While MQTT v5.0 does not have a significant advantage over v3.1.1, it does solve some problems in specific situations. So, if you think this might be the case for you, keep an eye on the latest developments. Even if it is not of direct interest to you, seeing v5.0 in action could spark some possibilities.
My Platform Is Ready. Now What?
The first thing you should do with your own IoT platform is develop a sample application. Why? Because it will give you a better idea from a full cycle standpoint and may highlight issues in the build. It may show what is not adding up or what is missing. Accordingly, you may have to fine-tune a few things to suit your requirements.
More importantly, when you develop a sample application, it serves as a boilerplate for the next few applications. The sample application also works like a sandbox for testing new things and changes while we make it. So, even if you have a final application that is waiting to be developed, spend a little more time to work on a sample app; it will help in the long run.
Additionally, you can extend APIs and microservices to your liking; add more authentication methods and checks for your platform access, or build a user and device management app to ease out future requirements.
The Next Big Thing
Emerging technologies are still emerging, and the Internet of Things is still finding its ground, marching toward the maturity it deserves. If you wish to make this platform bigger and even more powerful, try standing up multiple instances and create a high-availability infrastructure.
Use MQTT bridges and connect with other platforms for interoperability. You can also run multiple MQTT instances on the same cloud with different ports and effectively separate various applications per port while using the same platform core. This can help you create a multitenant infrastructure for your multiple applications and keep them away from data contamination.
Learn and integrate tensor flow into the platform to add machine learning capabilities. This can take your platform to a different usability and utility level.
The possibilities are endless when you have such a powerful core infrastructure ready, and it is in your full control.
If You Need to Find More Resources
The Internet is a one-stop shop in this case. Node-RED forums and NPM websites are places you should frequent. This is mainly because our platform heavily leverages these two technologies.
Additionally, since the core architecture is now in place, adding more technologies and protocols is not going to be a problem. Whether it is including MongoDB to the platform (and there is Node-RED node for that) or implementing encryption/decryption of data in-flight or at rest, depending on the technology you want to utilize, the search-ground may change, but eventually, they wire up nicely together to make the platform more powerful; one that is your own!
Finally…
One of my many objectives for writing this book was to provide a step-by-step guide on building something that is quite valuable and yet not openly available. I have interacted with several clients and colleagues who are dismayed because searching “how to build your own IoT platform” does not yield anything useful. I hope this book has helped you find something useful in this context.
To me, this is not the end, but the beginning of your self-sufficiency in emerging technologies, and for this, I wish you all the best!