Content-type: text/html
E-Learning 3.0, Part 2: Cloud



In the early days of the internet, when people drew network diagrams showing how computers and programs were connected, they would represent internet connections with a cloud. This was because a message being sent from one computer to another might take any number of different routes, so there was no specific computer or path to draw. Hence, the internet was represented as a cloud.

 

Today, the joke is that "the cloud" is just shorthand for "someone else's computer," but the meaning is essentially the same. Today's internet cloud does much more than send messages. It stores data, caches requests, processes information, suns services, and more. But the core idea is the same. There's no specific computer or path to draw. It's on someone else's computer, but it doesn't matter whose computer it is.

 

Aside from cost savings, one of the key advantages of placing data or services onto the cloud is that they can be accessed from any computer connected to the internet. That's how I use Google Docs, for example. I created an outline of this course I wanted to be able to edit from my home or office, and that I wanted to be able to share with people as they became associated with the course. Because it was located in the cloud, I could share it simply by sharing a URL. This one: https://docs.google.com/document/d/1iBSfbijqt_WmMb9T8_tD8BSlPGwHogaZ8bafvhk1GS0/edit

 

While on the surface it may feel the same to work with a document in the cloud or on the desktop, conceptually they're quite different. You are really working with data directly. It doesn't matter what file format you're using; you begin to think of file formats as nothing more than output formats. And you rarely use them; everybody who needs to interact with the document can interact with it in that same place.

 

It helps to reconceptualize what you are doing with the internet. You are not using it to send messages any more. Rather, you are using it to access and work with data or to extract that data and apply it as needed. Data is like water or electricity. There's a big repository of it out there somewhere (it doesn't really matter where) and the internet helps you tap into it wherever you are, as though data were just a commodity you could use, manipulate and store however you want.

 

Some cloud services simply store data. That's the most basic use of the cloud. Places like box.net and dropbox.com offered cheap storage. Sites like Youtube.com and Flickr.com also added data storage to their services; you could (and still can) store videos and photos. Soon, most major providers were offering cloud storage: Apple's me.com and icloud.com, Microsoft's onedrive.com, Google's drive.google.com and Adobe offered Creative Cloud.

 

If you can share access to some data to other people, then you can work on that data at the same time. That's how some of the earliest collaborative writing applications, such as EtherPad, worked: one data source, multiple authors. The wiki (of Wikipedia and WikiEducator fame) is another application of the same principle. Software such as Drupal and MediaWiki was created to enable multiple people to work on the data, either synchronously (both at the same time) or asynchronously (one after the other). Leaders in the field included Zoho and Google Docs, but now multi-author cloud data editors are commonplace.

 

Most educational applications were and are cloud applications. At Assiniboine and Athabasca we began by adapting online gaming technology, such as Multi-User Domains (MUDs). We used the internet to store learning resources, eventually developing multi-author learning object repositories. And the earliest learning management systems (LMS), for example, Blackboard, began as hosted services and (for students) were always accessed over the internet.

 

The more we think of it, the more it becomes odd to think of data as something we need to store in a document of a certain type, and it feels really odd to think of needing to download it in a certain format and save it to paper or tap or whatever, or to have to attach it to an email or (worse) print and mail.

 

But how do we create and manage the cloud? The computers that make up the cloud are very similar to the computers we use on our desktop; they have operating systems, programs, storage and communications. They usually run a Linux operating system instead of Windows, and they usually run web servers instead of web browsers, and they're usually stored in racks instead of in cabinets or laptop cases. But they're basically the same.

 

The combination of operating system, storage system, applications and communications software is typically called a "stack". Think of the machine hardware as being at the bottom, then the operating system, then the data layer, then the application programs, and finally, the user interface or communications layer at the top. A typical cloud computer configuration, for example, is called a LAMP stack - consisting of a Linux operating system, Apache web server, MySQL database, and Perl or PHP application programs.

 

When you have a hundred (or a thousand) computers to set up, it becomes easier to think of the entire stack as a single unit. The idea is that you could take an 'image' (or exact copy) of one computer's LAMP stack, and then 'flash' that onto a new computer with a single command.

 

This is the beginning of server virtualization. From the point of view of the LAMP stack, it doesn't matter whether it's running on a real computer, or software that is pretending to be a real computer. So, for example, you could have a Windows computer, install an emulator like VMWare and use it to run a LAMP stack. Or you could be running a Linux operating system with WINE and run Windows programs. Or, if you used a Mac, you would run Windows programs using Parallels.

 

These were mostly for desktop computers, they required a lot of computer power, could be difficult to set up, and it was hard to see the advantage. But for services running thousands of web servers, they were an important way to save time and money. The faster and smaller the emulator, the better. The easier to automate the setup process, the better.

 

And that brings us to the present day. Service providers use tools like Vagrant and Virtual Box, or more likely, even smaller and lighter containers like Docker. And instead of running one single container for each web service, they run a collection of containers (known as a 'swarm') working in concert, each one a fully-functioning web server, some dedicated to specific tasks (like load balancing or databases) and others delivering web services to cloud users.

 

What we think of as the cloud today is a set of services offered (mostly) by large corporations allowing people to create, duplicate, deploy and use these containers. Amazon Web Services, Azure, Google Cloud and Digital Ocean are just some of the cloud service providers.

 

It was decentralized and distributed computing that allowed MOOC companies like Coursera and EdX to serve thousands of students at a time. These services are created and provisioned through a maze of new types of file with names like 'Dockerfile' or 'Vagrantfile' or 'YAML'. They enable an online course to start small (and inexpensive) and grow with new students simply by adding more containers.

 

By now we should have left the concept of a 'document' far behind, except perhaps as a metaphor to think of a medium-sized chunk of data. But even this metaphor doesn't capture the true transformation. While we might think of a document as a relatively static block of content you read and write (or record and view), today's conception is more like thinking of that document or video as nothing more than the interface layer of an entire computer. You don't jut read or view documents, you do things with them.

 

Think of media in this new world as entire computing environments as pieces of content that we can share back and forth with each other. If we really wanted to, we could save them to a disk or attach them to an email, but it's easier just to leave them in the cloud and to access them with a browser. It really doesn't matter where it's located, or what it runs on; what matters is what you can do with it.

 

One example of this is the Jupyter Notebook, which is essentially a text document - a notebook - with live functioning computer code inside it that you can modify and run again as often as desired. And when you run a notebook, you're not just running some simple bits of application programming; you're downloading data from third-party repositories, manipulating it, displaying it as graphs or animations, using is as input to machine learning artificial intelligence, and hence, understanding it and learning from it in ways books and videos could never offer.

 

Containers with entire websites are as easy to download and deploy on your as clicking a link or opening a PowerPoint. These new resources allow us to redefine what we mean by concepts such as 'textbooks' and even 'learning objects'. By putting powerful applications into the hands of students we create new possibilities for manipulation, visualization and creativity. We share not just the musical notes that create a concerto, but also all the instruments that play the music, and the collaborative authoring tool used to arrange the notes on these instruments in the first place.

 

Students are now able to not only create text, music and art, but also to edit and create new tools to create text, music and art. They will be able to directly experience the relation between algorithm and outcome, or between mathematics and music, as the case may be.

 

More significantly, networks of containers, each performing its own specialized function, will allow teachers and students to work cooperatively, creating distributed data networks and services. Learning a concept as simple as "load balancing" - a mechanism where requests to a single web page are send to different computers to spread out the load - is a doorway to being able to imagine and understand deep and complex service networks.

 

It's easy to think of the cloud simply resources as "someone else's computer" where you run your applications online. But the technology that makes it possible to use the cloud has created a whole new class of resources, a class where resources are more than just text or multimedia, but resources that are in fact fully functioning computers.

 

And this, in turn, changes learning. The concept of 'acquiring' or 'remembering' these resources, or even of education as the 'transmission' of their contents, no longer makes any sense. It would be like telling a child to "memorize the computer on your desk". You cannot grasp, acquire or remember the cloud. You cannot have the cloud skill, or even cloud competencies. What we think of learning when images, containers and virtual systems are the raw materials is something very different from learning where letters, numbers and figures are the raw materials.

Force:yes