The ITKO Blog: Service Virtualization and Application Lifecycle Optimization - CA Technologies

More About Dev & Test Cloud Environments from the Whiteboard

We're continuing our series of iTKO Chalk Talks about moving Development and Testing environments to the Cloud. In our previous post, John discussed the Challenges of Dev & Test cloud environments. Since there are extremely significant cost savings -- on the order of 95%+ cheaper -- to be gained by provisioning this Pre-Production capacity in Public and Private Clouds (or, "Hybrid Cloud" Environments) it behooves any enterprise IT shop that uses and integrates software to pool resources and use Cloud Computing approaches in this way.

In this Dev & Test Cloud Chalk Talk installment, we'll talk about why and how companies are moving Pre-production aspects of the software lifecycle to cloud environments:

What about the hidden costs of Dev & Test Clouds? Cloud vendors and providers can point out the significant cost advantages of using Private and Public clouds for a given computing resource above, but they leave out continuing costs like MIPS charges, transaction fees, data maintenance, and many other cost aspects that cannot be reduced by moving Pre-production to Cloud environments. We will cover this aspect next.

Cloudy Chalk Talk 2: Dev & Test Clouds in Pre-Production

To continue our series on Cloud Application Chalk Talks, our "chief geek" John will cover Development and Test Clouds. After the move toward commoditizing some hardware and capacity in Public clouds, we find that the next logical step is using Clouds to level off Pre-Production costs throughout the software lifecycle.

Capacity in Production is fairly easy to predict, but it is hard to predict in Pre-production. You can plan to make capacity for spikes and volume and provision your infrastructure if you are an eCommerce vendor getting ready for the next Christmas rush. But what if you could eliminate 80% of the unpredictability of the Pre-Production environment that hundreds of skilled developers and testers use, and therefore not need to buy all that capacity up front? Private/Public Clouds are a great way for our partners to pool together computing resources into Private Clouds, use Public Clouds for overages, and try to regulate their infrastructure costs (compare oh, $.06-.12 a CPU hour of private/public capacity vs. $2.00 for each team using dedicated systems - and you see the economics).

So what happens next? We'll cover how companies are dealing with those "spikes" in capacity and cost, as well as the hidden costs that you don't usually hear about in the standard arguments for employing Cloud Computing and Virtualization in pre-production.

Chalk Talks on Cloud Applications - Part 1: What is a Cloud App?

Over the last 3 years, I have been asked quite frequently how our vision of service virtualization and validation applies to Cloud Computing. Indeed, we have waited a while to inject our own views in this arena (though we posted a solid whitepaper on Cloud and several recent Cloud commentaries on this blog). So far, we have often found that the Cloud discussion seems to be all about deployment, and not enough about the software lifecycle. Well, it is time to address that side of the equation.

So here's the first installment of a new Chalk Talk series I've recorded on Cloud Applications: "What is a Cloud App?"

Think about the difference between Cloud Applications - the software you run on a highly distributed, elastic architecture, versus the deployment model of Cloud Computing itself. They go hand-in-hand. Everything we've done in the software lifecycle up to this point - from legacy enablement and reuse, to service-orientation, to continuous integration, validation, and collaboration across multiple teams, has helped make Cloud Applications possible today.

We hope you find this series useful and invite your comments and suggestions for topics you would like to hear.

What is a Cloud App?

We at iTKO are not claiming to coin the term “Cloud App” -- in fact a number of vendors out there have already been referring to cloud apps – for instance, vApps from VMware and others. But I wanted to frame the discussion around what cloud applications really are, and the challenges and benefits that will shape what cloud apps could be.

I do like that we can participate in this dialogue. We’ve been a part of many of the intermediate steps of making customers ready to have a cloud application over the last decade. The more distributed, service-based and loosely coupled applications have become, and the more they are connected through commoditized middleware and messaging, the more viable they therefore become as cloud applications.

Cloud apps must have these attributes, because without them, you would have a hard time delivering the value of Cloud to the business -- being able to interconnect various components from different vendors in different ways, and being able to do so in an on-demand basis.

For instance if I had 4 or 5 different service vendors underneath my application, I could elect to use Vendor A for a time, and then remotely switch to Vendor B for a similar service, based on price, availability, contractual reasons, what have you. This is an important concept, and not a new one. When we didn’t have Cloud applications and the ability to make that switch easily and remotely, the cost of switching was too high and thus, rarely happened.

The IT community tried to address this with SOA, to offer a “plug and play” capability for services, but the infrastructure didn’t allow for it. We did get service-oriented benefits around more modular programming, better reuse, and most importantly the distribution of business logic between teams, and a better way to get teams to iterate on development of components more quickly, without having to create a new application.

However, the ability to put the entire infrastructure in a service mindset really couldn’t have happened without a cloud infrastructure. So, Cloud Apps are just the next step in a journey you are already on. If you are building apps that are web-based, using web services, N-tier, with connected legacy systems, and service-based access to third-party systems or SaaS providers, you are already on your way to having a Cloud App.

The only difference is, you’ll now think of deployment as a service-based activity as well, and you will have a greater ability to switch from one provider to another, when it comes to acquiring and accessing those services.

I hope that explains what we mean by Cloud Applications, and you can expect to see more discussions on this topic here. Read more new content from iTKO on Cloud Apps:

• iTKO.com: iTKO LISA Solutions for Cloud Application Validation
• iTKO.com: iTKO LISA Solutions for Development & Test Clouds
• Blog: Chalk Talks on Cloud Applications - Part 1: What is a Cloud App?
• Blog: Cloudy Chalk Talk 2: Dev & Test Clouds in Pre-Production
• Blog: More About Dev & Test Cloud Environments from the Whiteboard
• Blog: Hidden Costs Off-the-Cloud: iTKO ChalkTalk

Employing Virtual Environments for Manual Testers: It Still Doesn't Suck

Here's a brand new article in Virtualization Journal: Employing Virtual Environments for Manual Testers from one of our expert architects, Andy Nguyen.

Here at iTKO, we evangelize virtualizing and automating the entire software development lifecycle. While manual testing is a topic we don't cover as often - Virtualization of Manual Testing labs is a really cool thing that can add a lot of value in any large IT organization. For every development and test automation expert in an enterprise, there can be a whole team of on-site, partner, outsourced and seasonal testers sitting idle - waiting for access to a valid, configured test environment to run their scenarios against.

This article contained a cartoon - you might remember our distant history when we advertised the claim that "Your Testing Sucks" - and nobody ever disagreed with us. So here's the comic by Sal Monella:

Service Virtualization is the best way to solve the above constraint for Larry Lamprey, not buying more hardware or conducting laborious, expensive custom setups of a multi-tier environment behind the UI for testers.

Manual testing is never going to disappear, as someone will always be expected to test application UIs for user experience, etc. However, to eliminate downtime from testing, and conflicts over limited available test environments, ALL testers can use a Virtual Service Environment (VSE) to stay productive. Virtualization of those setups and data scenarios also delivers a huge productivity boost.

Why Stubs Don’t Work: Part 2 – Performance & Virtual Services

[This is the 2nd Part of John's article on "Why Stubs Don't Work." For "Part 1: Producers & Consumers" read here.]

The last (but certainly not least important) audience that must weigh Stubs versus Virtual Services, is the Performance profiling team – the folks charged with measuring and tuning an application to meet customer expectations or SLAs in production.

Of course, a developer creating a stub “responder” would write that simple object to return a given response as quickly as possible. Yet, many of the most complex scenarios that would want to consume that stub are in the performance lab – so the team can do capacity planning, and get a feel for how the targeted application will perform or behave, before it’s all fully assembled and delivered to production.

You need a pretty sophisticated instrument to vary the responsiveness and handle all the variety of performance profiles that are needed to support tuning.

For example, I may have “What-if” scenarios -- where I want to performance test my system, with all the back-end services stubbed out. Now, I want to see what happens if those back-end systems respond 20% faster, or, 20% slower than they are supposed to be. With a stub, I can only get an immediate response about as fast as the network can deliver it, which is unfortunately not how the live downstream system is going to perform. 

And I certainly don’t have the ability to vary that performance in an “adjust the slider” kind of way – not without, again, building a pretty sophisticated framework for that simulation. And this creates – you guessed it – a whole group of people charged with coding stubs to respond at certain times or with certain payloads. There must be a better way.

Thus the need for LISA Virtualize, and Virtual Services.

Virtual Services are the technology we built on top of the LISA Virtualize framework to bring dynamic behavior to this functionality. LISA Virtualize allows Virtual Services to be automatically modeled or captured from live traffic, flat files or definitions, and then quickly adjusted for data or performance characteristics without coding. Here's a basic picture of how that happens:

Virtual Services have proven, time and time again, that development teams can get out of the stubbing business, and that consumers of these services can take control of their own destiny, and produce their own Virtual Services instead of waiting for a stub.

That’s important, because the producer or Developer of a given service should not be responsible for infinitely providing stubs to Consumers -- every Consumer is going to have their own requirements, and need to validate different scenarios for how they use the service. If there is only one stub available, then consumers will be missing the responsiveness they need.

From the other side of the equation, if Consumers are responsible for building their own Virtual Service models from downstream services, they will understand the kinds of performance levels, data scenarios and business processes they need to validate. And, they would know better how that service would need to integrate for their required scenarios with other downstream systems that are available.

Conclusion: The Tipping Point for Virtual Services is here…

Just like the “roll your own” database I used to make years ago, the requirements for this functionality have reached a tipping point. Once the requirements for stubbing or mocking reach the point where they become an item in your project plan, with an associated timeline and resource cost, you need to think about productizing and looking for solutions rather than building one.

One of the largest telecoms in the world, and a company I respect greatly, was talking about this in their Architecture Review meeting a few weeks ago. I was there, and one of their resources said “I hear where you are coming from - we thought of stubbing and mocking as a simple activity, but we have now evolved an entire career path out of people becoming simulation developers!”

There were literally scores of people whose work function was architecting, developing and maintaining simulation artifacts, or “stubs.” Think about it – what company (other than a couple software vendors) would split off an entire category of developers to go build their own database? The person who runs technology for this entire telecom would not make that kind of investment, without serious scrutiny for finding a better solution off the shelf.

So this is the awkward tipping point we find ourselves in today, moving from stubs and mocks to Virtual Services. People who have been building stubs for a long time out of necessity, are finding it harder and harder to keep this up. Our LISA Virtualize happens to be the first (and, without exaggeration, the only) solution on the market to handle this particular challenge.

Now customers are doing the math -- and rationalizing how we used to do it versus this new paradigm with Virtualize. By no means will Virtual Services create a career problem for so-called “simulation developers” either – I have yet to encounter a profitable enterprise that is seeking to do LESS development, or deliver LESS functionality to the business.  What ends up happening is better aligned development to the business needs, both within the company, and with partners. That is of course the goal of any healthy IT organization.

Long story short: I hope this provided some useful perspectives you can apply when thinking about using Virtual Services versus stubbing and mocking in your software development going forward.

Why Stubs Don’t Work: Part 1 – Developers & Consumers

I’m frequently asked what the difference is between what we call a Virtual Service, and what developers have done for years, which is “stubbing” and/or “mocking out” a particular service. There are a number of ways I can address this, depending on who I’m talking to.

 First, for the Developer, I’m going down the path that Virtualization is now taking on the task of industrializing or productizing the practice of stubbing itself. Some 20 years ago, when I first started development, I wrote my own database, wrote my own development tools, my own middleware to get components to talk to each other – in fact, I used to code all kinds of things that today, I would never even dream of building anymore.

The requirements for proper databases and middleware became advanced, so that it was no longer feasible for developers to roll their own. Instead, those requirements became a category of software, and vendors started delivering solutions for that space, thus we saw the rise of a database market, and a middleware market, and so on. We see that the requirements for simulating components have become too steep to roll your own. So in that light, we see Service Virtualization as essentially the “space” that is coming out of the requirements of stubbing and mocking.

The second answer I would give, more often to the Consumer of a stub or mock is just how brittle these stubs or mocks have to be in order to be efficient. The whole reason why a team would construct their own stub is summarized as: “I don’t need a product for that, because it is something I can make quickly and easily by myself.”

Well if the goal is to do something quick and easy, the best you will be able to do with this artifact, is do a “round trip” to the stub, to prove connectivity of a particular application to that stub. In reality, there is so much more detail needed by the consumer of a service, that calling it “something you can mock up quickly” means you don’t understand the true nature of the problem.

Let me explain: If every customer response for a stub has the exact same profile, and the exact same address, account balance, etc. all with hard coded values and dates, then that may help the consumer of that stub with ONE data scenario. But, what about customers with high account balances? What about old invoices? What about transactions that occurred yesterday – and will they work the same tomorrow when that date becomes 2 days ago?

The problem with a stub that has static data, is that it won’t support the real variety of scenarios that are needed for a real world application. And you can’t just randomize the data – that would be even worse!  Consumers need predictability and control over the data they’re seeing. And they need to integrate that data not only from the simulated application, but from all the other services that might be associated with that particular application they are building.

A simple example: Say you have customer lookup in one service, while you have account management in another service. So if you have Account IDs and Product Codes and Balances that are not aligned properly between the two systems, you will have an application that fails, either at the consumer level, or somewhere in the downstream systems.

When you think about data required to support development in this scenario, stubbing a system simply doesn’t hold up. Considering all the things you would have to do to make that stub more real, you would need a pretty sophisticated framework to build those stubs. So you might start out building stubs, thinking “it’ll only take a few hours,” but you end up taxing your whole project plan with the hidden cost of building the first generation of a stub, and then modifying it over and over again. And by the way, they don’t even work very effectively.

This is part one of John's discussion on "Why Stubs Don't Work." Read part 2 of the blog, where he will discuss Performance Lab uses of stubs, and the "Tipping Point" for moving from stubs to Virtual Services.

Seen in SA: The LISA Bank?

If you've ever been visited by one of iTKO's fine Solution Architects, no doubt you have seen our "LISA Bank" demonstration scenario of our virtualization and testing capabilities. Well little did we know there's an actual business just outside of Johannesburg, South Africa with the same name.

Thanks Randy for snapping this one. I guess if you stopped by for a demo, you might get a good price on a dealer car. We'll keep it in mind next time we are around the Cape and looking for a discount ride to a LISA demo.

Question: Are Pre-Prod Environments Balooning while Production Infrastructure Shrinks?

I recently posed a question to eBizQ and got some good answers, both reasonable and unexpected perspectives. See my eBizQ SOA forum question here: Are Servers Bloating in Pre-Production, but Shrinking in Production due to SOA?

K. Scott Morrison and Joe McKendrick discussed how Virtualization is a tester's best friend in reducing this phenomenon - and yes we have seen virtualization of hardware reducing some infrastructure needs. What about the ones you can't virtualize? I vote the best answer (received by 5:00PM CST) goes to Avi Rosenthal, whose comments highlight why this phenomenon is happening:

"In distributed Service Based, Virtualized and Cloud based environments the number of other environment servers is skyrocketing vs. the number of Production servers. This is true as well for virtualized server instances. The reason for that phenomenon is that Production environments are more controlled because no one can allow uncontrolled Production. The risks of non controlled Development or Test environments are less obvious. As the number of instances grows the number of servers in the non-controlled environments grows more rapidly than the number of servers included in the controlled environment. However, logically the number could be reduced at least to a ratio of 1:3 or 1:4 and not 1:20 if the non-Production environments will be managed and virtualized similar to the Production environment."

Really good point Avi.

However HP's Kelly Emo then came up with the gist of an issue I wanted to address further: the huge rift between measuring costs and effort for Production vs. Pre-production environments. It seems these activities are usually owned by two completely different departments and cost centers within the enterprise as she notes:

"In a majority of customers I speak with, their organization, culture and funding models are no where near having this happen... different silos are managing hardware and software resources and different SLAs are associated with them. In fact, in some cases, SOX compliance keeps organizations from being able to mix and mingle their networks and data between pre-production and operations. That said, I see one place where this can happen.. in the cloud..."

That's a next-generation view. Indeed the cloud is a big piece of the puzzle. However, many of the companies who get excited about the value of deployment savings using VMs and Cloud-based infrastructure to replace servers, simply do not have a reason to care about the number of groups maintaining and consuming dev, test and integration environments.

 The same goes vice-versa for pre-production - when you break up development into smaller, agile dev & test teams, those teams each provision and set up their own hardware and software environments in a largely unregulated fashion - and often find out that there are many dependencies they can't copy or replicate via conventional means. This leaves a lot of cost and effort unaccounted for in the wash of the software lifecycle, or as a cost of per-employee infrastructure or support.

You will see a lot more on this topic from us - while we aren't in the business of virtualizing servers and hardware, we are particularly curious about why companies aren't recognizing the value they get by optimizing Production vs. optimizing their infrastructure at every step along pre-production. Is a ballooning number of servers a side-effect of distributed, agile approaches, or is the symptom we are reporting simply a matter of perception? We'll keep you posted as we do more research in this area.