For many years I worked as a trainer for IBM Education, running both lecture and lab style training courses. Regardless of what I was teaching, the reality was that “learning by doing” always proved way more effective (and fun) than “learning by listening”. The students were more engaged, they were more educated (which is the point, after all) and the course itself was simply more enjoyable to teach.
However, Lab training courses were rare, simply because they were too expensive.
We needed:
- A lab filled with storage, SAN, network and hosts
- A lab remotely accessible in a reliable fashion
- A lab technician on standby (remember I am in Australia, the labs were often in Raleigh NC or France)
- A desktop for each student that had the right OS and tools and access to that lab network (which was often via a VPN).
When you added all this to the cost of renting a training facility, paying for a trainer and actually making a profit, lab based training was a hard sell.
Fast forward to 2012: I started at Actifio and once again have found myself in the instructor’s seat. Actually I mainly teach standing up. At Actifio A/NZ we have been running lab based training using cloud based resources that are both really effective but also far easier and way less costly to facilitate. What we do is create a pod for each student that consists of an Actifio Sky appliance, a Windows Server and a Linux Server, all running in the Amazon Cloud (AWS). We then run a lab/lecture style course where students access their lab using their own laptop over an education provider’s WiFi connection.
Because this approach has been hugely successful, I thought I would share some of the key lessons learned:
1) Keep the proximity close and connectivity will be fast.
Given the closest Amazon region for Australia/New Zealand is Sydney, we run up our pods in that region. Courses in both New Zealand and Australia have not shown any latency or performance issues. In fact performance overall has always been excellent.
2) Lab guides are better in Google Docs.
When we started running courses we would print a lab guide for every student. While this is standard practice, there are a number of problems:
- It wastes paper
- Students don’t always keep the lab guide
- Updates and corrections mean old guides have to be thrown away
So we switched the lab guide to a view-only Google Doc, an online source can be edited and updated on the fly. Annoying spelling mistakes (which avoided multiple editors eyes), can be resolved the moment they are finally detected. If the order of the labs needs to be re-arranged or a lab rewritten, this can be done on the fly. The only downside is that if the student is working off a laptop, they only have one screen. So we suggest if they have a tablet (such as an iPad), they bring it along to act as their second screen.
3) Building machines images is easy.
AWS allows you to generate a new AMI from an existing EC2 instance. As we customize our student VMs, we can save them as a new image each time, keeping multiple versions (and snapshots) that match the lab that each course requires. These images can be shared across regions and accounts.
4) The cloud is limitless, but your account may not be.
Early on, we discovered that AWS Accounts were limited to the number of EC2 instances and EBS storage which we could deploy at any one time. Some fast and furious phone calls to the AWS help desk were needed to increase our limits.
5) Sometimes, user laptops just won’t play ball.
By having students bring their own laptops, we avoid the need to provide work stations for each user. However, while most corporate/government laptops work fine, we have had problems with Remote Desktop (RDP). RDP seemed to be very uncooperative for some users depending on corporate limitations. For this reason we started running a Guacamole server so that if RDP doesn’t work, the user can fall back to Guacamole.
6) Automate your provisioning and save money.
Ideally, we want to start our pods up as close as possible to the course beginning and shut them down as soon as the course is over. For two-day courses, we want to power-down all the VMs once the students have left for the evening and restart them at 8am. Automating the pod builds, shutdown and/or power down has been vital. This is mostly done using Shell scripts, Cloud Formation templates and EC2-CLI. This also helps in case we get a few extra students on the day by surprise, as it only takes a few minutes to build a extra pod for each student.
7) Pre-configure the simple stuff and keep your students interested.
In any software training course, preparing a lab requires a number of setup steps. If at all possible, where these steps are not relevant to your training (or so trivial they are not worth teaching) automate them as part of your setup routine.
For instance it is pointless having your students install a software package where the installation steps are simply:
“Double click on the installer and then keep clicking next.”
Seriously? They already know how to click next.
Pre-install it for them and teach them something they didn’t know.
8) Secure the lab with an incoming firewall rule.
It is very easy with AWS to limit access into your VPC to a specific IP address so that intruders are kept out. While the education provider will normally provide their external IP addresses ahead of time, students sometimes attach to an undisclosed IP. A quick visit to http://www.whatsmyip.org will reveal all and you can then update your firewall rules.
9) Make sure your IP addresses don’t change.
Use Elastic IP addresses (EIP) for all EC2 images, so that when you power them down at the end of the day’s training, that they power up the following day with the same IP’s as the previous day.
10) Help your students.
Provide every student with their own unique Pod setup, rather than sharing with a partner. This reinforces that every student doesn’t miss out on completing all lab tasks. More importantly, we build in some automation to let us quickly see by logged activity where in the labs each student has accessed. This lets us easily identify students who may need a little extra help.
11) Pay attention to licensing.
Just because you can deploy an EC2 instance, doesn’t mean you are licensed for the software in that instance. For Microsoft SQL for instance there is an option to pay for it inclusive of the AWS fees, or to use the bring your own license model. Read more here.
12) Encourage your students to stopping checking their email.
One simple issue with giving your students access to the Internet on their own work laptop is that they might never ‘leave work’. Their email and instant-messaging clients can start pinging, let alone other attractions like Slack and Facebook. I would say this is probably one of the few disadvantages of training via the internet on a student provided device.
Overall our experience with IT education in the cloud has been phenomenal. It has let us focus on creating positive educational outcomes while dramatically cutting the cost of providing this training.
Read more: Learn how leveraging the cloud can reduce your data center headaches.