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