Microservice-based application design for IIoT cloud applications
A few key characteristics of IIoT applications are diversity in data, security, IIoT scale-machines generating tons of data, visualization of data and finally, high availability and reliability. Microservices architecture is a perfect fit for these types of IIoT application demands. Microservices architecture is all about developing applications using small but well defined, decomposed, modular services that can be deployed independently. Each of these services can model a business function and expose a set of APIs. Microservices architecture enables development of services that are loosely coupled and uses technology choices appropriate for that service.
In a microservice architecture, applications are built using smaller services aligned with business functions which interact with each other using RESTful APIs. These services are secure by design using HTTPS protocols and OAuth for authentication, and can use a variety of programming languages appropriate for their implementation; for example, a service which needs high parallelization may use the Go language, and, if the application has lots of business logic, a good choice will be to use Java and so on. This model of using different languages is called polyglot programming. In addition, these services have a choice of various different messaging services and datastores such as relational DBs, or NoSQL stores, or in-memory stores, to implement a robust service. Typical in an IIoT application architecture, as an example, is the time series service which can use a NoSQL DB along with Java as its data store/programming language. And also, perhaps, the events service can use a relational datastore as its database, which includes the Events table. Visualization can be built using an Angular/React application, such as using the Node.js application, as given in the following example. There are many advantages to this design. Because the services are isolated from each other, a developer can change their service's schema without having to coordinate with developers working on other services and can independently deploy the software to production:
This type of decoupling in-turn enables development of highly salable services that can scale independently from each other, for example, the time series store can be scaled to multiple VMs (virtual machines) versus a user management service which can use two to three VMs.
Our preceding example shows that we have broken the IIoT application into various smaller services, such as:
- Time series service, which was typically developed using either Java or Scala with an NoSQL data store such as Cassandra
- An Events service, developed using Java with a data store of relational db, such as Postgres
- A User Management service using a relation data store
- IIoT, UI, and visualization applications using Node.js and Web UI frameworks, such as Angular or React
- Notification services using SendGrid/Twillo
- Asset services using PostgreSQL
- An analytics service using Python, or real time systems such as Spark with its own data storage systems
For developing a robust microservices architecture The 12-factor app (https://12factor.net/) methodology is highly recommended to be adopted. The 12-factor app methodology covers best practices, based on a few specific parameters for deployment of cloud-native applications:
- It uses declarative formats such as YAML—yet another markup language—files to store environment specific configuration regarding dependent services, log levels, API keys, services, and database credentials for greater portability between environments.
- It limits differences between development and production, for continuous deployment.
- It aims for stateless applications that are designed to degrade gracefully. That means that, if a dependency fails, the app itself does not become a failure.
- It allows for scaling up and down without major changes.
The 12-factor methodology is programming language agnostic and works with any combination of backing microservices.