As enterprises are adopting private clouds, the question of how workflow and responsibilities need to change is one we find ourselves discussing with increasing frequency. In particular, the dynamic way in which clouds respond to provisioning requests from their users, and the "self-service" features that all clouds support, both change how users and administrators interact with the data center. Discussing the nature of these various roles (see Cloud IT Roles for more details) has become as much a part of the Eucalyptus deployment process as is the software itself. In this posting I'll try to discuss the nature of these conversations in broad terms.
Usually the way in which private clouds interact with existing network administrative policies is the most contentious management issue that must be resolved. Often, security, fault isolation, and QoS are implemented in the network fabric making network administrators the bulwark of the data center. Private clouds automate many of the tasks that network administrators perform manually through a set of service components (e.g. a set of web services). However, in most data centers, installed services use the network but do not operate on it or manipulate it dynamically. Instead, services live at the "edge" of the network the core of which is protected.
Thus network administrative duties change with the introduction of cloud services in that the control of the network "fabric" interlinking VMs resides in automatic services running at the network edge. It is only the virtual network fabric between VMs that the cloud controls, but often the traffic over this network must share physical infrastructure with the "real" network that connects the physical machines. Administratively, separating the management of the virtual network from the physical one requires some configuration and a policy for how the configuration will be managed. It falls to the network administration staff to define and implement these new policies.
Cloud administrators configure and maintain the cloud platform itself. User access, system software lifecycle, data center policy compliance are all necessary for a cloud in the same way that they are necessary for individual physical machines. However, cloud administration also differs from more traditional system administration in a few important ways. First, the cloud administrator must maintain two separate system software domains: the system software on the physical machines and the system software that is the platform itself. For example, it is often tempting to think of the cloud platform as being the "operating system for the cloud." This simplification, however, can lead to confusion particularly with respect to cloud installation and upgrade. An operating system "boots" when a machine is started. A cloud is deployed and its components securely registered regardless of the running status of any given machine. Thus a cloud administrator must differentiate between operating system administration on the physical machines and administration of the cloud platform itself which is a distributed and, in some sense, more abstract and unifying "machine."
Cloud Application Architect
Because application code is encapsulated in virtual machines in a cloud, the integration between these virtual machines and the application or application platform must also be managed. Specifically, each virtual machine contains its own system software and data. All dependencies between the application and the system software environment in which it runs must be captured in the virtual machine and maintained over the application's lifecycle.
The typical methodology for developing this linkage between the application code and the virtual machine centers on the preparation of an "image" within which the application code will be embedded. A Cloud Application Architect must prepare and maintain an image for the application within the cloud. To do so, the architect must customize a "base" image (the base is typically installed by the Cloud Administrator in a cloud-public catalog). If all customizations can be automated (e.g. scripted) execution at VM start-up time, the scripts for transforming the base image can be stored as "templates" that are then "filled in" with runtime-available data during the VM init process. When customizations cannot be automated or when they require a lengthy runtime process, Application Architects may elect to "snapshot" the customized image thereby creating a new "base" for the application. Thus it is the Application Architect who is responsible for the process of developing and maintaining templates and image snapshots.
A Scalable Administration Model
While it may seem, at first blush, like there are a number of new and potentially complex administration tasks with clouds, it is important to understand that they are all "up-front" tasks that can subsequently be automated by the cloud platform itself. For example, once an image for an application is prepared and installed in the cloud, it need not change until the application's dependencies change regardless of how many times the application is run. Thus the administration model is scalable, relying on the automatic deployment and provisioning capabilities of the cloud platform for scale. Ultimately, it is this scalability that is at the heart of the new administrative approach for private clouds which is also where the operational cost savings are derived.