Saturday, 27 April 2013

Part3 - Cloud Computing Cost-Benefit Analysis Assessing Green IT Benefits

DESCRIPTION
The cost-benefit analysis (CBA) is done for the ICT team of the Engineering Center of (****NAME HIDDEN****)Corp. The project under consideration consists in evaluating the business benefits of using the Amazon Web Services (AWS) public cloud4 for the software development, test and quality assurance (QA) customary tasks of GEC. As observed by a number of field practitioners, software development and test/QA ICT service delivery functions constitute an interesting use case for cloud computing, because it allows software R&D organizations to develop and test applications without having to build and maintain a large datacenter infrastructure.
According to (Syntec 2010, p.7), software development, test and quality assurance (QA) is one of those application types that can best leverage the benefits of the cloud and is easiest to deliver, as shown in the following illustration.

CIO.com online magazine in (Golden 2009b) and in (Golden 2009a) argues that development and test in the cloud makes sense for a number of reasons that are outlined below.
Companies devote the highest percentage of their ICT budget to keeping vital business applications up and running. As a result, development and test procurement of computing resources is often underfunded, leading to poor R&D efficiency and effectiveness.
Development and test (including QA use of resources) is spiky in nature, leading IBM Research in (Rosenberg 2010) to observe that the average enterprise ICT department may devote up to 50 percent of its datacenter infrastructure to development and test, and that up to 90 percent of the available test infrastructure may remain idle at certain points in time. By its very nature, development and test is spiky because a developer will write code, test it out, and will move to other tasks such as design reviews, whiteboard discussions, and so on. Similarly, QA teams make a non-linear use of computing resources for reliability, performance and scalability testing that surges when an alpha release is made available. At times like these, it seems that there are never enough servers to go around.
Development and test teams are often hindered in their attempts to access a productionlike quality environment because it is too costly to replicate and maintain a productionlike infrastructure setup and topology. This issue is particularly acute when testing out how well an application responds to load and stress tests. This means that assessing how well an application behaves in production (i.e., performance, reliability, request latency and throughput) is difficult or impossible to evaluate in constrained environments. Also, many of the most important bugs only surface under heavy load conditions, meaning that these bugs aren't found during development and testing, and that they will surface when deployed in production where it is most costly to fix them.
The datacenter's operations staffs don’t want development and testing to affect production systems. Putting development and testing into the production infrastructure, even if quarantined via VLANs, holds the potential of affecting production applications throughput, an anathema to operations groups. Consequently, development and test groups are often hindered in their attempts to access a production-like environment.

No comments:

Post a Comment

Please Share Your Views