A viable PaaS Model

7 Dec

What makes a PaaS a PaaS?

I’ve seen many discussions on blogs and twitter around this topic, so much so that many people are tired of talking about it because it always leads to cyclical discussions.  I for one haven’t been satisfied with any of the answers that I have seen.  Some people try to define PaaS with requirements such as it must be on demand, while others say that an API and services need to be exposed.  I disagree with these requirements/constraints on describing PaaS.  I think there is a model should be applied to define what is PaaS, to make this model credible there is a necessity that it can be mapped to most (if not all) current and future offerings defined as PaaS (Which will be a follow-on series to this post).

The PaaS Model

The PaaS Model is made up of two different constructs, which are called Spaces.  These two Spaces serve different purposes, but are composed of the same PaaS Element Types (elements will be explained in detail, in an App Space deep-dive follow-on post).  The Control Space and App Space are show in the diagram below, notice that the App Space is fully wrapped/contained within the Control Space.

Control Space:

The Control Space performs all of the automation, management, provisioning that is required by the PaaS.  Interaction with other lower level components such as an Orchestrator is achieved through API abstractions if/when necessary. The Control Space and its implementation also determine what elements are allowed/exposed to the App Space. Further, the Control Space is responsible for maintaining App Space coherency and dependencies.  While the Control Space is comprised of several separate functions, they may be combined in different manners depending on the specific PaaS implementation.  All of this will also commonly be exposed through one or more API interfaces (this however, isn’t necessarily a requirement in the model presently).

App Space:

The App Space is where end-user/customer applications are deployed, updated, and run.  The App Space is controlled (and commonly coordinated) by the Control Space.  The exposure of PaaS Element types by the Control Space to the App Space is one of the key differentiating factors between different PaaS implementations.  App Space characteristics are controlled by how the Control Space is built/designed along with what PaaS Elements were used to build the Control Space.

  • App Network: The path which applications communicate with app each other and services/resources exposed to apps.  The App Network exposes Network connectivity to the App Space.
  • Executor: The application bootstrapping mechanism for apps being or currently deployed.  The executor provides compute/memory resources to the App Space.
  • Code Processor: Examines code, libraries, and dependencies before sending to the Engine and/or Executor.  This can also be thought of as a code inspector or post/pre-processor.
  • Coordination Network: Where the Control Space components communicate/coordinate with each other.  Think of this as a management network that is in most cases out-of-band from the App Network.  The Coordination and App Networks could be combined, however in a production system this would introduce too large of a security risk.
  • Engine: Coordinates the distribution and provisioning of code, services, and their dependencies (most frequently in the Control Space).  The Engine decides the where and how of what happens in the App Space.  Also, the Engine may be capable of coordinating with an Orchestration Layer or other automation tools outside of the Control Space to provide new/additional resources to either/both the Control Space and the App Space.
  • Monitor: Looks at the state of the App Space and the Control Space, signaling other Control Space components to resolve conflicts.  The component most likely to resolve conflicts would be the Engine or a specialized component designed purely for conflict resolution.
  •  Notes: These components/functions may be grouped differently based on the specific PaaS implementation.  Also, some of the functionality or components could be put into an API, split into sub-components, or even externalized through/in a Client or Client side API.

PaaS Elements:

PaaS Elements are abstractions on top of different layers of resources.  Most PaaS Element abstractions are done through Service based or Service centric abstractions.  This is not the only way of creating/doing an abstraction, but it is one of the most flexible ways.  PaaS Elements are broken up into three primary types which are defined below:

Please note there will be an in-depth post on PaaS Elements following this blog post.

  • Primitives : The Core Building Blocks of Resources
  • Sophisticates : Composites / Combinations / Extensions of Building Blocks (Primitives)
  • Definitives : Instantiations of Primitives and Sophisticates either directly in use or wrapped in Services/APIs

All PaaS Elements have the ability to provide or interact through a pass-through interface or abstraction to any other PaaS Element type all provided by the Control Space.  Elements are combined to create an Application (App) in the App Space.  The most interesting twist to the model is that the Control Space is made up entirely of PaaS Elements as well.  There is a great deal more to be covered on this topic both here on this blog and out in the community.  Please provide feedback and questions in the comments section of this post or live on Twitter (@mccrory)

I would like to give a special thanks to Shlomo Swidler (@shlomoswidler) and Derek Collison (@derekcollison) for providing valuable feedback in several draft iterations of this post.

Advertisements

4 Responses to “A viable PaaS Model”

  1. Chris Haddad 2011/12/07 at 3:56 PM #

    Good architectural starting point. A section describing how the model is different from a traditional application server and language container (i.e. JVM, CLR) would be helpful.

    A few questions:
    What happens when an application spans multiple ‘control spaces’?
    Where is lifecycle management and state handled?
    If the ‘orchestration layer lives outside the Control space’, where does the layer live?
    If ‘App Space’ resides within a ‘Control Space’, can one build an application spanning multiple control spaces? A few fractal diagrams may help.
    How does the model modify/augment the application developer experience?

    • @mccrory 2011/12/07 at 4:28 PM #

      There will be a follow on Post describing the Element Types (which should hit tomorrow), this should explain why/where JVM and CLR would fit.

      Replies to your questions:
      What happens when an application spans multiple ‘control spaces’?
      Then it is not an application running in a PaaS any longer? A Control Space isn’t bound by Geographies, so I don’t see why an app would span multiple control spaces unless you are talking about a Service (say an external cloud dependency). This is would be a choice made by the PaaS Control Space implementor and would fall into the Element Types I mentioned earlier.

      Where is lifecycle management and state handled?
      Lifecycle management could be an added capability to a Control Space or could be handled in the App Space depending on the implementation. State is another option, as some PaaS solutions are mindful of state and others expect complete idempotence, this depends on the Element Types that were chosen to compose the PaaS.

      If the ‘orchestration layer lives outside the Control space’, where does the layer live?
      It is an optional extension to the PaaS that would operate by Element Types being used to interface with some type of Infrastructure. The Engine could trigger events to an Orchestration interface or agent to drive events, this all depends on the implementation. The PaaS model is generic, when I apply it to different PaaS solutions, then I will be specific about where extensions have been done/could be done.

      If ‘App Space’ resides within a ‘Control Space’, can one build an application spanning multiple control spaces? A few fractal diagrams may help.
      I’m hoping the Table I have in the coming space will help provide clarity.

      How does the model modify/augment the application developer experience?
      This comes from how the model is implemented by specific PaaS providers. This determines what the dev. experience is, and is why the follow on Element Type post will be important. Depending on your Element Type choices and what you decide to expose determines what the experience will be.

      I hope this helps.

      • greg schulz 2011/12/08 at 1:41 PM #

        Great post, good read, thanks, look forward to the follow on material…

Trackbacks/Pingbacks

  1. PaaS Element Types « McCrory's Blog - 2011/12/08

    […] Please Note : This post builds directly on the previous post “A viable PaaS Model“ […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: