An Interview with Alex Henthorn-Iwane of QualiSystems
As we have more ways to manage our ICT infrastructures, from bare metal to virtual, doing so becomes more complex and labor intensive. Manual processes tend to be error prone and not scalable with rapidly multiplying and changing computing resources.
We need automated systems to manage various kinds of logical and physical resources to accommodate rapidly changing computation loads at data centers. We have seen something similar in the past when all the resources were physical and real, rather than virtual and logical. We use a GUI to specify what we need in terms of machines and equipment from a pool of resources and dump the collected information into a configuration file. Then another program sends out resource allocation commands on the basis of that configuration file. This is illustrated in the figure below (Figure 1).
Figure 1: Traditional way of allocating necessary resources from a pool of available resources
Does this apply to the more complex systems of physical and logical (virtualized) resources that are becoming the norm? To find out, I sat down with Alex Henthorn-Iwane, VP Marketing, QualiSystems, at the recent Teladata Technology Convergence Conference.
What I did for this blog was not to analyze the subject matter in detail and review to what extent QualiSystems could solve problems encountered in the subject matter. Instead, I came up with a set of conceivable issues and questions beforehand and asked Alex for answers. I got a lot out of our short chat, but I want to find out more. The subject is very complex and half an hour was not enough time to get answers to all my issues/questions. He was nice enough to offer me a chance to talk to his technology expert at QualiSystems later. I will write more about them as I learn more about their system, as I did for CloudVerox.
What QualiSystems and Its Differentiations Are
According to Alex, QualiSystems is a automation software company with product lines in cloud management and in test and continuous integration orchestration.
The configuration control and orchestration may sound easy enough to implement, if we simply look at it from 30,000 feet up. But the devil is in the details. I asked Alex what the QualiSystems’ differentiations were.
His answer was that QualiSystems’ expertise lies in:
- Dealing with physical and virtual entities together
- Visual automation and orchestration
- DevOps cloud enablement
A typical data center today consists of physical and virtual resources, and any configuration or orchestration system should be able to handle both seamlessly. Because potentially a number of resources of numerous types are dealt with, automation is needed to shorten setup time and eliminate human operational errors. The current target is the DevOps environment, and it is essential to understand what it takes to support DevOps.
The following is a diagram (Figure 2) of user groups and infrastructure thatt DevOps must encompass.
Figure 2: Illustration of the scope of users and data center infrastructure (Source: QualiSystems)
QualiSystems’ CloudShell and TestShell
QualiSystems’ CloudShell is a cloud management/orchestration system, and TestShell is a test automation platform for both programs and infrastructure. TestShell runs side by side with CloudShell and is not discussed further here.
CloudShell acts as the cloud self-service interface for various users to access IT infrastructure, as shown below (Figure 3).
Figure 3: CloudShell acts as the cloud self-service interface for various users to access IT infrastructure
Where the Engine Runs
Quali’s CloudShell is a web-based enterprise application, but it does not really matter where it is physically located because the GUI is web-based and can be hosted on any physical or logical (virtual machine) computing platform. As long as you are comfortable with your security environment, it can be hosted anywhere. CloudShell consists primarily of a Web-Server component, a main Server component, and multiple automation execution engines. Each of these components can be deployed on separate machines, and the automation execution engines are distributed and fully scalable to meet demands (Figure 4).
Figure 4: Simplified CloudShell Block Diagram
The web-based UI allows the end user to model and request infrastructure configurations (called web catalogs by QualiSystems) from a user, and the server then orchestrates the configuration of required resources and schedules available resources so that no contention takes place among multiple users. The distributed automation engines provision the underlying infrastructure as needed.
As mentioned, the self-service portal allows admins or architects to model infrastructure environments which can then be customized and consumed by end users. When requesting an environment, end users have the option of scheduling access to the environment for a specific time. The system automatically determines and resolves resource contention and capacity issues. This enables efficient access to limited physical resources in multi-tenant scenarios. In addition, you can design more complex orchestration workflows. For example, you can specify dynamic allocation of resources within an environment on an as needed basis. If you run out of the resources you allocated at the beginning, you may want to increase computing or storage capacity power and storage dynamically, subject to availability. This may be done as more resources are required manually or automatically. The system also allows resource pooling, to limit the amount of additional capacity a dynamic environment can consume.
Further, you can preallocate power or cooling resources and make sure that resources are adjusted as necessary. This ability is what I am very much interested in, as an analyst covering the interaction of ICT and energy. However, these sophisticated abilities are actually beyond what the current market demands.
Quali Systems’ CloudShell is targeted to DevOps and allows developers to test their code easily by setting up (auto provisioning) and tearing down (auto deprovisioning) necessary ICT resources. One such case is for a research organization needing a few months of computing resources. A cyclic workflow type is another. EMC has adopted Quali Systems for provisioning their VSPEX reference architecture.
Multiple Clouds and Multiple Data Centers
People have started to talk about computing over inter-clouds and inter–data center. Hybrid clouds are via interclouds (private and public) and inter–data center. There are many potential configurations of how clouds are implemented. You have options to use your own cloud at your own data center and/or to use public clouds outside your premises. You can mix and match private and public clouds in any combination.
CloudShell can be used to set up a computing platform beyond a single data center across multiple data centers and clouds. A few things come to my mind when I think of it. For this, some requirements need to be satisfied, including:
- Secure transmission of commands to allocate resources at remote locations, regardless of cloud or noncloud environments
- Secure transmission between the resultant computing environments across multiple cloud and noncloud environments
- Permission to allocate resources in local/remote cloud and noncloud environments
- Dynamic features
- Load monitoring at remote cloud and noncloud environments
- Power and other constraints
I am sure I missed something, but more will be added as I learn more about this feature and its requirements.
For #1, when commands are sent out over the network, especially WAN, they should be delivered securely, which is guaranteed with CloudShell.
#2 indicates that once multiple clouds and data centers are interconnected, each and every communication must be secure, which is the case with CloudShell.
#3 says that if we want to orchestrate multiple clouds and data centers, we should have all the access and permissions to those clouds and data centers. CloudShell honors a domain concept where all the access and permissions are granted. Within the domain, it can configure and orchestrate local and remote resources. This means we should have accounts to allow us to have access to those remote resources in advance. Suppose we decided to use Azure cloud in addition to AWS, can we add to current resources easily?
This leads to #4, which means that even if we want to use our predetermined cloud and data center resources, depending on the environmental factors (i.e., running out of resources), we may not be able to do so. Such factors include the limitation of computing resources like servers and storage, cooling capacity, and power (when loads outweigh resources). For example, if for some reason your use of an AWS public cloud is limited because of failure somewhere (unavailability, no network access, or whatever), you might want to try other public cloud resources, such as Azure. Could you do it? If you run out of power, could you limit the current computation or go somewhere where power is enough? .
What’s Next for QualiSystems?
There are many things QualiSystems could do in the next few years. Some of the issues I brought up, such as power monitoring and load balancing among multiple clouds and data centers, could be options rather than left to users to design into the system.
Alex said that even though the media and marketers are hyping private, public, and hybrid clouds equally, private cloud adoption is still in the early stage in enterprises. QualiSystems understands that, and wants to focus on the DevOps area for now and gradually focus on multiple clouds/data centers and production markets as they mature. This is a very good idea, in my opinion.