Chao-Kuei Hung
Associate Professor
Information Management Department
Chaoyang University of Technology
Abstract
(Taiwan) Government is about to invest 800M US dollars
to promote the cloud technology and expect to create an
industry worthy of 30B US dollars in value.
Yet one of the advantages of cloud computing is saving money.
So how do these figures make sense? Who stand on the paying
side of the 30B US dollars? University professors are not
just partners of the commercial sector. They must not forget
that they are also employees of their Universities who may
be the purchasing party, and that they are also educators.
University professors need to investigate the cloud computing
trend or hype from a consumers' point of view.
This article summarizes a brief history of the cloud computing
before the commercial hype, and provides suggestions about
buying wisely. Cloud computing is intimately related to the
"small pieces loosely coupled" phenomenon of the web 2.0 trend.
Observations show that many enterprizes, organizations, and
universities have rigid working flows and administration cultures
that go against transparency, democracy, and loose coupling,
which are essential features of a successful cloud computing deployment.
We suggest that the success of a cloud computing deployment lies
not so much in buying expensive products as in changing the working
flow and administration culture.
keywords: cloud computing, wiki, transparency, flattening,
web 2.0, read-write web.
A Brief History of SaaS
Telnet is the earliest SaaS (Software as a Service).
Its development started in 1969 and finalized in 1983. It is equivalent
to the all-text version of VNC (see below). Some computer geeks
are used to browsing using lynx, reading/writing mails using
mutt (or pine or elm), editing text files using vim, ...
For these people, telnet is the most complete cloud computing solution
that put all application software in remote servers.
In view of telnet's security concerns, Tatu Ylönen developed
in 1995
ssh, a protocol encrypted from end to end.
Later versions of ssh has the X Forwarding feature capable of
forwarding any GUI application from the cloud to the local machine.
An ssh -X user is the earliest, most complete cloud user.
There is no single cloud technology that fundamentally surpasses ssh -X.
For example, collaboratively editing the same text file using ssh -X
is not that different from a wiki. The write and talk commands in
the 20th century is a fundamental form of instant messagengers
(which are also SaaS). Of course the newer forms of SaaS have
more features. For example, wiki as a partial replacement for
Microsoft Word have additional features such as history,
version comparison, and self-registration. But it does not show
that wiki has any technically fundamental improvement over ssh -X.
Any advanced feature proposed by cloud providers can be realized by
writing a "localized version" of an application and "cloudified"
by ssh -X in principle. The author believes that the most significant
value of introducing cloud computing for an organization is
building a new working culture -- the web 2.0 wiki culture
(or read-write web culture, or the prosumer culture).
Yet for an organization not ready yet to deal with the huge challenge
of "changing work culture", the ssh -X way of realizing cloud
computing is not only cost-saving and efforts-saving, but also
provides the following advantages:
- This is the most mature SaaS with the richest set of applications.
Every existing application can be a service for the ssh -X SaaS
solution.
- Maturity also results in better security.
- Existing and familiar file formats can be used,
which is important in terms of long term document
preservation and hence organization sustainability
without depending on the good will or even the existence
of specific software company.
- It is easy to use simple scripts written in existing
scripting languages to extend or even mashup the existing SaaS services.
- When there is a need to develop new applications,
existing single-machine API (Application Programming Interface)
are PaaS. Programmers need not waste time learning newly
developed proprietary API that have not stood the test and
scrutiny of the netizens.
It is quite convenient for various versions of Linux, BSD, Mac OSX,
.... to use ssh -X. MS Windows users need to install an X Window
Server (yes, the software running at the local machine is
called the
X server whereas the piece running in the cloud is the
X client) such as
Xming X Server.
VNC developed in 1999, on the other hand, lets users of any
operating systems to use each other's desktop (provided
they exchange passwords). For security concerns, it is suggested
to go through an ssh tunnel. There are also SaaS applications
based on VNC such as
iTalc, a software screen broadcasting tool.
The earliest similar technology on MS Windows is
RDP appearing in 1998.
As we advance into the www age, the most popular SaaS that
emphasize the web 2.0 read-write culture is
wiki. Next to wiki are the
Content Management Systems. Google using these words along
with "comparison", one can find a plethora of existing
software such as Xoops, Joomla, and Drupal,
which can serve as a basis for SaaS. At one point there was
a trend of "webalizing" all applications. If an organization
was wise enough to choose one of these FLOSS
(Free/Libre/Open Source Software) alternatives to
build their own private cloud for SaaS (which are terms
that didn't exist back then of course) instead of
writing their own using proprietary technologies,
it would have not only saved money but also enjoyed these
benefits:
- These widely used systems tend to be more secure
than customized proprietary systems because the former
have much wider audiences.
- These services welcome any browser.
- For systems that are to be accessed by outsiders,
these solutions are better than proprietary
solutions in terms of search engine optimization.
- New features can be implemented as plugins or extensions.
- Various systems for personnel, purchasing, stock management,
announcement, ... can be loosely integrated.
Every employee needs only one account (instead of one for each system).
- Learn once, and use it everywhere. Employees need
not learn various different kinds of web systems.
Successful Joomla sites
and Drupal sites abound.
And then contrast these with organizations that bought expensive
proprietary tools and spent extensive human resources, only to
build
self-defeating sites or information systems (Chinese) and
drive themselves into self-censorship about
security problems (Chinese) when the only version of browser
(IE 6) that they serve are shown to have serious security problems.
People who know about SEO choose these FLOSS to build their SaaS as private clouds not mainly
because of price but mainly because of many other technical reasoning.
Many more cloud applications have already been in wide use
before the commercial hypes, such as:
- file sharing: nfs developed by Sun at around 1984,
and smb developed by Microsoft based on IBM's product
(which is known as "network neighborhood" in layman terms,
and which is not quite a mature cloud product because
it is limited to local area networks);
- webmail services;
- word processing: gratis, ad-sponsored, and paying
wiki services, google doc, ...;
- online maps, online translation, online photo albums, ...
Each and everyone of the above SaaS supports clients from any
operating systems including various versions of Windows,
Linux, and MacOS. Why is this important? The story of proprietary
information systems locked into a particular version of IE vs
the open source CMS should be an important lesson for us.
MS Windows is without doubt the most popular desktop systems today,
but it is not so easy to predict which operating system will
dominate the market five years from now. In a world where the
smart phones are becoming ever important and where Windows does
not compete well in the smart phone market, the wisest thing
for technology purchasers to do is neither discarding Windows
immediately nor ignoring other operating systems completely,
but rather to take care of clients of all operating systems
accessing the cloud.
Incidentally, most of the above SaaS has a Free/Libre/Open Source
Software solution except the online map. Open Street Map is not
yet competitive with googlemaps whereas replacing google doc
with wiki might cost some formatting control details.
Each of the other services can be setup using FLOSS.
There is even an
xrdp as an alternative to Microsoft's rdp.
Why is this important? Setting up a private cloud using proprietary
technology requires complicated licensing calculations based on
the number of clients connecting to the cloud service,
a problem which is absent in FLOSS solutions. For an organization
planning to buy ready-to-use cloud services, the
scalability and reliability features would be much more
worth the cost than the SaaS software licensing price.
Finally, the social networking tools such as twitter, plurk,
and facebook are all examples of SaaS. Once again, we see that
the challenge for an organization to deploy cloud computing
lies more in the change of administration/working culture
than in buying advanced software. It is hard to imagine how
an organization can benefit from buying/renting expensive
SaaS software if they have not successfully used these gratis
cloud services (or an even older cloud tool -- blogs) to
advertise themselves.
A Brief History of PaaS
Remote Procesure Call appearing in RFC 707 around 1976 is
probably the earliest PaaS. The author as a PhD student in
Computer Science witnessed the popularity of Sun RPC.
NFS as described in the SaaS section is based on Sun RPC.
Microsoft RPC / DCOM continued along this line but was not
widely used, possibly because it is too complicated and also
because it was not open in the beginning. On the other hand
Sun RPC evolved into ONC RPC which is still used even today,
mostly for migrating old applications based on the old RPC
to new environments.
The second wave of PaaS began in 1998 as XML-RPC when
http and xml became mature. This open protocol collaboratively
developed by UserLand Software and Microsoft evolved into
SOAP (Simple Object Access Protocol).
Around 2000,
REST (Representational State Transfer) appeared
in response to SOAP's complexity. It is more a design style than
a standard. Instead of invoking complicated XML structure to
define a protocol, it treats a simple URL as a way to "call"
or "retrieve" a remote resource. Apparently REST is gradually
replacing SOAP as the most popular way of providing PaaS.
[1,
2,
3] This is consistent with the "small pieces loosely joined"
trend of the Web 2.0 / read-write web culture.
AJAX technology appears to be the best compliment to the REST style
as prominently demonstrated by google maps.
One PaaS by itself is hardly interesting at all.
For an end user, only SaaS is truly useful.
Yet there would be (probably more than one) SaaS implementation
if an PaaS turns out to be useful/interesting.
There is no point in buying a complicated PaaS product, only to
hire a programmer to develop SaaS on it.
For an PaaS application to be interesting and worth of monetary
and/or human power investment, it usually means mashing up two or
more PaaS into an SaaS.
Mashing up google maps with google calendar
(Chinese) is a simple example.
ProgrammableWeb collects a directory of freely available
PaaS's, and their mashups. It was built around Oct 2005
according to the way back machine. (But of course the
term "PaaS" did not yet exist back then.) Every PaaS programmer
should know of this site, which grew from a 26x26 matrix to a huge
collection of more than 2000 PaaS's and 5000 mashups.
S/he should also know of
Google Maps Mania, which reports interesting google maps mashups
and which can be seen as one column (or one row) from ProgrammableWeb's
collection.
Purchasing Suggestions aboud PaaS
The following are purchasing suggestions aboud SaaS based on
the author's own experiences and historical analysis.
Most small and medium-size businesses don't need
PaaS. If SaaS is like a ready-to-serve meal,
PaaS is like one piece of a kitchen recipe. It takes cooking (programming)
efforts to turn one or a bunch of PaaS's into something edible.
For most SMB, it makes much more sense to simply use existing free SaaS
such as wiki, google doc, or CMS (especially the FLOSS ones).
Of all businesses and/or organizations that could benefit
from PaaS, few are ready to challenge their own working culture
and successfully deploy PaaS. Take
rss mashup (Chinese) as an example.
It can be very useful for a University.
Each department or office can have its own bulletin board manifested
as an rss feed, and the home page of the University can have a
mashup of all these rss feeds. Each rss being a REST example,
this is the simplest form of PaaS mashup and requires hardly any coding.
Each department or office can go one step further and make good use of tags
if they use blogging systems in place of existing complex information
systems (which are, sadly, typical in Taiwan). A student could subscribe
to the "workstudy" tag of the mashup so that s/he can focus on all
announcements related to workstudy opportunities regardless of its source .
Yet most universities' long history of building centralized and
integrated information systems for the past one or two decades
has also built an administration culture that runs completely
against the "small pieces loosely joined" trend of the internet.
Such suggestion probably seems quite foreign, if not outright
ridiculous, to the administration.
Of all businesses and/or organizations that are capable of
changing their working culture and thereby successfully deploying PaaS,
most will use PaaS on the client side (calling side) of PaaS.
For example, I was on the client side (calling side) of PaaS in the
google map - google calendar mashup example. Besides, this kind of
mashup requires IT staff of certain level of programming capability.
Moreover, it is wise to make use of mature, popular, and public
PaaS interfaces listed in ProgrammableWeb rather than some
obscure proprietary PaaS's for long term considerations.
These organizations have no need to purchase PaaS products.
Those that can benefit from the **server side** of
a PaaS don't need to buy PaaS products.
These businesses and/or organizations should have a group of
engineers who are more familiar with cloud technology,
in particular REST+AJAX, than the author is. If they find existing
cloud tools (such as hadoop of apache) not entirely suitable to
their purposes, it makes much more sense to develop
extensions/modules/plugins for existing FLOSS frameworks than
buying some obscure proprietary PaaS product. A whole army of
international developers are there for one to consult.
By the way, it is interesting to note the kind of business that can
benefit from the **server side** of a PaaS. If the business is
also its only user from the **client side**, then very likely
there are already FLOSS solutions that can directly provide a
ready-cooked SaaS. A PaaS provider is meaningful
probably only if it is listed in ProgrammableWeb.
Yet that entails providing these services to arbitrary clients
on the internet. In this case, note that each client (calling side)
of a PaaS is a web site in its own right, which means that
each client has its own set of clients! Two corollaries follow.
Firstly, advertisement/visibility would be an important element
of the businesses of this PaaS provider. Secondly, not too many
businesses are capable of doing this. This PaaS provider would
be some kind of internet company. PaaS provided by Plurk and Twitter
for bloggers to embed into their sites are concrete examples of
this situation. For a business to go this far, they must have a
much better understanding of
attention economy and cloud computing than the author and
most professors. In other words, this is not a typical SMB cloud buyer.
Conclusions
IaaS (Infrastructure as a Service) is not discussed in this paper.
Products at this level need to provide scalability and reliability,
which do have associated physical costs that are absent in SaaS and PaaS.
Besides, it has a relatively simpler history. There is less controversy
around it from a consumer's point of view.
The SaaS and PaaS solutions presented in this paper may not be unique
nor the best suitable to your organization. Nor is this paper meant to
invalidate all non-gratis public cloud subscription services and non-gratis
private cloud setup services. Yet organizations are highly advised
to ask their IT staff to take note of these existing gratis solutions
listed in this paper before making unreasonable investment in suspicious
cloud products. Deploying some of these existing gratis solutions can serve
as low-cost experiments for the organization, and as a yardstick against
which more costly products can be compared.
Office software is the easiest to understand and easiest to
perceive the difference when an organization goes cloud. It so happens that we
are at the cross road of replacing .doc files with something new.
The road of least resistence is of course remaining with .doc file
if an organization is not yet ready to think about long term
document preservation. On the other hand, if an organization decides
to make a change, going .odt is certainly a much better alternative
than going .docx,
which is under patent threats. There is however a third alternative.
If one thinks about it, MS Word is the most used software other than the
browser and is certainly most worthy of going cloud.
But wiki and/or google doc is exactly what the cloud version of word
looks like. The Wikipedia project uses mediawiki as the cloud
collaboration tool for its contributors. It does not have fancy
formatting or annoying flash, and yet it enjoys extremely high traffic.
This global project is the most successful large experiment of
"using wiki as the cloud version of Office" and it demonstrates how
a well-coordinated web 2.0 working culture can achieve
natural search engine optimization.
In a university for example, many administrative tasks can be
greatly simplified if Office software and complicated "information
systems" are partially replaced by wiki.
Think about scheduling a meeting with students,
preparing meeting agenda, gathering faculty publication statistics, etc.
The lack of wiki adoption in universities shows that most
universities are not yet prepared to change their working culture /
administration culture even for the simplest, the most effective,
and the least expensive cloud technology. It is hardly persuasive at all
for professors who have no experiences in using wiki to participate in
developing and selling less influential and yet more expensive
cloud products. A university professor should be more than a partner
for software companies. S/he should exercise academic integrity
in choosing the best cloud technology for her/his employer -- university
-- which costs little and brings about real values in the web 2.0
read-write internet age.