Choose the operating system for our cloud instance
List the base specifications of the instance
Determine what we need on our local computers for access
Expand on our own IoT platform’s block diagram
Deciding Cloud Instance Specifics
The total cost of ownership. The most obvious advantage is that Linux is free, whereas Windows is not. A single-user license may not cost much; however, the total cost of ownership can be higher over time, and thus increase ongoing costs.
Reliability. Linux-based systems are more reliable than Windows. Traditionally, Linux systems are known to run for years without having a failure or a situation that demands restarting. This is a critical criterion for the selection of an operating system for our IoT platform.
Hardware resources. Linux systems consume fewer system resources like RAM, disk space, and so forth, when compared to Windows. For our IoT platform, we need at least 1 GB of RAM and 20–25 GB of disk space. That said, costs remain in control if we go with a Linux-based system. A Windows system may not run efficiently with this level of specification.
Security. Linux-based systems are built with security at a fundamental level. It is the choice for more secure environments. Due to this inherent security, we will save on antivirus costs and additional system overhead.
Control. Control is one of the main reasons for building your own IoT platform. Linux-based systems provide control at all levels. No bloatware means a lot for speedy systems like our platform. Being in control of what is installed helps us closely maintain that control.
Power. Windows presently runs only equipment that will not run at the low power desired for systems running often or always.
Additional Specifications
We need a minimum of 1 GB RAM and at least 20–25 GB of disk space on the operating system for effective basic functioning. We also need Node.js and Node-RED software for writing our platform code.
With a Linux-based system, we need a LAMP stack installed on our system. A LAMP stack is a set of open source software for creating websites and web applications. LAMP is an acronym for Linux-Apache-MySQL-PHP. It consists of the Linux operating system, Apache HTTP Server, the MySQL relational database management system, and the PHP programming language.
In addition to these basic software packages, we need several add-ons; we will get to that list as we progress. Once we have our instance up and running with the LAMP stack, Node.js, and Node-RED installed, we have a basic infrastructure ready to proceed.
Where Do We Get this Cloud Instance?
There are quite a few choices for putting a cloud instance on a virtual private server—AWS (Amazon Web Services), Google Cloud, Alibaba Cloud, and DigitalOcean, to name a few. Moreover, there could be many more, which may spring up soon.
Which vendor you choose for the cloud instance depends on your vendor preferences, pricing for the instance offered by these vendors, and many other factors.
On many fronts, DigitalOcean seems to be a good choice; mainly because it offers a nice, clear user interface without the unnecessary clutter of choices and options. This is the key to remaining agile and finishing tasks quickly.
From an affordability perspective, DigitalOcean is clearly the best option given that it has transparent pricing, as compared to complex millisecond calculations from other vendors. The price is based on hourly billing, and it is usually fixed for a month on monthly usage.
DigitalOcean is not a managed service like AWS or Google Cloud, but that should be okay for our purpose. A cloud instance on DigitalOcean servers must be managed by the owners—from upgrades to patches, and so forth, which is not the case for AWS and Google Cloud. However, when dealing with bare-metal cloud instances, things are not that simple, so even with Google Cloud and AWS, you have to take care of your own system if it is a bare-metal instance.
In short, if you have a massive scale implementation, AWS or Google Cloud should be chosen; for all other purposes, DigitalOcean is a better choice.
For our platform, we want agility (i.e., build within 24 hours), cost-effectiveness, transparency in billing, full control, and other such aspects. So, we will use DigitalOcean as our cloud instance in this book. However, if you are comfortable with other vendors, that is fine.
What About Our Own Machine?
Although we will be doing most things in a cloud instance, and the majority of the development will happen in a cloud environment, we still need some tools installed on our local machine (laptop or desktop).
Terminal emulator for SSH. We will use a program called PuTTY , which is a well-known and widely used terminal emulator. It is a free and open source program with support for several network protocols, including SSH, SCP, Telnet, and so forth. It allows raw socket connections. It can also connect to a serial port of a computer, which may come in handy when testing a few hardware modules on our platform.
Basic editor. This can be as basic as a Notepad program. I recommend Notepad++ . It is a free software text editor for use with Microsoft Windows. It supports working with multiple open files in a single window and thus comes in very handy. The project’s name comes from the C increment operator.
FTP program. There are several choices for FTP applications, including WinSCP, FileZilla, CoreFTP, and FireFTP. We will use FileZilla throughout this book.
PuTTY, Notepad++, and FileZilla are effective and fit for our purposes; however, they are not mandatory. You are free to choose any other available options.
Expanding on the IoT Platform Block Diagram
In Chapter 2, we discussed a detailed block diagram of an IoT platform. Now we will decide which blocks we want to prioritize for quick development and which functions/features we want to develop in the first pass.
Edge Interface, Message Broker, and Message Bus
This will be a fundamental function for our IoT platform, and we will work on it at the very beginning. We will use the MQTT protocol for message exchange because MQTT is almost a de facto protocol for edge devices and IoT applications communication. We will discuss MQTT later. This will be one of the most critical modules of our IoT platform.
Message Router and Communications Management
At the outset, we will develop only a skeletal message router. It will not have a major communications management functionality. We will develop this module as a placeholder for the second pass of the development.
Time-Series Storage and Data Management
As explained in the previous chapter , this is not a core function; however, it is one of the elements that we will build in the first pass to use later.
REST API Interface
To test the platform functionality from device to platform and from web applications to platform, the REST API is necessary. We will start with skeletal APIs, and then add complex features in later passes.
Microservices
Although we will not be developing them until the second pass, we will be making a few arrangements to make sure that when we add them in the later stage, we will not have to make major changes to the fundamental design. By design, microservices are not critical in an IoT platform.
Rule Engine
As this is one of the most powerful features in an IoT platform, we will keep it in perspective from the beginning. The rule engine cannot be developed in one go. We need multiple passes to make it good.
Device Manager and Application Manager
While good to have, these functionalities are not a core part of the platform, so we will not be developing them for our IoT platform. It is still easy to use numerous devices and applications without formally having a device manager and an application manager .
Our Own IoT Plat form Block Diagram
Block diagram of our planned IoT platform implementation
In a nutshell, our platform will be fully functional from the perspective of a core IoT platform. All the aspects that are considered features will be left out for future enhancements. This is a good compromise of speed over features and will in no way harm the product performance of this platform.
Summary
So far, we have made various choices for cloud instance specifications. We listed what is needed on our laptops to build the platform.
As a next step, we will create a wish list for our IoT platform’s REST API, and we will detail what we want each API to do. We will also list the requirements for an edge interface and broker, a database manager, the message router, and a few microservices.