68 |
J. Jiang and G. Yang |
besides routine maintenance work, system administrators must do much extra work to coordinate local administration policies with global ones. For example, they must make sure that resources are shared in a way fully compliant with local regulations. In addition, they must separate environments of local users from global ones to guarantee reliability and security. None of this work is trivial. Moreover, since there are quite some independent or interrelated components and services involved in a grid, installing and configuring the grid software itself implies a lot of work and presents some challenges even to experienced system administrators.
On the contrary, resources in cloud computing are usually possessed or operated by a single organization and as a result, there is no need to coordinate different administration policies. In addition, since each VM in cloud computing provides an isolated and independent running environment that is fully controllable by the user who creates it, there is also no need for system administrators to install and configure users’ programs and to worry that they may interfere with each other and cause system disasters. Therefore, the burden of system management is greatly eased.
4.2.3 Comparison from the Viewpoint of Users
Different design philosophies lead to different systems, which in turn place different constraints on their users. This section compares grid and cloud computing from the viewpoint of users. Two kinds of users distinguished here are end-users who consume resources and services, and application developers who develop new applications or services using the resources and services supplied by a grid or a cloud.
Both grid and cloud computing provide two ways for end-users to consume resources supplied. The first involves using pre-installed software services through their own interfaces. Since these services are designed to support the needs of common users, in both cases end-users with special requirements or habits have to adapt themselves to the preset operation styles and instructions. Given the fact that grids are usually operated by computer scientists who know little about the domain needs, the problem is especially severe. The second involves running a task directly in a grid or a cloud. This shows quite some differences in operations and constraints as stated below.
To run a task in a grid, end-users need to specify the type and quantity of resources desired, information used for authentication, the program to be run and its arguments, sources of the input, and the output and its destination. This is an annoying procedure that often makes users stop. For example, globusrun-ws, the command supplied by GT4 for job submission and management, has 30 options for submitting a job and 15 options for monitoring a job. Though some tools have been provided as a help, much work is still needed, for example, to compose a job description file. Even if end-users have done all the work perfectly, there are still other risks that prevent their jobs getting done. One thing often ignored is that, because each grid middleware itself is a software system and has its special
4 Examining Cloud Computing from the Perspective of Grid and Computer-Supported |
69 |
requirements on the running environment, the existing grids are very tightly bound to a specific operating system (OS), software libraries, or applications. For example, gLite presently can only run on Scientific Linux 4 and 5, and Debian 4. As a result, if the program corresponding to a job is not executable on the platform on top of which a grid middleware is running, or if one or more libraries needed by the program are unavailable, the job just could not get done even if there are enough resources available. Another depressing thing is that, because different grid systems in the real world deploy quite different ways for users to express their needs, the job description file prepared for one grid usually cannot be used in another one.
In contrast, running a task in clouds is much easier and faces fewer constraints. The only thing needed is to reserve the desired resources and configure them for the task to be run. Resource reservation can be done by several mouse clicks and resource configuration makes no difference when compared with the activity using local machines. Owing to the VM technology, users in cloud computing can always set up an environment capable of running their programs and thus the constraints laid by grids on the running programs as mentioned above no longer exist.
Grid and cloud computing also impose different requirements on application developers. Generally speaking, developing applications on a grid is a complex task. First, this implies that developers should know many details about the grid environment, for example, the way to stage data to and from the execution site, the way to find a specific service to be invoked, to name but a few. In addition, they must spend much time learning the related APIs (Application Programming Interfaces) – even the Simple API for Grid Applications (SAGA)1 has a document of more than 300 pages. Second, since the grid is a highly dynamic environment, developers must pay more attention to such issues as exception handling, fault tolerance, scalability, performance, and so forth. Third, there are no mature tools for debugging and measuring the behavior of grid applications. Developers must struggle in their own ways (e.g., setting up an experimental grid of their own to monitor the behaviors of the application) to ensure the correctness of the application developed. It is easy to see from the statements above that programming on a grid raises a heavy burden on application developers.
As a comparison, programming in clouds is much easier. For IaaS, developers can always customize their working environments with their familiar tools and configurations, so there is almost no difference to programming on local machines. For PaaS, nearly every service provider supplies a platform SDK (Software Development Kit) and/or some debugging tool. For example, Google App Engine provides a fully featured local development environment with which developers can write, for example, standard Java applications. The Google plug-in for Eclipse provides an IDE (Integrated Development Environment) with application wizard and debug configuration for Google App Engine projects, making the development
1 SAGA is an open standard defined and maintained by the Open Grid Forum (OGF). Its aim is to provide an interface for high-level grid application programming and enable application developers to write programs without knowing the detail of specific infrastructures.