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

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...

Mock & Roll will Never Die

If you already have built a "mock system" in order to advance development, why would you need something better? I recently had a good conversation with our East architecture lead Ken Ahrens (see more of his work here) after a great CA World event for ITKO was winding down in Las Vegas. We had a lot of questions in our sessions about the development shop that has already "rolled their own" system of stubs and mocks - and what that meant for Service Virtualization practices.

When a company says they already have a mock system, we normally view that as a very positive sign - and tell them as much.  Often we have to convince customers that incomplete and unavailable systems are development problems that need to be solved, before we can even talk about the idea of Service Virtualization capabilities. Whereas the customer with a mock system already understands this is a real problem that needs to be solved.

I usually comment at this point about how we’ve replaced several mock systems at other customers (banks, utilities, telcos, etc...) with LISA's service virtualization. SV really is the productization of the stub and mock space, with enough sophistication to support more complex logic and performance scenarios. Similar to how you wouldn’t write your own database nowadays, it doesn’t make sense to build your own mock system when there is an industry standard solution for this available.

Some questions that usually come up:

• Does your mock system meet 100% of your needs and is it used on every single project?
• How expensive is the mock system to build and maintain?
• How fast do you need new mock services built, and are they ready on time?

If a development shop is mocking a single binary transaction -- that is a simple enough problem to solve with a bit of code. But as soon as multiple systems talk to each other, and multiple business scenarios need to be validated - the manual stub approach quickly starts to trip over its own weight, and the process of mocking and massaging test data and environments can drastically slow down delivery.

On one recent visit to an East coast utility, the customer team decided that LISA began to win (from a cost perspective) after only 10 rather finite services were mocked.  One of our favorite banks established a "center of excellence" for enabling teams with Service Virtualization instead of stubs, and measured a full return in about 6 months - then did something even more interesting by rapidly fixing issues found in production by virtualizing production behavior into the dev environment.  A successful customer like this doesn't just buy software, they take the adoption of the practice seriously - and it's usually the guys who have experienced the pain of rolling their own mocks that see the potential benefits the fastest.

In short – if you already do mock services we think it’s a good thing, so tell us about your story!

 

Emergency Alert Message: Seek a Virtual Environment Immediately!

Did you hear about yesterday's "Government Alert" test message broadcasted to Verizon mobile subscribers in New Jersey and other Eastern US states? The message said:

"CMAS Alert - Civil Emergency in this area until 1:24 PM EST Take Shelter Now U.S. Govern." (story in NJ.com)

Thousands of panicked callers immediately flooded 911 lines wondering what went wrong, and where the "Take Shelter" should happen. State Police and the NJ branch of Department of Homeland Security were on the case. As it turns out, the company apologized later that the message was just a test the carrier was running to verify their participation in the government's CMAS, or Commercial Mobile Alert System.

Events like this are a ringing endorsement for the practice of Service Virtualization - coupled with a solution like LISA that could have been used to simulate the back-end systems, the message relay, or any number of end-user phones receiving the message -- so Verizon could complete their development and test cycles. Outside of the constraints of limited access time to live systems, and the high costs of securing or replicating solid test infrastructure and data, there is a brimming risk factor for end customers.

Testing your software against (or anywhere near) the live system is inherently volatile and risky. One wrong destination address left in the code, one unauthorized data change executed by developers, can generate very troublesome results indeed. The ability to message everyone with an alert only works if we can be assured that the message is real. We hope these teams make the call to decouple themselves from live systems and customers, and immediately start testing them in a virtual service environment.