This is the third post in our series based on the new whitepaper "The Next Frontier for Virtualization: Over-Utilized Systems" by iTKO (Ahrens, English). In this installment, we will break off one of the big 3 challenges of Over-Utilization: the "Common Bottleneck" that constrains multiple teams attempting to develop, test and integrate enterprise software. Conventional virtualization can break under the strain of attempting to eliminate these bottlenecks, as they are often too large or too complex to be replicated on a given VM.
[Nifty picture I took in Tierra del Fuego, Argentina - constant 50mph west wind]
Well-respected enterprise
application design patterns are actually causing software development lifecycle
bottlenecks where numerous teams rely on a key system or technology. These systems become new constraints to
development and testing, and push the original goal of time and cost savings
further out of reach. Here's the key points where we find Common Bottlenecks:
Design of Core Services – In some Enterprise IT organizations, a
few key services are so fundamental that they are used in a majority of
projects. From the standpoint of re-use
this is exactly what we were looking for, but while designing, testing, and
running our applications, these core services create dependencies which slow
teams down, because unlimited access for software teams is often considered too
risky.
Examples of core services
include:
o
Customer/Account – An example of one of the most commonly
created core services, so there is a single place to get customer records.
o
Billing – Customers don’t want to receive multiple
bills from the same vendor, so this is also a common core service to create.
o
ERP
System – Especially for
internal purposes (HR, Financials, etc.) companies adopt a single platform and
require everyone to integrate.
Customer Example:
A large North American Telco had issues in
replicating their core SAP system across a myriad of environments. Only 3 of 7 non-production environments have
an SAP instance they can use. Also the training system does not have a copy of
SAP, so they cannot train their Customer Service Reps on applications that
integrate with SAP until they are rolled into production. The result is that
bugs are not found until it is too late to repair them and still deliver
projects on time.
Data Warehouse – Numerous services depend upon the same
set of data, especially for account information. In order to make data
available for development purposes, this data usually comes from a production
“refresh” as needed, and is put into pre-production.
- Data
setup & teardown –
Managing relevant, stable and secure data in the environment can become a huge
drain on team productivity, sometimes consuming 60% or more of testing time.
- Data
volatility - When data
is treated as community resource for multiple development and test teams, other
teams can pollute the test data (for instance deleting a key user required for
your regression test suite).
- Secure
data - In addition,
live data must be suitably scrubbed or “desensitized” to protect unauthorized tester
access to account information, which is a time-consuming process.
Cloud Services – Saving money by using external service
vendors on a pay-per-use basis is great, but not when they get in the way of
being able to do testing and development. This means we have another team we
need to coordinate with from a data standpoint (test accounts, etc.) and
potentially we are charged a usage fee when calling on these services.Incremental fees are fine if they are a part of a revenue-generating customer
activity in the live application, but they are a problem when they become a
development cost to the business. For instance, how can we avoid skyrocketing
fees for load tests that include a cloud service, or analyze negative
ramifications if the cloud service doesn’t meet their SLA?
Customer Example: Insurance in the Cloud
A regional insurance company needed to be
cautious about how they run their performance tests for adding new auto
insurance customers. Among other things, the new client application performs a
credit check and runs an automobile history report. During one of their routine load tests
against the new app, they sent actual requests for automobile history reports
to a third party, resulted in a $15,000 access charge. After this unexpected
charge they simply chose not to test any third-party service calls until they
reach production.
Next installment: Limited Capacity and Other Inefficiencies