WORKLOAD AUTOMATION COMMUNITY
  • Home
  • Blogs
  • Forum
  • Resources
  • Events
  • About
  • Contact
  • What's new

CONTAINERS AND WORKLOAD AUTOMATION 101

10/25/2019

0 Comments

 

All the questions you never dared ask about containers, Docker and Kubernetes ​

Picture
​You have heard a lot about containers in the last years, but you still do not know how you can leverage them with Workload Automation? This is the right place to start then.  
We collected the most frequent questions our users do when we talk about containers.  
1. What we talk about when we talk about containers 
What are these “containers” anyway? 
According to docker.com, “Containers are an abstraction at the app layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in user space. Containers take up less space than VMs (container images are typically tens of MBs in size), can handle more applications and require fewer VMs and Operating systems.” 
 
So, are containers and virtual machine the same thing? 
Nope. Again, as stated on docker.com “Virtual machines (VMs) are an abstraction of physical hardware turning one server into many servers. The hypervisor allows multiple VMs to run on a single machine. Each VM includes a full copy of an operating system, the application, necessary binaries and libraries - taking up tens of GBs. VMs can also be slow to boot.” 
 
Take a look at the difference between containerized applications and virtual machines:
Picture
What’s the difference between containers and docker? 
With Docker technology, users can develop, deploy and run containerized applications. Thanks to Docker containers, we can package the application and all of its dependencies and have it ready-to-run anywhere. 
You do not need to worry about the operating system used, the libraries, the dependencies.  


And what about Kubernetes? 
Welcome to the automation domain. As per its own definition, “Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.” 
originally launched by Google, the project was open sourced in 2014.  
While Docker and Docker compose could be great to run containers in a development environment, when we talk about large, high available, multi-tenant production environments deployed on clusters, we talk about Kubernetes. Like an operating system kernel allocate different processes and threads on the available CPUs, so Kubernetes distributes the containers on different servers called nodes, eventually starting multiple instances to scale up the application. 
​It also monitors the availability and health of containers, restarting them in case of container or node failure, it makes the containers easily accessible despite their actual location using an internal DNS, routes and load balances external connections to the containers, takes care of attach persistent volumes based on containers need, and much more. 
Kubernetes is available as the core open source project, or many commercial offerings like RedHat OpenShift, or available on public clouds like IBM Cloud, Google Kubernetes Engine, Amazon EKS, Azure Kubernetes Service (AKS). 
 
2. Why is Workload Automation relevant 
Wondering why you should care about workloads automation? 
Workload Automation is the platform to schedule, initiate, run and manage digital business processes from end to end, automatically. 
Thanks to it, business processing can take place without human intervention. 
Plus, the solution is available on mainframe, virtualized (on-premise), cloud and hybrid environments. 
Workload Automation is then a complete solution for batch, real-time IT, and application workload management.  It increases productivity with powerful plan and event-driven scheduling and runs and monitors workloads at any location.   
The platform provides a single point of control for application developers, IT administrators and operators, providing them both autonomy and precise governance through a centralized access control and auditing. 
 
So, wherever there is a process to automate there is the need for workload automation to manage it.  
Containers are definitely Workload Automation’s best friends. 
 
Take a look at how the architecture of Workload Automation is organized and how Docker fits in it: 
Picture
Workload Automation is basically made of 3 layers, every component can run on containers, physical or virtual machines, cloud platform, supporting also hybrid cloud environments. 
  • Execution: multiple agents launch and track the execution of scripts, programs, temporary containers, API calls, DB statements and stored procedures, and multiple job types that integrates with applications locally or remotely. 
  • Automation Engine: a centralized server which schedules workload based on advanced calendar rules, orchestrates flows from simple sequences to complex graph including also conditional branches and loops, and passes variables from one job to the next one. 
    It also includes Event management for notification and event-based scheduling and analytics capabilities to continuously predict and monitor SLAs compliance. 
    For larger or geographically spread environments, it is also possible to coordinate the workload of multiple engines using cross engine dependencies. 
    Everything is exposed via REST APIs. 
  • Web Console: it provides access to all product capabilities for defining the workload, monitoring, dashboarding, graphical views, reporting and what-if analysis. 

Can I then schedule containers with Workload Automation agent in container? 
Definitely yes. And you can even choose among three methods. 
Picture
Agent with application 
In this case, both the agent and the app are in the same container. Actually, this is not the best option out there, since cons are definitely more – and with more constraints – than pros: 
Picture
Pro 
  • Traditional deployment, as with a Virtual Machine 
  • Agent and Application running in the same container 
  • You can both  
  • adding application to agent container 
  • or adding agent to application container 
  • Agents dedicated to applications 
​
Cons 
  • Need an agent for each application 
  • Agent and Application must use the same OS distribution and libraries 
  • More containers running, more resource used 
  • Less load balancing, the applications run on the same container/node where agent is running 
  • Agents and application scalabilities are locked together 
     
Invoking application remote APIs 
The agent and the apps are each in separated containers and the applications are invoked via remote APIs (e.g. REST, jdbc, etc..). With this solution, the only cons are related to the need of application exposing APIs and having the containers always active. Let’s recap: 
Picture
Pro 
  • Agents and Applications running in their own container with their own libraries and OS distribution 
  • Can run on different nodes 
  • Agent and applications scale independently 
  • Same pool of agents can schedule multiple applications in the cluster 
  • Best solution for DB and microservice applications, especially if they already need to be always active 

Cons 
  • Possible only if the application expose APIs 
  • Application container always active 
​Starting temporary containers 
Here come containers at their best and the power of Kubernetes unleashes to make the most 
out of K8 clusters. 
Kubernetes can manage scaling, automatic failover and more, so no need to worry. 
Picture
Pro 
  • Agents and Applications running in their own container with their own libraries and OS distribution 
  • Application container runs only when needed 
  • Can run on different nodes, K8s will run each job on the best systems 
  • Same pool of agents can schedule multiple applications in the cluster 
  • Agent authorized by K8s security to run jobs on one or more namespaces 
  • Most efficient way to use K8s cluster 
  • Best solution to run executables, scripts, java mains 

Cons 
  • Not possible if the application needs to be called via APIs and is always active 
Already a containers fan? 
Sounds great, we want to hear your stories! 
What did you like the most about them? How did they improve or change the way you manage your workloads? 

And if you still have doubts, just leave us a comment below.  

This article is deployed into a container and will auto-destroy after reading it. Share it before it’s too late! 

docker run --rm my-article 
Picture

Franco Mossotto, Workload Automation Lead Architect ​

Franco Mossotto is the lead architect for the IBM Workload Automation products.
​He joined IBM in 1998 as a Tivoli Workload Scheduler for z/OS developer. Franco has worked in design, development and support of IBM Tivoli scheduling and provisioning products. In the scheduling area Franco worked as developer, chief designer, L3 technical leader for both Tivoli Workload Scheduler and Tivoli Workload Scheduler for z/OS, and as an architect for the development of cloud and Bluemix offerings. Following the IBM and HCL partnership in 2016, Franco transitioned to HCL with the rest of the development team to continue his work on IBM Workload Automation portfolio in the role of Lead Architect.

View my profile on LinkedIn
Picture

Emanuela Zaccone, Workload Automation Product Manager

Emanuela Zaccone is the HCL Workload Automation Product Manager.
​She is an experienced 
digital marketer with strong product management skills and an addiction to innovation. As Digital Entrepreneur she founded TOK.tv in 2012, reaching more than 40 million sports fans in the world before selling the company to the Minerva Networks Group in 2019. In the same year, she granted the inventor title by patenting social TV. She completed a PhD between the universities of Bologna (Italy) and Nottingham (UK).   ​

View my profile on LinkedIn
0 Comments

Your comment will be posted after it is approved.


Leave a Reply.

    Archives

    March 2025
    February 2025
    January 2025
    December 2024
    November 2024
    October 2024
    September 2024
    August 2024
    July 2024
    June 2024
    May 2024
    April 2024
    March 2024
    February 2024
    January 2024
    October 2023
    August 2023
    July 2023
    June 2023
    May 2023
    April 2023
    March 2023
    February 2023
    January 2023
    December 2022
    September 2022
    August 2022
    July 2022
    June 2022
    May 2022
    April 2022
    March 2022
    February 2022
    January 2022
    December 2021
    October 2021
    September 2021
    August 2021
    July 2021
    June 2021
    May 2021
    April 2021
    March 2021
    February 2021
    January 2021
    December 2020
    November 2020
    October 2020
    September 2020
    August 2020
    July 2020
    June 2020
    May 2020
    April 2020
    March 2020
    January 2020
    December 2019
    November 2019
    October 2019
    August 2019
    July 2019
    June 2019
    May 2019
    April 2019
    March 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    September 2018
    August 2018
    July 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    January 2018
    December 2017
    November 2017
    October 2017
    September 2017
    August 2017
    July 2017
    June 2017
    May 2017

    Categories

    All
    Analytics
    Azure
    Business Applications
    Cloud
    Data Storage
    DevOps
    Monitoring & Reporting

    RSS Feed

www.hcltechsw.com
About HCL Software 
HCL Software is a division of HCL Technologies (HCL) that operates its primary software business. It develops, markets, sells, and supports over 20 product families in the areas of DevSecOps, Automation, Digital Solutions, Data Management, Marketing and Commerce, and Mainframes. HCL Software has offices and labs around the world to serve thousands of customers. Its mission is to drive ultimate customer success with their IT investments through relentless innovation of its products. For more information, To know more  please visit www.hcltechsw.com.  Copyright © 2024 HCL Technologies Limited
  • Home
  • Blogs
  • Forum
  • Resources
  • Events
  • About
  • Contact
  • What's new