In the Robotic Process Automation universe, where almost everything is unassisted, automated and “auto-magically” managed, ensuring high availability of the RPA platform and all of its components is an essential requirement.
According to the classic definition, “high availability” in the context of an information system means the ability to recover a service after a fall without the intervention of any administrator or operator.
The Jidoka platform includes a rebound of the automatic controls to ensure that the console and agents (nodes) are always in service. Such controls periodically check the state of each component and have the reception of information from them.
Jidoka offers licenses both under a Cloud model (infrastructure managed and administrated by us) and On-site (on the customers’ data center and managed by them):
- Cloud consoles include an automated remote monitoring system. If a problem occurs, the system is able to activate the necessary services in order to make the console available online again.
- On-site consoles allow the configuration of actions to be executed as a consequence of an event. The platform can execute multitude of actions associated with a specific event. The system registers many types of events.
The platform provides events and associable actions to the Jidoka agents, a Java component that runs on the nodes and executes the robots, which allow their monitoring.
Although the client’s IT team has multiple options to implement high availability mechanisms on the Jidoka software components, we wanted to include a new option: the ability to use Kubernetes.
Kubernetes (K8S) is an Open Source system for the deployment, scaling and management of applications included in containers (Docker or others) that was initially designed by Google, who later donated it to the Cloud Native Computing Foundation.
With Kubernetes we can create a cluster of machines to replicate our services in execution. Kubernetes will then be responsible for monitoring the status of the same, from the use of CPU to the memory stress. Kubernetes can also indicate if the cluster is underutilized. A cluster is therefore a managed group of standardized VM instances.
Should any of these machines fall, Kubernetes will restart it immediately.
In addition to clusters and VM instances, Kubernetes handles the concept of pods. A pod is an application giving some type of service. It is possible to combine pods into larger elements or use somewhat less simple pods, although the important fact about pods is that they are the minimum unit that Kubernetes will execute. If a pod stops running, Kubernetes will automatically raise a new pod either in the same VM, or in another machine available in the cluster.
In this way, Kubernetes not only ensures that the VMs are always available in number (duplicates) and form (execution), but also the pods that are executed in them.
In addition to the pods, Kubernetes exposes services that allow connectivity from the outside to the pods.
These services facilitate administration and configuration tasks. An example of this is the load balancing service, which allows to publish an IP address by masking the IP addresses of the real Kubernetes VMs. Thanks to the load balancer and the ability of Kubernetes to provide unassisted VMs and pods, we can always have our software available.
A Kubernetes pod is a piece of software included in a container, usually a Docker container, so any system that we “dockerize” can easily be included in a Kubernetes cluster. Therefore, you can benefit from the load balancing, high availability and monitoring offered by this tool.
In Jidoka, both the console and the nodes are available in Docker containers, so their inclusion in a Kubernetes cluster is practically direct.
We invite you to watch a video of the installation of Jidoka in Kubernetes where you can check that, in case of any drop in service, the system will restore it again, in matter of seconds!