Cloud Computing
Historical and theoretical perspective on cloud computing
Bertrand du Castel, Austin, Texas
Amended July 16, 2009
Amended July 16, 2009
Déjà vu all over again?
In the 1970's, before the era of personal computers, IBM was reigning supreme, and was offering an operating system feature called TSO ; this Time Sharing Option allowed workers with a computer terminal to submit jobs to remote IBM computers sitting in one of the vast computer rooms that IBM had in Paris at the time (one I visited was, if my memory is correct, in Boulogne s/Seine, a suburb of Paris). As I spent a year as a post-doctoral student in the Paris IBM research center in 1977-1978, I remember that TSO was used to share an IBM mainframe between various units of IBM, as it was not exclusive to research. In fact, we in research were taking second priority to at least some commercial jobs. This to say that TSO had enough security measures to allow sharing of vastly different types of jobs, had ways to prioritize those jobs, and was capable of tracking and allocating usage. I don't know if that tracking was used for each division to pay its fair share, or if the costs were in a sharing pool. If anybody remembers please let me know.
Cloud computing in the 1970's
Angels of the cloud
| Time sharing | Virtual machine | |
| DEC | Multics | |
| IBM | TSO | VM/CMS |
Cloud computing in the 1970's
At the same time, IBM had an operating system called MVS (Multiple Virtual Storage) which, although somewhat different from today's virtualization software such as VMware, was nevertheless on that evolution path (actually, IBM had another operating system, VM/CMS, with VM standing for Virtual Machine, that was even more advanced on that path, but that didn't work with TSO). At the research center, we were using TSO with MVS to develop our software tools. In other words, we were using remote computers to perform tasks on demand, and these tasks were in turn implemented on virtual machines, that themselves ran on dedicated computer somewhere. That would be called cloud computing today, except that I don't know if that configuration was ever used to serve not only internal customers, as IBM was doing, but also external customers. If IBM has ever served external terminals with TSO, with several customers eventually being mapped to a same machine, there IBM could truly claim to have implemented cloud computing a long time ago.
But they wouldn't be alone. When I was hired by Schlumberger, the company was running oil and gas software on Digital Equipment Corporation mainframes (Dec-10; I remember programming on it and chasing hardware pointers, an original architectural feature). Here several divisions of the company could access the computer in a time sharing fashion, and remotely, again prefiguring cloud computing. We are even closer to today's cloud computing, because some Digital Equipment mainframes were shared in the early 70's between several academic institutions; they were bearing the Multics operating system (an inspiration if not a precursor of Unix and Linux, which are today operating systems of choice for cloud servers) or an alternative, TENEX (a precursor of computers supporting the same artificial intelligence that is now a component of cloud services; see below) [Thanks to Claude Baudoin for telling me of being witness of that in 1974 at Stanford]. So, from that perspective, we can start looking at what' s original about today's version of cloud computing.
Angels
Modern (2009) cloud computing has four angels: web interfaces, virtualization, Internet, and platforms. Web interfaces stem from the ease of interfacing computers on the web, either via the ubiquitous HTML (HyperText Markup Language), or via the powerful XML (eXtensible Markup Language), or in a combination of both. HTML is the language best understood by everyday browsers, the core machinery of the web, what makes the pretty pages like the one you're just reading. So browsers can go anywhere on the web where there is a server ready to deliver pages for our enjoyment. A side effect of that is that any computer can act like a browser. Using the same HTML language as the browser, a computer can access any server to request pages for its own enjoyment. The computer can formulate its request in such a way that the server understands that before delivering the page, it has to perform certain functions, say, retrieve names in a data base, or compute the weather for tomorrow, or whatever. Et voila! That's cloud computing. A computer can ask another one to perform a task by, in a sense, impersonating a browser. This is all simple and efficient. However, this simplicity comes at a price. Because each computer using HTML to request tasks does it with total freedom of format, each new task required learning a new way of doing things. After a while, the diversity is such that it because too bothersome, even for computers.
| Web Interfaces | Virtualization | Internet | Platforms |
| HTML XML REST SOA | VMware Xen | TCP/IP HTTP(S) SSL | LAN Servers Blades Desktop Phones |
Angels of the cloud
That's where XML fits in. More elaborate than HTML, XML has been built with a different goal in mind than HTML. Whereas HTML has been targeted at humans using browsers to read information on the Web, XML has been dedicated to computer-to-computer interactions. It carefully builds constructs that allow computers to communicate very naturally (see Computer Theology page 182 for an easy to read explanation). And better than that, it allows building more specialized languages on top of it, for specific purposes (a little bit like in English, we build specialized linguos depending on our specialty, be it chemistry, medicine, or any other trade). Using those specialized languages, computers can talk with other computers in ways that are understandable by any observer, be it human or yet another computer. We now have a uniform way of building computer to computer interactions, and that's the first angel of cloud computing.
What's virtualization? It's a variation on the Russian puppet scheme. You open the puppet and find another one, that you can open, and there is yet another one, and so on. It is possible to put a computer inside another one in a slightly different way; by making that software look to the outside world on the network just like another computer. That's because when we are on the network, the only thing our browser sees is a flow on information going back and forth. Our browser might be talking to an Apple machine, or a PC on the other side, it doesn't make a difference to it if the information flow is the same. If we pursue the analysis a little further, it would be possible to put software on a PC that would make the PC look on the network like an Apple machine. All this software needs to do is to send information saying "I am an Apple machine." Our browser can believe that, and here we are, we have a virtual Apple machine on the network, actually a virtual machine running on a PC.
Virtualization is the second angel of cloud computing as it gives great flexibility to the providers of services on the network. They can have several virtual machine on one computer, or conversely, one virtual machine spread over many computers. The former case is useful when the requests to the service are not requiring the full capabilities of the host computers; combining many requests on one computer thanks to virtualization makes it possible to use the host computers to the fullest extent. In the latter case, the virtual machine, while looking like a single computer to the outside, actually can make use of many real computers in order to provide a lot of power to bear on the task at hand. As far as the requester is concerned, here is a lot of capability available.
The Internet is much of what makes the difference between cloud computing of yore and today's version. Thanks to the Internet, computers providing a service can be anywhere in the world, subject to legal and other policy considerations. This is why Google has put server farms in cold places next to water dams; there are less power requirements and the power that's needed is more readily available. Another way to benefit from the Internet is to have servers residing in distinct areas, therefore lowering the risk that they be all affected by, say, a flood or an earthquake. A virtual machine can rapidly migrate from one set of computers to another, thereby providing continuity of service. Conversely, in the 1970's, access to computer farms were restricted to clients who had a dedicated link to them. Today, anybody can access a cloud computing service, which greatly opens the customer base. The Internet is the third angel of cloud computing.
Finally, a huge difference between today and yesterday is the cost of computing itself. Thanks to modular technologies that allow scaling up computer power via the assembly of relatively inexpensive parts, the cloud computing provider can build whatever capacity is needed in a progressive fashion. This opens the number of possible providers, while providing them with a business model that can adapt to the equally adaptive needs of their clients. It is possible to assemble computing platforms in all dimensions, be it space, connectivity, size, and speed, depending on the demands and evolution of the market. The computing platforms that sit on the cloud waiting for requests are the fourth angel of computing. But were does this all go?
Back to earth
While the 70's had their own version of cloud computing, the 80's saw the personal computer take over, to such a point that not only were those computers used more and more for heavy tasks, but they themselves became servers on the network, replacing the mainframes of yore. In the 90's, computing capabilities found themselves almost equally shared on client and server computers of the network. In the 00's, an evolution started in earnest that is still progressing today. Instead of installing software on our personal computers, which by now include phones and even banking cards, we have the software downloaded as need be from the network. In a reversal of sort, cloud computing becomes computing on earth, on our own machines, but using software downloaded from the cloud. A prayer exhausted, the angels have talked.
| Light client | Rich client download | Rich client install | Server client | |
| Desktop function | Browser | Application | Application | Server |
| Network function | Cloud | Cloud | Cloud | Cloud |
| Back Office function | Server | Server | Server | Application |
Who serves whom?
In some situations, since our personal devices are ready sources of computing, they may become themselves servers of cloud computing. For example, SETI (Search of ExtraTerrestrial Intelligence) runs on our personal machines to then feed a server somewhere. In this case, we have become the cloud. Assuming that the trend continues of using personal and server machines both as source and targets of computing demands, we can see that cloud computing becomes a huge experience of optimizing usage of electronic capabilities over the worldwide network. This is with this in mind that we can now study the social impact of cloud computing.
Deconstruction
A large company today caters to many masters. A most important one is the core value proposition of the company. Whether the company is into products or services, a body of assets, intellectual property, practices, culture, and relationships, is unique to that company and has to be carefully nurtured. Accompanying this body of ownership are procedures, processes, and a set of methodologies building around them a barrier that allows the company to survive in an evolutionary struggle for capitalistic success. Equally, a governmental, or quasi-governmental, or non-profit, institution builds around services (and sometimes goods) that constitute a unique proposition with possibly core information not to be shared with everybody. Obvious as it is for governmental institutions like armed forces, police, health, and other secrecy or privacy oriented bodies, it is also important for information-driven or people-driven organizations such as communication institutions and public congregations such as church and charities, which have to protect work in progress, privacy of their constituents, and information trusted to them in confidence. So whatever the institution, a core set of information structures constitute the very soul of the value they provide.
| Finance company | Data company | |
| Cloud service provided to clients | Finance | Data warehouse |
| Cloud service purchased from supplier | Data warehouse | Finance |
Reconstruction
In contrast, numerous functions of organizations are similar from one to the next. Personnel, finance, treasury, marketing, operational procedures, factories, transport, are all functions that have most often much in common even if in many cases they may differ in very important ways that then relate to the core proposition of the institution. However, this commonality is difficult to define. In fact, the function of companies providing, say, accounting software, such as SAP, has been somehow to express this commonality as they wanted to effect economies of scale by selling the same product to many clients. They somehow had to integrate in the same product various practices and needs in a way that would allow them to adapt rapidly to both the differences between their client needs and their evolution. Another company, say Oracle, may do similar things, but actually in a totally different manner than SAP, although at the end, both products try to satisfy the same needs. If we extend this description to the hundreds of products a modern company uses everyday for its functioning, we see that today there is little ground for efficiency of scale at the global level of the company/institution ecosystem.
In order to make any real progress in the sharing of non-competitive knowledge and practices between various organizations, an upheaval is needed. That's were XML enters the stage. Beyond allowing cloud communications, XML can be categorized as a cognition language (see Computer Theology page 279 for a detailed explanation). XML has the power of expression of natural language, the language of humans, albeit with a particular structure that makes it palatable to computers. Therefore it is conducive to defining common information. Actually, the attempt of industries at commonality didn't wait for XML to come along. Multiple standards organizations, many under the umbrella of ISO (International Organization for Standardization), have been developed that went a long way towards common practices. Accounting standards and the full legal infrastructure can be considered exercises in standardization. However, those standards were not generally in a form that was conducive to widespread use by computers. That's the dimension that XML brought, and because it is also the lingua franca of cloud computing, deconstruction had found its enabler.
Deconstruction means a possible reorganization of businesses and government akin to that of the industrial revolution. In the same way as the industrial revolution has deconstructed society to provide for specialized enterprises, cloud computing can bring an equally thorough institutional change by concentrating expertise and relieving it from amateurism, or, to say it positively, craftsmanship. Craftsmanship doesn't lose its function in a deconstructed environment; simply, it becomes a node of expertise amongst other. What we don't see anymore is companies devolving precious time and money in solving problems that are not part of their core expertise. With cloud computing, they can contract to services that themselves have those activities as core expertise. Deconstruction meets cloud computing, and provides a blueprint for its evolution.
Sunny weather above
All that remains is to then find common ways for institutions to communicate their expertise and associated services. With a solid layer of XML standards to draw upon, more layers of generic communication between institutions can be built and are spelled out in the semantic web hierarchy from XML to RDF (Resource Description Framework) to OWL (Ontology Writing Language, although that spelling of the acronym is now considered obsolete) to Trust. RDF brings to XML the possibility of building sentences much as we do in everyday conversations. "I specialize in accounting." "Tell me your prices." These are examples of sentence that RDF can express. However, being able to utter the sentences doesn't mean that we (or the computers) understand them. Although the technology is still primitive compared to what we can prefigure, there is another layer, now on top of RDF, that describes some of the meaning of sentences. OWL is good as specifying that, for example, goods and services have prices, that they have delivery mechanisms, which themselves are subject to options, and so on. It also brings artificial intelligence to cloud computing as it natively supports some forms of reasoning. What OWL is not good at is engaging in automatic learning; this is yet a domain beyond the reach of computers on the scales that we are describing in today's cloud computing (but still approachable, with many examples, including our own unifying model of logic and rhetoric). Still above OWL, lies trust. Computers need to trust the cloud, and the cloud must provides means for evaluating that trust. Well, that's what Computer Theology is all about. Computer Theology is the first attempt at totally formalizing the role of trust in cloud computing.
Semantic Web
| Trust | Theology |
| Logic | Learning |
| Ontology | Knowledge |
| Resources | Data |
| Cloud | Medium |
Semantic Web
Standard-Bearers Raise the Flag
From our description, it seems that the following tasks are part of the new recipe:
- Identify what's core and what's generic in the institution
- Get the generic on the cloud; keep the core in house
- Establish trust levels and rules
After a rough evaluation, the first task involves some tedious modeling and establishment of policies. The difficulty in this compared to previous efforts at modeling an organization is in partitioning it both vertically (into functions) and horizontally (into value). That effort of deconstruction leads to an assessment of ready candidates for cloud computing, where the institution becomes client of functions more efficiently performed by others. The other parts of the partition, the core values of the company, its expertise, become themselves nodes of cloud computing: in this case, the company provides the expertise to others which externalize to it. So cloud computing has two ends. It is a supplier base for generic functions, and a client base for core functions. Once that partitioning is clear, interfaces need to be defined that formalize the flow of information between clients and suppliers, and contracts must be established for the business models associated. Coupled with an evaluation of trust levels sought, the exercise then becomes one of identifying clients and selecting partners, engaging them in the symmetric evolution for the better good of some and hopefully of many.
| External to Internal | Internal to Internal | Internal to External |
| Amazon EC2 and S3 Microsoft Azure Open / standards | CISCO EMC IBM | SOA REST Proprietary |
Cloud services (examples)
Eric Schoen mentioned to me that from a client-supplier perspective, a cloud service may indeed be summarized as an interface plus a contract. The interface provides access functions of interest plus necessary authentication, authorization, and accounting capabilities. The contract spells out service levels for availability, support, performance, expansion, and other desired features such as memory and storage if applicable. It also spells out service properties such as privacy, security, regulatory compliance, and other considerations, e.g. political or geographical constraints. The interface can be human to machine or machine to machine, or even human to human in some cases, such as today's web services that bring human expert responses to questions asked over the web. The interface+contract model of cloud computing provides a ready way to organize the map of enterprise services along the three axes of external services used internally, internal services provided externally, and internal services used internally. External services used externally may equally be mapped to understand further the role of the enterprise in the cloud ecosystem; for example, what are external flows of exchange that should properly be part of the enterprise?
Now comes the hard part. Where to start? The central issue is probably that of externality. At this point (early 2009), none of the cloud services can provide an encompassing contract covering the properties that we just enunciated. One has to deal with important limitations. Therefore, it is important to study which of a company's applications and data can live outside of its control, as defined by these limitations. Other applications and data will have to wait until the contracts are satisfying. As far as a company providing cloud services, it will have the reverse challenge. Contracts provided to the outside must meet the company's capabilities. Actually, specific emphasis on certain elements of a contract, such as, say, cryptographic measures, may provide by themselves a determining value to the service offered. Finally, internal cloud capabilities offered internally have the advantage that the company controls both sides of the contract, and therefore has much more levy in defining the services. It is likely that we'd find companies that prefer to start right there, gaining insight and experience before affronting external winds.
External to Internal
This is the domain of today's (early 2009) such offerings as Amazon's (EC2) and Microsoft 's (Azure). Amazon has a succinct contract (Service Level Agreement or SLA) that boasts of availability greater than 99%, with some flexibility in the definition of availability. Microsoft has no SLA for Azure that I could find. Amazon lets users build virtual machines embodying their software that is then managed by Amazon cloud services. This allows to package one's software, but I don't know if and how commercial packages can be included, both technically and license-wise (it's obvious in some cases, but not obvious at all in other cases, say, if one wants to use Matlab). Microsoft provides interfaces (.NET extensions) that allow to program against them; technically, it means that commercial software using those interfaces can be integrated in one's Azure programming, providing licenses allow it. However, again, I don't know how one would package other commercial software (the question is similar to that for Amazon in this case). Also, buyer beware if the contract is of essence. In general, as the interfaces are different, buying into one offering is likely to lead to a long-term commitment.
Other offerings by Google, Sun (soon part of Oracle), and Yahoo are up, and the Amazon/Microsoft discussion we just had applies to them as well. Of course, newcomers try to bring differentiation, and a rapid pace of innovation is typical of initial growth. For example, Google offers in their cloud services , with a product called Secure Data Connector, the possibility for corporate external cloud applications to access data in and out of their own corporate firewall. What Google does is that each time, say, the cloud application requires data, the data request is repackaged by Google in order to encrypt access to the firewall data. Actually, the data are decrypted in order to be consumed by the application, so, for a moment at least, corporate data in the clear reside on Google servers, wherever they might be. To watch also are open source products such as Apache's Hadoop. It provides a distributed file system that balances data over thousands of nodes. In such a situation, interestingly, there is no hope of getting a contract specifying where the data reside in the general case, since moving the data around to optimize performance and reliability defeats that purpose. So if data control is at a premium, Hadoop then becomes an internal proposition. In particular, Yahoo uses Hadoop.
Other offerings by Google, Sun (soon part of Oracle), and Yahoo are up, and the Amazon/Microsoft discussion we just had applies to them as well. Of course, newcomers try to bring differentiation, and a rapid pace of innovation is typical of initial growth. For example, Google offers in their cloud services , with a product called Secure Data Connector, the possibility for corporate external cloud applications to access data in and out of their own corporate firewall. What Google does is that each time, say, the cloud application requires data, the data request is repackaged by Google in order to encrypt access to the firewall data. Actually, the data are decrypted in order to be consumed by the application, so, for a moment at least, corporate data in the clear reside on Google servers, wherever they might be. To watch also are open source products such as Apache's Hadoop. It provides a distributed file system that balances data over thousands of nodes. In such a situation, interestingly, there is no hope of getting a contract specifying where the data reside in the general case, since moving the data around to optimize performance and reliability defeats that purpose. So if data control is at a premium, Hadoop then becomes an internal proposition. In particular, Yahoo uses Hadoop.
Internal to Internal
Internal delivery of cloud computing services can be made in two ways. One is to install an internal cloud computing product such as CISCO or IBM claim to offer and use their interfaces. The other one is to piggy-back on existing enterprise infrastructure to deliver cloud interfaces themselves backed up by perhaps a combination of internal and external cloud services. For this, a candidate is a Service Oriented Architecture (SOA) around an Enterprise Service Bus (ESB). Such services already offer functions such as authentication, authorization, and accounting. They can be combined and have already proven their usefulness to the business. Worth noting here is that Azure doesn't offer an internal cloud computing option; it's all external, i.e. hosted by Microsoft. As Microsoft is installing components of Azure in its products, that might change, but as for all those activities that are second thought, it's a question whether there will ever be an internal Azure offering. An interesting development is that VMware is promoting their vSphere product as an internal cloud operating system.
Internal to External
The provision of enterprise services to the outside is a variation of the internal version just presented. An enterprise with a solid SOA/ESB architecture has ready XML protocols to export services. However, the contractual aspect of the venture comes to the forefront, and involves covering all aspects of the SLA. From availability to support to localization to legal concerns, the plate is full.
Before leaving the question of externality, we'll note that the prevalent cloud computing architecture will be that of integrating the cloud as a unique proposition covering all needs at the same time. Where computing will happen will eventually depend on business issues, many contractual, and the only difference between internal and external will be a that contractual boundary. For that reason, vendors that straddle internal and external cloud computing will be at an advantage, or better even, as we'll now turn to, standards will be established that allow vendor interoperability, allowing to chose cloud positioning inside or outside the enterprise more in function of needs than of necessity.
Beyond maneuvering on a large scale which is typical of computer development, it is reasonable to expect that standards will eventually happen, would it be only for the reason that we explained earlier regarding externality. Companies will want to integrate external and internal computing, and to migrate between the two depending on business and contractual needs. Therefore, they will create pressures on vendors that should exceed their capability to resist with totally proprietary solution. One possibility of course is that one player wins it all, like Microsoft did with operating systems. However, history is a guide, and it is unlikely that the computer community and its legal environment will let it happen this time again. Governments, in particular, are now keenly aware of the propensity of computer business of generating de facto monopolies due to the complexity of the solutions involved. Once somebody has taken a solid technical lead, it's hard to encroach on it. I don't think that the world is ready to let its entire network infrastructure be dominated by a single-vendor, or, as an extension, a single country.
Before leaving the question of externality, we'll note that the prevalent cloud computing architecture will be that of integrating the cloud as a unique proposition covering all needs at the same time. Where computing will happen will eventually depend on business issues, many contractual, and the only difference between internal and external will be a that contractual boundary. For that reason, vendors that straddle internal and external cloud computing will be at an advantage, or better even, as we'll now turn to, standards will be established that allow vendor interoperability, allowing to chose cloud positioning inside or outside the enterprise more in function of needs than of necessity.
Standard-Bearers
When a field of computing has established players, even recent ones at that, like Amazon and Microsoft, the next player has little room to maneuver. So the way the game is played is that if you're second, you want to pick up a flag and raise it high (before you ask; yes, I've been there), claiming the high ground of interoperability, open systems, and standards, and denouncing proprietary systems, and in the making getting an opportunity to try to lead, or at least to better understand, the industry. That's what happened in the end of March 2009, with the creation of the Cloud Computing Interoperability Forum under the leadership of a new cloud computing company, Enomaly, which converted the marketing of its original internal cloud product to that of providing companies to a path towards vendor independence. With a standard interface on top of all other interfaces, the industry would now be free of the dreaded dependence on one provider. While this works well on focused products, it is much more difficult to do on vast enterprises like cloud computing. We can expect jockeying inside the Cloud Computing Interoperability Forum, competitive fora appearing which will present themselves as even more open, standard, and interoperable (while having many of the same members; that's a good way to create confusion, which can create fields of opportunity), and companies reversing the proposal to claim that yes they are proprietary, but that's because their technology and services are superior, which may well be true in a situation where what constitutes exactly the field is yet in development, and where there is lots of place for innovation. By the way, an important part of the Cloud Computing Interoperability Forum is that as of inception, it has an ontology in the center. We've already talked about that earlier, and we'll come back to it later as well. As co-Chairman of the W3C Semantic Web for Oil and Gas industry conference last year, I have some particular interest here.Beyond maneuvering on a large scale which is typical of computer development, it is reasonable to expect that standards will eventually happen, would it be only for the reason that we explained earlier regarding externality. Companies will want to integrate external and internal computing, and to migrate between the two depending on business and contractual needs. Therefore, they will create pressures on vendors that should exceed their capability to resist with totally proprietary solution. One possibility of course is that one player wins it all, like Microsoft did with operating systems. However, history is a guide, and it is unlikely that the computer community and its legal environment will let it happen this time again. Governments, in particular, are now keenly aware of the propensity of computer business of generating de facto monopolies due to the complexity of the solutions involved. Once somebody has taken a solid technical lead, it's hard to encroach on it. I don't think that the world is ready to let its entire network infrastructure be dominated by a single-vendor, or, as an extension, a single country.
Applications Tickle
Applications can be of several kinds. Traditional applications can adapt to the clouds in the sense that they are still installed and used as before, but they actually communicate to the cloud for computing or storage. "Rich" applications are downloaded from the cloud on demand and executing on the user's machine, perhaps communicating with the cloud. "Light" applications are downloaded from the cloud with minimal execution on the user's machine, and the actual burden of computation and storage is entirely on the cloud.
Cloud Applications (examples)
| Traditional Adapted Applications | Rich Applications | Light Applications |
| Oracle SAP | Adobe Flex Adobe Flex Microsoft Silverlight | Citrix / virtual desktop Microsoft Explorer Mozilla Firefox |
| Read the SLA | Read the SLA |
Cloud Applications (examples)
Traditional Adapted Applications
An example of a traditional application adapted to the cloud could be the database maker Oracle. While Oracle has been used to manage data on a company's computers, the same Oracle could find data and computing extensions on the cloud. Or, going one step further, all the data and computing could happen on the cloud while Oracle would then become just an interface and a contract for the user's machine. As we mentioned, the main challenge is the contract (Service Level Agreement). With data being stored outside of the company's perimeter, or even used in a transient manner during computation on the cloud, come sets of concerns of regulatory, legal, safety, and security nature. For example, the contract might stipulate that data can only reside in certain countries, ownership of the data must be clearly defined, recovery procedures must be specified, and such security characteristics as encryption, whether static or dynamic, have to be established. Obviously, availability, performance, and other operational features such as support have also be part of the service agreement. Insurance may have to be considered in case of failure to deliver, as loss of database information may be crippling for an organization. When I was working on smart cards, I remember of once having a contract with a company that was doing marketing for one of our projects. When we wanted to stop using their services, they refused to hand us the list of our own clients that they had on their computers. A good lesson learned.
Rich Applications
This is a new class of applications made possible by a combination of browser technology and considerable improvements in languages aiming at virtual machines. When Java was introduced in the mid 1990's, what would become the first widely distributed commercial language for virtual machines was ready to be deployed either via installation on computers for stand-alone programs, or delivered via the web to be executed within the confine of a browser (the latter usage made the word "applet" a household name). However, it turned out that only the former usage conquered the world (the latter has recently be revived under the name Java FS, but it sure is an uphill battle). In fact, Java allowed to create secure environments for programs to execute on the most defensive of widely available computers, smart cards and equivalent. As I have been credited to introduce Java this way to the most sold computers in the world (see this knol), one would think that I could be partial here. However, it happened that better languages than Java for Web distribution would eventually make it to browser execution. In particular, Adobe's Flex has evolved from being a virtual machine language dedicated to human interface and graphics to a general purpose language similar to Java, but drawing from its pedigree of initial severe network performance limitations a passion for cohesiveness, and from its pedigree of movie-like environments a passion for controlled speed. It is thus now possible to download from the cloud applications that are general in nature, and execute within the confine of the browser with set properties of security, performance, and functions such as easy communication with other cloud applications. In this case, we see a reversal of the cloud model, in that the application may not run on the cloud at all, unless one considers that this makes one's computer part of the cloud.
As is generally the case, Microsoft followed suit, and its Silverlight offering is an attempt to compete with Flex, a tall order as Flex executes within the Adobe Flash players that by now have made it to a vast majority of browsers on computers all over the world. Flex has had many iterations and while initially quite cumbersome to program, can provide top grade human interface experience. By contrast, Siverlight is younger and does not come from a tradition of interface development. However, it is essentially a repackaging of the .NET virtual machine that Microsoft has developed to compete with Java. Although .NET has been designed for allowing multiple languages, its main target is C#, a derivative of C/C++ that is functionally equivalent to Java. From a Microsoft perspective, the advantage of .NET derived products is that they all provide an integrated environment, from the desktop with Silverlight to the web server (Microsoft's Sharepoint environment) to now the cloud with Azure. If we add to that traditional applications on the user's computer that are the forte of Microsoft, we see that any company aligned with Microsoft has an environment for cloud computing. While individual components of Microsoft's offering are often inferior to similar components that are typically precursors of Microsoft's products, the integration that Microsoft presents for these components may be beneficial to companies that are ready to forego individual weaknesses in exchange of communal benefits. Via a well-conceived SOA architecture, it is moreover possible to elegantly match Microsoft products with other products. However, the complexity of Microsoft integrated environments is then compounded by that of heterogeneous environments, so this is probably the domain of large companies and institutions in its full-blown version.
Light Applications
These are essentially interfaces. A minimal part of the application, say the human interface, executes in the browser while the rest of the application is situated on the cloud. In this case, again, it is important to understand the contract in place, with about the same concerns than those we discussed above regarding traditional adapted applications. Before going to the next section, let's note that the interface provided by a light application doesn't need to be dedicated to humans, but rather be offered for machine interactions. In a way, such an interface acts as a browser driven by a computer program on the user's machine instead of being driven by a human. Technically, what really happens is the interface uses the same facilities that the browser uses to link to the cloud. Light applications is what looks much like those "cloud computing" offerings of the 1970's and 1980's that we talked about at the beginning of this paper. "Traditionally" light applications meant applications which use minimal browser facilities, such as HTML and perhaps light Javascript. However, more and more applications make use of either heavy Javascript libraries or Adobe's Flash player to play Flex interfaces (a new contender is aforementioned Microsofts's Silverlight, and yet a new one might be HTML 5), so per the discussion above, the line is blurring between light applications and rich ones. Another kind of light application is exemplified by Citrix, a product that installs on a user's computer to then provide the same interface to another computer on the network than the user would otherwise see while using her or his own. In truth, Citrix, which deployed its products in volume in the 1990's, can be considered a precursor of cloud computing. Providing remote desktop images a la Citrix can be particularly interesting for institutions that want to offer access to legacy applications on, say, remote mainframes.
Case Study 1: e-mail
Few companies would now think of managing e-mail servers, but many do. The case for e-mail on the cloud is very strong, either directly by using a service like Google or Yahoo mail or countless others, or by establishing dedicated servers on the cloud. In the former case, one has to rely on the standard contract that the e-mail provider offers, or some elaboration of it in the case of enterprise editions of the service. In the latter case, one can establish more control on, say, the location of the server and its terms of service. However, if a company wants strict control of its e-mail servers for reasons of regulations, security, or business or more, in-house mail services may still be at a premium. In terms of cost, standard cloud e-mail is less expensive than dedicated cloud servers, whereas dedicated cloud servers may turn out to be more or less expensive than in-house e-mail servers depending on the business needs and the quality of the support staff, and the contract demands (in some cases no company may accept a contract reflecting what a company does in-house, for example in certain business or governmental situations, such as intelligence).Case Study 2: Virtual Desktop
Virtual desktops allow to access one's personal computer from an other computer, mobile phone, or other devices. In terms of licensing costs, a virtual desktop is adding to the software licenses of the accessing device the software licenses on the machine on which the real desktop is installed, so it's not necessarily a positive financial contribution. However, providing a virtual desktop to employees can free up support costs as they can be centralized; instead of delivering and managing software on the user's device, the installations are made on the server side. That, however, comes with strings attached. If the security environment of the accessing device is not controlled, it can impinge on the security of the virtual desktop, while presumably a company supporting real end user devices also manages their security, and so is already in the remote support business. Another issue is that companies whose employees need to install various software then create a bottleneck because of restrictions on installing it on the server (administrative access to servers has to be limited to few personnel for security reasons). Therefore users will install it on their own devices instead of the server, and now they have both a virtual and a real desktop commingling, which seems to defeat the original purpose of lessening support, security, and other issues of company management. It is worth noting that whether virtual desktops are provided via internal or external clouds doesn't make a difference on the downsides of foregoing control of the user devices management.Case Study 3: Cloud Servers
This is today the most general case of cloud services. Cloud services provide computation on demand, storage on demand, or both. We will talk later on higher level of services but let's consider in this case study the raw power offered by today's (early 2009) offerings such as Amazon's, Microsoft's, and others. Those products offer unique capabilities of demand elasticity, outsourced support, constant upgrading, and other benefits of scale. This is a compelling proposition for any company, particularly small ones, that gets access to resources previously unavailable at any cost that it could bear. If these companies can accept the contract of the provider, they stand to benefit and face new possibilities of business creation and expansion. Now, if the contract is unacceptable, that's an argument for in-company cloud computing services or otherwise classical server management. Or, if the contract is acceptable, it might be nevertheless be true, particularly for big companies or smaller ones with special requirements, that they can better manage their servers in-house. It should not be taken for granted that external computing services are necessarily the best proposition, and proper evaluation is of the essence here.
What's next?
Next we need to talk of human vs. machine interfaces, distributed applications, semantic web and ontologies, and new models that the cloud enables.
I enjoy receiving comments, so if you're so inclined, please don't hesitate to contact me, ducastel@slb.com; in particular, I love fixing my own mistakes. All the opinions herein are mine only, not Schlumberger's, and I assume no liability with respect to the use of any information, product, process mentioned in this paper, or for damages resulting from that use.
I enjoy receiving comments, so if you're so inclined, please don't hesitate to contact me, ducastel@slb.com; in particular, I love fixing my own mistakes. All the opinions herein are mine only, not Schlumberger's, and I assume no liability with respect to the use of any information, product, process mentioned in this paper, or for damages resulting from that use.
Bertrand du Castel is Schlumberger Fellow. Head of Research for the smart card division of Schlumberger, and then Axalto (now Gemalto) from 1996 to 2006, he received the 2005 Visionary Award of Card Technology Magazine for the Java card, the most sold computer in the world (more than 5 billion units by 2009, and counting). Bertrand is author with Tim Jurgensen of Computer Theology: Intelligent Design of the World Wide Web (Midori Press, 2008, ISBN: 978-09801821-1-8). Bertrand has an engineer diploma from Ecole Polytechnique and a PhD in theoretical computer science from the University of Paris.
© Bertrand du Castel, 2009. All Rights Reserved.
© Bertrand du Castel, 2009. All Rights Reserved.
Comments
Write New Comment ▼
Write New Comment
Sorry! This knol's owner(s) have blocked you from editing, making suggestions, or commenting here.