Saturday, 24 October 2009

The Squirrel on Cloud Computing

[Concrete/Important] The Squirrel is pulling his tail fur out – I’m surprised he has any fur left. He’s been trying to convince the Bears that Cloud Computing is important and in paw’s reach but the little Acorn ERP is just too big to get up into the clouds.

The first push back came from Little Bear, and the Squirrel was expecting this. “Cloud Computing is not really aimed at us” said Little Bear.

Little Bear is scared, probably has too much on his plate. And he’s been nurturing the Acorn and building this huge Oak Tree. In a way, he’s right, though Squirrel. The Cloud is not for our type of ERP, not today. We need to be lean and we need to change if we’re going to live in the Cloud. And it’s the same for On Premise and Hosting – storage may be cheap, but the more structured the requirements, the higher cost per GB. And it’s costing us an arm and a leg to host our Oak Tree. “No way will we be able to manage a forest of Acorn ERPs, not unless we change...” replied the Squirrel.

“And we are not just chucking images onto a file system,” said Squirrel, “We need a relational store and that costs money. We need to think how we can move down to Structured Storage, where storage is cheaper, in the Cloud or otherwise”.

Now Squirrel has always and still believes that sense will prevail. Just then, Mummy Bear entered the debate. “I’ve talked to a number of bears and we think the Cloud is at least 2 year away” she said. “What the f***?” thought the Squirrel. “Possibly true,” he replied, “but not sure what that has to do with it.” Squirrel now wondered where this was going – it certainly didn’t look like the bears were convinced the Cloud was something they should take seriously. “The Cloud may be a way away, but we still need to get lean with our data, regardless of the Cloud. The point is, if we do, we will be Cloud ready and that has to be good”. Where the hell is Daddy Bear, thought the Squirrel?

Cloud Computing is not a fad, it is a step in the evolution of Software and the commerce of Information Systems. The move towards Software as a Service is driven by the commerce of lowering the total cost of ownership. This means I’m willing to “Pay per Click” because I don’t have to own the software, hardware, operations and support. But software companies will die if they just swap the billing model from “license and support” to “service utilization” while taking on the infrastructure costs. This is especially true of hosting but also for the Cloud. It’s not the license cost, it the cost of operations. And the key to this is data. A huge data set in a relational store requires not just disk space, but CPU and memory. And this means support services around the RDBMSs. Add in resilience and high availability and the costs will soar. By dropping down to unstructured or weakly structures storage, costs can be removed without sacrificing storage capacity, resilience or availability. And your scalability improves.

The thing about the Cloud is it forces you towards this discipline. The Squirrel knows this and at the risk of losing all his fur, he needs to ensure the Bears understand this too.

Thursday, 22 October 2009

Is your code RESTful

[Concrete/Important] Well nearly, but not 100% - well not yet.

A few years ago I wrote an HTTP GET/POST web service (sounds RESTful) between a Windows CE.Net client on a hand held device and an Apache server running a light SOAP Web Service. It wasn’t hard to write but the messages were specialized, so fell short of being a true RESTful implementation.

REST stands for REpresentational State Transfer and refers to an architectural style or pattern. In essence it describes clients served by services where state transitions or transfers in the client take place through the representation of a new state in the data returned by the service.

Web applications architected in this way have stateless servers and would typically map messages or web service requests onto the HTTP verbs GET/PUT/POST/DELETE.

At its core, my latest project http://www.far2muchmail.com/ , uses messaging between an Outlook desktop client and a web service. The web service is in PHP and not currently highly scalable. Over the last couple of years I’ve been using XML-RPC and make extensive use of this for messaging between my Outlook plug-in and the web service. However, I’m thinking about making a more RESTful approach.

But XML-RPC is cool. It is well supported by the guys at http://www.xml-rpc.com/ and others around the world. It provides remote execution interoperable between .Net and PHP and many others like Perl, Python, Ruby, Objective C... I really love it.

Client side under .Net, its asynchronous so you need to think about a RESTfully and this is typically how I use it.

So what’s wrong with XML-RPC, it certainly works for http://www.far2muchmail.com/.

Well it does now. However, XML-RPC has a few niggles. First it’s bound to HTTP, not really a problem but it might be if I want to move my services inside the cloud.

XM-RPC is also a bit verbose – the XML message that is. And it gets worse with binary data. This also leads to weak implementations and misinterpretation of the protocol. So if you want to talk to a public service, you may have to code for that particular implementation.

So, if you want to move to a more scalable service architecture, XML-RPC may not be your first choice.

REST based on HTTP verbs is now well established, very lightweight and simple to interpret. With the big players like Microsoft, Google and Amazon adopting the RESTful approach and providing a REST interface to anything that moves, it may be time to start thinking RESTfully.

And as REST builds momentum we are going to see a lot more services out there that speak to REST clients, including services hosted in the cloud (Cloud Services). This should mean that in the near future you should be able to benefit from high scale platforms running scalable services, on premise and in the cloud, ranging from business application services through to storage and bus and communication services... all speaking RESTfully.

So for me at least, I think it is worth taking a more RESTful approach.

"Better to say nothing and be thought a fool..."

[Abstract/Important] "Better to remain silent and be thought a fool than to speak out and remove all doubt." - I read this on one of my colleague’s Skype. Made me wonder ‘why do people say this sort of thing?’ and I was reminded, this is something my Dad used to say to me.

I guess some people say this because they believe it to be true. Seems reasonable, maybe that’s why Dad used the phrase. Sometimes people use the phrase because they have nothing better to say – now that’s perverse.

Although not every topic attracts or even deserves debate, I believe that if a debate is offered, one almost has a duty to present one's views. More so, at the risk of saying something foolish, in any debate of weight, whether or not your view is solicited, you must speak up. To do otherwise is indeed foolish.