My Thinking Till Now For Cost Benefit Analysis (CBA)

The CBA of the migration project for the software development and test activities at GEC to the AWS cloud shows positive financial results. However, it was not possible to demonstrate that the assumed environmental benefits of cloud computing played a sensitive role there. By migrating parts of the computing resources of the datacenter to the AWS cloud, the financial analysis demonstrated that GEC could achieve significant cost savings in areas of hardware equipment costs, electricity consumption costs for the servers' power and cooling, as well as in user productivity gained from the better effectiveness of the hybrid cloud solution. The financial analysis shows that GEC could obtain a risk-adjusted return on investment (ROI) of 117%, with a payback period of 9 months, by migrating its software R&D's development and test activities to the AWS cloud. However, the initial environmental benefits assumption about cloud computing―resulting from a higher computing efficiency―could not be objectively quantified in the analysis. Failure do to so, can be explained through two main reasons:

Firstly, it is not argued that cloud computing can save billions of kW-hours in energy consumption because cloud providers can squeeze the performance and efficiency of their infrastructures at much higher levels than private datacenters, especially when compared to those of small firms of limited innovation and cash resources. But while the energy efficiency benefits of cloud computing are generally not contested, claiming that cloud computing is a green technology is a totally different story, as reported by a number of ICT practitioners and ONGs like Greenpeace. Despite the fact that some cloud providers are reaching extremely low PUEs, and are also looking to build massive datacenters in places so as to maximize energy efficiency and harness renewable or clean energy, the primary motivation is cost containment, which doesn't necessarily meet environmental and social responsibility objectives. The study showed that while energy efficiency reduces the energy consumption footprint, it is not green if cloud providers are simply looking at maximizing output from the cheapest and dirtiest source of energy available, such as Microsoft's Chicago cloud who supplies power to its datacenter from a coal-burning electricity grid.

Secondly, the current body of environmental legislations that are enacted by governments and regulatory organizations that apply to the ICT sectors are not to a large extent quantifiable in financial terms. This observation I think is coherent with the findings of this study and coherent with the common perception that the economics of green IT are stimulated primarily by the concern of cutting costs in areas of energy-related expenses as well as hardware and maintenance expenses. In other words, “do the right thing for the environment” is not sufficiently rewarded by today's legislations “Energy Policies and Implication”. For example, the EU Emission Trading Scheme (ETS) that regulates the emission of greenhouse gases for the energy sector and other heavy energy consuming industries is not enforceable (yet) to the ICT industry sectors. With regard to energy policies that are of importance to the ICT industry sectors, including the EU Energy Performance of Buildings Directive, the EC Code of Conduct on Data Centers Energy Efficiency, and the Grenelle of the Environment for France, have had, so far, minor to zero financial impacts for the datacenter sector. All this may change in the future, but at the time of this writing it is the current state of business.

Cloud Computing Deployment Models

A common misperception about cloud computing is that, eventually, there will be only a handful of cloud platforms, all of which public. This is highly unlikely given the complex ICT needs in large organizations, according to the consulting firm Accenture in its special report “What the Enterprise Needs to Know about cloud computing”

While some general-purpose public clouds will exist, two other types of cloud are likely to emerge. One type, community or speciality clouds will cater to the particular needs of a select group of organizations, an industry or even a country. The healthcare industry is a good example since the inherent nature of medical records underscores the need for clouds to be  non-public so as to ensure data security, while levering mutualized infrastructures to lower ICT costs. Likewise, some large multinationals may opt to build and operate their own private clouds or internal clouds while continuing to tap into external cloud sources. In this way, they can achieve both elasticity and control over service quality, security, data ownership and integrity, and other important regulatory issues. Furthermore, there are applications that simply don't run well in a pure multi-tenant environment. Databases, for example, perform better on dedicated hardware where they don't have to compete for server input/output (I/O) resources. Plus, some businesses prefer to run databases on dedicated hardware for PCI compliance16 reasons or because they do not want sensitive data to reside on a shared platform, even if the environment is highly secure.

Other applications, such as web servers, run well in the cloud because they can use the elasticity of the cloud to scale rapidly. For example, GoGrid Hybrid Hosting gives businesses the option and flexibility of building a secure, high-performance scalable server network for hosting web applications, using a combination of cloud and dedicated server hosting interconnected via a private network link.

Overall, the NIST as well as other practitioners and academics agree to identify four common cloud computing deployment models.

Public Cloud

In simple terms, public cloud services are characterized as being available to clients from a third-party service provider via the Internet. The term “public” does not always mean free, even though it can be free or fairly inexpensive to use. A public cloud does not mean that a user's data is publicly visible; public cloud vendors like Amazon typically provide an access control mechanism for their users. Public clouds provide an elastic, cost-effective means to deploy solutions.

Private Cloud

Private cloud computing—sometimes called Enterprise or Internal cloud computing—is a style of computing where scalable and elastic ICT-enabled capabilities are delivered as a service to internal customers using Internet technologies. This definition is very similar to the definition of public cloud. Hence, the distinction between private cloud and public cloud relates to who can access or use the services in question and who owns or coordinates the resources used to deliver the services (Daryl C. Plummer et al. 2009, p.5). In other words, a private cloud is a cloud that implements the cloud computing model in a private facility where only a single organization has access to the resources that are used to implement the cloud. Therefore, it is a cloud that an organization implements using its own physical resources such as machines, networks, storage, and overall data center infrastructure (Wolsky 2010). A private cloud intends to offer many of the benefits of a public cloud computing environment, such as being elastic and service-based, but differs from a public cloud in that in a private cloud-based service environment, data and processes are managed within the organization for an exclusive set of consumers without the restrictions of network bandwidth, security exposures and legal requirements that public cloud services may entail. In addition, private cloud services are supposed to offer providers and users greater control over the infrastructure, improve security and service resilience because its access is restricted to designated parties. Nonetheless, a private cloud is not necessarily managed and hosted by the organization that uses it as it can be managed by a third party and be physically located off premises, built atop of a public cloud infrastructure or built as a hybrid cloud. In principle, a private cloud assumes a dedicated hardware environment of pooled hardware resources with a virtualization layer running on top of it, allowing an enterprise to create and manage multiple virtual servers within a set of physical servers and charge the organization's business units per usage. According to Gartner in (Bittman 2009, p2), it is envisioned that private  clouds may prevail in the first phases of the cloud computing era whereby many large companies will offload their ICT operations from running their own data and enterprise applications to secure offsite clouds linked to the company's offices through virtual private   networks (VPN) over the Internet. There is some amount of controversy whether a private cloud should be considered as a genuine cloud-based computing environment. For instance, (Armbrust et al. 2009) argues that except for extremely large infrastructures of hundreds of thousands of machines, such as those operated by Google or Microsoft, private clouds exhibit only a subset of the potential benefits and characteristics of public clouds.

There are inherent limitations to consider with private clouds when it comes to elasticity and scaling because the number of virtual machines that can be provisioned is limited by the physical hardware infrastructure. An enterprise can of course add more machines to expand the infrastructure compute power, but this cannot be done as fast and seamlessly as with public clouds. Thus, (Armbrust et al. 2009, p.13) argues not to appoint private clouds as full-fledge cloud computing platforms as this would lead to exaggerated claims. However, they acknowledge that private clouds could get most of the cloud-based computing benefits when interconnected with public clouds through a hybrid cloud-based computing model. The Table below summarizes the key differences between public clouds and private clouds.

Community Cloud

A community cloud is controlled and used by a group of organizations that have shared interests, such as specific security requirements or a common mission. The members of the community share access to the data and applications in the cloud.

Hybrid Cloud

A hybrid cloud is a combination of a public and private cloud that interoperate. In this model, users typically outsource nonbusiness-critical information and processing to the public cloud, while keeping business-critical services and data in their control. The embodiment of hybrid clouds is sometimes found in what is called a Virtual Private Cloud (VPC) whereby a portion of a public cloud is isolated to be dedicated for use by a single entity or group of related entities such as multiple departments within a company. In its simplest form, access to VPC services will be limited to a single consumer and will deliver a service consumption experience that is virtually identical to the public cloud services. VPC services are an emerging phenomenon driven by consumers that are interested in the potential of cloud computing, but who do not want to concede too much control, or share their computing environment with other customers. When combined with a hybrid cloud computing model (for example, using internal resources and external cloud computing services) (Wood et al. n.d.), VPC services have the potential to bridge the gap between public and private cloud models. By providing additional control, management and security beyond that of public cloud services, the VPC approach reduces risks and makes it feasible to deploy a wider range of enterprise applications.

Cloud bursting is a technique used along with hybrid clouds to provide additional resources to private clouds on an as-needed basis. If the private cloud has the processing power to handle its workloads, the hybrid cloud will not be used. When workloads exceed the private cloud’s capacity, the hybrid cloud will automatically allocate additional resources to the private cloud.

All three main cloud providers examined for this study (GoGrid, Amazon and Rackspace) provide some form of hybrid cloud computing services.

Case Study - Cloud Computing Opportunities

Opportunities

The ICT team of GEC believes that cloud computing can help evaluate, plan, design and implement a dynamically scalable and virtualized software engineering environment. As such, cloud computing is perceived as an opportunity to build a more flexible and cost-effective development and test computing environment for the engineers working at GEC. It should allow the organization to accelerate the product life-cycle and reduce costs by centralizing and automating the deployment, configuration and tearing-down of this complex environment. Through this strategic decision, GEC expects to obtain the following benefits.

·        Reduce capital expenses while at the same timeoffering the elastic scalability to handle fluctuating business needs.

·  Reduce dependency by allowing engineers to allocate and manage computing resources themselves with minimal intervention from the ICT staff.

·  Reduce operating and labor costs of managing, deploying and supporting software test configurations while improving productivity by eliminating the time spent on the setting and tear-down of the lab environment.

·     Facilitate innovation and improve time-to-market by reducing development and testing setup times from weeks to minutes.

·   Improve quality by eliminating critical software issues prior to deployment through testing in environments that more closely match production environments.

·       Maximize efficiency from a centralized lab supporting multiple and/or remote teams.

Action Plan

The action plan for the migration of the development and test computing environment to the cloud is broken down as follows:

The analysis will be based on the Amazon Web Services (AWS) EC2 and EBS services, which cater for a world-class infrastructure-as-a-service cloud computing platform.

Sourcing of the development and test environment to the AWS cloud will rely on the Amazon Virtual Private Cloud (Amazon VPC) architecture. Amazon VPC enables enterprises to connect their existing infrastructure to a set of isolated AWS computing resources via a Virtual Private Network (VPN) connection, and to extend their existing management capabilities such as security services, firewalls and intrusion detection systems to include their AWS resources in a hybrid architecture that takes full advantage of the benefits of the AWS cloud in a secured and dedicated area as shown in illustration 2.

Illustration 2: Amazon Virtual Private Cloud Architecture (Graphic Courtesy of Amazon)

The ICT staff will create set Amazon Machine Image (AMI) templates—for the Solaris, Windows and Linux operating systems—containing the software necessary (middleware, libraries, data and associated configuration settings) for engineers to perform their customary tasks as if they were working locally.

One small AWS EC2 reserved instance will be permanently allocated per engineer. In addition, engineers will be able to allocate additional EC2 instances on demand through a modified version of the Virtual Instance Reservation Portal (VIRP) application. On average, engineers will be able to allocate two more small instances on demand when development and test tasks require running software on multiple nodes.

Development and test data will be hosted on Amazon Elastic Bloc Storage (EBS) volumes. Amazon EBS provides block-level storage volumes for use with Amazon EC2 instances. Amazon EBS volumes are off-instance storage that persist independently from the life of an instance. Amazon EBS provides highly available, highly reliable storage volumes that are particularly suited for applications that require a database, file system, or access to raw block-level storage. Amazon EBS also provides the ability to create point-in-time snapshots of volumes. These snapshots can be used as the starting point for new Amazon EBS volumes, and protect data for long-term durability. The same snapshot can be used to instantiate as many volumes as is needed. As such, engineers will be able to maintain multiple versions of the software components under development as well as multiple configurations and testing scenario setups without needing to hold a complete virtual machine for such purposes.

Developers will be allowed to create new EBS volumes of various sizes, ranging from as little as a few giga bytes to hundreds of giga bytes of storage, through the VIRP application and mount them onto their EC2 AMI instances dynamically. It is estimated that engineers will need on average no more than three EBS volumes ranging from 70 to 250 GB in size.

The number of managed servers—which for the most part are inefficient legacy machines whose use and purpose are not always clear to the IT team — and as such the virtual machines equivalent, will be drastically reduced. By transferring its computing assets to the cloud, GEC will also be able to “pull the plug”. on those unattended or quiescent systems and avoid the effect of server sprawling in the future.

Case Study - Cloud Computing Challenges

Challenges

The following is a summary of an interview with the ICT team who manages the datacenter of (****NAME HIDDEN****)corp. that counts for 135 employs among which 105 engineers are working in software R&D. The ICT staff is in charge of maintaining the operations of about 1,000 machines, scattered in 9 different labs of around 50m2 each, and a central computer room of 160m2. The datacenter is a horrendous collection of different computers with various hardware configurations ranging from recycled personal workstations, inefficient old servers (e.g. Ultra1 and Ultra2 boxes) stocked in racks, to more recent medium-to-high-end multi-core servers interconnected with large storage systems. The central computer room is primarily used to host the file and backup servers of the labs. It is interconnected with the 9 labs through fast 10 Gb ethernet links. The heterogeneity and aging of the machines populating the datacenter make it difficult to cost-effectively manage the datacenter because it is time consuming to maintain such a diverse ICT environment and requires a significant inventory of spare parts to replace faulty components.

Among the 1,000 or so machines, it is estimated that a small proportion cannot be easily externalized to the cloud because they are either used extensively—with, for example, release engineering that runs non-regression tests on a daily basis using large amounts of data that would be too costly and impractical to migrate to the cloud—or require control over the hardware specifications of the machines—like a SPARC versus an x86 processor architecture—to conduct performance benchmarks, product qualification, and other similar platform certification tasks. Conversely, it is estimated that the vast majority of the x86-based servers could be externalized to the cloud for general development and testing purposes on the condition that the solution can ensure both excellent access performance and security. Amazon's Virtual Private Cloud, as we will see below, and CohesiveFT were cited as companies who can tackle the issue of bridging the datacenter with public cloud services in a secure manner to ensure that data at rest and data in-flight are not compromised. CloudSwitch5 was also cited as a well regarded startup that pushes the concept of hybrid cloud computing further by offering a service that takes care of all the networking, isolation, management, security and storage concerns related to moving VMWare-based virtual machines to Amazon EC2.

The primary motivation for GEC to outsource parts of its development and test infrastructure to the cloud arises from the actual inefficiency in the use of the lab resources. Secondly, the organization is seeking to reduce its hardware procurement and maintenance costs as well as its electricity bills for cooling and running the systems, hence inducing a greener IT positioning by reducing CO2 emissions from the sprawling of servers and storage farms. Thirdly, they are seeking to become more agile and productive by providing developers and testers with a unified and more effective computing environment.

Currently, GEC is facing several challenges that hamper its ability to reach these objectives:

There are many contention issues among lab users between developers and testers to get access to available machines of the right configuration type. QA teams are generally scrambling to get access to machines when an alpha release is delivered. They rely heavily on the engineering teams to free up boxes from development.

Developers tend to be very inefficient in their use of lab resources because they step in and out randomly with various engineering tasks. Meanwhile, they retain control of the machines they own for weeks and even months because they are reluctant to release them as doing so would mean that they would have to reinstall and reconfigure the different pieces of the working environment every time they get a machine back from the pool. It is common to see developers keep a dozen or so machines up their sleeve while they are in actual fact only using one or two at a time. Similarly, QA has to reinstall the entire software stack every time they get an available machine. This is because part of a real testing cycle is to ensure that the application mirrors a production environment, which means the machine needs to have a clean install with appropriate versions of all the software components. It can take days to manually set-up a proper QA environment, from the time the alpha version is released to QA and the time that QA actually gets an environment set-up properly to begin the test.

The demand for resources is overall very spiky over the course of a year. The ICT staff does not keep an exact track of this, but their “gut feeling” is that , in general, machines are most of the time in an idle state, which leads to a utilization rate below 10%. For example, QA activities are linked to the product's life-cycles, which concentrate a stiff peak of load twice a year for a couple of months at most, thus involving the allocation of a large amount of resources, yet ephemeral, to be able to release the product on time. The worst thing that could happen is to delay the release of a product as a result of a lack of available resources.

To prevent such impediments, the policy, so far, has been to largely over-provision the capacity of the datacenter. But in times of cost cutting, budgetary constraints and energy efficiency pressures, this approach is no longer viable. So far, the ICT staff has been able to contain this precarious situation, while reducing the number of physical servers, through an aggressive server consolidation process started a couple of years ago, by using the virtualization technology of VMWare. But, for historical and customary reasons, not all servers are yet virtualized. In addition, ICT staff is seeing today a demand surge for larger server configurations—typically fast eight-core CPU machines with 16 GB of memory and more—that the current virtualization layout cannot easily fulfill because most of the underlying physical servers in the datacenter are small-to-medium size machines.

In addition to the points outlined above, the interview uncovered some other relevant goals that the project should address:

·        Allow administrators to centrally manage the labs' infrastructure and configuration, including policies, which determine what resources can be allocated and consumed by whom (i.e. groups of users or individuals).

·        Allow testers to safely reserve virtual machines without conflict and provision automated test configuration scenarios on a scheduled or on-demand basis with no manual intervention.

·        Allow testers to reliably request and securely access test configurations 24/7 through a standard browser that enables R&D personnel—in any location worldwide—to deploy test configurations via a self-service portal without requiring access to the physical hosts.