Archive for category PaaS

AWS leads in PaaS v.Next

One of the most popular posts on CloudComments is the year old Amazon Web Services is not IaaS, mainly because people search for AWS IaaS and it comes up first. It does illustrate the pervasiveness of the IaaS/PaaS/SaaS taxonomy despite it’s lack of clear and agreed definition — people are, after all, searching for AWS in the context of IaaS.

Amazon, despite being continually referred to by analysts and the media as IaaS has avoided classifying itself as ‘just’ IaaS and specifically avoids trying to be placed in the PaaS box. This is understandable as many platforms that identify themselves as PaaS, such as Heroku, run on AWS and the inferred competition with their own customers is best avoided. As covered by ZDnet earlier this year,

“We want 1,000 platforms to bloom,” said Vogels, echoing comments he made at Cloud Connect in March, before explaining Amazon has “no desire to go and really build a [PaaS].”

(which sort of avoids directly talking about AWS as PaaS).

As an individual with no affiliation with analysts, standards organisations and ‘leaders’ who spend their days putting various bits of the cloud in neat little boxes, I have no influence (or desire to influence) the generally accepted definition of IaaS or PaaS. It is, after all, meaningless and tiresome, but the market is still led by these definitions and understanding AWSs position within these definitions is necessary for people still trying to figure things out.

To avoid running foul of some or other specific definition of what a PaaS is, I’ll go ahead and call AWS PaaS v.Next. This (hopefully) implies that AWS is the definition for what PaaS needs to be and, due to their rapid innovation, are the ones to look at for what it will become. Some of my observations,

  • AWS is releasing services that are not only necessary for a good application platform, but nobody else seems to have (or seem to be building). Look at Amazon DynamoDB and Amazon CloudSearch for examples of services that are definitely not traditional infrastructure but are fundamental building blocks of modern web applications.
  • AWS CloudFormation is the closest thing to a traditional PaaS application stack and although it has some gaps, they continue to innovate and add to the product.
  • Surely it is possible to build an application platform using another application platform? Amazon Web Services (the clue being in the ‘Web Services’ part of the name) provides services that, in the context of modern application architectures, are loosely coupled, REST based and fit in perfectly well with whatever you want to build on it. It doesn’t make it infrastructure (there is no abstraction from tin), it makes it platform services which are engineered into the rest of the application. Heroku, for example, is a type of PaaS running on the AWS application platform and will/should embrace services such as DynamoDB and CloudSearch — architecturally I see no problem with that.
  • The recent alignment of Eucalyptus and CloudStack to the AWS API indicates that AWS all but owns the definition of cloud computing. The API coverage that those cloud stacks have supports more of the infrastructure component for now and I would expect that over time (as say Eucalyptus adds a search engine) that they would continue to adopt the AWS API and therefore the AWS definition of what makes a platform.

What of the other major PaaS players (as put into neat little boxes) such as Windows Azure and Google App Engine? Well it is obvious that they are lagging and are happy (relieved?), for now, that AWS is not trying to call itself PaaS. But the services that are being added at such a rapid rate to AWS make them look like less and less attractive platforms. Azure has distinct advantages as a purer PaaS platform, such as how it handles deployments and upgrades, and Azure has a far better RDBMS in SQL Azure. But how do application developers on Azure do something simple like search? You would think that the people who built Bing would be able to rustle up some sort of search service — it is embarrassing to them that AWS built a search application platform first. (The answer to the question, by the way, is ‘Not easily’ — Azure developers have to mess around with running SOLR on Java in Azure). How many really useful platform services does AWS have to release before Microsoft realises that AWS has completely pwned their PaaS lunch?

I don’t know what the next platform service is that AWS will release, but I do know two three things about it. Firsty, it will be soon. Secondly it will be really useful, and lastly, it won’t even be in their competitors’ product roadmap. While there is still a lot to be done on AWS and many shortcomings in their services to application developers, to me it is clear that AWS is taking the lead as a provider of application platform services in the cloud. They are the leaders in what PaaS is evolving into — I’ll just call it PaaS v.Next.

Simon Munro


Leave a comment

ALM on IBM SmartCloud

IBM announced the PaaS component of SmartCloud. It will be available from ‘qualified IBM Business Parters’ from ‘early 2012′.

There is little buzz on the IBM cloud stack, probably due to it being fairly closed and only available from the channel. I also can’t really say much about how it measures against other cloud stacks, although it does seem to be a WebSphere oriented with a DB2 database. There probably is some cloud washing going on, but until people have had some hands on experience and report back, we won’t really know.

What I did find interesting and worthwhile pointing out is that the Rational ALM products are part of the offering. To me this is a big indication that PaaS is moving out of the startup culture to a more enterprise friendly set of tools. While rolling your own ALM tools with Github, Jira and self maintained CI environments may be cool and the current trend, it doesn’t lend itself to an integrated platform that can provide all that is needed. Amazon doesn’t have anything for ALM and Microsoft Team Foundation Server (TFS) still doesn’t run as an Azure service. TFS and similar tools are non trivial to set up, require ongoing maintenance and should be offered as a service.

Enterprises have different software development practices (read: needs) to the current users of cloud platforms. Whether those practices exist because they have been buying software from IBM, or because they have different complexities is an open debate (although I think it is a combination of both). The fact remains that ALM (and the ‘Rational’ stuff of task and requirements management) is a big deal for enterprise development shops – so a PaaS offering that has these familiar tools helps the management transition. Coupled with integration with existing management and monitoring tools (IBM Systems Director and Windows Azure/SCOM) the new breed of proprietary PaaS products that integrate with existing process and monitoring will get the attention of the IT director.

So while OpenStack and CloudFoundry argue about what should be in the application stack they are ignoring the broader needs such as ALM. Established vendors (IBM. Microsoft, Oracle) may sweep the floor with their existing arsenal of products that are (hopefully but unlikely) engineered for PaaS platforms. There is also the risk that in a vacuum of solutions all the bad practices from enterprise development that are counter-cloud will find their way into cloud development practices and (shudder) architectures.

Simon Munro




Azure – All PaaSed up and no IaaS to go

There were two interesting events in the Azure world last week.
Firstly Joyent and Microsoft have partnered to port Node.js to Windows (and Azure). This is interesting because it lands slap bang in the middle of frenzied activity around server-side JavaScipt, using the JVM (or not), and the appreciation of frameworks for services by those who have been happy just with web frameworks (such as Django or Rails). I don’t see .NET enterprise developers dropping WCF and C# en masse to run stuff on Node.js, but perhaps if you hang out with the trendy kids then some of their lustre will rub off on you – this applies, I suppose, to individual developers and Microsoft themselves.
In other news 10Gen (I assume) has been building a wrapper for MongoDB that hosts MongoDB in an Azure worker role. I’m not quite sure how this will work (they talk about a hot standby with shared storage) in the MongoDB world where data is (preferably) not committed to disk immediately. Where Azure likes to recycle roles whenever it feels like it, it would seem that you have little choice but to always work in ‘safe mode’.
In both of these cases, I find myself wondering why anyone would bother running MongoDB or Node.js on Windows in general or Azure in particular. It reminds me of the AWS tech summit that I was at a couple of weeks ago where a Microsoft evangelist was telling everybody in the room that you can run Ruby on Windows. “Why bother?”, were the thoughts echoing around the room. The AWS crowd have their choice of OSs and the rubyists are happy without Windows, thank you very much.
There only two reasons why you would be interested in MongoDB or Node.js on Windows. Firstly, it is mandated from above (as in ‘enterprise standard’ or something) that you run Windows. But then surely those same ‘standards’ would mandate the use or SQL for storing data and I doubt Node.js has made it onto an enterprise architecture powerpoint slide yet. The second reason is because you have been locked in to the Azure platform and cannot run any other OS because it is simply not possible in the (Azure) datacentre. And this is where the strategy around Azure becomes confusing.
Quite simply,
If Azure intends to be more IaaS it has to run something other than Windows. If it can’t do that then it must become frikkin’ good at PaaS.
Obviously Linux will run on the Azure fabric shortly after hell has frozen over, so that is out of the question. Azure simply needs to get better at PaaS. It needs to add good platform features like scheduling, search capability, map reduce (Dryad) and native, performant NoSQL capabilities (as in more than one), rich monitoring (like New Relic) and recoverability tools. And it needs to add these features fast, with an AWS-like tempo – releasing meaningful features every single week instead of languishing with a feature set that has barely moved since launch.
Azure as PaaS is currently simply not good enough and getting involved with throwing IaaS scraps is confusing their brand, removing engineering focus from what is important and ultimately pushing developers to other platforms. They definitely aren’t getting Ruby/Python/Node.js developers to come rushing. So why bother?
Simon Munro


1 Comment

Containerised PaaS welcome to a new entrant

RedHat has finally stepped up to the mark with a bold challenge to the previously new entrance to the cloud party  Cloudfoundry with openshift . It’s targeting the same developer market as cloudfoundry .

I think this screen grab from the openshift home page pretty much sums up what it’s about:

openshift overview

Some familiar players there from the CloudFoundry flurry of announcements .

This should be fun to see how the Java/Ruby/php   developer community react.. The fragmentation of the PaaS container market place  means choices for the Java/Ruby/php    have just got hard . Nothing here for .NET that’s what Azure is for and at least for the .NET community their PaaS choices are pretty clear cut .

Grace Mollison

1 Comment

When is PaaS not PaaS ?

This week the Interweb has been a flutter with the excitement of the release of CloudFoundry . It does sound nice  but I feel that it  being touted as portable PaaS is not quite how it should be sold.

Never mind the fact that PaaS and IaaS are pretty much terms that are now long past their sell by date so to continue to use them  when you want to be ahead of the pack is a bit strange  as a marketing ploy anyway.

James (@jamessaull) made a succinct observation  when he said that CloudFoundry sounds like PaaS for service providers I have to agree. Forget the technology it’s how much actual work is needed to  feed & water the  solution . So if I find myself having to worry about the underlying plumbing it’s defiantly not  PaaS  as per the current dictionary definition. But if someone else was to host the plumbing for me and then all I have to worry about is my application then that’s a whole different scenario with a lot less support & maintenance.

In all this noise it seems some have forgotten that Microsoft have tried to meet this aim of you  not having to  worry about the plumbing ( ignoring the VM Role) with Windows Azure and yes they have a ‘cloud’ that can sit on your desktop for development purposes too.

I welcome another player to the park especially one touting openness but there are already players out there who shouldn’t be forgotten especially as they have a head start in winning the minds of large corporates whose requirements are quite different from those of the developer community.


Grace Mollison


Leave a comment

Cloudfoundry: Suspicious but hopeful

I remember getting a demo of CloudFoundry from @ewolff nearly two years ago when VMWare acquired SpringSource. I thought the “experiment” had be subsumed into vFabric until today:

To quote @swardley on twitter: “CloudFoundry on OpenStack built on an environment designed using OpenCompute – you can just feel the goodness.”

You know what? I feel just as energised about the announcements in the last week. However I feel the need to comment…

One. Recently OpenStack (and OpenCompute) have been really driving the game forward. I note that CloudFoundry is an open source project and not a Spring project. Cynically this would look like a cheap way to buy industry kudos by spinning off old IP going to waste.

Two. PaaS, to me, implies the following (using AWS Simple Queue Service as an example):

  • Increased value over IaaS usually through higher levels of abstraction. I have an API to create/remove queues and to add/remove messages. As a consumer I am not aware of how virtual machines, networks and storage are all orchestrated, scaled, patched etc.
  • Described by its service and not its components, and therefore billed for the utility of the service and not the components. I am billed for the messages sent/received and the bandwidth consumed.
  • An SLA. Of the Service not the components. If it is made up of VMs don’t let that leak through the abstraction.
  • A suite of management and monitoring capabilities that relate to the service and not the components. E.g. messages per second, queue length, latency etc.

SQS is just one example of many. But to build, multi-tenantise (yikes), operate, document, monitor, backup, recover, replicate across data centres in a high redundancy high availability, you-name-it-way is a very big distance from the original queuing technology it might be based on.

So, whilst I am thrilled to see the likes of MongoDB being part of CloudFoundry it is a very long way from a PaaS announcement surely? Let me qualify that. A very long way from PaaS from a consumer perspective. As a Service Provider it might help to have a set of standards and a broad cooperative ecosystem on which to help me construct a PaaS on top of of my IaaS. But as a consumer this does nothing as it leaves me with having to take the underlying technology and using all my skills in IaaS to construct the PaaS and a commercial model around it.

I look forward to blueprinted best practice telling me how to deliver CloudFoundry application platform services atop commodity compute utilities such as AWS / OpenStack. For example, how will I deploy, operate and commercialise Database as a Service using MongoDB as my kernel in a high availability, multi-tenant (you get the idea) fashion? How will I wire it up to the monitoring and billing engine and ensure true elasticity? How will I guarantee that it is isolated from other tenants?

This is the hard part and of course where the value in the “P” is.

Clearly this is a journey, and I want to be excited but I am struggling to see how we really got much further than IaaS with these announcements.

At best it sounds like vCloud for PaaS – i.e. an API spec for queuing as a service, database as a service etc.

1 Comment

Amazon Web Services is not IaaS

Update: A more recent follow-up to this post – AWS leads in PaaS v.Next

It is commonly accepted, when using the IaaS/PaaS/SaaS taxonomy, that AWS is clearly IaaS. After all, if you can run whatever you like on your favourite flavour of OS, then surely AWS is simply offering infrastructure? The common knowledge doesn’t seem to come from AWS themselves (although they don’t overtly deny it) and I have tried to find a document available on their website that classifies them as such. If you can find a document by AWS referring to their services as IaaS, then please provide a link for us in the comments.

This assumption results in interesting behaviour by customers and the rest of the market. Patrick Baillie from CloudSigma is running a series of posts ominously titled Death of the Pure IaaS Cloud where he takes a swipe or two directly at AWS and, using Amazon in his examples, concludes;

So, what might seem like a pretty innocuous decision for a cloud vendor to offer some PaaS alongside its core offering can actually mean less choice and innovation for customers using that cloud vendor.

While it is true that AWSs could, virtually without warning, release a new services that undermines one of the customers’ business models, that is only ‘unfair’ if the business committed to the platform making the incorrect assumption that AWS is pure IaaS.

Maybe there was a lot of IaaS in AWSs distant past, but since it has become mainstream it hasn’t been IaaS. As a user of AWS, I don’t see the bulk of their services as infrastructure. I see them as some sort of platform, if you will.

Take S3 (Simple Storage Service) for example. I interact with it using a proprietary API (from AWS) rolled up in my framework of choice and I don’t simply receive storage. I receive a good model of handling security tokens, object accessible via the web (via my own domain name), logging, 11 nines of durability, automatic multithreaded chunking of large files and, with the click of a button, a CDN thrown in. That is so far from storage infrastructure (logical disk or SAN) that it cannot be called infrastructure. EC2 may be considered the most infrastructure-y part of AWS, but there is a whole lot bundled with EC2 such as load balancing and autoscaling which makes EC2 less ‘virtual machine infrastructure’ than you would think.

The fear of AWS as the gorilla that locks customers into it’s platform and, by virtually owning the definition of cloud computing, be able to have huge growth and market penetration must be of concern to it’s competitors. Perhaps, as Patrick points out, it’s market dominance and business practices may negatively affect innovation and influence consumer choice. This is something that we are used to in IT with market gorillas such as IBM, Microsoft, Oracle, Google, Apple and even Facebook. We, as IT consumers, have learned to deal with them (maybe not Facebook yet) and we will learn to deal with AWS.

Competing with AWS by attacking their IaaS credentials will fail, they are simply not an IaaS vendor. These aren’t the droids you’re looking for, move along.

Simon Munro




Get every new post delivered to your Inbox.

%d bloggers like this: