Cisco Logo


Data Center and Cloud

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

In an effort to keep conversations fresh, Cisco Blogs closes comments after 90 days. Please visit the Cisco Blogs hub page for the latest content.

1 Comments.


  1. Matthew Jonson

    The full article was good to read, thanks Rodrigo!

    One of the challenges you bring up is the need to be able to deliver network and compute in a utility model to the PaaS layer just as that PaaS layer delivers utility to the application programmer.

    An opportunity here for our traditional Cisco partners is to see that they can enable that utility infrastructure and effectively deliver IT as a Service to their customers … with an offer that keeps the infrastructure up to date and delivers a network and compute platform that has the feature-rich capability necessary to be able to abstract an application platform on top of.

    We need to deliver the tool set to the partners that allows them to enable the utility infrastructure model from catalog to provisioning to operation.

       0 likes

  1. Return to Countries/Regions
  2. Return to Home
  1. All Data Center and Cloud
  2. Return to Home