Barely a couple of weeks after the final of the soccer World Cup, we have another exciting piece of news: Quali is announcing a sneak preview (EA) of the latest release of CloudShell: v. 9.0.
As part of this story, I will cover 2 major features of CloudShell 9.0 that will help current and future customers further their infrastructure utilization efficiency and significantly accelerate Cloud transformation initiatives.
The Cloudshell built-in orchestration has already included since the very beginning the setup and teardown of a sandbox. As an option, CloudShell users will now have a simple way to save and restore their sandboxes.
The "Save and Restore" add-on allows saving an active sandbox, preserving the original sandbox content, configuration, and network state. The “Saved Sandbox” can then be restored by the user at a later time. The capability can be enabled per blueprint as well as defining the maximum number of saved sandbox per user.
What does it really mean? Simply put, let's assume a user needs to stop their work on a project, for instance, the test and certification of a new virtual application, or the support of a complex IT issue. They can now use simple interactive commands from the CloudShell UI to save their sandbox with a specific name. The action will trigger in the backend a clone of all the VMs and their connectivity and create a new snapshot artifact based on these settings. Once the user is ready to resume, he/she will be able to deploy this artifact and create a new sandbox that will have the exact same settings as the original one.
This feature prevents overconsumption of limited infrastructure (physical or virtual) resources while allowing individual users to create a back up of their work environment.
CloudShell already supports out of the box the leading private and public clouds (Vcenter, Openstack, AWS, Azure). This allows users to model and deploy complex applications in the cloud of their choice using out of the box sandbox orchestration to automatically set up and tear down the environment.
It's a fact: there are many other Cloud technologies that we do not support yet, including some that we don't even know about. Patience, as in "maybe it will show up in the roadmap someday", is not a virtue of the fast-paced technology-driven world we live in. Thankfully, wait no longer. Cloud Provider Templates are here to help organizations to quickly collect the benefits of cloud-driven, environments as a service automation.
CloudShell is an open content platform and we provide in the Quali community standard templates to build your own infrastructure "Shell" (the building blocks of sandbox automation). Cloud Provider templates are just an extension of this concept. Just like Shells, these templates are python based (anyone who doesn't code in python yet please raise your hand!). They provide a standard for any developer to quickly add support to a new cloud provider (public or private) in CloudShell and deploy complex application environments to these clouds. These new cloud provider will inherit of all the existing Cloud provider orchestration capabilities (create/delete/network connectivity) as well as the ability to create custom commands (extensibility).
Note that container based orchestration platforms such as Kubernetes may also be modeled in CloudShell as "Cloud Providers", so the range of technology supported is quite broad.
This feature is a major step for organizations looking for rapid time to value to support their cloud transformation initiative.