Recently, I wrote an article on PaaS for IT BusinessEdge entitled the road PaaS, understanding your post IaaS options. Here’s an excerpt.
The Road to PaaS
PaaS is an enticing proposition that has generated a lot of market buzz.
But PaaS forces tradeoffs and it shouldn’t be seen as a one-size-fits-all proposition.
To understand, I like to draw the distinction between what I call “Silicon Valley PaaS” and “Enterprise PaaS.” The majority of the discussion in the market today revolves around the Silicon Valley PaaS pattern, which is a truly abstracted “black box” approach to software platforms.
This form of PaaS exposes a set of standardized services to which you write your applications, completely sheltering developers from the underlying complexity below the PaaS abstraction.
It makes a lot of sense for brand-apps built with modern frameworks like Python and Ruby in greenfield development environments that are highly standardized.
The basic premise of the post is that PaaS for an enterprise is VERY different from PaaS for a Silicon Valley start up. And nowhere is it more different than in the network requirements.
The PaaS customer is a developer who will code an application, use the underlying services offered by the PaaS stack, such a database, storage, queueing, etc. The developer deploys the code, selects a few options and code is live.
So what’s going on with the network? Well, the PaaS layer will need to auto-scale, fail-over and deliver performance at some level. It may need it’s own domain as well. That PaaS layer will need to talk to underlying network services such as firewalls, switches, etc. That PaaS really needs access to infrastructure models that deliver network containers to whatever PaaS abstraction the PaaS layer has.
Hard enough to do when all the containers are the same, as it would be in a Silicon Valley PaaS offering.
It doesn’t work with the existing enterprise platforms. This is a big opportunity for innovation