Rubber Meets the Road: Classroom Lessons Learned from Seattle

When Seattle first debuted in 2009, it brought to life several exciting ideas. For starters, it demonstrated the potential of cloud technology that could securely run on donated devices. It also gave educators a powerful new way to show novice student programmers how networks actually function. In less than a decade, it has spawned a number of new applications, and has taught thousands of students in 100 classrooms around the world concepts in cloud computing, networking, distributed systems, and parallel programming. Increasingly, Seattle has also provided an effective method for teaching the basics of systems security.

As its name may indicate, Seattle was initially developed at the University of Washington, the brainchild of several researchers, including SSL director Justin Cappos. The program offered researchers a way to “run code on any device and safely share computer resources,”thus turning “any device into a cloud provider,” Cappos explains. Developed at a time when cloud computing was just coming to prominence, Seattle offered an easy-to-use platform for tapping the potential of this technology.

Recently, Cappos, and research professor Albert Rafetseder, an early adopter of the technology, reflected on the evolution of this project into an effective teaching tool. Cappos also shares some lessons learned along the way about the best ways to introduce new teaching technologies.

According to Cappos, Seattle’s initial set of adopters were intended to be educators. Early on in its development, two decisions were made that shaped the overall nature of the project. First, these testbeds were designed to be easy to use, so developers with little experience could get up to speed quickly. And, secondly, Seattle was to be a free “community project,” with interested individuals and universities donating computational power, storage, and making improvements to the Seattle software. In addition, it was designed agnostic of any particular language or operating system, so it could be run over a wide number of platforms.

Support for the new project was generated in a somewhat unusual way. “In the initial phase of the project, I gave 100 talks at schools around the country and ran demos of Seattle for faculty and students. We built an audience for the product that way.” As the talks drew in supporters, users, and a growing number of donated devices, the research team decided to write a few “prepackaged” assignments for use in networking classes. The inspiration for these assignments was what was currently being taught. According to Rafetseder, the Seattle classroom materials “developed naturally” as a way to “show off how easily the platform enables you to do interesting experiments.” This approach of “teaching something moderately complex by building on simple examples,” has also allowed students a great deal of flexibility to use Seattle for projects that match their interests.

Exposing students to “real networks,” such as internet sites, and letting them see “real world latency, firewalls, and other things that they would not otherwise have hands-on experience with,” has been the primary benefit of Seattle’s educational offerings. But, both Rafetseder and Cappos point to other plusses of the software’s use in the classroom. Cappos observes that using the program prevents students from “accessing and using existing libraries, which students often use as crutches” when developing a program. Rafetseder cites how it allows students to learn “how many things go wrong in computer networks all the time, and how brilliantly smart yet relatively simple the algorithms that govern the networks are.” He adds that “it’s great to let students experience that network protocol design is tough,” and “that there is hardly ever an optimum set of parameters, or an algorithm that is guaranteed to work under all circumstances.”

When queried as to how Seattle is being used today, Cappos acknowledges that, as an open source project, “we don’t always know who is using it unless people tell us.” All the necessary code can be accessed through the Seattle website, free of charge and, for users that do not use one of the Seattle clearinghouses, Seattle can be used without the need for any type of registration. The advantages of such an approach to universities and research communities are obvious, but Cappos acknowledges that occasionally it has its issues. Recalling one of the project’s earliest educational adoptions, he explains “there were problems with the platform. Unfortunately we didn’t get errors or complaints till much later, when the user told us,‘this has been broken for a week.’ As a result of that encounter, we added bettermonitoring, but even now, we don’t exactly know in how many, or in what ways Seattle is being used.” When feedback is received, however, it is generally favorable.

As Seattle begins to close in on its first decade, Cappos notes there has been something of a shift in which faculty are accessing the program, from networking classes to system security classes. Seattle’s ability to create reference monitors makes it increasingly appealing to faculty looking to offer their students hand-on experience in security topics. Another shift that may grow in the future is away from using Seattle on computers and towards smart devices. Running Seattle, or its spin-off project Sensibility Testbed, on smartphones and tablets “provides a direct way of interacting with the device thanks to quick code turnaround times,” Rafetseder states. “Feedback is immediate. I think this is of great use for newcomers.”

Asked to summarize the lessons learned from Seattle’s educational components, Cappos shared the following observations:

• Know your audience. “We never take the attitude that Seattle is a finished product. We have found it valuable to be able to look over someone’s shoulder to see how they implement the projects.”

• Eat your own cat food. ”We have used and built on the tools we created. In our case, we used Seattle code to implement new tools and products. For example, the code base in Seattle was used in Sensibility Testbed, which adds the ability to safely and securely collect data from sensors on mobile devices.”

• Make it easy for others to fix your mistakes. By presenting Seattle as an open source project, “we have made it easier for people to collaborate with us.” Cappos is genuinely proud of the fact that “more than 100 people have worked on Seattle at one point or another through its history. We have viewed our role as ‘quality control.’ We allowed the program to scale, addressing problems as they were called to our attention. In doing so, people are much more invested than if they had simply purchased the product.”