How to orchestrate dynamic container instantiation and legacy applications with HCL Workload Automation

This article describes possible scenarios where HCL Workload Automation enables dynamic services creation. The need is to enable the prompt and dynamic provisioning of a service, triggered by external events such as: a new user subscribes to the service, a user logs in to the service, a user logs out of the service, a user signs off from the service.
​

This article derives from of a study made for a real case, and it’s presented here as abstract as possible. 

Reference environment and problem to solve 
The reference environment of the following scenarios is that of a consolidated enterprise that delivers services to the consumer market, with legacy systems such as: 

• CRM 
• DBs 
• Billing 
• Invoicing 
• and more

The company wants to launch a new service for the consumer market, and wants to optimize the IT resources for it. This led to design an architecture for the service itself that is based on docker containers, so that the service consists of a series of docker images intended to work in conjunction among them, and to interact with legacy applications. 

The service will be implemented by creating dedicated docker containers for each user, so that anybody will have its own separated instance. 

The nature of docker guarantees therefore scalability and IT resource optimization, but it does not solve the need for: 

• Promptly instantiate the containers when needed 
• Orchestrate the interactions between the service on docker and the legacy applications 

These two aspects are where HCL Workload Automation comes into play. 
In the sequel, the scenarios are described. 

Note: the diagrams below present as container only the elements that are strictly necessary to be docker-ized, other elements of the diagram that are represented outside docker could be implemented in container if needed (this is to be analyzed case by case and it’s not in the scope of this article). 

Scenario 1 – end user service instantiation 
Trigger of this scenario: 
1. A new end user registers to the service. 
or 
2. An existing user logs in again to the service. 

Flow of events 
1. There has to be a front-end user interface that intercepts the action from the end user, typically a portal or an app. 
2. HWA APIs are invoked to trigger the proper jobstream(s). The jobstreams may vary according to the event (for example, new user vs returning user). 
3. HWA Agent invokes kubectl or HELM, instructing kubernetes to create the architecture instance for the end user (a container with HWA agent will be instantiated as well). 
4. All needed containers (as well as the HWA agent container) are created by kubernetes. 
5. If needed other actions can be performed on other systems to orchestrate the complete set up of the service. This may include additional actions on the newly instantiated apps in the container.
6. The service can be delivered to the end user. 
7. Centralized monitoring of the scheduling and automation results are presented to the administrator of the service.

Scenario 2 – end user interaction 
Trigger of this scenario: 
1. A logged in user interacts with the service. 

Flow of events 
1. The end user interacts with the service, so that changes are required on various systems.
2. The service triggers HWA via API .
3. HWA orchestrates the needed actions on all the systems involved, including the service apps in the containers. 
​4. Centralized monitoring of the scheduling and automation results.

Scenario 3 – end user environment clean-up 
Trigger of this scenario: 
1. A logged in user sign-off or logs out from the service. 

Flow of events 
1. The end user initiates an action (sign off from the service, log-out,…). 
2. HWA API are invoked to trigger the service provisioning. 
3. HWA Agent invokes kubectl or HELM instructing kubernetes to remove the architecture instance for the end user (including the associated container with HWA agent). 
4. All needed containers (as well as the HWA agent container) are detleted by kubernetes. 
5. If needed other actions can be performed on other systems to orchestrate the complete clean-up of the service. 
6. Centralized monitoring of the scheduling and automation results.

Cristiano Plini
Senior Technical Manager at HCL

Cristiano is part of the Sales Team of HCL Workload Automation. He has sound experience in R&D, consultancy  and sales of IT solutions, gained in +25 years working for worldwide enterprise industries in Europe, North America, and Latin America.