PaaS: A mid-2010 survey

I’ve said in the past that I am a hands-off type of guy when it comes to servers. To avoid dealing with servers in any traditional sense, I have been keeping an eager eye on how things are going with server-side JavaScript, and the push-to-deploy type of application development (Heroku, Joyent Smart Platform). But there’s something relatively new in the offing, which claims to do away with code entirely – the Platform-as-a-Service (PaaS) company. You might have heard of some – LongJump, Force.com, Zoho Creator, QuickBase (there’s a longer list at the bottom of the post).

In general, people who label themselves with “PaaS” want to do two things: reduce your dependency on coders, and give you a shortcut to setting up business online. Reasonably appealing, you might think? I’ve been giving the PaaS sector a bit of a once-over in the last couple of weeks, and this is an attempt to piece together half-formed conclusions about what PaaS is and whether it is useful to me.

Rapid recommendation

If you don’t have time to read the rest of this article, then here’s my advice:

  • if you are at the non-technical end of the scale, with no access to designers and developers, and you don’t care about the way your apps will look, PaaS will help you open up your company information for visualising and editing; changes can be set up to trigger other changes and notifications, and you can schedule reports
  • if you are a professional web designer and developer, you are likely to become frustrated at the unresponsive tools used to create PaaS apps, and the barriers to designing the experience of the people using your app

A motivating problem

This survey was prompted by the familiar need for a pair of hands to help build a system that neither myself nor my partner felt capable of building well. If I give you an outline of what the system roughly looks like, it ought to set my opinions of PaaS in context.

Essentially, we want to make a website handling information about people and the properties they live in. There are public areas for browsing and private areas for people with accounts. Plenty of design has gone into the appearance and function. There are some web services in the mix – PayPal, a booking system I wrote in server-side JavaScript, and EchoSign. Interactions with the website and notifications from foreign systems need to have effects, manipulating the people and property information.

I think that what I have just described sounds like a very generic web application. Some bits require more know-how than we possess to build: how to write and manage workflows, which link events and notifications to effects; what our data stores should look like and where they should be relative to the website and its contents; how to get our system to respond to notifications from foreign systems; and how to serve the product to multiple customers and charge for it.

I don’t recall what prompted me to look at PaaS, but the PaaS companies I first looked at made a big deal about how you can easily model company data structures and create workflows between them. This sounded great. So I went about having a long look at what was out there and whether it would be cheaper and easier to build my app on top of that.

What does PaaS claim to do?

In general, PaaS companies want you to model your business and its processes as objects on their platform, with various properties hanging off the objects (think Salesforce.com and its tabs). You create forms that open up the system to let people add and amend data, and you hook workflows on to triggers such as the submission of a form. The example that everyone seems to use is an expenses approval system, with Bob, his manager, his manager’s manager and Lynne from accounts, ploughing through the process of dealing with Bob’s $5000 business trip claim.

Once you’ve configured a PaaS app to model whatever it is you want to model, you can publish the app to the world, often as something that other people can buy and customise for themselves and their own businesses.

Variations around this theme include companies devoted to: creating complex workflows; providing sets of micro-services; pain-free hosting for code.

General characteristics of PaaS

Without giving what would probably be a boring account of all the companies I looked at, there are several axes along which PaaS seems to range which it is worth looking at. I’ve picked out a couple of example companies that fall along each axis.

Building a business

Several PaaS companies highlight your ability to use their platform to run a business. That can mean several things: you use the app you make to help run your business; you use the app as a part of your own customers’ experience; you run a business selling the app to other companies to use with their customers. Some companies cater for all these scenarios, others specialise in one or two.

If you’re building an application to use with all your customers, it makes sense to make it a multi-tenanted system – that is, the different customers all log-in to the same app, but see whatever is appropriate to them. If you are building an app that other businesses will sell to their customers, you’ll want something a level deeper – multi-tenancy within multi-tenancy (erm, Inception?).

Apps for your own use: Zoho Creator, TrackVia, Iceberg
Build your shop: Caspio Bridge, Wolf Frameworks
Shop-within-a-shop: WorkXpress, Rollbase, LongJump

Technical accessibility

If you’re a no-hoper when it comes to HTML and you’ve never heard of PHP, there are PaaS products for you. They will help you model your business and its processes and do helpful things like sending you emails when your tasks are late.

Equally, some products require someone versed in the vagaries of Microsoft systems integration to get anything out of them. However, if you have the requisite knowledge, you could be integrating with your Active Directory or performing complex database queries to help the system make decisions.

Anyone could do it: TrackVia, WorkXpress
You’ve just come off a web dev course: Zoho Creator, BlankSlate, Iceberg
You’ll need a seriously hardcore dude: Skelta, LongJump

Access to the bare metal

If you’ve ever used Salesforce, you’ll know that almost every Salesforce app looks the same. This is not an adequate level of control over the experience. Ideally, a PaaS product should give you – the app developer – enough power to control your customers’ and their customers’ experience (hopefully whilst providing tools to make this easier than coding from scratch). Some companies have a stab at this (even if they don’t make it very easy), others lock the experience down.

Complete control: BlankSlate, LongJump
Not quite like putty: Zoho Creator, Rollbase, WorkXpress
You do it OUR way!: Skelta, Iceberg

Presentation: AJAX vs. templates

This is not PaaS’ strong point. It seems very few PaaS companies expect there to be a presentation layer beyond Salesforce.com-style tabs and tables, which is a shame.

You can pretty much take it for granted that online products provide API access to read & write your data. PaaS products are online products and that assumption seems to hold good with most of them. This of course means that you can create experiences all of your own by writing AJAZy mashups. This isn’t ideal in practice, as it leaves the non-JavaScript browser without an experience at all, not to mention that AJAZ-heavy apps are unlikely to function appropriately on a mobile; SEO and accessibility are concerns as well. Unfortunately, some PaaS companies actively promote this method.

You could employ an app developer to use the PaaS API’s as a substitute data store, but this approach does seem a little odd given that a stated aim is to take the developers out of the process, but anyway…

The PaaS companies who have their heads screwed on correctly, manage your presentation layer using templates, interpreted on the server. However, you are often straitjacketed into using a particular layout. It would be a valid PaaS model to offer you an easy way to hook in a presentation layer of your choice, and since an app’s appeal very often benefits from decent visual presentation, this model could look very attractive.

AJAZ-only is the way: Wolf Frameworks, BlankSlate, Caspio Bridge
Templated goodness: LongJump, Zoho Creator

But does any of this suit?

My overall impression from looking at around twenty-five PaaS companies, and deeper at a dozen, is that everyone wants you to think their way, and that even though webby people are generally supportive of open data, there is something very “lock-in” about the way you put these applications together. This includes the feeling that you have to get into their developers’ heads to understand how you should construct an application; that your application is really just tweaking something that’s been set up in advance, both functionally and visually; that no-one wants to play nicely with any other tool-providers out there.

Then there’s the question of whether the objects/properties/process model is as straightforward a mapping of the real world as is claimed. Even if an entire business can be abstracted to these bare elements, the difference between two businesses is more than skin-deep, and so this abstraction feels hollow. I am troubled by the observation that I struggled to find any examples of PaaS offerings backing good public websites and services. Only BlankSlate had anything attractive and functional to show, and they had integrated with existing websites (BlankSlate are entirely focused on providing APIs).

The main advantage to the craft of web development and web design is that you are free to imagine any types of interaction and see those brought to life. You design and create both public and private areas, and hand-code the logic that links the two. Normally, this involves a creative and complex response to a client’s problem – a design process.

I think that the experience of use, which is the end result of a design process, is the most important facet of an online system. In my opinion, PaaS companies are neglecting this, and they appear to imagine their customers want to build applications for robots. Even if a PaaS app is only destined to be used inside a business (which it would appear they are in the vast majority of cases), that is no excuse for a bad experience. Haven’t big-company employees been complaining about the state of their corporate IT for decades?

Web development by web developers is something approached with a toolbox. What makes a tool? Something that is self-contained and has its part in the bigger job – a favourite framework, or an image editor, for example. The tools work together to turn stuff into useful stuff. PaaS is supposed to be bringing the experience of creating application development to the people who are coming up with the needs for them – “business” people. Most PaaS products do not look like a toolbox, but a single, infinitely complex tool. And when an app is built, it’s likely the people using it will be doing so through the tool used to build it i.e. itself.

Something’s gone wrong here.

So what do I want?

Here’s my shopping list for PaaS:

I want the typical PaaS setup to resemble a toolbox, full of useful things that you use to create experiences. The output is not just the tool, reconfigured.

I don’t want to fight with my tools – they should be tuned to the context they will be used in and they should respond to my touch (laggy interfaces are a massive turn-off).

The best (web) tools are those you can extend in a modular way with plugins. They play nicely with other tools, exporting and importing files in standard or commonly-used formats. People get passionate about them, because they let you exercise your craft.

Tools should talk JSON (or, if necessary, XML). While we’re on the J-subject, JavaScript is spoken by many, and JavaScript on the server got hot a while ago – if you want to empower less-technical people, start supporting it.

Everything you create should have a URL and behave as a RESTful resource. Then people can do cool things with their resources you didn’t expect.

Notifications over HTTP is the underpinning of workflow. The thinking behind Web Hooks is very appealing – systems talking to little blobs of code on the web. This keeps things nice and open.

Open source used as a learning process: almost everything a person makes is not worth hiding and definitely worth sharing. In an environment where people are working with similar systems, open source will make people make better things (we don’t have to be talking code – process, procedure, example are all good).

Finally, don’t try to do everything. Not everyone needs to write their own process editor or form maker, nor do they need to invent their own cloud or firewall.

The companies

This does not include everyone who thinks they are doing PaaS (Google App Engine and Heroku are not on my list). My investigation was focused on developing applications with less technical skills, but I’m mentioning all the PaaS-esque companies I found in case they are useful to someone. In no particular order…

Generally convincing

TrackVia
BlankSlate
Zoho Creator
Rollbase
Iceberg
SnapLogic
Skelta
Wolf Frameworks
LongJump
WorkXpress

Generally unconvincing

Caspio Bridge
WyaWorks
QuickBase
Ragic
WaveMaker
BungeeConnect
ProcessMaker
Microsoft Dynamics
AppPad
Force.com
Google Scripts
DabbleDB
tarpipe
Boomi AtomSphere
Informatica Cloud
Hubspan
Cast Iron OmniConnect
ElasticApps

Advertisements

4 Comments

  1. Posted August 24, 2010 at 8:48 pm | Permalink

    Hi Jonathan, great summary thanks for your insights. As a vendor it is often hard to maintain an unbiased view of the market and our competitors — analysis like this helps.

    Regards,
    Matt (CEO, Rollbase)

  2. Posted August 29, 2010 at 6:32 pm | Permalink

    Jonathan,

    Great reading. I could not agree more. As a small business owner who has been looking for the right solution to build and deploy a web application since 2008 I know the frustration over the current state of offerings.

    Some items you did not mention that I think are also very important are:

    1. Reliability – I have seen Coghead and now recently DabbleDB go away, which feeds into my concern about “here today gone tomorrow” providers.

    2. Branding – Wow, I cannot believe how the current providers just cant seem to get this right as well as understand how important it is. Who wants to develop an application that has SOMEONE else’s name plastered all over it????

    3. Cost/DB size and storage – I think all paas providers are missing the mark when it comes to how much they charge and what exactly they charging for. Most providers offer a truly paltry amount of storage with their offerings.

    • Posted October 18, 2010 at 8:52 am | Permalink

      Hi Jose,

      I completely agree with your points, PaaS seems to answer a lot of challenges but it can be hard to find a vendor that reliably checks all the boxes.

      You might be glad to know that Iceberg has a good answer to all 3 of yours points.

      1. Fractis (the company behind Iceberg) has been in business for 5+ years, is profitable and not dependent on investors or a changeable market.

      2. You can completely change the branding and design of Iceberg

      3. We don’t charge by database size.

      If you are interested in talking further and getting a deeper look at Iceberg please email me at wayne@geticeberg.com

      Wayne (CEO – Iceberg)

  3. Posted February 8, 2011 at 2:51 pm | Permalink

    Hi Jonathan,

    Great post! For us, paas companies, it’s crucial to know how the final user feels at the end of the day, not only the final user, but also the developer.
    In our company we try to performance a good balance between technical approach and WYSIWYG, we have blurred that step by creating our own scripting language, that can be imported onto the application.

    Cheers,
    Rafael (Analyst – Pengower)