Agile Cloud Computing?

Last year we reported that Arjuna Technologies, the original home of transaction technologies from HP and now Red Hat/JBoss, were now working on fault-tolerant grid infrastructures. That article generated a lot of interest at the time, even though there was not a lot available for people to try. However, almost a year later Arjuna has just announced the release of something more concrete: The Arjuna Agility Federated Cloud Platform. There's the mandatory white paper and webinar (which is actually pretty good), but most of what's important about Agility is available to browse. Plus

[Agility] is a 'federated cloud computing platform' designed to improve business agility through a more flexible infrastructure approach. Federated, because Agility™ is constructed from IT resources that are assigned by autonomous, cooperating, business parties within and beyond the enterprise.

The description goes on to say that:

Whilst trust and power are real organizational barriers to resource sharing, Agility™ provides a controlled way for the enterprise to organically grow its 'internal cloud'. Resource owners retain control by attaching policy to the assigned resource which describes the conditions under which it can be shared by Agility™. Once assigned and subject to policy, Agility™ dynamically provisions the resource pool to meet the changing IT demands of the business.

As with some other Cloud-platforms, the services and tools needed to accomplish this provisioning can exit with existing infrastructural investments. However, ultimately Agility needs control over the whole Cloud if it is to deliver on the promised benefits:

Whilst Agility™ can be deployed onto existing infrastructure without compromising it, the power of Agility™ will be realized as IT resources are incrementally assigned under its control.

It would be good to compare and contrast this new platform with existing solutions, but it's obviously still early in its development. However, the updated white paper does give some clues:

Unlike other approaches, Agility does not force “big bang” changes onto the enterprise’s IT infrastructure and applications.

This initially seems at odds with the statements around needing full control, but there does seem to have been a lot of effort put into squaring that circle. In fact, according to the information available, Agility "does not require existing infrastructure to be restructured or changed in any way" and "does not require resources to be shared, except with the permission of the owner". It would seem that this non-invasive approach extends all the way to users, who do not even have to be aware of Agility when utilising services.

The platform appears to be based around an ESB, since there are a lot of references to it being "services-based with protocol gateways for a variety of access protocols". Although there are some of the usual suspects you would expect to see in a Cloud-platform, such as controlled sharing of services across administrative boundaries and dynamic provisioning of services, there are some potentially novel aspects that make this more interesting:

• Services and resources are made available to Agility through the definition of policies, e.g., a policy that allows some of their resources to be made available to other users in particular circumstances, such as during critical times for the business when the rest of the infrastructure is overloaded. Unfortunately there's no obvious indication of how policies are defined within Agility, e.g., WS-Policy? In fact all relationships are represented as Service Agreements. Could this be a step towards embracing more SOA Governance approaches in Cloud computing in general?
  
• Then they have a Virtual Deployment Description Language, which is a high-level language in which to describe services, along with the hardware and software resources they require, and the connections between them. Once again, this has parallels in some aspects of SOA Governance and service dependency graph work. But it appears to be a novel approach for Cloud-computing. If not then this may be a place where standardisation would help to reduce the vendor lock-in problem.
  

But given Arjuna's background, where does fault tolerance come in?

... dependability can be improved by supporting the dynamic redeployment of resources whenever failures are detected. After failure, as service requirements are decoupled from the IT infrastructure, Agility is able to identify alternative resources that could be used to satisfy the service requirements and then reconfigure the system to use those resources in order to ensure continued fulfillment of service requirements

There's no indication of whether Agility works with existing failure suspector mechanisms or uses its own. Without a more detailed architectural description it's not possible to say either way. But one things does seem certain: it looks like this time round transactions are not in the picture (unless they are a hidden part of the infrastructure.)