PaaS shouldn’t be built in Silos–Part II–The PaaS Score Card

I met Geva Perry on Friday last week and as in many of our discussions we started exchanging thoughts on various topics that bothers each of us. Not surprisingly we ended up discussing my last post, PaaS shouldn’t be built in Silos, in which Geva had some part of (without even knowing).

Anyway, Geva brought an interesting question – "What would be your scorecard for second-generation PaaS and how would it be different than an App Server scorecard?"

It took me a second to think and I came up with the following answer which I’d like to share with you and get your thoughts on.

The Second-generation PaaS score card

1. Elasticity –  What happens when I add another machine to my application pool? Which parts of my application can grow? Can I control any of this?
2. Multi-tenancy – what are the means provided by the PaaS to handle multi-tenancy of:
   • Data – Can I have multiple customers accessing the same data service but in isolation from one another?
   • Application – Is it possible to share multiple applications on the same hardware? Is it possible to control the various sharing/isolation level between the different Applications? Can an application affect the service levels offered by other applications on the same hardware?
3. Continuous deployment – What is the process for rolling out new applications, features, or services? Will it involve downtime? What is the process for  changing my data schema? What is the level of granularity for deployment - must I deploy new virtual machines, or entire applications as a single unit of deployment, or can I roll out specific application components?
4. Scalability – What is nature of the built-in scalability? How is it implemented? How can I trust the scalability features? How is scalability consistent across the various tiers of your PaaS? What are the tradeoffs in terms of consistency, or API semantics?.
5. DevOps – What are the tools that enable control of the deployment of your app? How robust are those tools – will they handle also the case of post deployment? What are the troubleshooting and monitoring tools that come with the platform? Can I use the same tools in a consistent way in my development and production environment? Can they integrate with other data-center monitoring tools?
6. Middleware services – What are the middleware services that are provided with the platform (Web, Data, Messaging, Analytics)? Is it possible to plug in other middleware services of my own to the platform?  How easy it is to use those services? What are the performance or latency characteristics of those services? How well they are integrated - i.e., does each one come with its own high availability, scalability, and management tools or do they share the same underlying clustering?

The main thing to note is that I scored Middleware Services as the last item. This is intentional.

You could  argue that this is incorrect, as you can’t do anything with the platform without those services - many that I spoke with about this actually scored the middleware services as the first (and most important) item and spent the entire bulk of their design and selection process on that item. They didn’t realize that by focusing on middleware services they often miss out on everything else - the other five items. 

That said, is there a "right" or "wrong" viewpoint here? Well... no. As usual, there is no absolute "right" or "wrong," but there are different perspectives. Let me try and explain the rationale behind my perspective:

My score is based on the assumption that most of the platforms provide similar degrees of features at the individual middleware services level. (Since they usually compete with each other based on a list of features, this is very common.) The differences between platforms tend to be relatively marginal on a feature by feature basis. The real big differences are:

1. How well those services are integrated in compliance with items 1-5 above
2. How easy it is to plug-in my own services
3. How open those services are for different languages and APIs.

Note that item 2 is really an interesting one.

Today, middleware services evolve at an extremely fast pace. Unlike the application server world where you expect to get everything with the platform, with PaaS it is more likely that none of the platforms can deliver every service as they evolve.  (There's a perceptible lag between conception and delivery.)

It is therefore important to see that the platform is geared to host external ecosystem services in the same way it hosts its own pre-packaged services. It's important to show that I can plug in my own services to manage and extend and use the deployment, management, and multi-tenancy aspects that I listed early in this post.

Item 3 is also important.

Java EE application servers came to the world under the assumption that the world is entirely built on Java. While some shops could get away with this assumption - at least internally - it's never been very true. Now, someone presupposing an all-Java architecture is wearing blinders. In the real world, one has to expect multiple languages - externally, at the very least, and more likely internally as well.

One common way in which some of the platforms address the multi-environment need is by  exposing a RESTful interface to their services. For example, Microsoft Azure provides a way to run Java on top of their platform by exposing all their services through REST. That’s fine to some degree but it also means that all other languages becomes second class citizens to your platform if this is the only option, as REST often comes with a performance and latency cost.  That’s probably the reason why some of the platforms support Facebook Thrift in addition to their support for a REST API. In GigaSpaces, we even went further and enabled the binding of .Net, Java and C++ without any network call from the context of a single process.

Test yourself – are you building a PaaS or yet another Application Server?

If you end up with a score card that focuses on middleware services (item six in my scorecard) and your entire application has solutions that fit into the silos of the other items in the stack - possibly comparing compliance to spec XYZ, or asserting that it supports all of the WS-* specification, or what-have-you ... that’s fine, but you should note that you're in the business of building yet another application server, not a PaaS.

We're still in the early PaaS days. I would be very interested to learn about other perspectives, specifically - how do you  plan to select your PaaS platform? How would your score card would look like? What features would you demand or offer as a competitive advantage?

It's important for us, as an industry, to know what issues we are trying to solve, if we're going to solve them correctly as a whole.