Tar Replaces Ear: The Cluster is the Computer

The Cluster is the Computer timeline

In 1984, John Gage of Sun Microsystems famously coined the phrase, "The network is the computer."

It was prophetic and is more true today than ever. Especially with Web 2.0 and now Cloud Computing, John Gage's dream of needing only any device to access data stored in the network is fully realized.

But still there are actual physical computers on that network, and to play off his quotation and recognize the limitations of individual computers and individual servers, we can now say that "the cluster is the computer."

Once CPU clock speeds and hard drive capacities plateaued, creating clusters of computers, such as with Hadoop, became popular.

Now there were computer clusters before Hadoop, of course, and important, production ones too, like WebLogic and round-robin web servers. But those clusters served very specific purposes. Those clusters in no way acted like general purpose computers that could run arbitrary software.

Hadoop was the first cluster that could possibly be considered general purpose computing. And now that Hadoop is no longer an experimental thing, and now that there are other needs for clustering beyond just Hadoop -- such as Spark, Storm and Cassandra -- data center admins expect to manage and allocate them. And the bean counters expect multiple groups to be able to utilize this expensive capital investment.

The two most well-known solutions of course are YARN and Mesos. There are others. Google internally had Borg, which was later replaced by Omega. Mesos is an Omega-inspired open source project, similar to how Hadoop is a BigTable-inspired open source project.

YARN, Mesos, Borg, and Omega all act as an operating system for the cluster, treating the cluster almost as a single computer, allocating reasources on the cluster, and launching cluster-aware applications on that cluster.

YARN is a bit tied to Hadoop's Map/Reduce v2, and is a natural path for older Hadoop shops or those wedded to a Hadoop distribution that favors YARN over Mesos. It's theoretically possible to run YARN on top of Mesos, but then one would have to worry about two levels of resource allocation.

Mesos has a lot of add-ons, such that it is its own large and rapidly growing ecosystem now. Twitter's Aurora is now an Apache Incubator project that provides scheduling of jobs onto a Mesos-controlled cluster. Ringmaster facilitates Spark and Cassandra on a Mesos cluster.

Chronos is cron for Mesos. Marathon is the init daemon of Mesos.

But the most exciting entry into the Mesos ecosystem is the ability to execute Docker containers on Mesos. The deimos project, which supercedes mesos-docker, provides this.

Docker logo

Docker has been getting a lot of attention lately of its own accord, independent of cluster computing. Over the past year or so, Docker containers have been replacing heavyweight VMs (virtual machines) in the data center with lightweight containers that share the same OS but with separation, similar to "jails" of the 2000s. See the chroot history on Wikipedia that I was the primary contributor of that outlines the 35-year path from chroot to jails to containers to Docker.

Docker applications are packaged as tarballs. A regular Docker system can load and launch a Docker application into one of, say, a dozen Docker containers running on a single physical machine.

But then, with Docker-on-Mesos, a cluster-aware application packaged as a tarball can be launched onto a portion of a Mesos-controlled cluster. The cluster has effectively become the new mainframe. In a further bit of irony, the "tar" in "tarball" stands for "tape archive", a file format once used for mainframe tape drives.

The headline for this article is a slight stretch: that tar files are replacing ear (enterprise archive) files for application servers such as WebLogic, but not by much. Today for a production system, one would probably still be running dedicated clusters of web servers or application servers. But allocating web servers out of a Mesos-controlled cluster has already been accomplished.


Like Sun's Grid Engine and before that DQS.

michaelmalak's picture

You make a good point in that previous "grid computing" solutions handled resource allocation and job queueing better than conventional HPC solutions. However, I don't believe those previous grid computing solutions had either the single-file .tar packaging of Docker-on-Mesos or the init-daemon of Marathon that make the Mesos/Marathon/Deimos stack have the application launching and monitoring characteristics that we've come to expect in a single-computer operating system.