OSGi & The Cloud (Part 1)

I recently attended the OSGi Community Event where I gave a talk entitled "OSGi And Private Cloud" the slides for which are available here. However as has been pointed out, if you watch the slide deck they're a little on the zen side, so if you weren't at the event then it's a bit difficult to guess the underlying points I was trying to make.

To address this I've decided to create a couple of blog entries that discuss the ideas I was trying to get across. Hopefully this will be of interest to others.

In the talk the agenda was as follows:

• Where is Cloud computing today?
• Where does OSGi fit in the Cloud architecture? (Part 2)
• What are the challenges of using OSGi in the Cloud?
• What does an OSGi cloud platform look like?

I'll stick to this flow but break these sections up into separate blog entries. So here goes with the first section...

Where is Cloud computing today?

Ironically Cloud computing is viewed by many as a pretty nebulous technology so before even describing where Cloud computing is, it's possibly useful to define what Cloud computing is.

• Wikipedia defines a Cloud as: "Internet-based computing, whereby shared resources, software, and information are provided to computers and other devices on demand, like the electricity grid".
• InfoWorld defines Cloud as: "[sic] a way to increase capacity or add capabilities on the fly without investing in new infrastructure, training new personnel, or licensing new software. Cloud computing encompasses any subscription-based or pay-per-use service that, in real time over the Internet, extends IT's existing capabilities".
• NIST defines (see the "NIST Definition of Cloud Computing" link) a Cloud as: "a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction"

For me all of these definitions seem pretty similar to Utility computing. Again wikipedia defines Utility computing as "[sic] the packaging of computing resources, such as computation, storage and services, as a metered service similar to a traditional public utility (such as electricity, water, natural gas or telephone network)". So what is the boundary between Utility computing and Cloud computing? Others have attempted to define Cloud by what it is not. I tend to agree with some of these points but not others.

So where does this leave us…?

Actually I think the NIST definition I referred to above does a good job of describing what Cloud is as long as you read past the first sentence. For me the summary of this document is that:

Cloud is computation that is: on demand; easily accessed from a network; with pooled resources; and rapid elasticity.

As a final foot note in the NIST document it mentions that:

"Cloud software takes full advantage of the cloud paradigm by being service oriented with a focus on statelessness, low coupling, modularity and semantic interoperability".

This last sentence for me is of fundamental importance when considering the relevance OSGi to the Cloud.

I'm tempted to break off from the flow of the slides here and leap to the conclusion but I've set my self a goal of explaining my presentation. So before I explore this point further I'll continue with the slide deck as presented but rest assured this point will be returned to.

Why Cloud?

So as the previous discussion suggests, the reason for using a Cloud model is it gives users just in time:

• Processing power
• Storage capacity
• Network capacity.

Clouds models are great for small, medium and large organisations.

• Small organisations benefit from the reduced startup costs of Clouds compared with setting up and provisioning home grown infrastructure for web sites, email, accounting software, etc.
• Medium sized organisations benefit from the on demand nature of Clouds - as their business grows so can their infrastructure
• Large organisations benefit from Cloud due to their shared resources - instead of having to maintain silos of computing infrastructure for different departments they can get cost savings via economy of scale.

There are a large number of vendors touting Cloud products, including Amazon, Google, Salesforce, Rackspace, Microsoft, IBM, VMware and Paremus. These products fit into various categories of Cloud, IAAS (Infrastructure as a Service), PAAS (Platform as a Service), SAAS (Software as a Service) and Public or Private Cloud.

Cloud Realities

So Cloud seems pretty utopian right? In fact despite promise of Cloud the realities it delivers are somewhat different.

• As there are so many vendors, there are also multiple APIs that developers need to code to for simple things they used to do like loading resources
• Depending on the vendor the sort of things you can do in a Cloud are often limited (in Google App Engine you can't create Threads for example)
• Some vendors package Clouds as VM images and for simple deployments this is perfectly ok. However, as the number and variation of applications changes the course grained nature of VM images is a prohibitive factor. The system administrator needs to build and manage lots of different VM image configurations.

Finally, and this is a factor that effects all Clouds, they are not - despite marketing - infinite resources (pdf). Contention and latency are real problems in Cloud environments. The the shared nature of Cloud architectures means that SLAs can be severely impacted by seemingly random processing spikes by other tenants. Cloud providers employ many different tactics to minimise these problems but running an application in the Cloud and running it on dedicated hardware is not a seamless transition.

Why Private Cloud?

If Clouds are about shared resources and mimic utility services like electricity, gas or water, why would organisations choose to host their own Clouds? Well, it basically comes down to a healthy dose of paranoia. For large organisations the risks associated with Public Cloud are just too great for many of their business processes. Concerns often touted in the industry are:

• Data ownership risks – A bank for example is often extremely reluctant to host private customer details on infrastructure they don't own. This can be for legal/regulatory reasons or business intelligence reasons
• Data inertia – I've heard one horror story at a previous Cloud Camp in London about a Web2.0 portal that had started their business in the Cloud (I forget which one). However once it got successful its users were creating data in the Cloud faster than they could offload it, meaning they had a hell of a job moving providers once they started. Not a good position to be in from a price/negotiation perspective
• API lock-in – The requirement to code to vendor specific APIs is a major problem in terms of vendor lock-in. As a small company the cost of starting out is pretty minimal but once the business starts to scale, finding you are locked into an uncompetitive pricing plan is obviously not good for business
• SLA – The contention and latency issues of Clouds can mean that for those businesses that are are in a competitive compute-intensive business then any downtime or latency outside of your control can have a major effect on your bottom line.

Private Cloud implies all of the on-demand, dynamic, network accessible goodness, but in a controlled environment where the business has direct control of the cloud tentants, so can better control their SLA. A bit like owning a well, or growing your own food, there are costs but also benefits.

This pretty much takes me to the end of the beginning. I left this section with a question posed in the form of a set of images (which I've used in this blog entry). The Cloud vision is certainly an enticing one and there are already a lot of commercial benefits to using Cloud in day-to-day business. However, there are definitely still problems. The final question is...

How Do We Get Here?

This is M51a “The whirlpool galaxy” discovered by Charles Messier in 1774 (and its companion galaxy NGC 5195).

I came at computing from the physics angle and when I think of computer software/architecture I tend to think in terms of patterns. A galaxy is just a cloud of gas after all - but there is structure, dynamicity and mechanics that describe their overall behaviour!

• Homogeneous Cloud deployments can be inefficient – sometimes local processing is just faster than distributed algorithms. We need fidelity in our Cloud deployments, but with fidelity comes administrative cost. Dealing with fine grained structure on the scale of millions (or even tens of thousands) of nodes requires new models
• Clouds are dynamic, resources come and go, their can be gaps in communication caused by latency, their can even be large scale events like data centre collapse. Software that is deployed on them must be able to cope with these dynamics
• As anyone who has worked on any large or even medium sized software project knows, software is often a tangled web of interdependencies. Changing the processing laws in local parts of an architecture can have drastic effects on distant components. We need ways of encapsulating and segmenting Cloud software to allow for updates.

There we go, I'll try to write up the next section "Where does OSGi fit in the cloud" soon. But to look briefly into the future (or the past - depending on your perspective), I think we need to use modularisation and abstraction to help tame the complexity/scale curve and this is where OSGi fits into the Cloud model.

In the mean time, I'm very interested in any comments or feedback on any of the ideas discussed here.

Laters,