I am privileged to be a new addition to the Hands-on Labs team within Technical Marketing at VMware. I have been here just under 3 months, but I have been using our products for almost as long as we have had products, I am active in the community and have spent time in the field as both a customer and a partner. I hope that my background allows me to provide a unique perspective on what we do in my group. There were some things that I always wanted to know, and I’d like to share as much of that with you as I can.
As the new guy on this team, I have spent quite a bit of time understanding how the Hands-on Labs infrastructure is set up, where resources are located, and how we deploy labs to support various conferences, user groups, and the new 24×7 online activities.
Hands-on Labs Online
If you don’t know about the free HOL Online portal, you should stop reading and go sign up for an account right now. Seriously, point your browser to http://hol.vmware.com/ and get an account. Now. It’s in Public Beta and we’re signing people up continuously. Request an account and you should have one soon. Of course, I would appreciate it if you decided to come back here after you sign up.
Hands-on Labs @ VMworld
Most people know about the labs at VMworld. In fact, the labs have consistently been one of the highlights of the show for a large portion of attendees. I had been involved with the labs in the past as a content creator and presenter, so my new role is something that I am really excited about.
Several years back, we had two different types of labs: instructor-led labs and self-paced labs. Each type had its own benefits and drawbacks. For example, instructor-led labs were like classes and attendees had access to the people who actually developed the lab content because they tended to lead those sessions. Unfortunately, it was often very difficult to get into the lab sessions that you wanted because there were limited seats and sessions available. The capacity issue was addressed by the self-paced labs, and enhanced by a slick provisioning system that allowed any self-paced lab to be taken from any station in the pool. The drawback was that the people who created the labs were not always available when you wanted to take the lab.
As long as the labs were available, most attendees didn’t seem to mind, especially if we could direct them to a session where the lab’s topic was covered in more depth. However, our goal is to have as many subject-matter experts in the lab area as possible to answer questions as they arise. At conferences, we do our best to schedule lab resources so that one of the content contributors for each lab is on the floor during all posted lab hours.
Our current Hands-on Labs offering has evolved from this self-service model. At VMworld US 2012, we debuted our first BYOD capability. We expect to enhance that capability this year and provide several different types of lab experiences in addition to a whole batch of fresh, VMworld-exclusive content. It is no secret that we experienced some challenges with the labs at VMworld last year. We have listened to your feedback and made some changes. I firmly believe that your lab experience this year will be more satisfying.
Cloud!
When I think about it, even though our use case is somewhat unique, what we are doing here has many of the characteristics of “cloud”:
On-demand Self-service: Anyone with an HOL online account can sign in and experience a lab. The environments are provisioned on-demand and presented for use. (Well, technically, we maintain some pre-deployed instances of each lab in order to save you time. This works similar to the way that VMware Horizon View pools work and is handled by our front-end application.)
Measured Service: We don’t charge for this service, but the “cost” could be measured in minutes: when you enroll in a lab, you get to use the environment for set amount of time. When that time expires, your environment goes away. You can get a new one as many times as you would like, but nothing persists beyond the allocation.
Leveraging Pooled Resources and Rapid Elasticity: Our labs are designed to be self-contained, deploy quickly, run for a finite period, then disappear. This is an incarnation of what I like to call the “Paper Towel” use case: need it, get it, use it, toss it. We deploy known, fixed blocks of capacity, which have been designed for a specific use case.
For our use case, availability is important, but not in the traditional sense:
There are specific times during the year when we need 100% availability. At the VMworld and Partner Exchange conferences, attendees want the labs available during all of the hours that the labs are open — and more!
The remainder of the year, people accessing our online portal would be inconvenienced if their lab disappeared due to a backend issue. However, it wouldn’t kill them to re-enroll and get a new copy. As long as we design for this kind of failover (i.e. not preserving any state), we are fine: we’re not running a reactor, mail server, or performing brain surgery here.
From a design and capacity perspective, we have to design for steady usage with some pretty massive spikes:
Typical usage of labs via the HOL online portal’s public beta period averages 600-700 per week. We typically have 6-10 people taking labs concurrently unless there is an event of some kind going on. We have roughly 60 pre-staged copies of various labs deployed and waiting for you to use, with over 1000 VMs deployed within the tenant that services the HOL online portal.
As for spikes, during a conference, we deploy and destroy an average of 8,000 VMs per hour!
What about Hardware?
All of that cloud stuff is well and good, but I’ll bet many of you want to know what’s behind the curtain: what gear do we use to run this environment, and what does this look like. I will have to save that for another post.
