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

6 Top SV Mind Tricks: "These are not the virtual services you are looking for"

We've seen a growing phenomenon of misdirection going on lately in the market of Service Virtualization. Fortunately, last time we looked up Service Virtualization on Wikipedia - someone got the definition right. Thanks to everyone who updated that page and understood the bigger picture here. It can be difficult to maintain perspective when there are so many sources touting different meanings of the words "service" and "virtualization" used together.

What is the reason for such a masquerade, and why would someone describe things that are not virtual services as virtual services? Perhaps this is simply an unintentional mislabeling, but just as often this means someone is selling software or delivery capabilities that are either not ready, or never will become what we define as Service Virtualization.

Here's the top 6 kinds of "Fake Virtual Services" we are not looking for, but getting anyway:

1. Test Stubs as Virtual Services: This is by far the most common fake VS we find lately. The market for Software Testing tools is very crowded and tough, so you will find that any testing tool that allows you to enter a request/response pair as a step within the context of their test, will start calling that stub a Virtual Service. That's a far cry from dynamically built and intelligent virtual services that support stateful transactions, performance characteristics, etc.

2. Virtual Machines as Virtual Services: Conventional virtualization still pops up as a compare-and-contrast with SV. Indeed, those hardware or server virtualization solutions can "Virtualize an Entire Environment" for software development -- IF AND ONLY IF the entire environment is in scope. While they can image hard drives, desktop software and CPUs very productively, VM's cannot handle the heaviest and most constrained assets in your enviroment, nor will they be able to image or replicate anything that is "out of scope" for your team.

3. Manually Built Libraries as Virtual Services: This one may be hard to identify, as it often comes from within your own company or its partners. You may have a team of engineers who have painstakingly coded and maintained their own "Responder Framework" of mock services intended to support the other end of a needed transaction. Inevitably these manually coded elements are brittle and require an ever increasing amount of maintenance over time - leading to the question "Is my team spending time developing and assuring useful functionality -- or managing stubs?"

4. Service Directories as Service Virtualization: Around the time we were rolling out the first SV systems for end customers in 2006-2007, there was another definition floating around among integration vendors that basically called UDDI directories with "pointers" or dynamic links to the locations of given web services objects Service Virtualization. That was correct on the "Service" part and nice for governing or managing services, but it didn't really represent virtualizing anything except for being able to change a link to a WSDL.

5. Cloud-Covered Service Virtualization: This is the latest fad in fake SV. Cloud is great, it is on-demand, has virtually unlimited elastic capacity, instantaneous deployment of servers, reduced cost etc. But it won't eliminate dependencies by itself. If you are doing any heavy enterprise integration work leveraging Cloud, you will also need a robust enough Service Virtualization solution to solve the "wires hanging out" that will still constrain capacity for any serious enterprise software implementation.

6. Outsourced Labor as Service Virtualization: Of all these mind tricks, this one actually made the most logical sense and was the easiest to spot. It simply means you get people somewhere else to be your "virtual assistants" and do things for you. Still popular in practice but fortunately we stopped seeing services firms call it SV or virtual services. I think they just call it outsourcing or contracting services again.

Service Virtualization must cover a lot of ground in order to eliminate the most complex constraints, because they don't happen at any one single point in your architecture. Your best defense is to understand that while virtual services are lightweight, they are not simply generated via a quick slight of hand or misdirection.

Virtual Services should be based on very detailed and intelligent observation of everything your teams must connect to, and scaled to industrial readiness through automation.

Educate yourself on Service Virtualization. You can't fake out a professional faker. Once you are aware of the above "mind tricks," and ask for delivered proof of the real core capabilities of SV, you will much more easily be able to spot fake virtual services when they are presented to you.

And then you can go about your business.

CloudLuminaries Video: Leveraging Cloud & Service Virtualization at DirecTV

Just saw a very good interview with DirecTV's CIO Mike Benson, talking about how his development and test strategy uses Cloud-based resources alongside ITKO's virtual service environments to accelerate time to market for more than 25 million customers.

 

Mike talks about how for faster development, it is important to have an environment that "feels like the real thing." That's exactly the kind of approach we would encourage. Setting up virtual environments can take minutes, versus hours or days compared to production-style test labs - and the results are far more predictable and stable.

We highly recommend visiting CA's Cloud and Innovation Luminaries sites for many more great customer stories like this one. Stop by our friends at http://www.CA.com/CloudLuminaries for more high-business value video.

 

Cloud Chaos for App Dev: Who Should Manage the Change?

We see a lot of enterprise IT teams saying "this year is the year we will take charge of our app dev environments and move them to Cloud."  Indeed, Cloud should empower these dev and test teams, and ease the time and expense of standard lab provisioning practices greatly. We have often said that the best, first application of Cloud is for software development itself.

But what happens if different teams select "Hybrid Cloud" approaches? Or, even scarier, what if the company migrates or evolves their overall Cloud strategy over time, as some of the first generation Virtual Lab Management (VLM) offerings are already being replaced by newer vendors and systems?

What this has done is create a new kind of Cloud Chaos for software development labs: one where you might have each software team spending time configuring and working with various Cloud lab provisioning approaches, instead of focusing on developing and testing functionality that delivers value for the business.

One major energy customer we worked with literally sent 600 developers and testers to Lab Manager training to learn how to provision VM systems - only to find that the next quarter, the IT operations group selected new Cloud infrastructure to replace that system!

We recommend an approach that does not dictate a particular Cloud hosting, lab server virtualization or management platform to give teams access to their software devtest environments - changing the "many to many" issue to a "one to many" capability.

By using LISA's DevTest Cloud Manager (DCM) technology, a company can centralize the provisioning of all Cloud environments through one system, so multiple development teams can get access to all the labs they need - including the VLMs that deliver both server VMs and Virtual Services to simulate off-cloud or "big data" dependencies that cannot be conventionally replicated.

The DCM approach mitigates the consequences of change, and eliminates the need for development and testing teams to know exactly where, or how their Cloud environments are hosted and managed.

End dev and test consumers make a request to LISA DCM and instantly stand up a lab environment that is ready to go, with the systems, test data setups, and virtual services needed for distributed enterprise software development. They no longer need to focus on whether their environment is hosted in a Private cloud with CA's AppLogic, run as a Hybrid Cloud with AutoSuite or IBM solutions, or whether that capacity for a big Performance Test lab gets pushed out to Amazon or MS Azure and managed using VMware tools.

The main point of agile development and testing in the Cloud is to allow teams to focus on high-value activities -- meaning they are building and assuring software that meets business needs, instead of managing and setting up environments. The trend for all companies to move more software functionality to the Cloud will only continue. Let's embrace this high rate of change and increasingly heterogeneous future without sacrificing the productivity of software development.

We appreciate your questions and feedback on Cloud development and testing practices. Look for more articles from ITKO on this topic soon.

 

Forum: What was the biggest development for Cloud in 2011?

Participating again in the eBizQ forum on Cloud - and starting the process of looking back on a very eventful year for ITKO (and CA Technologies) in 2011, and picking our horses for what will happen in 2012.

The most obvious thing we saw in Cloud was a continued increase in consumerization and public level awareness, thanks to the usual suspects of Amazon, Apple, Google & Microsoft. You would be hard pressed to complete a download of consumer media or software these days without an invitation to claim your own Cloud spot for storing information or streaming your playlists.

But what about big business? How effectively did major companies in other industries embrace the Cloud? I just wrote a little piece on this here: http://www.ebizq.net/blogs/ebizq_forum/2011/12/what-was-the-biggest-development-in-the-cloud-for-2011.php

The biggest development for the cloud this year was, well... development IN the cloud. The categorization of Cloud as "another place to host your apps" provided some incremental efficiencies, yes, but that's a pretty commoditized activity. We always knew the cloud could do more!

Setting up elastic, on-demand dev and test environments in cloud actually turns out to be the best first use case of cloud in the enterprise. As developers need to create new functionality and verify its performance and quality on top of layers of existing stuff, they all inevitably demand their own environments.

We've seen many enterprises that have dev and test environments outnumbering production environments by 7-to-1 or more - and with inconsistent accuracy, as there is a great deal of manual setup and maintenance involved in each of those instances. Let's harness all that excess computing power and pool it inside the company as Private clouds -- and for higher capacity or seasonal needs, instantly provision ready environments in Public clouds. [more >]

Hopefully that makes sense to our readers who live in the application development and testing world -- you are in the vanguard of Cloud simply because these activities are the most natural first step, and there are immediate infrastructure efficiencies to be gained right off the bat.

As for the rest of our predictions and a look back, stay tuned...

LISA on the Map at CA World - Optimize IT Change and Operations

Less than a week until CA World 2011 in Vegas Nov. 13-16, and ITKO's first-ever appearance there (as a CA company) is gearing up to have quite a lot to offer attendees of this premier IT event - many of whom may not be familiar with how much ITKO can help IT Operations, Environments and Performance Management teams do their jobs, outside of LISA's better-known role in enterprise software virtualization and development solutions.

Take a look at this little handout map we are bringing - you can hear from ITKO experts at almost every moment of CA World, starting with the Service Assurance General Session on Monday. ITKO engineers, LISA customers and partners will be presenting on best practices for Service Virtualization, continuous testing, building Cloud-based DevTest environments, and more.

Also, check out some more interesting content featuring ITKO with CA Technologies solutions at CAWorld 2011:

1. Sessions featuring CA Service Assurance (Introscope/Wily/NetQoS) and LISA - plays twice: AE007SR: Faster Time-to-Market for Critical Business Services with CA APM and CA LISA – Tuesday, 11/15, 1:15 – 2:15PM, and Wed., 11/16, 2:45 – 3:45, Lagoon H
2. ERwin's Data Modeling and the Application Lifecycle: Monday, 2:45PM. What are the best practices for understanding data dependencies and reduce risk from software design, through development and testing? Features content about ERwin and LISA. CA's Donna Burbank presents.
3. Service Assurance and CA LISA in the Expo: See how to use Service Virtualization for Performance Optimization, and find out about faster Break/Fix capabilities using CA's Application Performance Management and LISA's defect resolution features together.

So - besides catching ITKO's track for optimizing the application lifecycle, look around next week - there are plenty of opportunities to learn new techniques for increasing agility at CA World.

Forum: What Don't Companies Get about Cloud?

Recently participated in a forum thread from our friends at eBizQ: "What do companies still not get about Cloud Computing?"

A lot of this uncertainty stems from the old stalwarts of "Is the Cloud secure? Is it scalable?" -- and I think the panelists here debunk those fears pretty well. There are many well-secured ways to take advantage of Cloud, with almost unlimited scalability -- a lot more effort has been put into that at the big public cloud providers than most companies' own web and firewall strategies.

Now, let's get down to SLAs, or service level agreements in the public Cloud - many of which are starting to improve dramatically, while most still pretty much disavow responsibility for interruptions and downtime. Caveat emptor.

That said, Cloud is already happening, and is still going to happen - there is no way to escape the business appeal of provisioning IT resources and software in an on-demand basis. We are seeing many of the world's biggest customers first pooling resources within their own enterprise and rapidly obtaining a Private cloud, while thinking of Public cloud only for the highest capacity or "edges" of their applications.

Here was my take on this topic - read more at http://www.ebizq.net/blogs/ebizq_forum/2011/08/what-do-companies-still-not-get-about-cloud-computing.php:

"Yeah we gotta do it. But who owns it, and who buys it?" Cloud as a term can cover so many departments and responsibilities within an enterprise.

Is it general corporate IT infrastructure (stuff like shared drives, backups, security & email)? Or is it the company's revenue-driving edge where business functionality is developed and delivered to partners and customers (commerce and differentiated service offerings)?

Often we are seeing larger companies with a more innovative bent hiring a "Cloud Czar" type executive or guru -- with a responsibility to overlay multiple organizations and map out a Cloud strategy. It's not always optimal, but at least then you have someone looking at the bigger picture.

Anyway, we recently had a great little meeting of the minds with some of our customers on this particular Cloud topic as well as the "Czars" and front-line job skills and talent pool of the future in our industry, so look for more interesting material on that coming soon.

Take the voke Survey: What is Agile to You?

"To err is human, to err faster is Agile."

Just got a request to take an Agile Survey from our friends at market analyst firm voke, inc:

We are in the process of conducting a survey on Agile. We will use the data from this survey to create a voke Market Snapshot on Agile, the report will be vendor neutral. I know your customers have very strong opinions about Agile and welcome the participation of as many as possible.

So - here is that survey link: https://www.surveymonkey.com/s/LNCVQ6H

I took the survey myself and it made me rethink exactly what Agile meant to me - hence the quote at the top. Funny, this comes up almost exactly a year after this blogger commented on Mark Masterson's killer video about Cloud enabling you to fail faster.

Like many terms in the tech world, "Cloud" and "Agile" often get misappropriated for somebody's marketing agenda. But both terms have the intrinsic value of mobility that the business side of the enterprise craves from IT: smaller incremental efforts and costs, and deferred larger decisions, so they aren't going away anytime soon.

I'm quite curious about seeing the results and comments our readers might add to the mix of this survey and the resulting report. ITKO customers generally tend toward the leading edge of what we'd call Enterprise Agile, but we will wager only 50% of them actually refer to their own efforts by the term "Agile." Let's find out!

Has BPM Evolved? Preview of ITKO at Software AG's ProcessWorld Berlin

We'll be heading to Berlin next week to attend Software AG's ProcessWorld 2011 - Europe, and with their recent acquisition of IDS Scheer, this partner is really bringing BPM to the forefront by combining a strong combined product and services offering.

Lately most of our discussions have covered the development, integration and testing infrastructure needed to build software. But we are also being asked, especially by our EMEA customers, has the advance of Service Virtualization and elastic Cloud devtest infrastructure also advanced their ability to successfully execute on a BPM strategy? We think so.

Invoke and Verify is alive and well - and accelerating the delivery of proven BPM processes. This is largely because we are now able to "bridge the gaps" of waiting for human and machine responses, and decrease our dependence on manual verification of results.

Using Service Virtualization, a BPM team can set up automatic, continuous validation processes, with Virtual Services providing the underlying models of dependent mainframes, test data, transaction processes, and user response scenarios needed to ensure process integrity. Non-technical business experts should not only design processes, they should be empowered to self-verify them as well, and that's what LISA's Pathfinder capabilities are all about - one-click reporting and tracing of issue through the infrastructure, so your process guys can get all the details to developers for much higher acceptance and resolution rates.

In light of the need for continuous BPM validation - at ProcessWorld, ITKO's LISA Product Manager Chris Kraus will be presenting a session Wednesday, June 1st - 2:15PM titled:

"Continuous Development, Integration & Test with Virtual Service Environments"

What youll learn: As today’s enterprise applications include more composite elements such as SOA, BPM and Cloud-based services, IT teams struggle to deliver needed software functionality against rapidly increasing complexity and change.  The new technology of Service Virtualization, which captures and simulates the behavior, data and performance characteristics of unavailable or incomplete systems for unconstrained use in development and testing lifecycles, relieves these issues when applied with the right methodology.

Four key capabilities your organization should look for in a Service Virtualization approach can enable extended software dev & test teams to get high quality Software AG-powered applications to market faster, with dramatically lower cost and risk. This session will cover:

• How to provide software dev & test teams with a more Live-like environment  
• Parallel development and testing strategies
• Virtualizing Test Data for out-of-scope systems
• Performance Testing against Virtual Labs

Customer examples of faster software delivery with lower cost and risk will be presented from three leading Software AG-based IT shops in Financial Services, Telecommunications and Retail industries. Come see iTKO in Booth #1 - we're a proud Platinum sponsor of this critical BPM, SOA and integration summit.

 

 

Moving Gracefully to the Cloud (Revisited - 1 Year Later)

Has Cloud development changed over the last year? It's about a year since we talked about "Moving Gracefully to the Cloud" here and put out our first papers on this topic, and a lot has transpired since then.

Companies embarked on multi-million dollar Cloud application projects, and encountered many of the roadblocks we discussed -- especially those "wires hanging out" of the cloud of unavailable or out of scope systems that are harder to provision or access during development.

But we've also managed to debunk a lot of the naysayers repeating the hackneyed complaints of "Cloud's not secure" or "Cloud doesn't scale" as we simply haven't found this to be true. The success of moving applications, and application development practices, to Cloud depends on People, Process, Technology - in that order, same as it ever was.

So here's John's Cloud "Chalk Talk" video, redux 1.23 years later:

 

We've seen several successful Cloud initiatives over the last year here, when companies adopt a comprehensive approach - sound architecture, considerations for performance and scalability, and most importantly continuous performance testing and validation to ensure that business outcomes are realized by the applications under development, every step of the way.

One leading insurer says they have already replaced more than 5000 development and test servers in their environment the first year by using Cloud-based labs with virtual services alongside virtual hardware. An Australian bank nearing the end of the DevTest Cloud's first year there is now predicting a 40% increase in efficiency across its entire application delivery team. All that represents a lot more functionality delivered successfully to market with the Cloud as an enabler. We'll continue to check in on these DevTest Cloud initiatives over the coming years here at the iTKO LISA Soapbox.

 

 

DevTest Cloud and LISA Service Virtualization: The Commercial

You may have read our book (well, a long paper) on SV and DevTest Cloud, or even seen the webinar we put on. But what about the commercial? Here at iTKO, promotion follows product, so here is your first peek at the new :60 spot for "Initiate the DevTest Cloud":

 

Stay tuned for even more killer video from the new iTKO-TV studios in Plano, which is to Dallas as Burbank is to LA. Which is to say it is mostly an endless expanse of malls and suburbs with some TV guys in it, but our new location is a great place to program -- and produce programming.

Impact2011 Preview Video - LISA for WebSphere, SOA, BPM DevTest

Here's the follow up to last week's post on "iTKO Opens the Throttle for Agile App Dev at IBM IMPACT 2011 - Platinum Sponsor" -- which outlines 4 key sessions to attend at IBM's Impact2011 conference (April 10-15, Las Vegas - register here). In this new Chalk Talk video, John outlines some of the reasons IBM technology customers will learn something at the event:

 

Key approaches John covered in this latest Chalk Talk video - relevant to anyone in enterprise IT but especially tailored for IBM users:

1. Service Virtualization
2. Collaborative Defect Resolution
3. Continuous, End-to-End Testing and Validation

The reality of enterprise applications today is that complexity and rate of change will always increase. So if your company is doing IBM-enabled SOA, BPM, and seeking aspects such as data management and higher performance from applications, it will behoove you to explore ways to increase your agility and open the throttle with some of this new thinking.

Two Strategies for Agile Composite Application Development - SV and DevTest

We just put up a new version of iTKO's Cloud paper "Service Virtualization and the DevTest Cloud" that helps clarify that there are two separate solutions we call Service Virtualization (SV) and DevTest Cloud, and while it makes sense to SV in its own right in any integration or testing project, there are also very good reasons to specificially use it for DevTest Clouds. Here's what we mean:

1. Service Virtualization (SV) is the practice of capturing and simulating the behavior, data and performance characteristics of unavailable or incomplete systems or services that constrain the progress of development and test teams.
   
   In essence, this is a "productizing" of the very time-consuming custom stub-and-mock process teams used to try to do for systems they couldn't get access to or easily copy or virtualize in their own enviroments. Obviously this capability has a very broad set of projects where it could be applied - it can speed up a step in a conventional waterfall-type software project, or really streamline things in an agile, SOA/BPM, decoupled approach. Virtual Services can act as stand-ins for functional and performance testing with almost unlimited repeatability, and little setup time and cost. But by the time you get to Cloud, teams invariably find they have even more dependencies, which calls for something new...
   
   
2. DevTest Cloud is a platform for doing software development and testing in a Private or Public Cloud. By nature, this Cloud-based environment allows the computing resources and infrastructure to be provisioned with complete flexibility - elastically consuming them in an on-demand way to allow the project to proceed with less overhead. A DevTest Cloud contains a Provisioning tool for deployment, and conventionally virtualized hardware and system capacity, but it also contains Service Virtualization capabilities.
   
   Without Service Virtualization, that Cloud-based lab would be subject to the same constraints as your in-house test lab environments: dependencies or "wires hanging out" that constrain teams when needed systems are unavailable or unready for development and testing. With Service Virtualization, these components can be simulated to respond with highly configurable response behaviors and times, along with a near-infinite capacity for high-volume performance validation.

I hope this helps explain why we needed to make the distinction in the whitepaper. Service Virtualization is useful to any complex, composite application development and test project, whether or not that happens in a Cloud-based environment. But within a DevTest Cloud, the practice of Service Virtualization is the catalyst that makes it a truly elastic platform without constraints.

Bridging the Cloud Divide with Development & Test Platforms

(With iTKO's guest blogger and Solution Strategist, Ken Ahrens) Your boss wants you to "do Cloud," but you’re not sure ... so what now? At least you are not alone in coming to grips with Cloud. We recently saw this article from one of our favorite columnists Joe McKendrick, covering a CA Technologies-sponsored survey of both IT execs and practitioners. Check it out:

ZDNet Service-Oriented Blog: "Cloud divide: senior executives want cloud, security and IT managers are nervous"

There are a number of interesting data points about Cloud adoption in the article that made us think:

1. 44% of executives name security teams as primary opponents of public cloud (27% private)

First of all, your leading public cloud provider should have more resources exclusively dedicated to "perimiter security" than your team can muster, and they should be able to address many of the typical concerns of external access like firewalls, authentication, etc. So the real question is: how securely designed are your applications themselves?

This is a great reason to start by moving Dev and Test activities to the cloud.  In most mature enterprises the non-production systems shouldn't be using real customer data anyway.  What better way to ensure the protection of the data? How about by first moving the desensitized or "clean" data into virtual data models that meet the needs of dev & test teams; and then running lots of analysis to make sure none of the "safe" information gets out during the process, or in deployment through use of the software.  This would be a prudent 2-step approach to the problem. We outline aspects of this in our latest paper on "Service Virtualization and the DevTest Cloud."

2. 52% of IT managers fear job losses

Although we don’t normally comment on this kind of thing, it’s interesting to think that this would be a viable concern.  The point is that employees should move up the value chain, and concentrate on providing more vital services to their employer, and therefore its ability to deliver for customers.  Managers should be focusing on how much more agile they can make their teams in rolling out new features and functionality to the market, and Cloud approaches should be malleable to these efforts.

3. 80% of all enterprises (and 92% of large enterprises) have at least one cloud service

Shouldn’t this stat vindicate the security and control concerns?  If we’re already doing Cloud, we can point to a project to determine if control has been lost or data compromised.  These case studies should be reviewed seriously to determine the correct course of action for the next round of services. We just talked about this "Cloud Creep" in a previous blog -- so if it’s already happening, you’d be much better served to figure out how to get on board.

4. Mature adopters of cloud are already virtualizing.

Not a big surprise here that once you have grips around server virtualization, moving to the cloud should be much more straightforward.  The two naturally fit together. But all this cloud infrastructure puts even more of a strain on key "over utilized" systems that cannot be virtualized, especially in a Cloud environment. For more on this, see our paper on "The Next Frontier for Virtualization: Over-Utilized Systems." 

What about all of those mainframes, ERP systems, third party service providers, and large databases?  How will they cope with additional systems looking for access? That's where Service Virtualization is an applicable practice -- productizing the practice of simulating those over-utilized systems is also a way to bring "off cloud" and out-of scope systems into scope.

What are your Cloud concerns? We only covered a few of the points in the article, so let us know and we'll talk about them here. Thanks to Joe for the overview and CA for making these empirical survey results available.

On the Forums: Is Cloud Computing Now a Business Necessity?

How widespread is the use of Cloud now, and is it a business imperative, or just another deployment option? We recently commented on this on our favorite forum at eBizQ:

 http://www.ebizq.net/blogs/ebizq_forum/2011/01/is-cloud-computing-now-a-business-necessity.php

I thought Lori MacVittie's comment that "... the "business" doesn't need cloud computing. It needs applications." was very appropriate. True, business isn't usually driving cloud adoption. The IT side of the business has the most immediate gains to realize, having to offer more computing capacity while responding to budget pressures.

However we are seeing two current trends that are very real. Some major companies have identified Cloud as more than a different hosting option, or another word for leveraging somebody's SaaS applications. They are mandating that any business activity, including not just using functionality, but building and testing the applications themselves, must happen in the Cloud.

On top of that, you have what Alain Rap calls "cloud creep," which is the inevitable march of individuals within companies going ahead and using Cloud to get around administrative and procurement issues. Here's what John said about it:

It'll be like Palmolive. You're already soaking in it!

I would say right now about 20% of Global 500 companies identify full Cloud-enablement as an important strategic initiative. But what about the rest?

It may not be defined now as a necessity, but for many companies it is already becoming a reality - you have individual developers and business unit heads, tired of a multi-month IT cost justification for provisioning new servers and elastic capacity to test and run their apps... and many of them are just going out with their credit cards and purchasing some Cloud capacity or leveraging business services on their expense accounts.

What do you think?

Virtualization or Cloud? Both or Neither? Why or Why Not?

Recently commented on eBizQ's Forums about a question that on first read seemed rather silly: Is it better to use Virtualization for some business apps rather than the Cloud? Here's what I said about it:

"It's hard to picture how it is better to use one than then other, when both could be perfectly applicable. I would expect virtualization to be a commonly accepted precursor to leveraging cloud-based environments for applications."

The discussion here, especially in posts by Ian and Lori, does a great job of making sure we aren't lulled into thinking of Virtualization and Cloud as either/or propositions. You are talking about two totally different things. But let's play devil's advocate and discuss how they are not very different.

1. Near-Ubiquity. Virtualization, as in hardware/desktop VMs and system images, is now par for the course. And we expect Cloud Computing as defined here to also become a major part of every enterprise IT strategy - in fact, we think it truly arrived this year. Therefore, both are present in most major IT shops already.

2. Complimentary Value Proposition. Obviously, you have compelling reasons to do both - I like Satoru's quip on "selfishly" utilizing several different Virtual images on an Amazon EC2 Cloud environment - perfect for quickly launching or freezing several different versions of his software lab depending on their reliability or versioning needs. To an extent, you can use both for similar value reasons: cost efficiency, more optimal use of computing resources (and/or capacity), system flexibility or elasticity... again, different things but similar value props.

3. Constrained by External Factors. Lastly we have discovered that Virtualization and Cloud are most similar in what they CAN'T optimize conventionally. Almost the same behavioral rules apply here - if it's a system or server you have access to and control over, it is easy to image as a VM, and also logical and cost-effective to deploy it in a Cloud. If you are dealing with an Over-Utilized (high traffic and size) system, or one that is Out-of-Scope (external to your dept. or a major service outside your company's authority), BOTH hardware virtualization and Cloud quickly become ineffective or constrained. Here's what I commented on that:

"There will still be some over-utilized business app resources that are also resistant to both - it doesn't make sense to try to replicate a 2TB mainframe as a VM, or stick it in a public cloud..."

A solution to the above constraints for both, is a technology we call Service Virtualization - this is now a very mature solution space and something we've been discussing for more than 3 years  here, since we introduced LISA Virtualize product features. Virtual Services provide a companion to VMs, and simulate the behavior and performance of those Out-of-Scope items, so when and if you do deploy both in a Cloud, you truly get an elastic, constraintless environment for software development and testing purposes.

iTKO's 3 IT Predictions for 2011, and How 2010 Played Out...

Another year of accelerating change in IT has swept by, and as we clear out our inventory of leftover holiday cookies and cakes, we also like to collect some of our predictions for the upcoming year, while seeing how this past year went in retrospective. (Please note, these are in no particular order, and they are just the opinions of some iTKO execs we collected by passing the hat for thoughts - use at your own risk!)

Predictions for 2011: Are we entering a "Nirvana Age" for software development? We are starting to think so - more on this concept later, but here are 3 trends we predict for the coming year:

1. An Agile Resurgence is happening. Companies are increasing their commitment to Agile methodologies - but the big difference this time is that we're not talking about a few development teams adopting XP/Scrum etc. - Agile Resurgence will be the mandate Agility across the overall IT and software development lifecycle, so you will see it cover an entire delivery organization. Companies will measure their overall success in meeting customer requirements in terms of improved Agility - speed and efficiency across design, development, testing, support and services as a whole.
2. Enterprise Cloud will take hold. By the end of the year, we expect serious enterprise Cloud adoption to accelerate rapidly beyond merely using it to improve infrastructure and hosting capacity. A whole new class of business process applications that leverage cloud will appear, along with new Platform as a Service (PaaS) capabilities that make cloud an environment for collaboration and software development itself. We've been talking about DevTest Cloud for most of 2010, and we are seeing major enterprises take it as a part of establishing their enterprise-wide cloud initiatives.
3. Shakeout in Testing space is still not done: We have seen that many companies have delayed or deferred replacing their existing UI-based testing and load testing tools and focused mostly on development tools with testing as an afterthought. That is going to change bigtime, as companies can no longer afford to have exponentially increased test labor costs, and risk of failure accelerating faster than software can be delivered. Customers will demand both deeper testing coverage across complex multi-tier apps, as well as new Cloud- and service-based delivery models for testing that can offer more flexibility and labor efficiency.

Retrospectives for 2010: Did we call it? Well, this time last year we were busy releasing LISA 5 Suite, so we didn't stop to make 2010 predictions we can grade ourselves against. But here's some observations we couldn't help but make.

1. The Cloud took off like we thought it would. We're not a market research firm, but we couldn't help but notice an explosion in Cloud strategy and implementation. In our own customer base, the number of inquiries and interest of "how do I move to Cloud?" and "Should I use a Private Cloud?" increased by 3-5X over just the last 6 months. We sponsored a couple Cloud-related events and webinars, and found a huge increase in both attendance and sophisication of this audience.
   
   
2. Service Virtualization became a line item on the IT budgets of market leaders. We saw an increasing number of project requirements and RFPs here and in Europe specifically calling for more than just "stubbing" of responders for testing and development. 2010 was a breakthrough year for the concept of virtual services: the simulation of behavior, performance and data characteristics of systems that are constrained or unavailable throughout the development lifecycle, and customers want to know how to resolve these big constraints to delivering software. A big part of this awareness was assisted by our partnerships with HP and IBM, allowing customers of their testing and ALM product suites to simulate constraints in their environments with capabilities from iTKO's LISA Virtualize.
3. A weak economy did NOT take any pressure off IT to deliver more functionality, faster, maybe it was even worse due to it... While companies likely spend 2-3x the time scrutinizing their budgetary plans for IT, and hiring was usually frozen, companies could not afford to slow down one bit. Increased competition for customer dollars, rapid consolidation and acquisition in many markets, and more regulation all created big IT projects, often without a commensurate increase in budgets or resources.
4. VMWare successfully defended its near monopoly on large enterprise IT virtualization; it was predicted by many they would fail (not us!) thanks to competitive or open-source pressures.
    
   
5. SOA Governance fell flat.  This was definitely last year's fruitcake, regifted. It still seems like such a great idea - the runtime part of governance enables companies to do some cool stuff which kept some of the players afloat, but we didn't hear many inquiries about SOA Gov all year long.

 

John - Talking Cloud Development & Test on TMCnet

Here's a clip from my trip last week to Sys-Con's Cloud Expo 2010 West - I had the chance to catch up with TMCnet Executive Editor Erin Harrison for this interview about DevTest Cloud, and the trends we are seeing at this event.

Enjoy:

 

Here's to a continued - and inevitable - maturing of this sector of the Cloud market. Much of the remaining cost and constraint of IT is in properly equipping very expansive and widely distributed dev and test teams with ready environments that support needed scenarios.

 

Notes from Cloud Expo 2010 - This will fly...

Just got back from Cloud Expo 2010 in Santa Clara, CA, and this year's event was very much a coming of age for Cloud. Attendance and expertise levels were high. Two years ago when I audited a Cloud conference, the subject matter and vendors present seemed to be catering to an MIS or webmaster-level audience - largely a sideshow to the SOA/Virtualization audience concerned with moving servers off the racks of their data centers to save some incremental network and hardware costs.

iTKO's "Chief Geek" John Michelsen talked Tuesday morning on "The DevTest Cloud: An Essential Platform for Applications" and it was standing room only, with plenty of good audience interaction - a lot of developers and testers in the audience from a show of hands.

If you want to see the content from this session, and a little more specific to LISA DCM, I suggest you attend the iTKO webinar Wednesday, Nov. 10th, 1pm CDT: What Makes a DevTest Cloud Fly? (And what is the value?)

We are seeing a maturing of the space. Hardly anyone here is trying to "define Cloud" anymore. Not as many irrational fears about "is the Cloud secure? Can it perform?" Even in infrastructure terms, the Cloud offerings here are more specialized, for instance, leveraging private Cloud storage for content management uses, or offering industry-specific services atop cloud infrastructure. From my perspective talking to attendees on the Expo floor, people are looking for ways to develop business functionality to take advantage of Cloud, and not the other way around. Also it was good to see more reporters and analysts stopping by.

John also participated in the CTO Round Table that evening, and he will cover that discussion in an upcoming post.

Speaking of Cloud: Webinar 11/10 and Cloud Expo 2010 Sessions

This is not just a big week for political pundits - it's a huge one for technology pundits, and the topic of hype and speculation is, of course, Cloud.

We're heading out to the Cloud Expo 2010 in Santa Clara today, where we are hoping to hear less hype, and more about companies getting down to practical value with Cloud. I'll be back to my roots meeting people on the show floor, and iTKO's Chief Geek/Founder John Michelsen will be making three appearances at the convention on Tuesday, Nov 2.

  John's appearances at Sys-Con Cloud Expo 2010:

1. Breakout Session: Tues 11/2 - 9:55-10:40 AM: "The DevTest Cloud: An Essential Platform for Cloud Applications"
   What is preventing enterprises from realizing the elasticity and cost savings expected from Cloud applications? Successfully delivering complex apps in distributed Cloud environments requires a means for dealing with the constraints of systems and services that are unavailable to development and testing teams. The DevTest Cloud is an essential platform that provides the ability to provision development and test labs, consisting of Virtual Machines (VMs), Virtual Service Environments, and automated regression and performance test servers in the Cloud.
2. Demo Session: Tues 11/2 - 5:00 - 5:20 PM: A product demonstration of LISA DevTest Cloud Manager (DCM) for provisioning elastic, on-demand virtual testing and development environments.
3. CTO Power Panel: Tues 11/2 - 7:15-7:45 PM: John joins other Cloud development leaders in this CTO-only panel in the general session room.

All of this activity leads up to a DevTest Cloud webinar we are putting on next week:

iTKO Webinar: What Makes a DevTest Cloud Fly? (And what is the value?)
November 10, 2010 1:00pm - 2:00pm Central

So your company is moving its software development and integration activities to the DevTest Cloud. What are some of the new practices you should expect to be able to do in this environment, and what are other companies doing successfully right now? The DevTest Cloud is an essential platform that provides the ability to provision enterprise development and test labs, consisting of Virtual Machines (VMs), Virtual Service Environments, and automated regression and performance test servers in the Cloud. Examples of utilizing DevTest Cloud for performance tuning, regression testing and continuous integration will be covered in this insightful session.

A DevTest Cloud provides an essential platform for enterprise software development and testing. Whether the Cloud infrastructure consists of pooled on-premise computing resources, or public Cloud capacity that is provisioned as needed, the end result is the truly on-demand, elastic capacity we expected from the Cloud, at a fraction of the cost of dealing with the hard constraints of traditional dev and test environments.

Registration is open to iTKO LISA customers and subscribers. Sign up here and we’ll send you the meeting information: http://www.itko.com/resources/webinar_devtestcloud_nov2010.jsp

Stay tuned for more updates from iTKO at the Cloud Expo.

News from IBM on Development & Testing in the Cloud

Good news came out today from our partners at IBM that highlights many of the initial customer successes we're seeing for the discipline of moving software development and test processes to the Cloud - what we at iTKO refer to as DevTest Cloud.

The solution offering, called IBM's Smart Business Development and Test Cloud, encompasses several technologies and services from IBM and its partners. iTKO's LISA Virtualize technology is a critical catalyst of the solution, as LISA's Virtual Service Environments (VSEs) enable the virtualization of constrained systems and performance labs needed to make the Cloud a truly elastic, 24/7 ready resource for parallel dev & test.

You may remember two major announcements this year we've discussed on this blog - iTKO's role in IBM's Application Virtualization strategy, and our integration of LISA as a Ready for Rational solution enabling end-to-end testing and virtualization.

Key features listed in today's release "IBM Expand Cloud Offerings for Software Development & Testing" included:

• IBM Testing Services for Cloud - application virtualization: Clients rapidly create multiple virtual test environments customized for each development and testing team.  By providing testing teams with 24/7 availability without dependencies on back-end systems and data stores, the service gives testing teams the ability to test more thoroughly throughout the life cycle without worrying about data or service availability. A North American company using this service experienced a 22 percent reduction in the Function and System Test cycle and a 100 percent return in ROI within 90 days.
• IBM Testing Services for Cloud – performance testing: Brings together automation and performance testing tools to significantly reduce time by as much as 50 percent, the service provides flexible, utility-based testing that delivers on-demand performance testing, and offers robust, large-scale performance testing services to enterprises, via Cloud hosting.  This service identifies defects earlier in the cycle where they are less expensive to fix and eliminates performance-related bottlenecks.

How do customers start capturing the value above, and start utilizing Cloud Development & Test solutions like this today?  We recently wrote this case study with a major Telco customer that was an early adopter of our joint vision of VSEs and Application Virtualization in the Cloud, and they have certainly seen even more returned value over the last 6 months.

The World Finally Seems to Get the DevTest Cloud Idea

We're going to continue this week with more interesting things we've heard customers and partners say about best practices for employing DevTest Cloud practices to solve big, hairy software problems.

Last week we were at STARWEST 2010 in San Diego, and the attendance was about double last year's draw. More than 250 QA professionals stopped by, and many of the managers said "I was specifically asked to find out how to virtualize my test lab" or "We are looking for a way to take our SDLC to the Cloud" or "I know we are moving to a federated Cloud solution for our defense projects and we need to be involved" - referring to the government's Forge.Mil initiative we discussed here recently.

Heady stuff, because in previous years most of the questions at these shows were about testing specific protocols and interfaces such as web services, web 2.0 UIs or TIBCO, etc.

From our bizdev man Scott - he made one call to a potential customer, and he was already thinking DevTest Cloud. Check out an excerpt of what this guy sent out to his team, telling them all to get familiar with the concept -- before he'd even finished the first page of our recent whitepaper about virtualization in the DevTest Cloud:

If you glance at the executive summary of their white paper, they seem to address the issue of the various independent systems required to make up a test/development environment. From my high level discussion, I learned that they do this via simulation rather than reproduction of the external system. Having a solution to simulate external dependencies would be of great benefit for repeatable tests and to quickly reproduce a whole environment. I think it is very interesting.

All of the aspects that make Cloud enticing - elasticity, on-demand resources, provisioning as a "utility," multi-tenancy and low-cost capacity, make DevTest Cloud especially interesting, because it truly allows teams to work in parallel, while avoiding the constraints of huge costs and delays created by waiting for unavailable or live system dependencies to be available in their environments.

We too find it very encouraging that when enterprise IT thinks Cloud, they are starting to also think of software Development and Test as an essential function of the Cloud, rather than merely Cloud Computing as a deployment option.

 

What's the Best First Use of Cloud? iTKO on eBizQ Podcast.

Over the course of this year we have had an increasing number of customers who have made a commitment to "go cloud" as a strategy to realize flexible, on-demand computing capacity and IT cost savings in a broad sense. You would assume that we would also see some huge success stories in Cloud, but they are still waiting to be seen.

I just did a Podcast with eBizQ's forum editor Peter Schooff called "What's the Best First Use of the Cloud?" to discuss where companies could start their Cloud efforts to realize the maximum benefit for the minimum outlay, specifically in the software development & test area. http://www.ebizq.net/blogs/2010/09/whats_the_best_first_use_of_th.php

What stymies Cloud? It's not the negative hucksters who make unfounded complaints about the lack of Security or Performance in Cloud. An application that is poorly secured and tuned will be a problem whether or not it is deployed in cloud. No, we are finding the biggest issues to real cloud development are the elements of Cloud that are still external to your control or scope.

Don't just "stick your apps in the Cloud." Make your apps, integrate them, test them and tune them in a DevTest Cloud, where all of the external dependencies, data and configuration are ready anytime.

2010 - The year we met DevTest Clouds...

Today we released a new version of the whitepaper: "The DevTest Cloud: An Essential Platform for Application Development" -- and aside from looking really good (kudos to the designers), it contains a whole lot of new thinking about how we should best bring enterprise software development into the Cloud age.

If your enterprise has a Cloud initiative brewing, there is not a higher value lever to pull right now than optimizing development and testing activities in the Cloud. You should find out what DevTest Cloud platforms can do to bring the elasticity of Cloud to the software lifecycle: on-demand dev & test environments, with ready capacity at exponentially lower costs.

This is just a start, as we believe 2010 will be the year of the emergence of DevTest Cloud platforms. Leading vendors such as IBM, VMware, Citrix, Amazon and others are delivering elastic, on-demand infrastructures that are more than just places to host applications. We'll continue demonstrating how enterprises will be able to build their own DevTest Cloud platform that leverages these solutions.

Look for more blogs from us on this vital practice, as well as new videos, new press and articles, customer stories, and an appearance from John at the upcoming Cloud Computing Expo 2010.

You can get a copy of this paper, and find all the latest DevTest Cloud resources from iTKO here: http://itko.com/cloud.

SearchSOA Editor's Notebook: DevTest Clouds

A little while ago our CEO Shridhar Mittal, and IBM's Cloud executive Walter Falk had a chance to catch up with SearchSOA (TechTarget) editor Jack Vaughan. Jack wrote about our conversation on development & testing in the Cloud in his Reporter's Notebook:

Reporter's Notebook: "Push and Pull in Software Development"

Our discussion focused on how development & testing groups are addressing the increased costs and complexity of today’s distributed applications, by trying to move quality left in the lifecycle. However, there is an exponential increase in the amount of dependencies in the software lifecycle -– systems that are unavailable, costly to access, or simply not finished yet for development purposes.

This is where what IBM calls "Application Virtualization" comes in, with development and testing representing the most valid use cases for building applications in the cloud. This offering (see the post on the joint IBM/iTKO AV offering from May, and the IBM Rational news from June) paired LISA's form of Service Virtualization of unavailable or constrained 3rd party services and systems, with a full suite of ALM development and testing solutions, and best practices from IBM's services and technology groups.

Dev & Test are the most obvious places for larger enterprises to start moving to Cloud. With so many existing systems and multiple teams involved in integrating new software functionality, the virtualization of constraints as a "DevTest Cloud" is the key to productivity in the organization.

The question here is not "Where do I host this to save some costs or have additional system capacity?" That is important, but in this instance we are first asking: "Where is your software being built, and how efficiently is that delivery process meeting customer needs?"

This solution can be offered on an IBM Cloud, or other leading cloud infrastructure providers, but replacing some hardware is not the primary significance. It does not matter where the DevTest cloud resides: Public, private or a “personal” cloud on the user’s desktop, what’s important in our view, is that it provides an unconstrained platform, with dependencies resolved for successfully developing, testing and delivering applications that are ready for a service-oriented, or Cloud-based future.

News Today: Enabling the Defense Community in the Cloud with LISA Virtual Dev & Testing

Today iTKO issues a press release about our support for Forge.Mil, a collaborative software environment for the U.S. Department of Defense. As many of you know we have been following the dedicated work of DISA (DoD’s IT arm), and LISA-enabling their leading partners (such as Harris, Northrup Grumman, Raytheon, and many others) over the last 5 years, as a part of certifying and test services that are contributing to deliver functionality to the warfighter.

Here's the official press release out today:

Optimized Software Virtualization, Test and Validation in the Cloud for U.S. Department of Defense

DISA's Forge.Mil Initiative to Offer Shared TestForge Services in the Cloud, Enabling Faster Delivery of Capabilities to the Warfighter Through Software Release Efficiencies

Most discussion of Cloud to date is focused on either the infrastructure itself (the actual servers and running VMs, or IaaS - Infrastructure as as Service), or the applications themselves that are hosted on Cloud (for instance a SaaS-based offering). But how do we successfully deliver today's complex applications, when all the dependencies and constraints of unavailable systems drag teams down? Nowhere would this challenge be more evident than in Defense, where the work of many distributed teams must go on, while at the same time critical live systems must be secured against the volatility of testing and development.

Forge.Mil contains a Cloud-based community called TestForge - with a built-in Platform as a Service (PaaS) for Virtual Service Environments, so all development and test contributors can have 24/7 availability without impacting live systems, and create new levels of efficiency. The Forge.Mil initiative (which includes TestForge, SourceForge as well as providing a cloud platform for other aspects of software lifecycle management) proves that in many aspects of IT governance and innovation, federal agencies continue to lead the way over the private sector. Optimizing software in this sense can not only save time and money, but lives in the field. Thanks to everyone who has helped drive this vision.

Agile Cloud Development: Go Forth and Do the Wrong Things, Faster

Horror stories abound in the cloud... and fearful pundits rule the day, questioning the viability, security, or unknown costs of the enterprise adopting Cloud. But the reality is, it is going to happen anyway. Why? Because developers and testers can afford to adopt it on an as-needed basis without a capital expense mandate, and cloud allows software teams to fail faster.

Cloud is not just some "cheaper pay-per-use place" you deploy your apps. It is the culmination of distributed software development processes. The ideas of SOA, BPM, loose coupling, all play into the design of enterprise software for Cloud.

The beauty of developing and testing in the Cloud is not guaranteed success. It is that we can fail far faster, and at a much lower cost. One of our partner sales friends recently sent me this excellent little speech from CSC's expat Mark Masterson (check his blog here):

(Uh, whoever that bank is at about (13:40) in this clip, who lost $500M+ waiting for teams to have sequential access to test environments, needs a Virtual Services Environment to not only provision infrastructure with VMs, but also simulate those off-cloud dependencies in far lower cost for Cloud.)

I like what Mark is saying about companies being obsessed with reducing the risk of failure rather than the cost of failure. They spend all of their energy with a balance-sheet mentality - ensuring that any expenditure has less risk of failure, and in turn, delay projects and limit their options. Driving down the cost of failure is what enables real agility - allowing companies to delay their decisions to deduce the most optimal directions.

As a musician I make a point out of failing faster. The reason for practicing with others is not to play the music perfectly - instead, it is about going for it, and getting all the bad notes and bad ideas out, before you invest in recording or playing live. The same goes for software. If you had unlimited, low-cost ability to try options, rather than having to predict the one with the least chance of failure, you would find the best one much quicker.

Cloud is going to be the reality of distributed enterprise applications, because no matter what the pundits say, before it is a deployment option, it is an optimal platform for agile software development and testing. So get out there, and fail faster!

Mind the Development Gap in Virtualization and Cloud Approaches

We recently had the chance to catch up with Eric Knipp, who happened to be in the area (yes, we have astute local Gartner analysts in Dallas, and no cowboy hats on in the room). He made an interesting point: that the way we describe Service Virtualization was really oriented toward the "Design Time" aspect of a development environment.

That is definitely a "development gap" that needs to be minded. When I read and hear articles about new development processes, it seems like there is a wide gap between the developer's code itself (addressed by Agile, scrum, source control, some ALM) that extends all the way through integration and testing, and continues until Deployment (where the software assets exist in Runtime).

As an industry, we look at Virtualization and Cloud as deployment frontiers. That's cool, but it represents a small portion of what could be done with the two technologies working together to eliminate that development gap, before we step off into it.  

We are increasingly finding that as development becomes more distributed across small teams and separate domains, the number of pre-production development servers and test beds balloons. Whether that deployed app is on a regular web server, or a Cloud-hosted VM, it still seems like we are leaving a bigger proliferation there. It might not seem that big at first, but few real enterprises haven't already started leveraging these distributed computing resources now.

If Cloud Computing and Virtualization are all about replicating or replacing production servers, then why would a top banking customer replicate more than 1100 services and systems with Virtual Services instead of letting them keep making copies of Virtual Machines (VMs) on their network, and later, in their private cloud solution?

Short of longing for the old days of monolithic, centrally controlled systems with 1 production environment and a couple test and staging environments... business won't let IT go back to slow releases - our agility is also creating a new burden in pre-production. Of course, this applies for larger enterprises - there are many instance of new companies who are building functionality "for the Cloud" that is limited in scope and integration requirements, starts fresh, and thus, does not have as much of a burden here.

So here's my question again: If you had to count up the instances of pre-production vs. production "environments" and servers, would the pre-prod outnumber the production by 10-1? 100-1? Be honest and think about all those dev and test servers you don't know enough about to shut down... and think about all the partners that must have their own as well.

And, mind the gap before you step off that platform!

News Today: iTKO Teams with IBM for Application Virtualization in the Cloud

News flash (5/6/2010) - today from IMPACT 2010 we announced a new solution offering with our partners at IBM. Known as IBM Application Virtualization Services (or "AV"), this solution takes what LISA does well (Virtualization, Validation, Testing, Defect Resolution), wraps it with IBM services and technology, and makes this offering available on premise, or through an IBM Cloud platform, to solve critical customer needs.

• Press Release: "iTKO Teams with IBM on New Cloud Service to Help Clients Rapidly Deploy Applications"
• Download the Datasheet: "iTKO/IBM Application Virtualization"
• For more, see our Solution page for Application Virtualization

AV presents a highly differentiated solution to our joint customers, a solution that will revolutionize the way companies with distributed teams and technology components can build their applications. It's all part of a vision that goes beyond considering where software is deployed, to solving the root challenges of first successfully doing Development and Testing of that enterprise software where it will live in the Cloud.

eBizQ Podcast: Should you take a "Big Bang" Cloud Approach?

I recently had the chance to catch up with eBizQ's Forum Editor, Peter Schooff -- and record a podcast about iTKO's perspective on Cloud Application development. To us, Cloud Apps are the ultimate form of modern, distributed enterprise applications - they leverage everything we've done from service-orientation, virtualization, business process management and SaaS to date.

I think Peter asks some very salient questions - take a listen, read the full transcript of the interview (cool feature of their site), or download the mp3 Podcast here:

ebizQ Podcast: Should You Take a 'Big Bang' Approach to the Cloud? iTKO Explains

Cloud Apps are the apps themselves - not the hardware (or virtual hardware) they are hosted on - which are unique from the well known practice of Cloud Computing, which addresses and commoditizes computing capacity in deployment. We are especially excited about how developers and testers will be able to use Cloud App platforms to revolutionize their efficiency and reduce costs throughout the software lifecycle, so I hope that comes across in my interview.

Why iTKO is Moving Gracefully to the Cloud

You might have noticed our site, our webinars, our advertising, and this blog, appearing with a renewed emphasis on Cloud Applications. Indeed, iTKO is "Moving Gracefully to the Cloud." But why now?

Our LISA software is already well-established as a way to Virtualize service behaviors to eliminate the constraints of unavailable or incomplete systems - and that is a next generation of Virtualization that is a meaningful, unique, and growing technology for us to be involved in.

And not to toot our horn too much, but we were already winning customers and awards years ago for Validating and Testing heterogeneous apps, including SOA, web services, ESB-based integration layers, enterprise Java, CORBA, what have you. We have every intention of continuously improving our coverage on that front.

So when we now talk about Cloud Apps, we do so quite deliberately. We aren't another company trying to hitch ourselves to the latest hype cycle, or give lip service to the latest sector. We only wanted a role in the Cloud story if we were a significant, important part of the vendor community, helping enterprises develop truly elastic, quality, high-performing Cloud Applications that meet customer needs. And all of the things we have done for "modern apps," SOA, business process validation, performance testing, and rich UI testing, are part of that journey to better development of Cloud Applications.

Here's a perspective on why iTKO helps companies "Move Gracefully to the Cloud" from our founder John Michelsen.

Your Middleware ended up in my Cloud!

I recently spotted a really good question from our friend Miko Matsumura on the eBizQ SOA/Cloud forums: "When will the cloud start creating deep impact in the middleware space and what segments will be affected first? Enterprise-to-cloud integration? Web 2.0 Application Infrastructure? Modern Internet B2B? Supply Chain?"

Here's what I had to say on the topic: To date I think there has been a generalization of Cloud as a deployment alternative for production servers, etc, when at first there are few enterprise-level, middleware-enabled business processes that can realistically survive in a Cloud without having "wires hanging out" - constraints of over-utilized systems that cannot be placed in the Cloud.

The pre-integration Cloud you mention - well, the Dev & Test Cloud is going to be a significant area of growth over the next 5 years. It is hard to develop and deliver apps for the Cloud, when there are so many dependencies not available in the Cloud - mainframes, 3rd party apps like SaaS, systems of record and other over-utilized and pay-per-use assets that Development and Test teams simply can't budget for, since their use is highly variable. We will need to find a way to take our middleware processes, and other external constraints, and make them available for integration purposes in the Cloud.

I've made it one of my little missions to better describe this phenomenon with a series of YouTube "chalk talks" there's a series of 4 videos. (See our Solution page for Dev & Test for all 4 videos on the right...)

There's a reason why current successes in the Cloud are kind of consumer-oriented, content-heavy apps, and not as much "big iron" multi-enterprise apps and middleware. Pre-Production clouds will be a necessity for Cloud Apps.

The fears that Cloud Apps are not bulletproof enough for serious middleware and integration use are unfounded - good software, wherever it is deployed, is still up to people: good architecture, elegant development, responsible security approaches and early testing. If we give them the means to do their jobs better in Cloud pre-production environments the success will follow.

Hidden Costs Off-the-Cloud: iTKO ChalkTalk

OK, here's the last of our little whiteboard series on Development and Test Clouds. What are some of the hidden costs that are not improved by the use of elastic Cloud Computing based images for dev and test environments? iTKO founder John Michelsen discusses how these off-cloud fees and constraints can hinder the value of Cloud application development.

Cloud applications -- at least most of the ones that would support any complex enterprise goal -- do not mean simply sticking a VM on EC2, or "doing your SOA" in a Private/Public Cloud. Before you deploy successfully in the cloud, you have to develop successfully in the cloud. Taken together, you can see how the challenges of:

1. constrained or unavailable services and images, or "wires hanging out" of the cloud;
2. volatility of demand from development teams, and constrained capacity of cloud-based application resources; and
3. hidden costs that are unacceptable for dev & test organizations

can really hinder the incredible gains in flexibility and cost savings we expected from moving our application development and testing lifecycles to the Cloud. We hope you enjoy these occasional video series, and welcome your comments or recommendations for future topics you'd like to see us cover.

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

The Future of Cloud is the Past of SOA: DBTA article

I realize I might take some heat from a few Cloud pundits for comparing admittedly disparate items in this new article in Database Trends & Analysis: "The Future of Cloud Computing is the Recent Past of SOA for the Software Lifecycle".

As the hype around SOA faded into the overall idea of enterprise architecture, and Virtualization became a standard procedure for saving costs, Cloud Computing became the Next Big Thing for IT. (Somewhere, a self-described Cloud Expert is groaning while reading this sentence and getting ready to blast it on Twitter...)

The ability to provision a complete solution, and scale it on a pay-as-you-need basis on Cloud-based systems is very appealing. However, Cloud Computing faces an often unfounded lack of Trust - one that has nothing to do with the viability of well-designed and managed software, whether or not it resides within a company's datacenter.

So now, let's compare it to the recent past of SOA, which is well beyond it's "Wild West" days of a bunch of loosely assembled services that weren't appropriately governed or tested. Even 2 or 3 years ago, we found people asking very similar questions about trusting SOA. Now? It's quietly become a common strategy for integration in the enterprise.

I'm just saying, there will be a day, not so far in the future, when IT collectively wakes up, rubs its eyes and realizes almost everything has become some sort of Cloud Computing, some combination of Public and Private clouds. The concerns we hear today about trusting the Cloud will again fade into trusting applications in general: Are they well-designed and implemented with appropriate security?

And we can move on to worry about the Next Big Thing.

Virtual Data in the Clouds - Enabling Remote Testing Teams

We had a chance to briefly touch on this topic in our founder John's latest webinar with Infosys' Aparna Sharma on "Accelerating Modern Application Quality" -- archive available now.

A question came in during the show that was particularly pertinent to the topic at hand. How can these virtualized services and data models work in the Cloud to allow collaboration with distributed teams, especially offshore test teams? Indeed, without a good approach for virtualizing data in a Cloud-based development environment, you simply cannot get there without wasting about 80% of your effort and cost in testing today's service-based applications. 

You expected ubiquitous, flexible access to needed resources with Cloud Computing. So why can testing teams end up sitting on the bench instead of getting involved as early as possible? Much of the challenge lies within the test data itself.

In short there are "Wires hanging out of your Test Cloud" as we illustrate here - especially when it comes to Data. You can't just take a 4TB database or an external SaaS-type data provider and plop them into a hypervisor and provision them in the Cloud. Test Data is a frontier because it is not easy to replicate via known means - it is either too bulky or too dynamic to reliably move to the Cloud, but we absolutely must provision teams with good test data, in order to do enough testing to rely upon these systems for business.

Primarily there is the problem of valid data access needed for thorough testing. Most often, this is locked up in some mainframe or live service that is simply too critical to open up to the testing team. Since business continuity usually trumps new product testing, IT Ops guys will crack down on test access time windows to the live systems and the data within them. So you might have a 2 hour period of access - barely enough time to test an on-premise system, much less a Cloud-based system that is talking to other data providers.

Second, there is the problem of data sensitivity. Even if we have contracts and a good working relationship in place, we don't want to be putting data that needs to stay private in the hands of any third party. So we do need to mask or "desensitize" the data so it follows the expected structure, without BEING someone's social security number or bank account. This has always been a concern in healthcare for instance (see HIPAA guidelines), but the level of certification, compliance and controls around data privacy and security in every industry is only getting tighter. We need to be able to give these remote teams obfuscated data so they can continue testing efficiently.

Third, data setup and teardown continues to be difficult in Cloud environments. We touched on one of our favorite examples in the webinar, a Telco that literally spends 2 hours running tests, and 2 whole DAYS resetting data. Many of these problems wont go away when the Cloud-provisioned system is talking to external dependencies and systems of record that need to be accessed and later cleaned out of running systems. Quite often this is a main point of contention, as a test could corrupt the tests of other teams or even the live systems if not contained correctly.

These are just three concerns. There are many other open issues of how Test Data will be handled when we move to Cloud-based environments. I thought Judith Hurwitz nailed this as one of her observations in her "What are the Unanticipated Consequences of Cloud Computing" post:

"Data will increasingly be seen as a reusable resource that can be used in lots of different situations. There will continue to be strategic line of business applications but they will be more systems of record that keep track of the final result of actions that take place dynamically in the cloud. The value of data is not in its tight packaging as we have been used to for decades but it the flexibility to move, transform, and leverage data. The watch word for data in this new model will be Trusted Data in the Cloud."

Couldn't agree more with this observation. As we move to ever more distributed, flexible computing models, we are supporting these with very distributed development and testing teams. The data needed for the software lifecycle must be shared among business partners, on shore and off-shore teams, so success will all come back to our level of Trust that the Cloud will give us the data we need, and not give us the side effects of data we don't need.

Of course, here at iTKO, we've been stretching out our LISA Virtualize to better support Test Data Management (TDM) solution efforts with the capture, manipulation, dynamic "desensitization" and Virtualization of data used in Cloud-based development environments. Look for more discussion and research from us soon on how expert testing teams are taking advantage of Virtual Test Data in the cloud.

Virtualizing Over-Utilized Systems: Part 3 - Common Bottlenecks

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

 

Definitions of the Cloud Abound

We have been writing quite a bit here about how the public and business sector are defining the cloud. Here is another useful look at the cloud and how it can be positioned in the range of IT options. Ruben S. Montero provides a quadrant for sorting things out.

The two dimensions he espouses are local vs remote (where are resources located?) and physical vs. virtual (where are resources provisioned?). It is nice to see the options fit in the classic 2 x 2 table. It is also useful to clarify that the cloud is not simply remote provisioning, despite what some providers are claiming. Ruben uses his table to show the movement connected with the three major resource provisioning options (other than your own chip-and-mortar data center) employed today.

As Gartner's Lydia Leong recently wrote, "If you worry about hardware, it's not cloud, even if it is remote." As they added, "...if it's not on-demand, seamless, and nigh-instant, it's not cloud." 

Classic IT outsourcing involves a movement from on-site to remote systems, but stays within the physical world of data centers. Cloud outsourcing goes all the way across the grid to move from local and physical to remote and virtual. The hybrid cloud moves from local virtual to remote virtual. Each represents different challenges and opportunities.

One fulcrum for tipping off any given Cloud approach is that of authority and governance. By looking at the way the business or market wants to pay for the solution, and defines and manage service levels, you get a pretty good picture of whether or not a Cloud model is needed (or just virtual hardware/grid is needed) and which type of cloud would make a better target depending on security, authority and control factors (Private vs. Public). Of course, these distinctions will continue to abound.

Keeping Development Close in the Cloud with ZDNet's Gardner

Continuing our discussion on "Personal Cloud" technology from last week, I had a chance to catch up with ZDNet/BriefingsDirect analyst Dana Gardner, whom we also ran into at the most recent HP Software Universe event in Las Vegas.

In his latest blog: "The Cloud Gets Up Close and Personal," Dana was particularly interested in virtualization and Cloud Computing in terms of freeing up developers from dependencies and costs by replicating the target environment on their local workstation, a capability which is entirely possible today:

"The confluence of SaaS and cloud with application development and the test phase is changing rapidly..." he observed. "Compressing the test phase into the development and production becomes more feasible. And as virtualization becomes more common, building an application or service in its own runtime stack bubble from inception to sunset starts to make sense..."

Indeed, we feel that ANYTHING you can do to eliminate waiting on incomplete environments, unavailable systems, unexpected costs and fees, all of those things are what we need to solve if we are going to really see the value we expect from today's distributed, flexible kinds of apps -- which will likely lean heavily on the Cloud as a deployment strategy.

Having a personal-size development environment is almost as popular with developers as say, a personal-size pizza. And in terms of the costs IT departments currently must spend to enable robust test environments, the cost to the business can now seem as small as adding one topping to that personal pizza. He quoted me from the briefing:

"First, the developer working on a cloud application is free to work anywhere, anytime regardless of whether the real cloud services are available or accessible. If a cloud service for a shopping cart is down for some reason, developers are not impacted since their version of the service is on their laptop. They can also code when they are on a plane, or in another environment with no access to the cloud.

Second, although this is probably first in the minds of budget conscious IT managers, the developer is not running up charges for accessing the cloud services..." [Chris Kraus, iTKO]

Now, this sounds great. But what are the unaddressed frontiers of such an approach? Well, for one thing, Dana is looking for the whole package coming out of it:

"...while we’re combining all the elements of an application and platform from cradle to grave, why not tune the whole package before, during and after development too … then load the entire package as a portable cloud-supported production unit?

Now, that’s a “personal” cloud (I prefer cloud service nodule), but with high service performance output, and far less time in cost in the total lifecycle. Higher overall quality too. What do you think?"

We like it - however with critical deployed systems, even if they are very well tested before they are packaged and deployed by the developer, you still MUST test continuously in deployment, as all of the components and usage patterns the developer needed to have stable on the desktop, may not be so stable or used in known ways in Cloud deployment. We can get most of the way there, but probably not 100% there, as much as I'd like to be proven wrong someday.

In addition we will still see these efforts put into Public and Private Cloud environments, due to the ease of administration and economy of scale benefits of provisioning shared "anytime/anywhere" environments for the software lifecycle.

I do believe we will continue to see innovation in this realm - the personal cloud or "local virtualized" environment enabling multiple individuals and teams to work in parallel - married to next-generation application packaging and deployment options. Indeed there are already some nice technologies out there, which we will discuss with partners in future posts.

Could Open Cloud Computing Continue to Coalesce?

I wrote recently about the public sector (US Federal Government) in playing a leadership role in cloud computing. The private sector is also making moves, as James Urquhar wrote in IBM, Microsoft, others align on open clouds.

James noted that representatives of Cloud Computing Interoperability Forum (CCIF), CloudCamp, Cisco, IBM, Intel, Microsoft, and the IEEE-ISTO met. They agreed on a shared goal to promote use and awareness of open and interoperable cloud computing. They also discussed the ability to enable participants to be able to contribute and use results of broad community collaboration. There was also discussion of the possibility of a trade association or marketing association for cloud computing, but no actions were agreed upon at that time.

These kinds of activities typical for a technology that is still developing. I agree with the hope James expressed for open cloud standards operating in a cooperative, rather than competitive, fashion. I hope vendors are able to move forward with some vision around shared interests for Public clouds, while at the same time we see companies employing more specialized and secure "Private Clouds" and other hybrids such as the "Personal Cloud" we recently talked about, for specific software lifecycle purposes.

The release of an Open Cloud Manifesto, originally authored by IBM, was not without some disagreement, as Microsoft objected, and there were plenty of differing opinions thrown around the blogs I read after this announcement. The group's site shows that many players have signed up but, as James notes in another post, the "big four" of cloud computing, Amazon.com, Microsoft, Google and Salesforce.com, are not signatories so far. You can find the Open Cloud Manifesto at opencloudmanifesto.org.

It notes five challenges to adoption: security, data and application interoperability, data and application portability, governance and maintenance, and metering and monitoring. Several of the challenges this collective is concerned with, are also factors that in our experience, customers are very concerned with; especially the quality and validation aspects of governance, and the portability of Cloud services through virtualization of software components hosted in the cloud to eliminate some dependencies and per-use costs.

The manifesto concludes that it is meant to "begin the conversation, not define it." Obviously these kinds of industry groups are promoted merely as representatives of common interests, and not legal entities. However, we look forward to the rest of the story as the cloud coalesces.

On-Demand App Dev Strategies with Compuworld's Mark Hall

I recently had a chance to catch up with Mark W. Hall, an analyst and writer for Compuworld. Mark was especially interested in the concept of bringing development and testing environments into readiness in his blog "On Demand App/Dev? Not yet, but closer."

Mark talked to several vendors that are in application quality related fields, as this can often be an underdeveloped aspect of development. In other words, we are now take an extremely "agile" approach to developing new functionality, and the quality or ability to test all of the components and interconnectedness in an application's environment just hasn't kept up.

Here's an excerpt of Mark's article:

"At iTKO Inc. in Dallas the company's LISA product lets you tests services (in the cloud or in your data center) virtually. Chief Geek John Michelsen says LISA watches how your app interacts with a given service over time, then it creates a virtual instance of the service with all of its behavioral quirks and features that you can test as often as you like. Michelsen claims it is unrealistic for a developer to test against a live service."

[Just as a clarification - I believe we definitely must enable developers to test live services for checking implementation - however I do believe developers and testers cannot get access to the production environment to do so 95% of the time they really need it, especially if it is already handling live customer transactions...]

Mark also asked about hosting these virtual environments in the Cloud, and a resounding YES, we already see Cloud providers and partners offering up Virtual Services capabilities, playing nicely alongside other virtual servers and machines that make up a well-rounded test environment. Look for more from us on this topic soon.

Who needs a "Personal Cloud?" - Gualtieri

With all of the hulabaloo around Cloud Computing, you'd think the LAST thing we need is yet another kind of cloud, in addition to Public Clouds and Private Clouds (secured within a company's domain). Forrester's Mike Gualtieri, an application development analyst we have enjoyed talking to in the past, agrees in his blog "Cloudmania: Developers Need A Personal Cloud" that we don't need a new cloud for everything in principle, while proposing another cloud anyway.

"What developers could use is a Personal Cloud that would allow them to configure their local environment in multiple way and take it with them wherever they go. I know this sounds like virtualization and it is to some extent, but extend PC virtualization with cloud concepts and you get the Personal Cloud."

What is a "personal cloud" anyway? Is it the "Most Private Cloud?" In essence it is a way for developers to completely isolate themselves from dependencies, by having all of the services and resources they need to work and test in their own "personal cloud" environment right on their own computer. No connection to the Internet or a hosted service needed.

At this point you may ask yourself if this can even be called a Cloud, and if it is even relevant to the real world, much less plausible. Indeed, many of the comments on Mike's blog are challenging the feasibility of a "Personal Cloud" altogether. If you are talking about working with enterprise applications, you can't possibly replicate monolithic mainframes, systems of record, and simulate complex transaction and service environments right on the developer's laptop. Right?

In reality this kind of thing is happening today with the practice of Service Virtualization (you can read a paper on the concept here), when coupled with a localized Virtual Environment (or virtual "appliance") that allows a very genuine simulation of the developers' dependencies to run locally. Even if the moniker "Personal Cloud" doesn't stick, we think he is onto something.

Mike mentions Moore's law: exponentially increased processing power and capacity on the developer's desktop at lower prices. That makes what seemed to be an impossibility 5-10 years ago, a very real proposition today. As developers have more local computing power at the ready, they will be increasingly able to model sophisticated test and development environments within a VM, provided they are detailed, robust, and can perform close enough to reality to be relevant.

Anyway a good original blog and this idea is worth watching as it develops. While there are compelling reasons why Public and Private Cloud deployment are here to stay, don't be surprised when developers ask for the ability to truly work "off the grid" sometimes to move their lifecycles into parallel and eliminate the costs and constraints of access to the environment.

Whitepaper: Demystifying Cloud-Based Testing and the Related Benefits

You might have noticed a lot of commentary about Cloud Computing recently on this blog, and it is not a coincidence. In our conversations with analysts, peers and of course customers in the field, we are frequently asked about how this approach can add value to the testing and virtualization practices we support.

We have just put out an iTKO whitepaper on this topic, titled "Demystifying Cloud-Based Testing and the Related Benefits." The PDF is free to download.

There are many hard lessons and new techniques learned from industry-wide attempts to decouple and flexibly assemble enterprise software around key business processes. In order to reduce risk as we move into Cloud environments, we need systematic testing that gets around the roadblocks of inaccessibility and unexpected costs. We need to make use of automation and virtualization of the extended environment as much as possible. Cloud-based services need to be governed and validated as part of a continuous business process.

At this stage of the Cloud's development, there are many vendors and service providers that can contribute value to a comprehensive deployment and development environment solution. This short paper does not seek to recommend a comprehensive solution set, rather it focuses on gaining value within the software testing lifecycle. It outlines the key challenges and the top 4 strategies in play - first steps for virtualizing and testing distributed assets in the Cloud. We hope you find the information useful, and invite your feedback.

Testing Cloud Performance Strategies: Mike Kavis

Read a recent article from a very active pundit and practitioner in the Cloud Computing space, Mike Kavis, titled "Architecting the Cloud: Testing performance in your cloud application."

In the article, Mike advocates a layered approach to testing cloud-deployed applications that makes a lot of sense, in terms of the kinds of performance testing you can actually do while the design and development lifecycle is going on. To summarize, this involves testing from the system roots up while the solution is firmed up in this order:

1. Infrastructure. Test performance of the cloud provider(s) to ensure they can sustain the needed load.
2. Data. "it is time to analyze the impact of encryption, transformation, data replication, and the various ways that data is being manipulated to address security , compliance, reliability, and scalability requirements."
3. Business Logic. Interactions of services and processes.
4. User experience. Does the application meet user needs?

[Image Source: Mike Kavis]

This is a solid approach for testing to happen while a "build from scratch" cloud-based project is being designed/developed. Testing the raw performance level of the infrastructure first is something worth validating early on, and so on up the stack, finally testing the business logic and application when they come together.

Mike talks about how covering the core performance of the cloud infrastructure early can mitigate risk at deployment: "... It would be very expensive to find performance issues from the lower levels of the architecture at this point. That is why I recommend the layered approach to performance testing. What I also like about this approach is that you can start testing very early in the life cycle."

To expand on this discussion, one way to shorten this cycle is through Service Virtualization, which is the practice of simulating and modeling the behaviors and performance characteristics of components, business logic and even UIs in the cloud that are not yet available for live testing. This kind of virtualization can go a long way toward eliminating service and 3rd party system dependencies and bringing performance testing to bear much earlier in the process.

Then, after that rollout, there remains a continuous validation need. (Only so much you can cover in a blog, so this is a topic we'd like to see Mike address in a future post... por favor... : )

For instance, the infrastructure itself may behave differently under the kinds of data and usage variability in ways that you could never predict with the raw-traffic or user interface kinds of performance benchmarking. New versions of services can be introduced, the Cloud provider can do something that affects their performance -- the list of risks goes on and on. Continuously validating going forward is a way to ensure that there are no unintended consequences of change at any one of the above layers.

All in all, it is a nice development to see practitioners showing real architectures and methodology around Cloud Computing as it is being applied for the business, as opposed to continuously defining the space, so I'd recommend keeping up with future posts from Mike.

US Federal Government Plays Leadership Role in IT Again

Our Federal government has played an innovative role in SOA governance (see Federated Computing demands SOA Governance & Testing) and now they taking a leadership role in distilling the value of Cloud Computing.

James Urquhart recently wrote, Are the feds the first to a common cloud definition? James wrote that the "public sector is eager to get rid of data centers in order to focus funds and effort on delivering value to their respective 'customers.' ... it appears that SaaS and collaborative technologies stand to benefit greatly from this trend."

The National Institute of Standards and Technology, a nonregulatory arm of the Commerce Department, has developed a draft definition for federal use of cloud computing. James quotes Reuven Cohen, in that "cloud computing will be the de facto standard definition that the entire US government will be given ... In creating this definition, NIST consulted extensively with the private sector including a wide range of vendors, consultants and industry pundits..."

Here is what they came up with: "Cloud computing is a pay-per-use model for enabling available, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model promotes availability and is comprised of five key characteristics, three delivery models (SaaS, PaaS, and IaaS), and four deployment models."

This is just the opening to the definition and James provides the details on the five key characteristics, three delivery models, and four deployment models in his post. The definition statement acknowledges that it will evolve over time, but it tries to capture all of what is considered the cloud for now. This is a noble and useful effort. We have been writing a bit on one of these key characteristics, rapid elasticity. This can promote the cloud's use for application development and testing.

Thanks to the NIST for taking the lead here. I hope it can speed the use of the cloud within both defense and civilian branches of the government to maximize the efficiency of technology investments.

Pros and Cons of Application Testing in the Cloud

Well it seems we have a series of posts on Cloud Computing and Test environments to cover, as we've been seeing a lot of good background education in our research on the topic.

Jan Stafford recently posted on a conversation with Bernard Golden - author of IT bestseller, Virtualization for Dummies. Bernard is a strong advocate for virtualization and cloud computing technologies, but warned that it requires some new skills and has to be done right. In a brief video he said that application development is one of the areas were the cloud makes a lot of sense.

Bernard provided this example. A firm wanted to test their application and need 100 browser instances. In the old days it would have required 100 machines -- that would be a massive undertaking. Even with hardware virtualization, you would need 5 to 10 machines, and there would be some complex configuration issues. However, by putting it all in the cloud, they were able to sync up 100 virtual instances of the browsers and take them down over a weekend at a dramatic cost reduction.

However, that's just a web UI testing exercise. Bernard added that few development labs actually replicate the exact server and software environment as the target data center that will run the application in production. The cost of that set-up would be astronomical by conventional means, but that is starting to change. With Service Virtualization in a Cloud Environment, you can basically eliminate all of those downstream dependencies from the equation quite inexpensively.

In addition, development in the cloud allows you to scale up and scale down the application for testing of various load sizes without incurring hardware costs. The cloud can support more difficult testing requirements like load testing and scaling that many labs can’t scale to support. Finally, since many applications will be delivered through the cloud, testing them first this way makes sense.

To reap all these benefits, Bernard cautioned that there are several important decision such as finding the right cloud services provider. Software testers will have to acquire some new skills, and development teams have to be careful about integration with internal applications. They will also have to manage application lifecycle in the cloud. Many IT service providers have also made significant strides in delivering improvements in these areas.

Bigger New Fridges = Rotten Service Assets?

OK, file this under "food for thought." On second thought, maybe you shouldn't think about food and read this one.

Maybe you've heard news of a recent San Jose incident, in which the many leftover contents of a shared office refrigerator were emptied out for cleaning -- resulting in the evacuation of the office due to the smell and 7 people being hospitalized due to the toxic mix of fumes created from the cleaning process.

Fortunately everyone seems to be OK now. But it made me think of a disgusting, but kind of effective metaphor for shared computing environments. IT has focused much effort on making more room in the fridge, rather than better planning to decrease the need for a fridge.

At a desktop level, we already saw the complexity of systems increasing to follow Moore's Law. We are constantly increasing CPU speed, RAM, hard drive capacity, bandwidth, and the install size of the OS and many software packages seem to keep bloating to meet it.

In the enterprise, we saw the advent of SOA approaches - great if well planned, but nauseating for companies who started service-enabling everything and end up with JBOWS (Just a Bunch of Web Services) sitting around that couldn't communicate with each other.

Then came Virtualization - you could take 10 servers, or 100 system configurations, pack them up and deploy them as VMs on one machine with much less overhead. Awesome savings in hardware costs, but, eventually, like our fridge, you have a proliferation of many Virtual instances that can sit around past their expiration date.

Even with Cloud Computing you can experience this kind of pollution -- since provisioning costs are so cheap, even individual developers can throw an app into a Cloud environment with the relative ease of buying lunch on a credit card. What happens if some code is still referencing that instance, but the original owner forgets about it?

With today's flexible, decoupled software approaches, are we absolutely certain some part of a service or app we communicate with is not tied to some service down the line that has "gone sour?" And who judges which Services and virtual instances need to be turned off, when some dependencies aren't clearly labeled? "Whose, uh, thing, was this anyway..."

The answer to "rotten assets" lies in good architecture, a well thought-out plan of testing and rolling out services and Cloud instances around business needs that support the lifecycle (and not just convenience), and a strong governance approach that sets firm Policy (such as declaring expectations for use, expiration date, etc.), enforced with continuous validation that services are operating normally, whether real or virtualized. With some discipline, we have the means to keep our IT environments (and our shared office fridge, for that matter), a lot less cluttered.

Of course, you expect advice like that here. I just thought it was an interesting comparison and invite your thoughts on the concept!

Cloud Computing Enhances Enterprise Development and Test Groups

Dustin Amrheim of IBM recently posted on Five Ways Cloud Computing Strengthens IT: Enhancing Development and Test with Cloud Computing in the Cloud Computing Journal.

Dustin is a technical evangelist for IBM emerging technologies in the WebSphere portfolio. He first noted that much of the discussion about cloud computing covers the administrative and operational benefits. Then he adds that "sometimes lost in the cloud computing benefits discussion is how cloud computing enhances development and test groups in an enterprise."

Dustin then provides five ways this enhancement occurs which are worth remembering:

• First, there is self-service capability, a defining characteristic of cloud computing. You can easily commission and decommission computing resources as appropriate, which shortens the procurement process for testing teams, speeding up development and testing efforts.
• Second, there is enhanced resource availability. Cloud computing, through intelligent virtualization, usage tracking, and more, enables a better usage of the IT resource pool as a single, logical entity.
• Third, is increased environmental fidelity. Test and operation teams may have different conventions and configurations than development teams. Dustin notes that this can lead to unintended application behavior and delays in service delivery. Cloud computing offers a potential solution through the increasingly popular templatized solution stack. These solution stacks can include the application and entire environment down to the operating system. They enable all teams to see the exact environment in which the application was designed and unit tested.
• Fourth, hosted tools allow developers and testers to no longer worry with installing, configuring, running, or maintaining tools on their own machines. Instead, they can log into tools from any machine with a network connection and get to work. 


• Fifth, the four benefits above allow developers and testers to focus more on their core jobs. As a result, organizations can benefit from more developer innovation, increased test quality and coverage, and more.

These are all great features of the Cloud that we are seeing adopted by customers. You will see a lot more of our examples and perspectives on this blog covering how Cloud-based test environments are enhancing application lifeycles.

Service virtualization helps enable many of the above benefits for test and development environments. Third party services and monolithic systems are resistant to being encapsulated "in toto" and operating at realistic performance levels in many cases, so virtualization is a key aspect of completing the Cloud-based test environment circle.

Good material, check out Dustin's post for more detail.