Warning – If you’re the sort of person who chokes on industry buzzwords, then the press release I just got from FatFractal (a pretty cool name for a company) will make you gag. Here’s the headline:

FatFractal announces ‘Cloud-in-a-Box’ allowing enterprises to install its “top rated” Platform-as-a-Service (PaaS) and Backend-as-a-Service (BaaS) platform in public or private clouds or traditional data centers

All we needed was a big data or internet of things reference in there and we would have struck the jackpot. But buzzwords aside, it’s actually worth taking a look at this announcement to see a growing realization about the success, or otherwise, of PaaS. First a quick roundup of what this is all about. Fat Fractal is a vendor that delivers a platform for mobile and web development – it allows polyglot development, mobile app creation, deployment to heterogeneous stacks and the like. Today it is augmenting existing products with an enterprise offering, new pricing and a release of it’s product into general availability.

All interesting stuff but what does it all mean, and why is it something  that portends the future of PaaS?

Over the past few weeks I have been doing a number of private briefing sessions on the PaaS landscape. These sessions have been delivered to a number of investment houses who are starting to think about what PaaS means for them, and whether they should be including PaaS vendors within their investment portfolios. As part of my presentation I’ve been giving a high level view of what PaaS is, detailing some of the different classes of PaaS, and laying out where I think PaaS will go in the future.

Coincidentally I came across a post the other day by RedMonk‘s Donnie Berkholz. In the post he made the very astute observation that:

Although I’m convinced PaaS is the future of development (see the last slide), the lack of traction vs IaaS as far back as Google App Engine makes it continually unclear exactly when that future will arrive for most of us. It’s certainly not next year, but will it be 5 years, 10 years?

At this point, I would argue that any vendor pushing a PaaS is doing one of a few things:

  • Thinking about the long term rather than the next few quarters;
  • Thinks it’s large or influential enough to create its own market; or
  • Simply shipping software it uses for internal productivity.

Now I’m a huge fan of PaaS. it is, after all, yet another chance to abstract non-core activities away from organizations. But despite being bullish on it (and, for full disclosure, despite being an Adviser to Stackato, a PaaS vendor) the fact of that matter is that PaaS hasn’t got the early traction that many of us would have liked to have seen. There’s a number of reasons for this, platform immaturity, fears of vendor lock-in, doubt about what PaaS actually is etc.

Which gets us back to FatFractal who are delivering a solution that, despite blurring the lines as to what actually constitutes a PaaS, is probably a better fit for the marketplace. In making this claim I’m reflecting on what I hear from my enterprise friends – they don’t want to use a PaaS per se – rather they want to find a solution that helps them to create applications, enables them to build for mobile from the outset, eases the operation burden of application management and, yes, do all this within their organizational constraints, which often means within the four walls of their data center. So put together the discrete parts of what FatFractal does: Mobile Backend as a Service with all the plumbing for user management, notifications integrations, PaaS deployment giving auto scaling etc and with deployments to either public or private clouds (on-prem or otherwise).

It’s a compelling proposition and one which is going to continue as PaaS vendors remain squeezed for real revenue success. The recent acquisition of AppFog by Savvis that was labeled by many as an escape shute for the beleaguered PaaS vendor should be warning to other vendors that pure play PaaS isn’t sufficient – rather a platform that ties together all the end to end requirements that developer teams have is needed.

FatFractal may be a dog of a product and may crash and burn in the marketplace – but the changes that FatFractal heralds are, I believe, ones that the PaaS sector at large will follow over the months and years ahead.

Ben Kepes

Ben Kepes is a technology evangelist, an investor, a commentator and a business adviser. Ben covers the convergence of technology, mobile, ubiquity and agility, all enabled by the Cloud. His areas of interest extend to enterprise software, software integration, financial/accounting software, platforms and infrastructure as well as articulating technology simply for everyday users.

7 Comments
  • Many cloud platforms and services are proprietary, meaning that they are built on the specific standards, tools and protocols developed by a particular vendor for its particular cloud offering.

  • Hi Ben,

    Great post! – and thanks for the mention, I’m delighted we caught your attention 🙂

    Great to see you being so positive about our direction – your point about a
    “solution that helps them to create applications, enables them to build for mobile from the outset, eases the operation burden of application management and, yes, do all this within their organizational constraints”
    matches pretty much exactly with how we at FatFractal see the needs of the enterprise.

    In the past I’ve worked at several huge companies and one of my personal objectives when co-founding FatFractal was to offer to my many enterprise friends the type of power, speed and flexibility of development which is provided by the public cloud services / tools / platforms.

    Cheers

    – Gary

    PS I wrote a blog back in February that you might be interested in – http://fatfractal.com/prod/paas-baas-what/ … I’ll be posting again in the next week or so talking in more detail again about where we are right now, and what’s coming in the months ahead.

  • Utilising Platform as as Service (PaaS) for developers has many advantages. However, a major concern for any organisation considering adopting PaaS is avoiding vendor lock-in. A number of efforts are under way to define standards for cloud computing which will help avoid vendor lock-in. Some recent announcements of new Java PaaS offerings started me thinking how Java standards, rather than cloud standards, are helping define the platforms vendors are offering Java developers. If these platforms comply with the Java standard then vendor lock-in is avoided.

  • This type of PaaS does not include hosting as such, rather it provides open source software to allow a PaaS provider to run applications. For example, AppScale allows a user to deploy some applications written for Google App Engine to their own servers, providing datastore access from a standard SQL or NoSQL database. Some open platforms let the developer use any programming language, any database, any operating system, any server, etc. to deploy their applications.

  • When you start to build your application, you have to plan your target deployment platform because there is no standard similar to Java EE. If you are using PaaS then you have to use the API /SDK provided by the PaaS vendor. Next, I will examine PaaS offerings from a few popular vendors.

  • When you start to build your application, you have to plan your target deployment platform because there is no standard similar to Java EE. If you are using PaaS then you have to use the API /SDK provided by the PaaS vendor. Next, I will examine PaaS offerings from a few popular vendors.

  • Google’s App Engine provides a fully integrated development and testing platform which supports the following three programming languages: Go, Java and Python, including their requisite run-time environments. The Google App Engine also provides data access via their Datastore offering, which enables data storage and data retrieval for applications built using the Google App Engine. While Google’s App Engine provides an adequate platform for software developers who want to build SaaS solutions for a minimal cost, it fails to provide a full featured solution that ISV’s (independent software vendors) require to build, test, deploy and maintain SaaS solutions. Furthermore, Google’s App Engine does not support the various Microsoft technologies that so many organizations have heavily invested in, which creates a roadblock for the migration of on-premise solutions built upon Microsoft technologies to the cloud.

Leave a Reply to Jackie CamposCancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.