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

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.

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.

 

 

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.

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.

Application Development in the Clouds - Mike Vizard and John Michelsen

Mike Vizard at eWeek recently hosted a podcast with ITKO’s John Michelsen, on "Application Development in the Clouds." In this conversation, John and Mike talk about how cloud computing is going to upend the way IT organizations think about SOA and application development in general.

Mike started by mentioning the increased number of dependencies that SaaS brings to SOA testing. John said Mike really nailed the problem - it is something we are seeing in every engagement that relies on third party or shared services environments. The traditional waterfall method, and its assumptions, are now all undermined, and so much rethinking needs to be done. But the effort is worth it.
Mike, as seen on the left, next discussed the increased reuse happening in SOA. This broadens the need for trust. John, as seen below on the right, said that SOA requires good governance policies. In most organizations vertical trust already exists, as teams within groups and authority domains inherently trust each other.

Now with the need to go across the enterprise, and even to third parties and partners, horizontal trust comes into play and this is usually not in place. Service level governance can handle this issue and there are good frameworks available (in the form of SOA Registry/Repository solutions like Centrasite and Systinet). However, each organization will have to customize these frameworks for their unique environment, and think about how those teams can have a common way to validate that expectations are being met.
 
John added that SOA Governance needs to extend to the consumption of services, and this is where most organizations fall short. There is "no free beer" in consuming services - so if you have an intended workflow, that also needs to be validated. After all, is the business use case realistic, and how will the provider of services be compensated?

Mike asked about how these services be validated on a continuous basis, as the services may be constantly upgraded after deployment. John replied that LISA includes continuous validation since many applications allow for ongoing modifications. You need to test for the "unintended consequences" of these modifications.

Mike asked the need for visibility into services. John responded that this need is at the Behavior level to see if the desired behavior remains the same after changes in the application. This is where continuous validation can generate trust and allow for SOA in business critical functions.

How much time needs to devoted to validation, versus building applications? If there is too much time required for validation, developer productivity falls down. John said that this is where automated testing can play a key role and it needs to address dependencies.

Mike asked how developers can be encouraged to adopt this new thinking around continuous testing. Will a new generation of developers be required? John said that this approach is more evolutionary than revolutionary. However, most test organizations need to think in a new way.

Fortunately, there is greater awareness of this need than was in place a few years ago, when much of the SOA Governance conversation was only around Structural testing, for WSDL standards, WS-Security, WS-I etc., which are very important, but just one piece of the puzzle. The idea of design, change and runtime policies that incorporate behavioral and performance Policies and SLAs are now in focus. 

I have touched on the highlights. Go to the complete podcast for the details.

Getting ready for SoftwareAG Innovation World: The Tested, Validated & Secured SOA

We're all packed for the upcoming SoftwareAG InnovationWorld 2008 conference in Miami next week. Looking forward to a lot of good dialogue with customers and partners there - last year's was one of the most valuable SOA/BPM/Integration conferences we've seen.

If you're going, check out our session Wednesday morning (10:30am) with Software AG's VP of SOA Products Jignesh Shah, and iTKO's CMO Jim Mackay on "The Secured, Tested & Virtualized SOA."

There is a lot of confusion in the market about where the external concept of Security ends, and where the Validation of secure and appropriate behaviors within SOA begins. In reality, to avoid risk, you need both. Proper Security protocols, and strong management of who is authorized to participate in SOA apps is critical.

But once you have dozens of partners inside the "gate," Validation needs to take over, to ensure that the kinds of Policies that can't be managed structurally are being met. For instance, are participants ONLY seeing the information they should see? Is there a limitation on transaction volume, or being able to edit/delete orders and data? As you can see, there are many Policies to validate within our applications, especially when you have multiple partners consuming and sharing Services.

Then, Service Virtualization adds to the mix by allowing all of the teams to have very "safe" Virtual Services available 24/7 that they can develop and test throughout their own lifecycle, without impacting the performance or security of live business services, or being privy to live customer transactions. Of course the best byproduct of this is the agility and cost savings you can gain, through elimination of constraints throughout the lifecycle of development and testing.

Hope to see you in Miami - perhaps the best place to be in the continental US in November!

WS-FalseSecurity: Are you at risk?

In our previous post, we mentioned how the notion of standards in SOA can be just the opposite. This is largely because the standards are generally generated by whatever tool you are using to create services – it’s not something you construct by hand. “Compliance” is never a 100% proposition.

Well, I wanted to take a moment to talk about the idea of Security in an SOA world. We’ve seen some similarities in this space – particularly, that WS-Security is thought of as a means to ensure that SOA applications are actually secure in practice.   We've seen from our customers that QA and IT operations teams actually do have access to test mainframes in production - to run test suites and validate that unauthorized parties can't get in. That level of rigor around access got harder to maintain when we moved to a services-based model of software -- but the security technology of some leading vendors and platforms is doing a pretty good job of validating and keeping up with WS-Security, even if it comes in several proprietary flavors in execution.

However in reality, compliance to web services standards, like WS-Security protocols, will never even come close to providing the level of security we need from enterprise applications. Most of your business logic and behaviors -- beyond ensuring the “hookup” for the services themselves is using some form of this protocol -- are happening far below the service in the functioning apps and systems of record.<

These systems are owned and managed by different teams, inside and outside your domain of authority. So what is the answer? More detailed testing of the OASIS definitions of commonly encountered violations and loopholes at the WS-Security layer?  Automated unit testing of security protocols is important – we do it in every engagement. However, we need to remember that a set of 100, or 10,000 different protocol checks is still just that – it is only testing for the kinds of attacks we already expect.  We can set up wire fences and checkpoints, but what happens once you get past that point of entry into the application?

Take for example a Sales department that is leveraging an SOA application to collect buyer interest and respond to customer opportunities, but is not automating its own process as a secure service. Since the management insists on a spreadsheet-based process, the sales guys copy or export the customer data into a spreadsheet, send that spreadsheet all over the company, then enter orders back into the SOA application based on the results of the sales meeting and customer calls. What happens when that spreadsheet inadvertently gets attached and emailed to a supplier?

Or the IT guy who creates a handy service that scours the application for all available products and inventory, and then publishes that for a reseller to tie into their own order application. Soon word spreads, and 100 resellers are drawing data out of that service - creating a performance and availability nightmare that was perfectly authorized, but never intended.

The biggest loophole in your systems hasn’t changed. It’s still the guy in the cube next to you, or the partner on the other side of the transaction. It is the unexpected behaviors of that next service you hook up with your own. The agility of SOA – its greatest strength as an architectural model – is also its greatest weakness. It just means that there are many unintended ways the Security of your applications can be compromised, besides the misuse or improper use of the WS-Security protocols.

Real trust will not come about simply through compliance. Security in SOA will be a matter of coming to grips with the way an unknown quantity of users and other services could exploit your services in unintended ways, and how the services you depend upon can possibly compromise your carefully planned exterior when they are passing transactions through your application. That level of prevention simply can't be automated - it becomes a matter of finding the integration and interface points where you have the highest risk, and prioritizing the automation of testing there first, both at a “compliance” level and the interaction level.

Prioritizing and addressing risk is the only way to truly avoid the most risky behaviors. Of course, these concerns must be met in a timely fashion, and balanced with actually allowing customers to use the intended functionality. Good automation, and virtualization of services, reduces the time required to test while also eliminating unwanted behaviors, so end users can still get the access needed to work with your applications.

I welcome your comments and examples on this topic! We'll be posting more examples of behavioral security and how to limit the your business exposure to risk soon.

SOA as a SaaS or SOAaaSaaS

Serendipitously to John's recent post on "Consumption is not Free," Dave Linthicum just put out a great note on SOA as a SaaS (or "SOAaaSaaS") that nicely covers requirements of the Publish side of delivering reusable services. Merits further thought... see SOA as a SaaS...What to Plan For

Where is all of this going? SOA and SaaS are mutually very compatible and may overlap, but they are not mutually inclusive.

SaaS is really more of a business model for reaching end customers - delivering a business over the Internet, generally through a browser instead of requiring the end user to install a client or other software on their side. The method of creating a SaaS can be done as a SOA, but in most cases, it is developed as a vertically integrated platform that the SaaS provider can control, even if some parts of the SaaS are exposed as Services.

On the other hand, delivering a reusable Service in SOA fashion, even for profit, is not necessarily a SaaS. That Service might need interpretation and certification as a "good citizen" before being offered to the end customer. The real question, and maybe this is just a point of distinction for the pundits and analysts, is: Does a SaaS need to be a complete business offering - or core to the business model, or is any Service offered for profit technically a SaaS?

For my part, I'd say the terms belong to different software disciplines, one architectural, the other marketing related:

1. SOA is a business strategy for aligning IT assets as Services in a loosely-coupled way to support business processes with more flexibility and agility.
2. SaaS is a business model for offering or selling software (or a business service, with a small "s" and not a technology Service) to end customers without the installation or client requirements. Most SaaS offerings are actually vertically integrated web implementations of software under a single brand's authority domain, which isn't always in the SOA spirit.
   

Of course, the discussion does have value, especially if we look back at it in a year or so. We expect someday to offer certified Services that obey expected behaviors in a "for profit" way, yet to do SOA these services need to be cooperative at the same time. But enough for now, we could make distinctions with SOA, SaaS, Web 2.0, etc. all day long, without even getting into the underlying technologies or the overarching Governance strategy.

Labels: saas, soa business