Demo as a Service

Many of you out there who tried to run a demo online in front of a live audience are probably very familiar with the feeling when the demo is not working. Bill Gates trying to show Windows Media Center on Conan O’Brian is a good example of that :)

Having gone through this experience so many times, I know that getting a demo running successfully is not a trivial task at all.

There are many challenges involved in getting a demo right:

• Getting the demo inline with latest and greatest – every new version can break your demo. Since in most cases the demo is not going through the normal QA and testing procedures, the chance that your demo might break because of new changes get fairly high.
• Disseminating the demo among all the peers in the organization is also a challenge – if your demo is a little bit complex and requires installation of a database, a web server, etc., most likely you’ll end up with each sales rep having his own version of the demo, if at all. This is simply due to the fact that it takes time to get all those pieces to work and every update becomes a real project.
• Governing the quality of the demo – once the demo is on the hands of those sales rep you have absolutely no control over what they are running. Many will try to add their own tweaks, and without noticing end up with a broken demo or a demo that is not geared to highlight the right set of features.
• Demonstrating non-functional behavior such as scalability and availability on your own laptop is not that convincing. For example with GigaSpaces, which is a middleware product, scalability, performance and high availability are our main features. You can imagine how “impressed” I would be if you would showed me this type of feature on a single laptop.
• Now imagine what can happen in the ideal scenario, where everything worked out just fine, and the customer asked for a copy of the demo – ouch! This is where you’re going to try to find some really good excuses, because chances are that by giving the customer your demo she is going to be exposed to details you really didn’t want her to be exposed to at this stage.
• If you do get the chance to try and install the demo on the customer’s machines you might succumb to the “it’s not working on my machine” syndrome, which is often caused by environmental issues that are not so easy to spot.
• Last but not least is the collaboration challenge – in most cases demos are one of those tasks where we don’t have dedicated resources allocated to maintain and develop them. This is a classic scenario where collaboration can help to leverage the power of all the users and enable everyone to contribute to the demo in an effective manner. But this requires an initial effort to set such a collaborative environment, which the majority of us don’t spend when we set a demo. At the same time, there are only small number of users who would be willing to go through this investment themselves and contribute to such an environment.

The solution: “Demo as a Service”

The idea behind Demo as a Service is basically to apply the same principles of SaaS model to our demo.

This means that the demo would be fully accessible through the web (even if it’s a desktop application), there would be no installation required. It will be completely multi-tenant, meaning that each user can run on her own isolated environment even though she would share the same infrastructure with other users.

In this section I can refer to GigaSpaces as an example of a company that faced the obstacles I mentioned above and needed such a demo environment. I’ll share some of the principles behind the approach we eventually took to address these challenges. Assuming that others would be interested in creating a similar demo environment, we designed the system in a generic way that can be easily used by any user, even those that are not using our product, to run their own Demo as a Service without going through the same level of investment.

Here are the Demo as a Service platform design principles:

• Using cloud computing – as you can imagine, many of the things that I'll describe wouldn’t be possible if it wasn’t for cloud computing. Cloud computing enabled us to create a full production environment per demo in matter of two-three minutes, through a browser, from anywhere in the world. All you needed is an account set up and Internet access.
• No installation – only Internet access is required. I must admit that achieving this goal was a bit tricky at first, seeing as our product is not demonstrable through a web UI, and even if it was, there is not much you can see without running an application on top of it. So we had to create an environment that will enable you to deploy a demo application and watch what happens behind the scenes while the application was running. This included the ability to watch the cluster as it grows or shrink, crash machines and see how the application reacts to the event, etc. To achieve these goals, we set up the environment in such away that users can actually log into the servers running the application. We also needed to show the system view – CPU utilization, memory, etc. – of those specific machines. This meant that we needed to create system monitoring per demo and wire it on the fly so that it will monitor only the machines running that specific demo.
• Demo on demand – in our case we needed to support the option of creating a full demo environment that includes a load balancer, web containers, a Data Grid and a database, all in one click. Seeing as this happens while we’re facing users, we couldn’t afford any manual operations, and had to ensure that the entire setup would take less than five minutes. At the same time, when the demo is finished, we wanted to be able to clean the machines completely in one click. This had to be done in a way that wouldn’t conflict with other potential users running other demos at the same time.
• Fail proof – getting a reliable Internet connection is not always possible, and quite often the connection gets broken just a few minutes before the demo starts. We wanted to be able to recover easily from this type of failure. For this purpose, the web application we use to launch the demo is kept completely stateless. In addition, we keep the entire application in the cloud server repository, so we don’t need to ship any code from the desktop to the server. This enabled us to run the demo even under a low-bandwidth network. In case of connection failure, the deployment is not affected, and once the connection is re-established we are able to get the current state of the system as if nothing happened.
• Demos should be easily shared – one of the problems with demos, or any stand-alone application, is that it’s very hard to share the environment the application is running in, and therefore we found ourselves shipping different versions of the application when we wanted to collaborate or troubleshoot the application. One of the benefits of cloud computing is that I can easily share the resources I'm using over the Internet. This can also be useful if I want to interactively work with another user on the same machine, or even troubleshoot what she is doing.  All I need to do is log into the same machine and see what’s going on. There’s no need to ship any code. I can even fix issues immediately as I discover them, without needing to send long emails and package my patch for hours.
• Simple upgrade – we wanted to be able to launch a new version of our software, or the demo, very easily. We also wanted to enable users to use their current version and control when they do the switch to the new version. To achieve this, we used a shared repository model. The shared repository always keeps the latest update as well as the pervious version. The application only needs to indicate which version it wants to use, via an XML configuration file, and that’s it. In this case, we avoid the need to disseminate copies of our software with all our people or even force them to change their demos at the same time. All they need to do is to point the demo to the right version on S3, and when the demo runs it picks up that version and uses it.
• Governing the quality of the demo – now that the demo is running on a shared environment, we can ensure that everyone is using the same copy of the demo. Since we control not only the code but also the environment the demo is running in, we can eliminate any chances to the environment or human errors, which often happens when you ship a copy of the demo. If there is a fix that needs to be applied, it is applied immediately and everyone gets it. 
• Support desktop (fat-client) applications – there are cases in which the application needs to run a desktop application for its UI. In our case, part of our management tools needs to be accessed that way. For that purpose, each machine that is running can start the desktop application on the server and choose whether to launch only the application screen or the entire desktop. This is done without installing any software and without any manual setup.
• Simulate a real production environment – in order to demonstrate things like failover and scaling in a convincing way, we needed to use real machines and a real data center. This is another area where cloud computing came in pretty handy. We could easily instantiate real machines and allocate specific machines per demo and per user. This is extremely powerful, because it gives users the ability to experience the full product in a matter of minutes, without needing to download it or install it.
• Support multiple users at the same time (multi-tenancy) – multi-tenancy is a core principle in SaaS. It basically means that users can run on a shared environment while still being completely independent and isolated from each other. In our specific case, this means that:
  • All users share the same demo management portal.
  • The same user can run multiple application in complete isolation.
  • Different users can run at the same time in complete isolation.
  • Each application can be managed independently.

To achieve that goal, we had to design the management console to enable such isolation. In our case, we could use the same Amazon account to serve multiple distinct users, in other words there is no direct mapping between an Amazon user and our system user. The same user can run multiple application or different versions of the same application at the same time, and manage them separately.

Can I try it live now?

Yes. The built-in demos are available on www.gigaspaces.com/mycloud – to run the demos you don’t need to have an Amazon account, you can use a free trial user, which basically means that you’ll be running on our behalf. Note that this will only give you access to the built-in demos not your own application. A description of the available demos and how to run them is provided here.

Can I use it to deploy my own (non-GigaSpaces) demo?

Yes, you can use tihs same environment to deploy Tomcat or any other application fairly easily. Note that this option will require that you log in using your Amazon account.

An example on how to deploy your own Tomcat application is available here.

Note that this mode only provides the ability to launch new custom machines but doesn’t include all the elasticity, self-healing functionality that you would gain by deploying your web application on GigaSpaces XAP.

What’s the difference between a demo environment and a production environment?

One of the interesting thing is that there is not much difference. The difference would most likely be configuration – for example, security setup, or the size of the machines, which might be different in a demo because you would likely use low-class machines. Other than that, it’s pretty much the same environment. The beauty of that, IMO, is that you can move from demo to development to production without changing the environment.

Can I use this environment to run a POC and benchmark?

Yes. Since you get full access to the machines, you can keep them running as long as you wish, customize them and install your own software as well. This is actually the recommended way to run a POC, as it is more cost effective. You don’t spend time allocating the machines, setting up the environment and tuning the system, things that often take weeks. It is also easier to share the environment between two separate parties, e.g. the end-user and the vendor, without going through all the security processes required when you attempt to get access to the customer’s on-premise machines. In this way, you don’t need to ship code around when something is not working properly. I can log into the machine and see the exact behavior you’re seeing, and fix things immediately.

Final words

Demo as a Service is a very powerful model for overcoming many of the challenges involved in running demos and POCs. Cloud computing provides totally new capabilities, which allowed us at GigaSpaces to create a full demo environment for our product, at the click of a button. Having said that, based on our experience, setting up a full demo environment can take a while and would require investment. The mycloud environment was designed to get you the benefit of Demo as a Service while saving you the effort required to implement one. It is still in its early stages but is already being used extensively by our sales team and our partners. I’m eager to hear more feedback from users and suggestions on how to can make it better.