Cloud computing offers a bright future for enterprise IT in the form of a scalable infrastructure and pay-as-you-need pricing model. As cloud adoption emerges both in hype and value, all technologists are interested to know how the story will unfold. One way to examine the future of cloud computing is to look at the recent past of another formerly over-hyped technology enabling agility and cost-savings to organizations - service-oriented architecture (SOA).
Though they are two very different things, the difficulties of early cloud computing will parallel many of the frustrations early SOA adopters experienced. The more businesses depend upon a variety of cloud-based software as services, the more interdependency and risk they expose themselves to. Companies attempting to leverage new software models such as SaaS, third-party services, data-oriented services and cloud computing need to heed the pitfalls encountered by early SOA attempts, to get to the practical value.
The cloud will have its growing pains. However, also like SOA, the cloud can succeed if you pay attention to the right stuff - the governance issues, placing business issues before tech issues, hidden development costs and long-term planning. The first lesson applied to the cloud's future is to avoid the temptations of short-term ROI and think about the constraints that inhibit long-term value.
Dependencies on the Rise
In SOA engagements, many encouraged the importance of good architecture and governance, but often it was just too easy for companies to hook up a couple web services to a legacy system for a quick ROI. Several years later, we see a parallel as companies are attempting to get started with the cloud-based provisioning models. These organizations could face future unforeseen consequences, as dependencies will begin to infiltrate cloud architectures as they expand - similar to how they appeared with SOA.
Dependency didn't rear its ugly head in SOA until the services started to be used by multiple customers, each with their own needs, and then those services were connected with the services of business partners and used in a variety of unintended ways.
Similarly, the true cost and complexity of using cloud-based solutions will become evident only at the point when companies rely on them for critical needs, in that there are "wires hanging out" or dependencies remaining unsolved in the environment.
Dealing with Dependent Data
Along with service dependencies, cloud deployments depend upon reliable sets of data available for development and testing purposes. This data usually comes from a production "refresh" as needed, and is put into pre-production.
Managing relevant, stable and secure data in both environments can become a huge drain on team productivity, sometimes consuming 60% or more of testing cycle time. While collaboration among test and development teams is great, other cloud users can unintentionally "pollute" data, such as deleting a key user required for your regression test suite. In addition, live data must be suitably scrubbed or desensitized to protect unauthorized tester access to account information, which is a time-consuming process.
Data consistency issues need to be resolved in the cloud, however specific data scenarios are easy to control and manage, as a solution developed for SOA environments applies to the cloud. Rather than having to negotiate set up and removal of test data sets from multiple sources and partner systems, the team can fire up a stable virtual set of data to validate scenarios without impacting the live systems or other teams' test data. By virtualizing the behavior of systems and data, stable test data can be made available across a variety of systems - even the systems that are not under a given team's direct ownership and control, a crucial requirement for any distributed system.
This practice is called service virtualization (or SV) and is a complement to existing practices of hardware and application virtualization that are already in place in most data centers. SV is the process of capturing and modeling the response behaviors "between the boxes" or "between the clouds" to eliminate dependency and vulnerability to change. SV provides enough realistic data and response behavior intelligence to shield the test and development team from volatility in the cloud and its dependent services.
Governance Must Rule Again
As cloud computing becomes widely adopted, it becomes even more important to have a solid governance model to make the decision on which components should move from the traditional deployment model to a cloud-delivery model. In the process of getting to a service-centric IT governance model, organizations are going to have to deal with the governance model for deploying new services, much like they needed to do with SOA.
The validation aspect of governance is especially important when looking at maintaining quality while controlling costs in the cloud, as loosely coupled resources add more dependencies, increasing the need for effective governance policies in place to ensure the infrastructure is performing optimally.
As a parallel, the initial thinking around SOA governance was largely siloed and specialized around design-time WSDL validation, runtime performance, and security policy enforcement. As SOA governance matures to support robust and widely diverse SOA/cloud initiatives, this thinking must expand dramatically. One of the greatest values an SOA governance platform must provide is automated validation - the proof that the policies written in human or business terms are in fact implemented in the system, on a continuous basis. Good IT governance models can better sort through the risk/reward trade-offs on cloud computing, and validate the business outcomes we expected.
Hidden Costs Lurk
After an application has been tested and deployed in the cloud, there is relatively little cost associated with the provisioned environment, other than what is used in terms of capacity. This is the reason the cloud is appealing from a cost-savings perspective. Not to mention, IT departments are used to paying up-front, so pay-as-you-go is a very appealing pricing model. But like SOA, additional costs can unexpectedly appear when companies have to test these applications. While validation of the environment is critical, the cloud service provider's practice of charging fees on a per-transaction basis actually discourages proper testing.
One firm's operations team needed to run a performance test to verify required service-level agreements to verify that customer response times would be within bounds. One routine load test cost about $10K in access fees from the service provider - an unforeseen bill that wouldn't have appeared if the team was banging on their own servers.
While most firms are more than willing to accept some fees for customer transactions, as those can be justified by the revenue they create, the opposite holds true for non-revenue generating activities like the software testing and development lifecycle. Since they are seen as costs, these capacity limitations inhibit the team from testing and adjusting their service appropriately.
Lessons Learned
Similar to the experience with rampant vendor claims about SOA's value, cloud adoptions are case-by-case scenarios, and blanket statements about what type of cloud architecture is the best, won't work. Both technologies promise organizations more agility and cost-efficiency. As with any IT implementation, it's important to look at success stories, failures and a variety of validation processes to examine how to deploy the cloud within your organization's unique environment, rather than plugging in, integrating a key process and regretting it later on.