The main challenge
If you’ve come into industry from another sector, then you might think that Industry 4.0 from a software and integration may be tricky. Yet, the truth is that in theory the process should be straightforward, at least in terms of so-called cloudification.
However, that’s often not the case. In Industry 4.0, the proper infrastructure architecture rather than software is the backbone of success or culprit of the failure of the whole endeavor.
Wondering why? Well, there are a number of relatively common reasons for this, which we have outlined below:
- Industry customers want to have flexibility in terms of their computer systems and scalability of Cloud solutions for data aggregation and analysis, meaning that they are often opposed to fixed, one-size-fits-all solutions.
- Factories often don’t have access to a stable, fast, and readily available internet connection.
- Factories need to operate if a network is down, and therefore aren’t particularly keen on relying solely on an internet
- The IT setup in factories is as simple as it gets, almost always compromising HA, scalability, and access for the sake of practicality. This presents real issues when it comes to technology upgrades.
These issues lead to partially conflicting requirements when it comes to non-hybrid approach (either On-Premises or Cloud):
- leverage Cloud infrastructure and services,
- factory production process cannot rely on it.
In-Cloud or On-Premises – how to combine it? The solution
The most obvious approach is to have both On-Premises services and In-Cloud services. However, it can be difficult to know how to separate the two.
Let’s take a closer look at what each of them comprises.
On-Premises essentially involves whatever is needed to run factory production without interruptions, while Cloud services basically cover all other aspects. This has two issues:
- factories need a lot of features of our product to run the production – that often includes some analytics,
- different customers have different needs and require guarantees in terms of what is needed to continue the production process.
This means that if we want to have homogeneous architecture across customers, knowing that some factories have poor internet access and cannot rely on Cloud based frontends and backends, everything should be On-Premises.
That said, there are alternatives, improved options that we can also consider.
- Have aggregated (for multiple factories of given customer) views and analytics only in Cloud.
- Move the rest of the services between Cloud and On-Premises based on needs and availability.
Although both options provide reliable alternatives, they can also throw up several issues:
- services with persistence,
- synchronizing state between Cloud and On-Premises is challenging if the network is not reliable,
- homogeneous infrastructure setup required between On-Premises and Cloud for this option to be easily maintained and swappable.
Homogeneous infrastructure setup
The Cloud setup can be based on the IaaC and gitOps approach. In this case, both infrastructure and application are defined and managed through the code. At ANT Solutions we achieve that through Terraform, Flux and Gitlab CI/CD orchestrating Cloud Setup, Resources, Kubernetes, Clusters, and applications.
Now, you may be wondering whether or not we can use the same setup On-Premises, which is often a single bare-metal setup. Well, the answer is yes! The most obvious solution is to use Kubernetes also On-Premises and orchestrate it via the same codebase. However, Kubernetes is not cheap to administer for On-Premises scenarios and, additionally, On-Premises industry setups often are minimal, containing one or two bare metal hosts.
Fortunately, there are tools designed to help with that. These include small, cheap, single node Kubernetes setups designed for Edge/On-Premises usage:
- micro k8s,
That enables us to use the same gitOps Flux code, no matter where the application has to be deployed and the same app setup via Helm Charts, ruling out double-configuration, double-setup scenarios, which are both error-prone and expensive.
Synchronization after downtime
The other aspect we need to have control of is our ability to sync data between On-Premises and the Cloud. For simplicity’s sake, let’s rule out application state exchange and simply consider the data acquisition from the factory, that is required for both data lakes and applications.
The first thing that comes to mind is to introduce retries and buffering. However, this may seem problematic in terms of code complexity and not particularly reliable as an On-Premises infrastructure, as it can lead to data loss.
Instead, the answer is asynchronous communication. We choose NATS which offer a range of interesting features, not only delivering asynchronous communication, but also automatic replication of data.
Whenever a system suffers downtime, NATS servers will synchronize the data, making the process seamless for our application. On-Premises software doesn’t care about network being up, or even about the existence of Cloud Services, and Cloud Services get all data whenever it’s available.
The result – configuration without making changes
All of the above points enable us to setup bases for decoupled adaptive hybrid architecture that enables swapping services between Cloud and On-Premises with minimal effort and without relying on any Cloud Provider hybrid-related products. These products generally locks us into subscription-like plans and don’t allow to inter On-Premises scenarios based on the same architecture.
The fact that both environments are decoupled and homogeneous also allows us to freely choose between on-premises setup, cloud setup, hybrid setup.
This, in turn, enables us as ANT to offer our customers whichever setup works best for them without needing to make any changes to infrastructure architecture. Any modifications are strictly limited to infrastructure configuration.
It should be mentioned that we usually try to encourage our customers to go as far into the Cloud direction as possible, as this pays dividends in terms of HA and scalability.
Additionally, homogeneous architecture makes testing different scenarios in replicable environments a breeze, and boosts further speed, heavily reducing bugs in production.
If you’d like to find out more about how ANT can help your company to get ahead in terms of ANT challenges, then don’t hesitate to get in touch with us.
Read about our other products: