{"id":1847,"date":"2009-02-12T16:11:48","date_gmt":"2009-02-12T16:11:48","guid":{"rendered":"http:\/\/www.redmonk.com\/jgovernor\/?p=1847"},"modified":"2009-02-12T16:11:48","modified_gmt":"2009-02-12T16:11:48","slug":"the-rest-of-the-cloud","status":"publish","type":"post","link":"https:\/\/redmonk.com\/jgovernor\/the-rest-of-the-cloud\/","title":{"rendered":"The REST of The Cloud"},"content":{"rendered":"

Last September I was at a Microsoft virtualisation event watching a presentation by Gartner\u2019s Thomas Bittman<\/a> when something struck me. Its been bothering me on and off ever since. Bittman\u2019s pitch was solid, but it was pretty much identical to Microsoft\u2019s, which was near identical to an IBM deck I had seen the week before.<\/p>\n

The consensus can be summed up roughly like so:<\/p>\n

Cloud Computing = Virtualisation+Automation+Software as a Service (SaaS)+SOA evolution<\/p><\/blockquote>\n

But if Gartner, IBM, and Microsoft all agree on something\u2026 that\u2019s a risk factor. there is a danger in consensus. WS-*, WS-*, WS-*.<\/p>\n

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 \u201ctoo simple\u201d, or even \u201cdon\u2019t really contain much intellectual property\u201d. That, in short, not only would Amazon\u2019s AWS<\/a> EC2, S3 and SQS be easily replicable but they don\u2019t tackle the right problems; that is – the really tough problems.<\/p>\n

Amazon\u2019s initial cloud offerings are instance rather than fabric-based<\/a> and as such don\u2019t involve a change in the programming model or style. An app isn\u2019t going to scale linearly just because its deployed to AWS. Of course you\u2019d 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\u2019t scale, even if they do create the odd work of genius. \ud83d\ude09<\/p>\n

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\u2019t 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.<\/p>\n

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.<\/p>\n

The Complexify Pattern at REST<\/h1>\n

While I am not of the opinion that Service Oriented Architecture (SOA) is dead<\/a>, 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.<\/p>\n

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.<\/p>\n

While there is a place for Big Architecture in IT, it shouldn\u2019t be a necessity. You wouldn\u2019t use a combine harvester to mow a lawn. You wouldn\u2019t use a space shuttle to get to the shops. You wouldn\u2019t build an airport to land a helicopter. But as an industry we are awesome at complexifying things.<\/p>\n

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<\/a> (Get, Put, Post and Delete).<\/p>\n

REST is peer to peer in terms of contract and web as agreement. Unlike WS-* Web Services the interface doesn\u2019t tell you everything about how it can be used. REST really only needs one standard- HTTP.<\/p>\n

But what is the equivalent in Cloud? What is the REST of the Cloud?<\/p>\n

That\u2019s 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\u2026 forgive me \ud83d\ude09 My problem is that I don\u2019t 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?<\/p>\n

Realising Simplicity: WOOing WOA<\/h1>\n

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\u2019s Web Oriented Architecture<\/a> (WOA) as an alternative. Burton\u2019s Anne Thomas Manes recently declared SOA dead<\/a>, although to be fair her argument was somewhat more nuanced than the headline. Please go to those sources \u2013 I certainly can\u2019t claim to speak on behalf of Burton or Gartner.<\/p>\n

So what if we run with a the idea of WOA in the cloud context?<\/p>\n

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.<\/p>\n

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).<\/p>\n

If we are to keep it simple stupid (KISS) what can WOO learn from WOA? [blimey- can\u2019t you talk in English? Ed.] Rather than finishing this post with a grand conclusion I would rather maintain this as an open thread.<\/p>\n

Talking of open threads, I had to chuckle last night when I saw a tweet from @jmettreaux<\/a>. It seems Stu Charlton had transcribed a quote<\/a> on a video podcast<\/a> in which I put my position rather more strongly than I have here. This is what I said:<\/p>\n

“If you think of the post-SOA term, from Nick Gall… Web Oriented Architecture<\/a>, 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.”<\/p><\/blockquote>\n

Well why not say what you really think James? I tend to be a strong believer in Joel\u2019s Law of Leaky Abstractions<\/a>. I don\u2019t think you make things \u201csimple\u201d and \u201cseamless to the end user\u201d 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.<\/p>\n

Yesterday IBM announced deployment to Amazon Machine Instances, on which more later, but a twitted question from Dennis Howlett<\/a> about portability really got the wheels turning. Instance Clouds are portable. Fabric Clouds are not.<\/p>\n

Is there a REST of the Cloud? You tell me.<\/p>\n

disclosure: Before I sign off I just want to thank my office share pals at Bash Studio – Matt Patterson<\/a> and James Stewart<\/a> for inspiring this blog. The REST of the Cloud- they provided the title.<\/p>\n","protected":false},"excerpt":{"rendered":"

Last September I was at a Microsoft virtualisation event watching a presentation by Gartner\u2019s Thomas Bittman when something struck me. Its been bothering me on and off ever since. Bittman\u2019s pitch was solid, but it was pretty much identical to Microsoft\u2019s, which was near identical to an IBM deck I had seen the week before.<\/p>\n","protected":false},"author":5,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"spay_email":"","footnotes":"","jetpack_publicize_message":"","jetpack_is_tweetstorm":false},"categories":[1],"tags":[],"class_list":["post-1847","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"jetpack_featured_media_url":"","jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p9wfjh-tN","_links":{"self":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/posts\/1847","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/comments?post=1847"}],"version-history":[{"count":0,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/posts\/1847\/revisions"}],"wp:attachment":[{"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/media?parent=1847"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/categories?post=1847"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/redmonk.com\/jgovernor\/wp-json\/wp\/v2\/tags?post=1847"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}