Democratizing Development – Where PaaS Should Go

A few months ago I wrote a post that looked at application development, and the existing tools that help bring the ability to develop software to an entire audience that formerly didn’t have the ability. Over the past five or six years I’ve grown increasingly excited about Platform as a Service (PaaS) and its ability to remove some of the more “mundane” aspects of application development and operations from the responsibility of the developer. The traditional view of what constitutes a PaaS, is fulfilled by products such as Heroku, EngineYard and Cloud Foundry – essentially these tools do an excellent job of allowing developers to code their applications, and thereafter run them without worrying about wrangling the practicalities of servers, load balancers, security and the like.

It strikes me however that, valuable as traditional PaaS is, it allows developers to be more productive and efficient, but it doesn’t do much to democratize the actual development process. If the very same people who were creating software before are the ones doing so now, we haven’t really come a long way. Especially not when one considers PaaS is one of the triumvirate of services generally shown in the cloud computing pyramid – along with Infrastructure as a Service and Software as a Service, IaaS and SaaS respectively – cloud computing is all about democratization. SaaS has resulted in businesses being able to do stuff they simply couldn’t before, IaaS means even the smallest startup can now afford world class infrastructure. meanwhile PaaS, as we’ve known it, does great things for efficiency, but little else.

It was this fact that encouraged me to segment the PaaS market into a couple of different categories – Infrastructure PaaS (iPaaS) is the category that covers all of the aforementioned vendors – it allows developers to do what they do in a more efficient way, and stop worrying about the realities of IT operations. Application PaaS (aPaaS) on the other hand is a very different beast. It is a data-centric platform that is tuned to allow average business users to build applications that are centric to the core business data they already use. In the example of Force.com, perhaps one of the oldest and best-known iPaaS vendors, this means that a business analyst can conceivably build an application that is based upon their core CRM data. Of course it goes without saying that all the infrastructure on which this application sits is automatically managed by the platform itself.

This higher level of PaaS really does make a difference within an enterprise. In the old days, a business that wanted to, for instance, create a custom application that integrated with its ERP or CRM, would have needed to engage a developer with a deep understanding of both development languages and the hooks into the software package being integrated with. With aPaaS that is no longer the case. The platform itself is built upon the application and hence is already integrated with the core data the organization is trying to use. The language is easy enough for most business people to use and hence they do, creating applications at will.

Of course there are a couple of problems with this sort of democratization, the first being that “real” developers dismiss these “light weight” platforms as being toys that aren’t for real software development – it’s a similar reaction to that which skeptics gave Visual Basic when it was first introduced. But, in the same way that Visual Basic brought development to a new class of user, so too does aPaaS. The second problem with these sort of aPaaS offerings is that, by definition, they tend to be highly proprietary and hence create a high degree of customer lock in. In this day and age when application and infrastructure portability is garnering widespread attention, highly proprietary platforms sometimes sit a little uncomfortably with organizations.

Which brings us to a new approach, a plain language approach towards application development that doesn’t even feel like development. In recent months, fuelled by the ever increasing plethora of services that are readily integrated by virtue of their public facing Application Programming Interfaces (APIs), we’ve seen the creation of a number of platforms whose very purpose is to allow users to connect service A with service B and create some workflow between the two. The ideas of services such as IFTTT and Zapier, is that they both allow application integration to occur, but that also workflow around the integrations is enabled. While it’s not development in the traditional sense of the word, it’s a definite proxy for some development tasks. Best of all however is that it’s easy for anyone to use – no developer skills needed.

The other direction that development democratization is occurring from is natural language. Recently researchers at MIT reported that some simple tasks – manipulating word-processing documents and spreadsheets – can be manipulated in ways that previously needed programming skills. Even more interestingly the researchers’ methods could potentially prove applicable to more general programming tasks. The researchers used a trained computer system to convert natural-language descriptions into “regular expressions”. In the same way that SIRI manages to understand a common language query and give an appropriate response, systems can begin to translate natural language expressions into code.

The cloud computing cognoscenti continue to obsess on the details – the minutiae of Amazon Web Services‘ latest product offering, or whether OpenStack is going to be the cloud operating system of choice or some other issue of major import to a handful of pundits. Meanwhile there are a massive number of organizations and individuals who simply want to get stuff done, to create applications that meet their organizational needs. These hyper-democratizing development solutions may not have the cachet of the better known options, but their impact is likely to more than make up for that.

 

3 Comments
  • Well, I think Mr. Kepes is on to something here. The adoption of PaaS does need to expand beyond professional developers in order for it to reach its full potential, which is to democratize application development for citizen developers. Current SaaS ecosystems that exist around dominant providers, like Google, make it easy to link one app with another in useful ways. Today this is done on the basis of published APIs. Tommorrow’s PaaS platforms could make this much more interesting for users to “embrace and extend” these app ecosystems in order to create the services or workflow integration that the user wants to implement.

  • nice thought, but a bit utopian, at least for the foreseeable future..)

  • Pingback: EPaaS is a new acronym I invented today | dbj();

  • Loved the sentiments expressed in this article. This has been at the height of several recent conversations I’ve had, and I look forward to what the future of an integrated cloud platform (or operating system) might look like. Google is well on its way with the Chrome OS, and the integration of IFTTT/Zapier like features could deal a final blow to the traditional operating system as we know it for the majority of end-users.

  • Pingback: Democratizing Development – Where PaaS Should Go - Jan Brass

Leave a Reply