Environment as a Service Concepts
We are all familiar with the terms “development environment”, “test environments”, “staging environment”, “production environment”, “demo environment”. Have you ever tried to look at what is common to them?
An Environment is a collection of components that need to be provisioned, deployed and orchestrated in order to perform a task – like developing, testing, demoing or deploying to production. The environment consists of applications and 3rd party services, deployed on infrastructure, and in some cases also data.
The important thing about an environment is that it is not limited to any single technology – the scope of the environment is the business need.
EaaS makes it possible for teams to get access to cloud-agnostic environments through a self-service portal, while allowing ITOps to govern access, cost and security.
EaaS is built for dynamic environments and leverages native environment automation to ensure compliance and standardization and optimize resource utilization.
A blueprint environment is a template that defines all the components in the environment. A blueprint is important because it is an automation plan – it documents everything that is going to happen when the environment is automatically setup. In automation, the value is in re-use. And therefore, the more you re-use your blueprint, the more valuable your automation becomes.
Using blueprints for automating environments makes it possible to unleash the power of automation, while also introducing some guardrails on cost and security. Win-win!
A Sandbox is a time-limited environment which is typically used for pre-production purposes like development and testing, or for evaluating technologies, training and demos.
Often it would seem quite similar to the production environment – the important difference is that sandboxes are ephemeral and will be torn down after a limited time.
Environment as a Service helps get end-users of environments (like developers, testers, sales engineers and operation engineers) the speed they need without losing control of cost and security.
Many times it’s quite easy to start automating for people with some coding skills, and the complex part comes later – how do we make automation maintainable and scalable? how can distributed teams get access to it? how do we make sure we tear down what we so quickly setup? how do we make sure it’s not abused?
Environment as a Service products help solve these challenges. For the end user they provide all the benefits of automation and infrastructure-as-code. For those responsible for cost, security and compliance – they provide control without becoming a bottleneck
Lab as a Service (LaaS) is an approach for transforming your organization lab to a cloud where users can get self-service, on-demand access to the lab resources, as well as share and collaborate on lab environments in order to support multiple teams and business groups within your organization.
Yes! Environments are not tied to any specific technology. Modular support for cloud providers and technologies in environments enables extension for any additional technologies that aren’t already built-in so you don’t need to worry about the next big technology. Automate on!
Yes! Environments are not tied to any specific technology. Modular support for cloud providers and technologies in environments enables extension for any additional technologies that aren’t already built-in so you don’t need to worry about the next big technology. Automate on!
Value Stream/DevOps Concepts
In the context of continuous delivery and DevOps, the value stream represents the series of stages that generates continuous value for customers. It consists of initiating, planning, building, and delivering a product or customer experience. While the term DevOps Toolchain is often limited to the automation of the CI/CD pipeline, the value stream includes the full spectrum of activities associated with delivering tangible value for customers, all the way from inception.
Blue green deployment is a strategy for deploying a new release to production. In a blue-green deployment, a new production environment with the new release is deployed side by side with the current production environment. The new production environment is called Green, while the current production environment is called Blue. While the Green environment is deployed all production traffic is served by the Blue environment. Once the Green environment is tested and ready, production traffic can be switched to the Green environment. During this process, it is possible to react to unexpected incidents with a roll back by switching traffic back to the Blue environment. The process is complete by tearing down the Blue environment, making the Green the new Blue.
Immutable infrastructure is an application and infrastructure management approach where deployed infrastructure is never upgraded or changed. Instead, any upgrades or changes are made by deploying applications on a new set of infrastructure resources and moving traffic to it. Taking an immutable infrastructure approach dramatically reduces the complexity of configuration management, helps abstract applications from the infrastructure, and makes the infrastructure a dynamic commodity that doesn’t have to be fixed but rather replaced.
Platform Ops is an approach to scaling DevOps, where a dedicated team maintains a self-service platform for the organization’s development teams that includes everything needed for automated DevOps value stream delivery. Platform Ops helps balance agility with control, and bridge the gap between developers and ITOps. It empowers developers by giving them the freedom to develop and deliver software at speed, without worrying about infrastructure and operations tooling. At the same time it leverages some degree of centralization to reduce risks associated with cloud and infrastructure cost control, security and compliance throughout the DevOps value stream, and makes it possible to harness automation for achieving governance.
Shift Left testing is a strategy to achieve continuous testing across the software development lifecycle (SLDC). Rather than discrete, sequential steps to first code and then test, shift left testing integrates coding and testing so developers can find and fix code problems very early in the application development.
Shift right testing is a strategy to conduct more testing in production environments. Using production data helps testers, site reliability engineers (SREs) and others to correlate real-world user behavior with test requirements. Shift right testing includes techniques including release validation, chaos testing, canary testing and application monitoring.
CloudShell Concepts
No. With Quali you “bring-your-own-cloud”. This means that you connect your cloud account to CloudShell and all the cloud resources are provisioned in your cloud account.
CloudShell platform consists of two products:
1. CloudShell Colony which is software as a service (SaaS).
2. and CloudShell Pro which can be installed on-prem, in your cloud account or hosted by Quali.
CloudShell allows admins to build a catalog of blueprints (blueprint is a template that specifies all the requirements for a live environment) and publish the blueprints for specific users. And when users access the CloudShell web portal they can choose the environment they need from the pre-published blueprints catalog and get a fully configured live environment with “one-click” deployment.
CloudShell provides self-service portal for end-users to request environments. By adopting a standardized self-service approach to allow end users to access environments, organizations eliminate bottlenecks in the process and increase speed while maintaining control.
CloudShell gives admins the ability to control cloud access and usage. All sandbox environments created in CloudShell are time bound and CloudShell will automatically tear down the environment at the end of the reservation windows to reduce cloud costs. In addition, all resources that are created in the cloud are automatically tagged enabling admins to use cloud specific and native policies and administration tools. Click here to read more.
Quali’s CloudShell platform can support any PaaS service. And we support many different devices from leading vendors.
CloushShell Pro
The Shells part in CloudShell Pro is open sourced. The Shells we develop are all open and available on our community
In the open CloudShell Pro community you can find free Shells and plugins, ask questions, get information, get involved and directly interact with our product team.
CloudShell Pro documentation is all open. You can access it from CloudShell Pro, but it’s also available online help.quali.com
CloudShell Pro integrations include Shells that make it possible for CloudShell Pro to support a wide and extensible array of technologies in environments. It also includes plug-ins to a variety of ecosystems tools like Jenkins, Jfrog, Atlassian, and more. All integrations are free and open-source, and available to download in the community integration page, all available to download freely at our community integration section.
A Shell provides CloudShell users a standard approach to interact with and automate different environment elements, like physical devices and virtual applications. Shells are open source and based on python. In the CloudShell community, you can find certified out-of-box Shells for common technologies, and it is also possible to independently create Shells based on existing standards using the Developer guide.
Shells offer a standard approach that can combine multiple technologies and be shared through our developer community.
CloudShell’s RBAC provides administrator power to control user level permissions. More information available here: http://help.qualisystems.com/Online%20Help/9.3/Portal/Content/Admn/Prmsn.htm?Highlight=user%20permissions
CloudShell allows customizing and extending the out-of-box automation to support specific business processes and automate manual tasks. For more information see the CloudShell Dev Guide: https://devguide.quali.com/introduction/9.3.0/the-cloudshell-devguide.html
Shells and the CloudShell Pro plugin integration are open-sourced. Our integrations are open, based on python, and available in our community integration page. There’s a comprehensive developer guide on the topic of extending CloudShell as well as a free SDK.
CloudShell Colony
CloudShell Colony is a managed infrastructure-as-code solution. It was designed and built to solve the main pain points of infrastructure-as-code. When modeling your environments with CloudShell Colony, you can focus on defining your application requirements (e.g. artifacts, variables, networking & compute requirements and test data) while we set up the required infrastructure for you, by translating your application requirements into either AWS Cloud Formation or Azure template.
CloudShell Colony is software as a service. So deploying it is as simple as just signing up: https://app.cloudshellcolony.com/sign_up
CloudShell includes out-of-the-box plugins for Azure DevOps, Jenkins, Team City and more, enabling you to easily deploy environments directly from your own release pipeline. It also includes an extensive REST API that can be utilized in any of your existing tools. We continuously release new integrations! Contact us! to discuss supporting your own DevOps toolchain.
Tags are used to logically organize cloud resources. A tag is a label that consists of a name and a value pair. For example, tagging all cloud resources in your production environment with the name “Environment” and the value “Production”, makes it possible to know which cloud resources are part of your production environment – including compute instances, storage, networking and other services. Tags are key to connecting between resource consumption and cloud bills, to the business purpose behind such consumption. Without tags, cloud bills are usually very difficult to understand, and ongoing cloud optimization becomes a daunting task. Properly and consistently tagging all cloud resources, whether they are used manually or automatically, by different teams and systems and across locations and cloud providers, is therefore an important foundation for cloud cost optimization.
Unlike some cloud providers, resource tags in CloudShell Colony are not case sensitive. For instance, “Test” would be treated the same as “test”. This improves your reporting and helps properly allocate costs.
Yes! Colony automatically tags cloud resources in environments, and therefore helps leverage automation for properly and consistently tagging cloud resources. Environments in Colony represent business activities like development, testing, troubleshooting, security assurance, staging and production. This means Colony can automatically connect cloud consumption with the business purpose and tag accordingly. It also means you don’t need to hope everyone remembers to tag resources or stick to tag naming conventions across teams, cloud providers, manual and automated cloud usage – it just happens as part of your normal operation. This is a critical foundation for ongoing cloud cost optimization and cloud governance.
CloudShell Colony includes out-of-the-box plugins for Azure DevOps, Jenkins and Team City, enabling you to easily deploy environments directly from your own release pipeline. It also includes an extensive REST API that can be utilized in any of your existing tools. We continuously release new integrations! Contact us! to discuss supporting your own DevOps toolchain.
Training and Service
Quali offers online and live training options for CloudShell Pro customers.
User can take self-paced training courses at Quali University https://www.quali.com/university/
Users can access the CloudShell Pro support portal here: https://support.quali.com/.
Quali customers also have a dedicated support team including account managers, customer success managers, and support engineers.
CloudShell Colony is software as a service. So deploying it is as simple as just signing up. Contact us for a trial.
