Posts Tagged ‘Federated Cloud’

Arjuna update

February 1, 2013

So, it’s a New year and inevitably I have some new resolutions. At the top of my list is the need to get more exercise and to use my gym membership for something other than the right to drink over-priced coffee in the company of fit people. (I’m loathe to give up my membership, even though I never do any exercise, as it’s a statistical fact that people who are members of gyms are on average more healthy than people who are not). Anyway, a more pertinent resolution is to blog more frequently. As a number of people have pointed out I’m a less than regular blogger – in fact I blog less than Andy Murray smiles. (It’s a statistical fact that people who own blogs are on average better networked than people who don’t).

Let me start with a quick update on what’s been happening at Arjuna. We’ve spent the last few years focused on delivering support for Federation in Clouds – in fact we’ve been banging on about Cloud Federation since around 2006. At Arjuna we think that Service Agreements are the key to glueing services together and we’ve built ‘Agility’, a platform to support flexible, dynamic agreements and the policies that enact them. Over the last couple of years we’ve utilised our platform, very successfully, with a number of customers but, to be frank, those engagements have only used a fraction of the capabilities of our product. What we’ve been missing thus far are two things. Firstly, customer interest in Federation. The reality is that most organisations have been so busy trying to virtualise their own IT infrastructures that they haven’t been ready to consider how they are going to manage the new service-based relationships they need to develop within their supply chains. Well, we believe that, finally, Federation’s time has come. I’ll blog more on that subject later. The second thing we’ve been missing is a customer who has a real and immediate requirement for sophisticated forms of Federation. The good news is that, with the assistance of a Technology Strategy Board grant, we’ve found that customer. We’ll be making a full announcement giving details within the next few weeks.

Service Agreements in the Cloud

October 11, 2011

Service agreement: an expression of functional and/or non-functional aspects of a service delivered from one party to another, along with any obligations upon either party.

In an earlier post I described how at Arjuna we believe that IT service will increasingly be delivered by Federated Clouds. In This post I want to look at the glue which connect Clouds together – Service Agreements.

When a service is both commissioned and delivered within a single organisation, the appropriate IT resources are designated and trialled until an effective service is deemed to have been provided. In this case both the consumers of the service and the suppliers belong to the same organisation, are ultimately responsible to a single authority, and have common interest. Common interest results in a level of trust where formal contractual and detailed expressions of precisely what is required of the service can frequently be avoided. Knowledge of the specific dedicated resources being used and/or faith in the ability of the IT team within the organisation can reassure the IT consumer that the requisite quality of service will continue to be delivered.

However, today if you’re commissioning an application delivering some service you’d ideally like to push it into the cloud and forget about it. You want the cloud to be opaque. You don’t want to have to make resourcing decisions (and particularly you don’t want to incur any expense associated with over-capacity). But if the cloud is opaque then you don’t know what resources will be utilised, and as there isn’t the same level of trust, how can you, or the consumers of your service, be confident that a satisfactory quality of service will be maintained?

Well, if the risks associated with the failure of the service to behave as expected are low enough so as to be ignored or effectively mitigated by the consumer then a general purpose, low-cost, cloud which offers simple ‘best-effort’ quality of service may well be ‘good enough’. Many of the applications hosted on the cloud today do indeed fall into this category.

However, if the risks are perceived to be higher then a service may only be useable if backed by a service agreement which provides some specific contractual guarantees. Those guarantees might constrain the provider to utilise specific resources in support of the service e.g. fault-tolerant hardware, replicated storage, the availability of skilled support staff etc, and thereby reassure the consumer that the risk is lower than it might otherwise be; and/or the provider might agree to compensate the consumer if quality of service is not maintained. This compensation could be through the provision of an effective alternative service or may even be financial. Service providers supporting this form of service agreement are effectively reducing the overall cost of using the service for individual consumers by mitigating their collective risk.

A service agreement could specify not only how the service can be operated and what it is expected to do, but also what might go wrong and what then happens, the legal, financial and support obligations, what reporting is to be delivered etc. In the real world service agreements (just like other legal contracts) can rarely be absolutely complete i.e. aspects remain open to interpretation, but in the cloud they certainly need to be much more explicit than they need be when services are utilised within a single organisation. The trust relationship which exists within an organisation needs to be replaced by a more formal relationship i.e. a contractual service agreement which clearly defines all relevant aspects of the service to be delivered.

Servce Agreements and the Federated Cloud

September 30, 2011

Federation: an organisational structure where the parties concerned are autonomous but cooperate through agreement.

The Cloud Computing paradigm is, at its core, about improved sharing, where the means of sharing is through the consumption of services. With constantly improving network capacity IT users are now able, in many cases, to consume services sourced from third parties rather than managing their own applications. As a consequence services will increasingly be delivered by providers who can reduce service costs by taking advantage of economies of scale. This trend puts economic pressure on IT consumers to utilise shared services, and by implication the IT resources (hardware, software and staff) used to deliver those services. As prices fall, and shared services proliferate and mature, it is inevitable that we will see a gradual but consistent move from services delivered by dedicated IT to services delivered by shared IT.

However, for at least three reasons we are unlikely to move to a situation where all IT resources are in the hands of a few providers, irrespective of the economic benefits. Firstly, there will be many cases where sharing is unfeasible or undesirable – bespoke services may not deliver value to anyone but their creators, or may be of such competitive value that the creators will keep them to themselves; other services might have restrictions e.g. security or latency considerations, that prevent sharing from occurring. Secondly, the transition to using shared services will be very gradual (due to inherent conservatism and to sunk costs in existing dedicated IT) and therefore it will be many years before even all of those services which could be shared, will be. Thirdly, governments will not allow such strong economic controls to be concentrated in the hands of a few.

As a consequence, at Arjuna we believe that IT services will increasingly be delivered by a complex, interconnected network of federated service providers. Providers will consume services from each other, organisations will cooperate together to share services to mutual advantage, service brokerage and trading will be commonplace. Given the variety and multitude of possible IT services we believe that the resultant network will be orders of magnitude more complex than other service delivery networks such as the electricity grid or telephone network. While a lot of effort has been aimed at enabling the technical integration that is required in order to build such networks, we believe that insufficient effort has been directed towards issues of organisational integration. In particular we believe that much of the complexity in federated networks will come from the need to manage service agreements between organisations.

Arjuna’s Agility product delivers the service agreements that are the glue for the Federated Cloud.

Cloud Federation

November 17, 2008

We’ve been talking to a lot of people about federation lately.

Last week, Professor Paul Watson presented federation on Arjuna’s behalf at the London CloudCamp to good reviews. Phil Wainewright picked out federation as a core them of the conference (read his blog). I’m currently in the Bay Area talking to a number of companies about this subject. It’s a hot topic.

Federation is seen as an important aspect by a number of companies including Cisco – Doug Gourlay recently outlined Cisco’s thinking around cloud and Phil Dean presented at London CloudCamp (again, see Phil Wainewright’s blog) – it was also covered at the Web 2.0 Summit although sometimes under the term ‘hybrid cloud’, a cloud that somehow spans private IT and the public clouds.

Personally, I don’t like the term ‘hybrid’ – it suggests a solution that is neither one thing nor the other. We prefer to talk about the ‘federation’ of clouds. It’s our belief that enterprises won’t present the public cloud to their internal users in its raw state, but that they’ll access the cloud-hosted services via a proxy/gateway which will represent the cloud to the users, and the enterprise to the cloud. By this means the enterprise will control access and manage the costs. This internal representation of the cloud looks to its users like a cloud – it’s opaque, and it behaves like a cloud. In fact it is a cloud – a ‘private cloud’, albeit one which doesn’t directly manage any resources itself, but a cloud nevertheless. If such a private cloud also had the means to manage internal resources and to make dynamic decisions as to whether service would be delivered by those resources or by the public cloud then we can begin to see the means by which internal IT infrastructure could over time be increasingly subsumed into the cloud.

Our Cloud computing product, Agility, is focused on delivering precisely this functionality. Agility instances can simply broker between the enterprise and one or more public clouds, or can be assigned a set of IT resources, offering users service delivered by one or the other set of resources, or by some combination of both. By this means Agility acts as an on-ramp to the cloud and allows the IT department to begin to experiment with cloud computing in a gradual, incremental way, without any need for disruption to existing service.

Taming the Dragon

June 9, 2008

Nicholas Carr writes of the dangers of Cloud Computing. ‘Beyond Here There Be Dragons’ he warns, pointing at the empty space on the map marked THE cloud. And he’s right. Bill Thompson notes that ‘in the real world national borders, commercial rivalries and political imperatives all come into play’. Who is going to send their applications, and more importantly their data, into this uncharted territory?


The answer of course is that no-one will. People won’t commit to THE cloud – but they would commit to A cloud. They’d commit to a cloud that they could trust, and in the absence of implicit trust, to one they could hold accountable. They would, for example, let their applications execute in their own department’s cloud – one that managed the departmental resources and provided its users with services and supported their service requirements, without the users needing to concern themselves with the IT mechanics involved. They’d do so if they could have clearly defined Service Agreements with that local cloud and insight into the Policy operated by that cloud.


At some point the local cloud might be connected to another department’s cloud within the same enterprise (so that resources can be shared) and this would require the creation of Service Agreements between those departments. If this happened the users wouldn’t care – or rather they wouldn’t care so long as their Service Agreements and the local Policy (the embodiment of the things they DO care about) were maintained. And when the enterprise connected to other enterprises or to some external cloud they still wouldn’t care. If concerns were present, or if new concerns arose, then the cloud user would need to:

  • be sure that their Service Agreement (or the Policies enforced by their department, enterprise or government) clearly specified what was, and what was not, acceptable and
  • place sufficient trust in their local cloud provider – sufficient that is to believe they could sue, fire or imprison the provider for breach of contract.

Does such a Cloud exist? A Cloud that respects Service Agreements and policy? A Cloud that can be formed from internal resources? One that can be federated with Clouds in other parts of the enterprise, or even with an external Cloud such as Amazon? I’d not found one, and so we at Arjuna have designed and built one – Arjuna Agility.


So, returning to Carr’s metaphor, if you want to use the cloud then you’ll need to tame the dragons. How do you tame a dragon? My advice is to start with a small one and right from the get go, make it clear who’s the boss! Impose a set of rules regarding its general behaviour (Policy) and give it clear instructions (Service Agreements). The dragons may be stirring but if you’ve got one on your side there’s no stopping you.