One of the most important aspects of a product is the ability to showcase its functionality. In the API space, it’s very important for a product to not just claim something, but to show that utility and use.
One of the best ways to do this is through the use of a demo environment. A demo environment is a perfect method to surface a specific use case or example for users, showcasing functionality that is often tailored to a specific interest group.
Today, we’re going to look at demo environments, and break out some functional key characteristics and best practices to get started with your own demos today.
Key Characteristics of a Demo Environment
Demo environments can often have very different purposes, and as such, they can vary widely in applicable structure or intent. For instance, a sales demo environment that is utilized as a proof of concept by a sales team might have a very different use case and structure than a demo environment designed by an engineering team for a structural demonstration of connectivity or interfacing.
Nevertheless, a demo environment by its nature has some pretty specific characteristics that help enable its utility, and as such, these characteristics are important to get right regardless of how your service is structured.
Production Separation
In a demo environment, data is often segmented from the production environment. This allows providers an accurate simulation of the product or service without exposing the underlying data or the live functions. This is essentially a test drive of the final product, and as such, mirroring this data as close as possible to existing production flows is vital.
Getting the most accurate data into the demo environment is very important. There’s a few ways this can be done, and we’ll cover these options shortly.
High Variable Control
A demo environment is meant to both provide a functional example of what a service looks like as well as provide a platform by which variations in service can be mocked. High variable control is thus vitally important, and allows the team demonstrating the product to show the product value both in isolation and dependent on other factors that may be more specific to each client or circumstance.
This variable control should also come with significant support for custom configurations. Being able to show the business case based on variables with traffic and use case is helpful, but taking this to the next level by showing constraints based on service level, network infrastructure, and interaction modality can give your sales teams and the potential clients a high level of trust with the product and its capabilities.
Temporary and Ad-Hoc
Demo environments should be easy to create, and they should be temporary in nature. These environments should provide limited functionality and lifespan for clients to experiment with the product, but should not be able to be pivoted into a long-term use case by potential customers.
Outside of the obvious concerns behind the business value, there are also significant security concerns that come with demo environments that aren’t approached as temporary, and it’s critical to have each system exist for the specific purpose of providing a demo experience rather than providing a total solution.
Components of a Demo Environment
With this in mind, let’s look at the individual components of a demo environment. A demo environment is composed of various moving parts that all work together to simulate, showcase, or demonstrated either a specific functionality or the total product offering of a software application or API. These components must provide a realistic yet controlled experience for prospects while allowing this experience to be customized to specific use cases or pain points based on client feedback.
Infrastructure
A demo environment needs a stable infrastructure to provide its demonstration bed. This includes a few key pieces.
Firstly, demo environments must have an environment to run upon. This can be an entirely local environment, leveraging solutions such as Docker or Kubernetes to contain the application in a customizable and deployable container for the given purpose of demonstrating the essential functions of the application.
Demo environments don’t have to be containerized, however, and can in fact be built upon external servers or hosting solutions. Cloud-based demo environments offer a significant amount of flexibility for where the demo application and services are hosted, but they do complicate the process somewhat and carry some security concerns.
Application Code
With the infrastructure set up, you need to consider the application code itself. The main application being demonstrated should be deployable for the given demo use case – with properly designed sandbox environments and a tight coupling between the sales reps and the engineering team, you can create the perfect demo for each customer in its own self-contained application.
It’s important to remember that no demo is going to be perfectly secure, and as such, you should limit each demo to a specific function or class of function. If an entire use case or application is to be demoed, you can introduce code constraints to ensure that the demo can’t simply be deployed as a solution at scale, which will keep both your business offering as well as the client’s codebase secure.
Data Layer
In many cases, the demo content itself will dictate what kind of data you have in the data layer. While it’s important to ensure that your data is as close to real life as possible, you should avoid using production data directly, as you can’t predict what network data might do in a demo environment.
Your best approach for making practical data in this context would be using something like Speedscale. Since Speedscale allows you to take real data and transform the user behavior within that data into a realistic environment, you can use this process to make data that is as close to real-world production data as possible. This will help demonstrate the key features in your product demo with real user behaviors, creating a tighter coupling between theoretical use cases and practical facts.
Integration Points
Leverage integration points with mock services to provide functional demonstrations. Mock APIs can simulate API endpoints that replicate these integrations even if there aren’t any real external services connected. In some cases, you can even provide these third-party integrations in their own containerized deployments, emulating or providing highly limited network access to show an end-to-end data flow.
Stubs and mocks can also be used to simulate these responses without live calls, providing an experience that is still quite secure and, most importantly, repeatable across multiple product tours.
Monitoring and Logging
Interactive demos can introduce a lot of complexity to what is otherwise a static demonstration, and as such, you should be using this as an opportunity to collect even more data! Deploying active error tracking and performance metrics can help you monitor the demo for future troubleshooting and iteration and can help test your theoretical use case against a use case that is closer to an actual production environment.
Environment Configuration
One of the benefits of creating demos is that you can ensure your demo environment is tailored to a specific target audience. Accordingly, you’ll want to build in as much environmental customization as possible. Utilizing predefined scenarios can help you provide a great demo for a specific product flow or feature, but utilizing these workflows as part of a cohesive variable set can allow you to model even more complex interactions.
It is important to keep in mind that this configuration should be controlled. You should have quite a lot of variability that can be used by your sales staff on demand, but this configuration should also be monitored, logged, and limited to specific areas that don’t undermine the security of the application.
Access Control
As with any application, access controls are vital. Your demo sandbox might contain privileged design and security processes, and as such, you want to secure your live demo as best as possible. Deploy rigorous authentication and authorization – you can use simplified or preconfigured login mechanisms to simulate user roles, but ensure that they are isolated and cannot escalate their own permissions or security roles.
Notably, you should do everything you can to isolate the environment both from exiting the demo sandbox’s virtual surroundings as well as ensuring that the external production world can’t get into the demo. Firewalls, permissions, gateways, and more can limit demo access to only the sales engineers and the prospective audience that is interacting with it, making your demo much more secure.
Presentation Tools
Software demos live and die by their presentation. Accordingly, your presentation tooling will be very important, as it will dictate how your demo environment is seen and engaged with. Ensuring you have adequate tooling that matches the use case in question will go a long way toward making your demo environment memorable and useful.
Each demonstration will have its own needs, and as such, the sales process will drive this variable.
Setting Up a Demo Environment
To show you how easy it can be to utilize a demo environment, let’s set up a hypothetical one using Docker and Speedscale.
Step 1 – Install Docker
This is a pretty obvious step, as you’ll first need to install Docker. Once Docker is set up, you’ll need to figure out how to build out your environment.
Step 2 – Plan Your Environment
To do this, you’ll need to look at your code and its dependencies. We’re going to imagine an API which checks a weather service for zip-code based data on current weather.
In this case, we’re going to need a few elements to emulate the environment. First, we’ll need our code. Let’s imagine we are the brilliant minds behind the OpenWeatherMap API. If we were demonstrating this API through a demo environment, we would first map all of the commands which touch the internal data or external services.
For instance, this is the API call to get the current weather for a given location:
https://api.openweathermap.org/data/3.0/onecall?lat={lat}&lon={lon}&exclude={part}&appid={API key}
This code has a few pieces that point to either external processing or a database call. The latitude and longitude parts of the code point towards another API, the Geocoding API (https://openweathermap.org/api/geocoding-api), for resolution. Accordingly, this would have to be bundled with our environment.
By repeating this process, we can begin to map out the dependencies our API has for other code bases, identifying which needs to be bundled with the environment itself.
Step 3 – Emulate Where Needed
If we are build a demo environment, we might want to only show the function of the API rather than provide a fully functional version of the API. In our example here, we might not want to provide real connected access to live data – in that case, we need to go through a second stage of processing, which is identifying the data we want to internally provide.
By providing data of our own, we can point the API to static data that simulates the data and the functionality upon that data without using an actual production workflow. In the case of our weather application, we might want to provide a database that has a snapshot of weather information at the time that we create the demo, and provide that data via an internal database.
Deciding whether or not to emulate data is going to come down to your security posture and the sensitivity of your data against the utility of the demo environment.
Step 4 – Create a Dockerfile
Now that we have all the pieces, we can actually create the Docker demo environment. Using Docker, you can utilize a range of options to create this file – for our purposes, we’ll assume that the code and database is local, and we can add this data utilizing the add functionality of Dockerfile to build an image.
Step 5 – Build and Run the Environment
As with any development process, testing is an incredibly important step of the process. Navigate to the demo environment and run the application to ensure that you have the environment built the way it should be built. At this point, you should have a base API and its associated data, but you shouldn’t have any traffic emulation or anything of that nature.
Step 6 – Simulate Traffic
To take this a step further, you can use something like Speedscale to capture real-world traffic and replay it for controllable traffic simulation. Using this in Docker is quite simple. Assuming you have Docker Desktop and Speedctl on your core application, you can record traffic quite easily.
Firstly, start Docker Compose by running speedctl install, and follow the Docker flow. Next, you will bring up the containers using docker compose –file <speedscale-manifest-file> up -d, which will start the containers as noted in the compose file. These containers will help capture the traffic and send it to the Speedscale cloud for processing.
Next, you’ll need to configure the socks proxy for your service. You can do this by configuring the application to run on *:4140 as well as forcing it to trust the local certificates. Now you can run all requests to localhost:4143.
From here, your live service data will be ingested by Docker, and you can simply record it. Once you have enough data for your use, you can again use the Docker flow for speedctl install to replay this data! Since you’ve created a Docker manifest for the content, you can replicate this data elsewhere, allowing you to have a repeatable traffic pattern that you can demonstrate against different variations of the product in practice!
Best Practices for Maintaining a Demo Environment
Maintaining a demo environment requires careful planning and consistent upkeep to ensure it effectively showcases your product in the best light possible; this will ensure that you have high conversion rates and success at selling your core offering while reducing the headaches of maintaining yet another branch of development.
First, always use realistic but simulated data. This will allow you to reflect genuine use cases while protecting sensitive information and will reduce the likelihood of data exposure, cross-site scripting, and other live service-based attacks. This will also help surface and provide valuable insights into the longevity of the product, helping to isolate issues with the codebase itself rather than the user interactions with it.
You should also refresh the environment regularly to avoid data clutter, inconsistencies, or other data-age-related issues, ensuring a uniform experience for every demo. It’s essential to keep the environment up-to-date by syncing it with your latest production development pipeline. This will help you maintain the accuracy of your demos while allowing your team to feel confident that they are presenting a real version of the core offering.
Ensure that you are training your sales staff often, both against new code developments as well as industry norms and expectations. Show them how to customize the environment, but also make sure they are aware of how far is “too far” – no sale is worth undermining the security of your application or your user data.
Common Challenges
Maintaining a demo environment can be challenging, especially if you want to ensure the quality and reliability of those demos. Data integrity is an omnipresent concern, as outdated, unrealistic, or corrupted data can undermine even the best demonstrations.
Code drift and lack of synchronization between demo and production can have a similar negative impact. You want the demo environment to sell the product as it is, not as what it could be, so maintaining an accurate portrayal of the offering is critical.
This can also be seen in the challenge of environment drift, where the demo environment deviates from production due to inconsistent updates or changes. This can lead to discrepancies that confuse or mislead prospective clients.
Resource limitations can be an issue, especially for complex workflows, but the advent of containerization and virtual machines has helped mitigate this somewhat, allowing for rapid scaling both horizontally and vertically as needed.
Future Trends in Demo Environments
As technology evolves, demo environments will only become more dynamic in their iteration. One major trend in recent years has been self-service demos, where prospective clients can spin up and experiment with their own demo environments tailored to their given use case. This leverages quite a bit of technology, however, and can cause some headaches for providers looking to streamline their demo experience.
Cloud-based environments are also rapidly becoming more ubiquitous in the demo space. Gone are the days when a local environment was “good enough” – many demos are doing incredible things with cloud-based solutions, even if the data that they are leveraging for that processing is not live data. Browser-based sandbox environments have found prominence as a way to provide sales demo environments without needing to containerize, deploy a remote service, or build out virtual IT labs. These implementations can be accessed through any modern browser, allowing for low-friction assessment. Given that the success of a demo environment lies partly in how low friction it is on top of how influential it is, making the demo slightly easier to engage with can pay some huge dividends.
AI-powered personalization is also an emerging tech in this space, allowing demos to adapt in real-time. In some cases, the AI solutions might even exist as a sort of chat bot, guiding users through the use of the demo product, eliminating much of the handholding that is part and parcel to the sales demo environment and the diligent sales staff waiting in the wings.
Conclusion
Ultimately, demo environments have never been easier to spin up. Using a solution like Speedscale can get you lifelike data at the snap of a finger, enriching your demos and making it easier to achieve wider market penetration and awareness. With a little forethought and planning, your demo environment can be easily deployed and hugely impactful, rapidly becoming one of your core enabling technologies.