By George Lawton
Cloud computing offers an extremely appealing future for enterprise IT: the ability to leverage ready services with lower initial investment and a pay-as-you-need pricing model. But it will be filled with surprises, and some of these will reflect surprises encountered in the early going of SOA. The difficulties of cloud computing will parallel many of the frustrations early SOA adopters experienced. The more loosely coupled and distributed the cloud based system becomes, the more moving parts you don’t have control over. “As a consequence, the development cycle in the cloud ends up costing more money than expected,” said John Michelsen co-founder and Chief Architect of iTKO.
Is there perhaps a hidden Cost of cloud development? 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. The applications need to integrate with functionality built by outsiders. These ‘outlying’ apps can change the service without notice, As well, hidden costs and constraints are associated with cloud testing.
One of the first challenges is that cloud functionality is created outside the organization, yet it still needs to be tested. Michelsen said that just because a set of functionality worked for another similar application does not mean it will work for yours. It is important to test the functionality of applications you did not build.
The adage after Sun’s Java promise of “write once, run everywhere,” was that you had to “write once and test everywhere.” Michelsen said the challenge is that even though an application only gets written once, its performance can vary widely depending on its particular deployment circumstances.
The problem is that the developers don’t write the requirements doc for the services they are using. They need to go through some kind of analysis by preferably working with the cloud service vendor, or build their own compliance step to check their expectations against reality.
The second issue is the need to continually validate an application against a set of service functionality. After the application is deployed, the service provider can make changes that could adversely affect the application without notice. The stuff that works today could break tomorrow. Michelsen said, “It’s not like you get to participate in the user acceptance phase of the new version of Google services.”
In traditional application development, the app is tested every time a change is made. Now the software does not have a system of validation in place. Without a system of continuous validation the service becomes brittle.
For example, one real estate firm that worked with iTKO incorporated a mapping component into its web site. Initial testing indicated that the mapping service worked flawlessly. But several months after having launched the site, they discovered that the map component was displaying the wrong address. They only found this out after one of the agents got lost trying to find a property. If the service had simply stopped working, they might have noticed much more quickly.
After an application has been tested and deployed, paying per unit of service (storage, CPU time, and bandwidth) allows a new app to get deployed with minimal cost. But these fixed costs can take a hidden toll when a company has to do any sort of testing, and particularly load and performance testing of a new app.
The problem is that the IT department is used to paying up front for hardware, rather than being presented with a bill after services are rendered.
Another constraint is that it is significantly more difficult to manage test data across multiple services. In order to do regression testing, there is a challenge in getting data to be consistent across different systems. You might need to create a set of dummy customer accounts in EBay, Amazon, and Salesforce.com, and then delete these at the end of the test. This is especially important for testing complex functionality like using business logic to present new offers.
Michelsen explained, “In the pre-cloud world, one of the challenges a testing team faces is that every time they need to test a piece of functionality, they need the data scenario to be present. For example, if you need to trigger a special offer to a card user with a low balance, that data has to exist in the system. It gets hard to create these scenarios when these systems are off-premise. I spend two-days resetting the environment for a two-hour test cycle.”
SOA guidelines, if heeded, no doubt pave a better way to clouds. Methodologies and tools that were developed for SOA testing by iTKO and may help establish stronger service level requirements, continuously validating functionality and performance, and virtualizing away the constraints of fees and limited access to critical services in the development lifecycle.
Related SOA test information
SOA complicated by ESB proliferation -SearchSOA.com