Taking College loyalty a bit far?

A few weekends ago I was at the Balliol College family day and they had a face painter. I got her to do a large college arms on my face, which came out quite well! Thanks to Jeremy for the picture.

WSO2 Stratos - Platform-as-a-Service for private and public cloud

Yesterday we announced something I believe is a game-changer: WSO2 Stratos. What is Stratos?

WSO2 Stratos is a complete SOA and developer platform offered as a self-service, multi-tenant, elastic runtime for private and public cloud infrastructures.

What that means is that our complete SOA platform - now enhanced with Tomcat and Webapp support - is available as a  "cloud native" runtime that you can either use on the Web (yes - you can try it out right now), on Amazon VPC, or on your own internal private cloud based on Ubuntu Enterprise Cloud, Eucalyptus and (coming soon) vmWare vSphere. It is a complete Platform-as-a-Service for private and public clouds.

I'll be writing more about Stratos over the coming weeks and months, and I'll also provide links and tweets to other Stratos blogs, but in this blog I want to simply answer three questions:

1. I'm already talking to {vmWare, Eucalyptus, Ubuntu, Savvis, Joyent} about private cloud - what does WSO2 add that they don't have?
2. What is the difference between Stratos and the Cloud Images that WSO2 already ships?
3. Why would I choose WSO2 over the other vendors offering Platform-as-a-Service?

In order to answer the first question, lets look at the cloud computing space, which is most easily divided up into:

• Infrastructure-as-a-Service (IaaS): this is where Amazon, Eucalyptus, vmWare, Saavis and Joyent play
• Platform-as-a-Service (PaaS): Google App Engine, vmForce, Tibco Silver and now WSO2 Stratos play in this space.
• Software-as-a-Service (SaaS): Google Apps, Google Mail, Microsoft Office Live, Salesforce, SugarOnDemand - these and many more make up the SaaS category.

To generalize wildly, most people talking about public cloud today are talking about SaaS. And most people talking about private cloud today are talking about IaaS.

SaaS is fantastic for quick productivity and low cost. WSO2 uses Google Apps, Sugar on Demand and several other SaaS apps. But SaaS doesn't create competitive advantage. Mule also uses Google Apps. They may well use Salesforce. SaaS cannot produce competitive advantage because your competitors get access to exactly the same low-cost services you do. In order to create competitive advantage you need to build as well as buy. For example, we use our Mashup Server together with our Sugar Business Messaging Adapter to provide insight and management of our pipeline that goes beyond what Sugar offers.

IaaS is of course a great basis to build apps. But it's just infrastructure. Yes - you get your VM hosted quicker. But someone has to create a useful VM. And that is where PaaS comes in. PaaS is how to speed up cloud development.

What does Stratos give you on top of an IaaS? It gives you an Application Server, Registry, Identity Server, Portal, ESB, Business Activity Monitor and Mashup Server. And it gives you these as-a-Service: completely self-service, elasticly scalable, and granularly metered and monitored. Someone in your team needs an ESB - they can provision one for themselves instantly. And because it's multi-tenant, it costs nothing to run until it gets used. How do you know how it's used? The metering and monitoring tells you exactly how much each tenant uses.

2. What is the difference between Stratos and the existing WSO2 Cloud Images?

The cloud images we started shipping in December are not Cloud Native. Stratos is Cloud Native. In practice, this means that when you log into Stratos (go on try it now) you can instantly provision your own domain, together with a set of Stratos services. This saves memory - instead of allocating a new VM and minimum half a gigabyte of memory to each new server you get a new ESB with zero extra memory cost. And it's much easier. The new ESB will automatically be governed and monitored. It's automatically elastically clustered.

3. Why would I choose WSO2 over other PaaS vendors?

Firstly, if you look at PaaS as a whole there is a huge divide between Public PaaS and Private PaaS. The public PaaS vendors simply don't offer private options. You can't run force.com or Google App Engine applications internally, even if you want to. WSO2 bridges that gap with a PaaS you can use in the public Web, on a virtual private cloud, or on premises.

The second big differentiator between WSO2 and the existing PaaS offerings is the architecture. Mostly PaaS is a way of building webapps. WSO2 offers a complete enterprise architecture - governance, business process, integration, portal, identity and mashups. And we support the common Enterprise Programming Model (not just Java, WebApp, JAX-WS, but also BPEL, XSLT, XPath, Google Gadgets, WSDL, etc). The only other PaaS that I know of that offers a full Enterprise architecture is Tibco Silver.

The third and most important differentiator is about lock-in. Software vendors love lock-in - and Cloud vendors love it even more. So if you code to Google App Engine, you are tied into Google's identity model, Google's Bigtable, etc. If you code to force.com or vmForce - you are tied to force's infrastructure services. If you code to Tibco Silver, you are tied to Tibco. WSO2 fights this in three ways:

• No code lock-in: we use standards-based coding (WAR, JAX-WS, POJO) and Stratos is 100% Apache License Open Source.
• No model lock-in: we use standards-based services: 
• Identity is based on OpenID, OAuth, XACML, WS-Trust
• Registry is based on AtomPub and REST
• Business Process is based on BPEL, etc
• No hosting lock-in: you can take you apps and data from our public PaaS and re-deploy internally or on your own virtual private cloud anytime you like.

I hope you found this a useful introduction to Stratos. If you want more information, contact me paul@wso2.com, or check out the Stratos website or code.

Cloud Native

Together with Sanjiva and the rest of the WSO2 architecture team, I've been thinking a lot about what it means for applications and middleware to work well in a cloud environment - on top of an Infrastructure-as-a-Service such as Amazon EC2, Eucalyptus, or Ubuntu Enterprise Cloud.
One of our team - Lavi - has a great analogy. Think of a 6-lane freeway/motorway/autobahn as the infrastructure. Before the autobahn existed there were forms of transport optimized first to dirt tracks and then to simple tarmac roads. The horse-drawn cart is optimized to a dirt track. On an autobahn it works - but it doesn't go any faster than on a dirt track. A Ford Model T can go faster, but it can't go safely at autobahn speeds: even if it could accelerate to 100mph it won't steer well enough at that speed or brake quickly enough.

Similarly, existing applications taken and run in a cloud environment may not fully utilize that environment. Even if systems can be clustered they may not be able to dynamically change the cluster size (elasticity). Its not just acceleration, but braking as well! We believe there are a set of these technical attributes that software needs to take account of to work well in a cloud environment. In other words - what do middleware and applications have to do to be Cloud Native.

Here are the attributes that we think are the core of "Cloud Native":

• Distributed / dynamically wired
  
  In order for an application to work in a cloud environment the system must be inherently distributed by nature to support operating in a cloud. What does this mean? It must be able to have multiple nodes running concurrently that share a configuration and share any session state, as well as logging to a central log, not just dumping log files onto a local disk. Another way of putting this is that it is clusterable. There are different degrees of this: from systems that cluster up to tens of machines all the way to shared-nothing architectures that cluster to thousands or millions of nodes.
  
  Of course its not enough to think of a single application here either. Cloud applications are not just going to be written in a single language on a single platform in a single runtime. The result is that applications are going to have to be dynamically wired: not just able to find their session state and logger but also able to find the latest version of a remote service and use it, without being restarted, and without any limits to where that service has moved to.
  
  
• Elastic
  
  If a system is distributed then it can be made to be elastic. This seems to be the attribute of cloud native that everyone thinks of first. The system should be able to scale down as well as up, based on load. The cluster has to be dynamic and a controller must be using policies to decide when to scale up and when to scale down. In order to be elastic, the controller needs to understand the underlying Infrastructure-as-a-Service (IaaS) and be able to call APIs to start and stop machine images.
  
  
• Multi-tenant
  
  A cloud native application or middleware needs to be able to support multiple isolated tenants within the system. This is the ability of Software-as-a-Service to handle multiple departments or companies at once. This compares to running multiple copies of an application each in a Virtual Machine (VM). There are two main reasons why multi-tenancy is much better than just VMs. The first benefit is economics: a tenant has a minor overhead (usually just a row in a database). A whole VM is costly: it uses a lot more memory and resources, there may be license issues, and its hugely more complex to manage 1000 copies of an application than one single multi-tenant application with 1000 tenants. The second reason multi-tenancy is important is because it enables:

• Self-service
  
  Self-service provisioning and management are key to getting the most out of a cloud system. If I can have an elastic tenant to myself that's cool. But if I rely on an administrator to set it up, configure it and manage it, then that isn't Software, Platform or Infrastructure "as-a-Service". It hasn't bought me faster time to market. Self-service applies at all levels - at the infrastructure level, self-service means managing your own VMs. At the platform level, self-service means managing and deploying production applications and middleware. At the software level, self-service means creating and managing your own tenant in an application.
  
  
• Granularly metered and billed
  
  One essential point of cloud is pay-per-use. But that has to be granular. Pay-per-year just is not the same as pay-per-hour. Even in a private cloud, metering is essential. In a multi-tenant, elastic environment, creating a new tenant (e.g. a new app server, a new accounting system, a new CRM) is (almost) incrementally free until the point at which that tenant is used. In a normal system model the cost of creating and provisioning a system is so large (think of the meetings!) that it usually obscures the first year's running costs. In a self-service, multi-tenant, elastic system the actual usage is the real cost. Therefore understanding, metering, and monitoring that usage is essential.
  
  
• Incrementally deployed and tested
  
  Applications running in the cloud need to be updated, just as any other application. But experience with our customers shows that they need to do clever things to handle new versions in a highly-scalable high-volume environment. Our largest customers typically have systems set up where they can incrementally deploy a new version of a system - side-by-side with the old one. Even once a new version is fully unit and system tested, there may be a desire to test the new version "in place" in the live cloud environment. Switching over traffic between versions is not just a binary decision - you may want to try the new version with 5% of your live load.

This list aims to characterize the real challenges in making software properly adapted to a cloud environment. I had a lot more to say about each point, but I wanted to keep this to-the-point. 

I strongly believe that it is only once a system really implements these attributes that it starts to give the full benefits of running in a cloud. And the benefits of "Cloud-Native" systems are immense: better utilization of resources, faster provisioning, better governance. Its probably a whole 'nother blog post to go into the full benefits of having cloud native software!

Have we missed any attributes? Please feel free to comment - and please post a trackback if you write a response.

Platform-as-a-Service freedom or lock-in

There has been a set of discussions about lock-in around Platform-as-a-Service (PaaS): Joe McKendrick and Lori MacVittie in particular bring out some of the real challenges here.

Lori brings out the difference between portability and mobility. While I'm not in 100% agreement with Lori's definitions, there is a key point here: its not just code, its the services that the code relies on that buy lock-in into a cloud.

So for example, if you use Amazon SQS, Force.com Chatter Collaboration, Google App Engine's bigtable data store, all of these tie you into the cloud you are deployed onto. Amazon isn't really a PaaS yet, so the tie-in is minimal, but Google App Engine (GAE) is based on Authentication, Logging, Data, Cache and other core services. Its almost impossible to imagine building an app without these, and they all tie you into GAE. Similarly, VMForce relies on a set of services from force.com.

But its not just about mobility between force.com and Google: between two PaaSes. The typical enterprise needs a private cloud as much as public cloud. So there is a bigger question:

Can you move your application from a private PaaS to a public Paas and back again?

In other words, even if Google and Force got together and defined a mobility layer, can I then take an app I built and run it internally? Neither Google nor Force is offering a private PaaS.

The second key question is this:

How can I leverage standard Enterprise Architecture in a PaaS?

What I'm getting at here is that as the world starts to implement PaaS, does this fit with existing models? Force.com and Google App Engine have effectively designed their own world view. VMForce and the recent Spring/Google App Engine announcement address one aspect of that - what Lori calls portability. By using Spring as an application model, there is at least a passing similarity to current programming models in Enterprises. But Enterprise Architectures are not just about Java code: what about an ESB? What about a Business Process engine (BPMS)? What about a standard XACML-based entitlement engine? So far PaaS has generally only addressed the most basic requirements of Enterprise core services: databases and a identity model.

So my contention is this: you need a PaaS that supports the same core services that a modern Enterprise architecture has: ESB, BPMS, Authentication/Authorization, Portal, Data, Cache, etc. And you need a PaaS that works inside your organization as well as in a public Cloud. And if you really don't want any lock-in.... hadn't that PaaS better be Open Source as well? And yes, this is a hint of things coming very soon!

blacksmithing may 2010

I spent the weekend blacksmithing at West Dean College with Peter Parkinson:

Thanks to Mike Cooter, who also did the course, for the great pictures taken at the workshop.

My Dad's Mini on the way to India

At one point my Dad drove from England to India, in a mini. I don't know what year this is or where he is! Maybe Iran?
Its a great photo though.

I guess I ought to say: (c) Adam Fremantle

The Digital Economy Travesty

Last night the House of Commons passed a Bill that shouldn't have been passed. There has been a lot written about the Digital Economy Bill but I'll just focus on three important points.

1) The Bill was deliberately pushed through in the least democratic way possible:

a) The Bill originated in the Lords (our unelected chamber), meaning that most of the debate happened there. Most of the focus of the public opposition to the Bill was with MPs (elected) in the Commons, where there was a very short time to debate the Bill.

b) The Bill was deliberately kept back until the last minute to take advantage of a process known as the wash-up. The Bill could have been brought before parliament three weeks ago - and the Commons has had spare time these past three weeks. Instead the Bill was held back so that it could be brought as part of the "wash-up" process. As John Redwood MP put it:

"Is it not an unprecedented discourtesy to the House of Commons for a Government to introduce the Second Reading of a substantial Bill after they have announced that we need a general election?"

Of course in Parliament they call it a discourtesy, but the reality is that this is a deliberate machination to suppress debate and bypass the democratic process. Just 236 out of 650 MPs turned up to vote and the majority of the Bill had no debate (most of the clauses were pushed through in the last 5 minutes of the third reading).

2) The complete disregard the major political parties showed for the public discontent 


Every MP is Britain has many letters about this from concerned voters. Even just before a General Election (when you would imagine MPs would show the most concern for voters) the result was negligible. Many backbench MPs spoke against the Bill, but the Front Bench and the whips ensured that the vote went through despite the public concern.

I personally find the process and the lack of democracy much more worrying than the actual Bill. Its a bad day for democracy in Britain.

3) The worst part of the Bill got the least discussion

The focus of the debate was mainly the disconnection orders - the ability of the entertainment industry to force ISPs to disconnect persistent filesharers. However, the worse part of the Bill is the part that used to be known as Clause 18. This will mean that ISPs can be forced to block certain websites that infringe copyright. The new amendment (that was passed) says:

"The Secretary of State may by regulations make provision about the granting by a court of a blocking injunction in respect of a location on the internet which the court is satisfied has been, is being or is likely to be used for or in connection with an activity that infringes copyright."

Bizarrely this could include sites publishing information made available under the Freedom of Information Act. More importantly it could mean Wikileaks or similar sites being inaccessible in the United Kingdom. The wording as about as loose as possible. What is a site that "is likely to be used in connection with an activity that infringes copyright"? That could mean any website allowing you to download a web browser. This effectively legalizes internet censorship in Britain.

The most depressing thing was the insight into the decision making process of this country. I, like many others, ended up watching parliament in action for the first time. The result has left me with a strong realization that our concept of democracy is poor at best. I frankly wasn't that bothered by the expenses scandal - I thought the few MPs who had been fraudulent should be taken to court, but the rest was a storm in a teacup. I am much more depressed that parliament can pass bad laws in full view of a disbelieving public. That is much worse than the cost of a few padded expenses - it costs Britain its freedom.