Last September I was at a Microsoft virtualisation event watching a presentation by Gartner’s Thomas Bittman when something struck me. Its been bothering me on and off ever since. Bittman’s pitch was solid, but it was pretty much identical to Microsoft’s, which was near identical to an IBM deck I had seen the week before.
The consensus can be summed up roughly like so:
Cloud Computing = Virtualisation+Automation+Software as a Service (SaaS)+SOA evolution
But if Gartner, IBM, and Microsoft all agree on something… that’s a risk factor. there is a danger in consensus. WS-*, WS-*, WS-*.
In the intervening few months I have seen little to disavow me of the idea that many in the industry are over-complicating things when it comes to Cloud Computing. I have spoken to any number of CTOs, general managers and representatives of major systems vendors about Amazon Web Services. They invariably say things like AWS are “too simple”, or even “don’t really contain much intellectual property”. That, in short, not only would Amazon’s AWS EC2, S3 and SQS be easily replicable but they don’t tackle the right problems; that is – the really tough problems.
Amazon’s initial cloud offerings are instance rather than fabric-based and as such don’t involve a change in the programming model or style. An app isn’t going to scale linearly just because its deployed to AWS. Of course you’d have to be high to believe competitor claims that their own approach does allow transparent scaling of any app. To hear competitors talk though, Amazon might as well have an army of trained monkeys in a data centre somewhere running around provisioning servers and storage. As we all know though monkey armies don’t scale, even if they do create the odd work of genius. 😉
I have heard a very similar line before: IBM systems executives dismissing VMware, for example, or Windows before it, or Oracle before that, whatever the new technology was that would be replaced as soon as the going got tough. AWS just isn’t enterprisey enough. If you talk to web developers today though most would agree Amazon is an essential tool. And web methods are coming to the enterprise.
Incidentally, there are many similarities in the emergence of AWS and VMware. Both were developer-led. Both were reactions to a lack of responsiveness of operations staffs to the needs of developers. Both were initially positioned (by enterprise vendors at least) as test and development frameworks, rather than production environments.
The Complexify Pattern at REST
While I am not of the opinion that Service Oriented Architecture (SOA) is dead, clearly as an industry we got carried away with the attempt to establish a specific, common set of standards interfaces and protocols, defined from the top down, for integrating all types of applications. Everything was to be transactional, secure, ready to roll back.
We should probably not forget that XML Web Services began as a reaction to Corba-generation enterprise middleware complexity. Simple Object Access Protocol (SOAP) was straightforward enough to get things done. But as the arabesques of the WS-I stack became ever more baroque, building layer upon layer on top of SOAP, simplicity was left well behind in the desire to have an answer to everything, to model every use case, to provide interfaces for all seasons and reasons.
While there is a place for Big Architecture in IT, it shouldn’t be a necessity. You wouldn’t use a combine harvester to mow a lawn. You wouldn’t use a space shuttle to get to the shops. You wouldn’t build an airport to land a helicopter. But as an industry we are awesome at complexifying things.
Some things work though because they are simple, which brings us to Representational State Transfer (REST) an alternative development model to XML Web Services. While enterprise architecture astronauts were delighting in complexity, REST was taking hold. REST treats everything as a resource stored at a uniform resource indicator (URI, or a web link to you or me), which can be manipulated with a limited but powerful set of verbs (Get, Put, Post and Delete).
REST is peer to peer in terms of contract and web as agreement. Unlike WS-* Web Services the interface doesn’t tell you everything about how it can be used. REST really only needs one standard- HTTP.
But what is the equivalent in Cloud? What is the REST of the Cloud?
That’s what I have been trying to work out. I had a pretty funny run in with IBM Tivoli CTO Alan Ganek at IBM Pulse earlier this week about the question of REST of Cloud. I tend to hold a number of positions in my head simultaneously as I try and work out my position on things. But Ganek kept catching me contradicting myself. Alan- i am still thinking… forgive me 😉 My problem is that I don’t know the answers, but I do know there is a simplicity at work in AWS, which we are going to lose as we build out enterprisey clouds. What do we need to retain though?
Realising Simplicity: WOOing WOA
It has been intriguing to watch the evolving positions of Burton Group and Gartner with respect to SOA. Both firms were aggressive proponents of SOA but have recently been adjusting their market narratives. Gartner increasingly positions SOA as not delivering on its promises, largely because of the calcifying impact of the WS-* stack, putting forward Nick Gall’s Web Oriented Architecture (WOA) as an alternative. Burton’s Anne Thomas Manes recently declared SOA dead, although to be fair her argument was somewhat more nuanced than the headline. Please go to those sources – I certainly can’t claim to speak on behalf of Burton or Gartner.
So what if we run with a the idea of WOA in the cloud context?
Cloud is to Enterprise Operations as WOA is to SOA. What is cloud if not web oriented operations (WOO)? The question though remains- what is the REST of Cloud? That is, the simpler model which we will come to realise is just as appropriate as the more complex versions we see in traditional enterprise computing. Its hard to know how long it will to see the rise and fall of cloud complexity, but Amazon will likely continue to dominate WOO.
Is AWS the Rest of Cloud, or am I guilty of reductionism? Do I give Amazon too much credit for driving the Cloud model? I would say Amazon is the canonical instance-based service, while Salesforce.com is the canonical Cloud fabric, with its associated Apex language (a Java for the cloud era).
If we are to keep it simple stupid (KISS) what can WOO learn from WOA? [blimey- can’t you talk in English? Ed.] Rather than finishing this post with a grand conclusion I would rather maintain this as an open thread.
Talking of open threads, I had to chuckle last night when I saw a tweet from @jmettreaux. It seems Stu Charlton had transcribed a quote on a video podcast in which I put my position rather more strongly than I have here. This is what I said:
“If you think of the post-SOA term, from Nick Gall… Web Oriented Architecture, clearly this is somewhat different from SOA, although there are some patterns common to both of them….. Is the cloud Web-Oriented Operations, or WOO? (We have WOA and WOO)… and what IBM is saying is definitely not WOO, it’s business as usual, it’s just about flexible delivery of application — all the stuff that is goodness, all the stuff that Tivoli has been talking about since 1995. That stuff all has value, but it’s not Cloud. Cloud involves difference. Business as usual, that’s just provisioning service, and automation and virtualization, which is all good, but… if I hear another person tell me that CLOUD = SOA + VIRTUALIZATION + AUTOMATION, I’m going to ignore them and rubbish the idea as much as I can.”
Well why not say what you really think James? I tend to be a strong believer in Joel’s Law of Leaky Abstractions. I don’t think you make things “simple” and “seamless to the end user” simply by adding more abstraction layers. Simplicity requires that you cut stuff out, that you use simple stuff. Simple needs to be inherent. And instance-clouds are certainly simple.
Yesterday IBM announced deployment to Amazon Machine Instances, on which more later, but a twitted question from Dennis Howlett about portability really got the wheels turning. Instance Clouds are portable. Fabric Clouds are not.
Is there a REST of the Cloud? You tell me.