CloudLabs: How UC San Diego Deployed Remote Computer Labs in Record Time
When everything else went virtual, labs did too!
By Valerie E. Polichar, Ph.D., Senior Director of Academic Technology Services
When COVID-19 caused a pivot to remote instruction with little notice, students lost access to on-campus computer labs where they could use licensed software to complete coursework. UC San Diego’s educational technology teams sprang into action. In less than three weeks, they built CloudLabs—providing students remote access to over 200 apps on three operating systems.
UC San Diego’s educational technology teams support over 300 pieces of software in 160 physical lab spaces on campus (2200 seats). In a normal quarter, these are heavily used, with 15,000 logins in a typical week.
But mid-March 2020, everyone was sent home.
Finals were two days away; Spring quarter was two weeks off. Would departments have to skip critical assignments? Curtail learning? Worst of all, cancel classes?
Not at UC San Diego. Instructional infrastructure teams architected, engineered, and built CloudLabs—a portfolio of several services with a customized one-stop-shop interface. They did it in under three weeks, just in time for the start of the second week of classes.
What’s more, they did it almost entire remotely.
Access to Licensed Software—without On-Campus Labs
Instructional software licenses generally don’t permit a student to copy the software to their home machine. When they do, many students’ home computers aren’t fast or powerful enough to successfully render graphics, model chemicals, or engineer in 3D.
UC San Diego did have a virtual lab—an elderly on-premises server cluster running a version of VMware Horizon View for remote desktop access. With out-of-date and out-of-support software, it was only suitable for the least demanding of applications. We knew we had to jump to the cloud.
Complications
The teams had been discussing cloud-based options for a while, but cost was high, faculty were reluctant, and vendor maturity was low. It was unclear what option would be both palatable and dependable. We had run small pilots of AWS AppStream and Apporto in early 2020 that were not yet complete. Some software might work well in one cloud environment, some in another. We didn’t have much information on which to make a decision.
Thanks to executive support, we were funded for this emergency situation. But even emergency money is limited—the less we’d spend of it, the better. Further, if we wanted to continue this experiment beyond a quarter or two, we needed our solution to be affordable.
Of the cloud products, AWS AppStream was more mature, but looked to be expensive, and had a less graceful interface. Apporto might be easier for students to use, but the company was young and small, and we were concerned about their ability to deliver under what was likely to be massive demand.
We could upgrade our old, on-premises Horizon View virtual lab with a minimum of expense, but it wouldn’t work for heavy CPU- or GPU-demanding software.
Complicating things yet more, some of our software was licensed to use in a cloud or remote desktop environment; some was not.
None of these solutions would work for MacOS or Linux. For those, remote desktop was our only option—making a direct connection to an on-premises computer in a now-locked lab. But this would limit us to the number of computers we had on campus, so the same old wait times would hold. Worse, it wasn’t going to be fast enough for all the software students needed to run.
A Portfolio of Solutions
We decided on a portfolio model that we called CloudLabs. We would use cloud services AWS AppStream and Apporto, to reduce cost and risk; upgrade our on-premises server to cheaply give students access to a lot of less-processor-intensive applications; and provide remote desktop over Apache Guacamole for our Mac and Linux users. (Because Adobe Creative Cloud didn’t work well over remote desktop, we encouraged students to take advantage of Adobe’s free download for Spring quarter.)
We soon discovered that our concerns about both cloud products were warranted. Many students and faculty preferred the Apporto environment, but the vendor was not able to get the software up and running as quickly as we were able to install it in AppStream. Some license server issues persisted with Apporto after the quarter started, so more classes started in the AppStream environment than originally planned. Apporto worked with our team throughout the quarter to resolve the license server issues, so we were able to accommodate some classes there in Spring quarter (and more in Summer and Fall). The flexibility to swap environments quickly for a given class turned out to be critical to course delivery.
At the same time, we set up Apache Guacamole to provide secure remote desktop access for MacOS and Linux. Needed software was already installed on the lab machines. Students connect from the web, authenticate, and get a familiar desktop environment.
Clear, Personalized Access
Instead, we designed an innovative single entry point—a website where students authenticate and are served up a custom menu that shows all their classes and provides links to the tools for each. If we’d simply put up links to all five environments, students would have spent hours trying to find the software they needed, tracing through a maze of different interfaces.
In the screenshot of the interface, a student has Apache Guacamole links for her Linux classes in Cog Sci and CSE, Apporto, AppStream; and Horizon View links for her Chemical Engineering classes. The Linux links let her know the course-based login name to use for access. For her Chem Eng classes, she has different desktops for the different packages of tools she’ll want to access.
The Impact
When we began, we hoped we could get the 50 most-used applications up and running for Spring quarter. In the end, the teams loaded 264 applications and were able to meet the needs of 114 Spring classes in 19 campus departments, both undergraduate and graduate. Additional applications have been added as needed, and now, hundreds of students in 200 classes connect each day. In addition to the students who require CloudLabs for their coursework, other grad students, undergraduate student organizations, and campus computing clubs have requested access to this desirable environment.
CloudLabs won’t eliminate the need to have on-campus labs, but it will reduce the need for growth. Over time, we believe we can gradually reduce the number of on-campus lab seats, a key goal at a time when campus space is at a premium. The reduced cost of refreshing on-campus equipment can be applied towards any future CloudLabs growth. CloudLabs also will continue to be a way to increase access for students with disabilities and for our remote population.
Ongoing Challenges and Next Steps
CloudLabs was a graceful and usable solution for courses in Spring quarter, but challenges lie ahead:
Adobe Creative Cloud. Licenses for this product don’t allow use in a third-party cloud environment, and remote desktop performance is unusable for many applications. Individual student licenses are very expensive. We continue to explore alternatives.
On-premises instruments and tools. Forty-four percent of our total on-campus lab seats are in locations where they are connected or adjacent to instrumentation, tools (such as 3D scanners and printers), equipment, or wet lab environments. We can’t replicate that in the cloud. For classes that depend on this adjacency, there are no immediate easy solutions, but we’ll be looking at the possibilities of remote instrument management for the future—and for potential use by online classes.
Replacing Horizon View. Our upgrades to the on-premises server save us money in the short term, but in the long term, we’d like to avoid refreshing that hardware a second time. We plan to move all apps to a cloud option before that hardware ages out. This will increase the recurring cost of CloudLabs, but we expect cost savings in terms of managing and refreshing on-campus hardware.
Flexibility—Beyond Campus Walls
A cloud-based environment means agility. We can spin up additional environments with relative ease. If we need more seats in a given environment, it’s no problem to expand. Fewer seats in Winter quarter than in Fall? No problem. The ability to scale as needed is something we couldn’t achieve with physical lab seats, where the count is always a compromise between peak need and available space and funding.
We expect to snap in on-premises lab allocations when they return to availability, too. CloudLabs provides one-stop shopping for a student to access the IT resources they need to complete coursework—a small but meaningful way to simplify the university experience in these sometimes confusing and overwhelming times. We hope the service will meet student needs during lockdown and beyond—reducing wait times for lab access and allowing students both near and far access to the same quality of instruction.
This article originally appeared in UC IT Blog, published January 13, 2021.