Running Pre-Sales Demos on the Public Cloud: Ingredients of a Winning PoC

Running Pre-Sales Demos on the Public Cloud: Ingredients of a Winning PoC

Posted by Pascal Joly March 22, 2019

"Anything that can go wrong will go wrong." Sales Engineers engaging in high stakes demos are familiar with this saying. One of the most stressful moments they experience during customer PoCs happens actually before the demo. Is everything ready? Until recently, preparing the infrastructure for a technical product demo involved reserving and shipping some hardware, connecting these servers or appliances to the network and configuring everything end to end. We're talking weeks or possibly months of planning ahead of the actual "D" day with delays pretty much a given, lost shipment and unresolved IT tickets highly probable.

Then came virtualization and public cloud infrastructure.

Demos on the Public Cloud: a turning point with a few caveats

Public cloud was a turning point for many sales engineers in the tech world. With unlimited on-demand capacity, Infrastructure as a Service is as simple as doing online shopping: there is no need to be technically advanced to deploy a virtual machine needed for a demo in Azure, AWS or Google Cloud, to name a few. Sales engineers were finally blessed with all the ingredients for a winning PoC.

Not so fast. Complains coming from the various stakeholders involved in the process were quick to emerge:

IT admin: "I want to know what's happening in the infrastructure, cloud or not, so I can't relinquish the control to some random SE's credit card account. I should be the one in charge!"

CIO, CFO: "I want to understand why my infra spending have been skyrocketing since these sales engineers have been using the public cloud."

Sales engineer: "I can't figure out how to build these demos when I have more than one VM involved. takes too much time and I always need help."

Was this line: "just run your demos on public cloud" too good to be true? Seems like we were missing a cheerleader team after all.

Overcoming the Hurdles with Self-Service Environments

Have you ever dreamt of a self-service platform that let pre-sales engineers dynamically deploy their demo environments on the public cloud, no matter how complex they are, and clean them up after the demo is complete? If only...

It turns out Quali's CloudShell has been designed to natively offers these features on the private or public cloud of your choice. It recently came in the limelight with a case study published by partner Microsoft on a joint customer win (Skybox security). Nothing better than a real customer story to illustrate the point.

CloudShell provided Skybox a few key ingredients to enable their sales team demo their solution on the Azure public cloud effectively:

Automated deployment of VMs with out-of-the-box network and security configuration.

Self-service approach with demos organized in categories for easy access by multiple teams.

Simple, visual interaction with the demo environment to access the resources and showcase the value of the solution.

Time-bound environments: once the demo is complete the infrastructure is automatically cleaned up: no more ghost VMs, subnets or leftover storage sucking up IT budgets.

Enterprise-ready and multi-tenant to scale up as your team grows.

Now that we're back on the right track, why stop here? Environment-as-Service have been used in many similar use cases such as a training platform for internal employees, cyber range, marketing team or even for the support team to reproduce bugs.

Additional links

Learn more about Quali

Watch our solutions overview video

Migrating to Oracle Cloud with Confidence using Dynamic Test Environments

Migrating to Oracle Cloud with Confidence using Dynamic Test Environments

Posted by Pascal Joly April 5, 2018

As part of their digital transformation efforts, businesses are overwhelmingly moving towards a multi-cloud approach. Modernizing applications involves taking advantage of the scalability and rich set of services available in the public Cloud. The Oracle Cloud Infrastructure (OCI) provides many of these services such as Database, Load Balancing, Content Caching…

However, when it comes to validating these complex application architectures before releasing to production, there are many challenges the QA engineer/Release Manager faces.

- How do you guarantee that your application will perform as well once you migrate it into the Oracle public Cloud?

- How do you guarantee that your application and its data will meet all regulatory and security requirements once you migrate it into the OCI?

- How do you make sure that your application environment gets properly terminated after the test has been completed?

- How can you scale these efforts across your entire organization?

Application Modernization Use case

Let's consider a retail company, Acme inc., who needs to modernize their Sylus e-commerce web application as part of an overall business transformation initiative. Their current legacy workload is hosted on a vCenter private cloud and contains the typical component you would expect: namely a backend Oracle Database RAC cluster, an application server tier and a set of load balanced Apache web servers front-ended by HA Proxy. The business unit has decided to migrate it to the Oracle public cloud and validate its performance using Quali's CloudShell Platform. They want to make sure that not only it will perform as well or better, but also it will meet all the regulatory and security requirements before they release to production.

Designing the Application Blueprint

The first step is for the application designer to model all the architecture of the target application. To that end, the Cloudshell blueprint provides a simple way to describe precisely all the necessary components in a template format, with parameters that can be injected dynamically at runtime such as build number and dataset. For the sake of this example, the designer considers 2 blueprints: the first one represent the legacy application architecture with Jmeter as a tool to generate traffic, the second one represents the OCI architecture with Blazemeter as a traffic generator service and Oracle Load Balancing service in front of the web front end.

Self-Service Environments

Once this step is complete, the blueprint is published to the self-service catalog and becomes available to specific teams of users defined by access policies (also called "user Domains"). This process removes the barriers between the application testers and IT Operations and enables the entire organization to scale their DevOps efforts.

Deploying and Consuming the CloudShell Sandbox

From the Cloudshell portal, an authorized end user can now select the Sylus blueprint and deploy an application instance in the vCenter private cloud to validate its performance with Jmeter. This is a simple task: all the user needs is to select input parameters and duration.

Built-in set up orchestration handles the deployment of all the virtual machines, as well as their connectivity and configuration to meet the blueprint definition. In this case, the latest build of the Sylus application is loaded from a source repository on the application server, and the corresponding dataset is loaded on the database cluster.

Once the Sandbox is active, the tester can run a JMeter load test from the automation available through the JMeter resource and directly view the test results for post analysis.

Once the test is complete, the Sandbox is automatically terminated and all the VMs deleted. This built-in teardown process ensures that the resource consumption is under control.

Testing Migration Scenarios: Rinse and Repeat

Then the test user deploys the same application in the Oracle Cloud Infrastructure from the OCI blueprint, and validate its performance with Blazemeter using the same test as in the previous blueprint. In such case, a link is provided to the live reports and from a quick glance: thankfully, the results show that there is no performance degradation so the team can proceed with confidence to the next stage. Since all the VMs in the Sandbox are deleted at the end of each test case, there is no cost overrun from remaining "ghost" VMs.

The same process can be repeated for validating security and compliance, all the way to staging.

Note that this can also be 100% API driven triggered by a tool like Jenkins Pipeline or JetBrain's TeamCity using the Sandbox REST API.

Using the CloudShell platform and dynamic self-service environments, the Acme company can now release their modernized Sylus e-commerce application in production in the Oracle Cloud with confidence and repeat this process for their entire portfolio of applications for each new version.