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

What are PaaS Element Types?

PaaS Element Types are the constructs required to build a PaaS.  Each PaaS Element Type builds upon the previous, I’m not the first to come up with the overall concept of Types building upon one another, this was inspired by Data Types from Software Development.  It is important to understand that all PaaS Element Types end up being abstractions built upon one another.

Why are they important?

As we move to the new paradigm of application development, architecture, and management, applications will be the comprised of these new element types vs. the traditional patterns and designs we have all become used to.  By fully understanding PaaS Element Types, you will gain not only an understanding of how different PaaS solutions work, but what their capabilities, strengths, and weaknesses are and why they have these characteristics.

Compute, Networking, Storage, what about Memory?

You may have noticed that Memory is not listed as a column, why is that?  Storage is meant to encompass all forms of storage, which includes Memory (Memory is just a very fast form of volatile storage, just as an L1 Cache is even faster than standard memory it is all for storing bits and bytes – albeit briefly).  All of the PaaS Elements have the ability to leverage memory for whatever purpose they may need, but I see no reason to separate memory in the Element Types.

Primitives as defined in the previous blog post

Primitives are the Core Building Blocks of Resources.  What does this mean?  Primitives cannot be reasonably reduced to a more basic/granular bit of functionality.  You may be thinking that an Operating System could most certainly be reduced to a more simplistic bit of functionality and you would be correct if we were talking about us in a traditional Infrastructure, but not PaaS.  Part of the magic of PaaS is the prescriptive nature that PaaS brings, along with the obfuscation in most cases of components such as the Operating System.  In the case of the Operating System, it is also important to recognize that as a Primitive, the OS has not actually been instantiated (it isn’t a running OS).  One final note is that PaaS eliminates nearly all direct ties between code and the OS (There are still limits imposed by the runtimes, etc. which are difficult to avoid – e.g. Mono for .Net support on Linux)

Sophisticates : Composites / Combinations / Extensions of Building Blocks (Primitives)

Sophisticates are built from Primitives, meaning that a Sophisticate cannot exist unless it is backed by a Primitive with some addition, change, or a second PaaS Element Type such as a Primitive or Sophisticate.  A Sophisticate could be built from a combination of another Sophisticate and a Primitive!  Let’s take RDBMS as an example (note that this would just as easily apply to NoSQL solutions, etc).  RDBMS will likely leverage a RuntimeVM, an Operating System, Processes, an Interface, Block Store, Cache, and a File System.  While this may be complex it is hidden by the RDBMS Interfaces, which is part of the beauty of PaaS is exposing this combination as a Service or Extension that can be consumed by an API call or a DB connection.

Definitives : Instantiations (Running) of Primitives and Sophisticates either directly in use or wrapped in Services/APIs creating easily leverage abstractions.

These abstractions allow complex configurations of Primitives and Sophisticates coupled with Application Logic, Dynamic Configuration capabilities, and more.  Definitives are the live and fully implemented abstractions as they consume resources.  This could be a Schema in a RDBMS or a Collection with Documents in it in a Document Store.  Definitives are where all of the specificity occurs in PaaS and ultimately what differentiates applications from each other once they are running.

What can you do with all of this stuff?

If you use the prescriptive side (what a developer writing to a running PaaS offering would do) of PaaS and simply consume it, you can quickly and without a deep understand deploy applications within the limits of the PaaS App Space.  Alternatively you can design your own PaaS with whatever capabilities you require to support the behaviors and design patterns that you need for your App Space.  This is done by using the PaaS Element Types to make choices on the Control Space, which in turn creates the boundaries of the PaaS App Space.

Control Spaces share some characteristics of the App Spaces that they provide, this is because the Control Space operates on the same infrastructure that the App Space operates on.  This is true in the majority of PaaS cases that I have seen to date (it could at least in theory, change).  Control Space components are Definitives built from Primitives and Sophisticates to provide the prescriptive approach to the App Space that makes PaaS an attractive alternative to traditional software builds, configuration, deployments, etc.

The work in mapping Primitives, Sophisticate, and Definitives is not yet finished!

What I have provided is the beginning, not the end.  More work needs to be done in adding additional examples of PaaS Element Types, along with mapping all of the current PaaS offerings to both the PaaS Model and what Element Types are used/comprise each PaaS offering.  In future blog posts with help from different collaborators I hope to accurately map the major PaaSes to the PaaS Model and their PaaS Element Types.

 Comment here on the blog or ping me on Twitter (@mccrory) with your thoughts and ideas.


  1. I find the PaaS element types described extremely infrastructure focused. A PaaS should shield developers from infrastructure elements (i.e. Compute, Network, and Storage). A PaaS should expose services, data entities, and process flows. A PaaS should expose first-class constructs supporting the Actor model, functional language attributes, eventual consistency, parallel process execution and coordination. Shouldn’t an ‘Application Platform as a Service’ provide an application-centric abstraction level?

    1. That sounds more like a share-schema style SaaS extension than a PaaS model. But, I would imagine there are levels of merging between this idea and yours. And your view is a pretty good one for high-level language with specific base construct needs.

      But if I am consuming a platform the assumption can’t be made that as an enterprise architect I don’t care about networking stack, computing domains, or storage delineation.

      Many EA platforms out there right now make serious decisions based on visibility to these elements.

      I see a PaaS as an easy way to quickly start building on the ‘platform’. But, I would expect to still see the planks underneath me.

      A much more interesting thought is how does multi-tenancy drive the PaaS consumption of those infrastructure resources.

      my 1/4 cent opinion


      1. Nick, isn’t the whole point about the layered Cloud model (i.e. IaaS, PaaS, and SaaS) to encapsulate lower level details? I think your infrastructure background ( ) and my developer background ( ) might indicate our perspectives our different. I equate PaaS with providing an application platform suitable for productive development.

        Within the Java/.NET development environment, I would maybe draw the line at the Definitive types as application platform constructs, which developers reference in their code.

        But even some items in the Definitive list don’t cleanly map to the developer experience and application platform responsibilities. For example, does the application platform set ‘routes’, or does the network layer determine routes? Within a web application development model, networking network topology is abstracted behind URLs. Load balancers, firewalls, routers, wireless access points, content delivery networks are hidden. The service consumer interacts with DNS services, specifies communication channels bound to an endpoint (ports, protocol, address). I don’t see where ‘network as a service’ is cleanly delivered in the proffered model.

        While I grant your statement, “consuming a platform the assumption can’t be made that as an enterprise architect I don’t care about networking stack, computing domains, or storage delineation.” is currently true with traditional terrestrial application infrastructure AND within cloudwashed solutions (see ), companies such as Apprenda and WSO2 are re-inventing middleware and hiding complexity. For example, WSO2 Stratos composes Primitive and Sophisticate elements behind the utility wall jack. Java application developers interact with business services, messages, and queues.

        For a perspective different from the me-too cloudwashed offerings, read and

        Another thought… The most effective application platforms satisfy declarative policy definitions, and EA intervention to define solution details are actually not necessary. Do EA’s tune solutions built on Google AppEngine or The platform determines the ideal infrastructure composition. Again, the interface simplifies complexity.

  2. Not sure if I can compete flat out with your experience in the development arena. But, I will make some easy points.

    As for background: guilty as charged. My roots are from infrastructure. I should also mention I work in the CTO Office for EMC Corporation which is a big vendor in the infra space as well as a majority holder in VMware(Cloud Foundry) itself. So while my comments aren’t related (you buy infra either way). I want to be clear who I work for. I think my record of knowledge in the EA/Dev space is pretty well known within strange small circles and won’t try and claim to be any expert in anything we talk about here.

    I did notice from the Linkedin links you shared; that you also work for a vendor (new VP role at WSO2, congrats!). And your comments don’t seem to clearly state that you work for the companies and products above. Not saying what you said is incorrect or that it was intentional. But you may want to be clear about where you are coming from. Your fourth paragraph reeks of marketing selling without that statement; which may be ruining a really damn good point(or product) you have behind those links.

    I don’t see how my comments were not encapsulating lower layers. In fact I think I was making the point that abstraction encapsulation of infrastructure-style constructs were a valid control point to expose in PaaS. Maybe I didn’t make that clear. If we look at Dave’s model above you can find a ton of places to tweak and change. My *new* point is that this a create example for defining first-level PaaS.

    To illustrate, let’s use the network layer example you gave. I would volunteer that routing is problem the worst example you could have chose (maybe you know that). The funny thing is I don’t see a single mention of the network fabric as a primitive. I see interfaces and VLANs; both of which are consumables on an endpoint and not control decision points in a fabric(where routing exists).

    And I would vote that visibility to available and *abstracted/virtual* interfaces and VLANs(logical segmentation) might me useful in a PaaS model. For example: if I am integrating specialized hosted sophisticates like Memcached on PaaS, I might care about controlling distribution behavior ingress/egress vs. a transactional DB or web services in the same design. Visibility and control for consumption of underlying primitives could be critical to issues like scale or resource management. An interface in a PaaS model doesn’t mean a developer is having to understand or deal with e1000 drivers, or buffer rings, or ipv6 in order to use. We are talking simple primitives for control/information on ingress, egress, counters, membership, and even more important (and really.. Dave’s point) how they relate to the sophisticates and higher-level definitives. What is exposed in PaaS can be something entirely different.

    Again I am not saying that for some designs simple service consumption, batch queues, AMQPs, and more won’t suffice. But I am saying that I believe limited *encapsulated* abstraction of infrastructure models are a great component for PaaS. Saying that you don’t want exposure to an abstract model for interface or segments(networking examples again) seems like saying you don’t want exposure to threads within a process.

    In my mind any model needs to have some visibility to the layer beneath it. Abstract, consumable, and maybe even simple. And your last comment on AppEngine and SalesForce totally confused me. Especially SF since my original comment was that your opinion seemed to lean towards that shared-schema model. I totally think shared-schema, SaaS, etc is awesome and can be very successful. I also think it isn’t PaaS.

    I like this statement: “I equate PaaS with providing an application platform suitable for productive development.” but I don’t buy that Dave’s types above don’t fit that.

    I will make this my last comment to keep from ruining Dave’s post. Feel free to tear the comments above apart.


    1. We do agree shared-schema is awesome. I didn’t pick up on your invite to explore multi-tenancy; where we may also find common ground ( If you prefer shared-container tenancy). My comment about networking was to illustrate an ill-defined delineation between IaaS, PaaS, declarative policy, programming language, and application in the original blog post.

      I also agree with you; After reading the two posts, I am not sure if Dave’s types fit the developer perspective or not. I do see Dave’s abstract model as a good start towards using a clean slate approach to redefine Cloud architecture. Whiteboard architecture is hard to convey in two short blog posts. When infrastructure level details are mentioned without specifying encapsulation points, the architecture model starts to leak. In the post, definitives are defined as “Instantiations (Running) of Primitives and Sophisticates either directly in use or wrapped in Services/APIs creating easily leverage abstractions.” But the example table doesn’t explicitly specify linkages and separation of concerns.

      I am attempting to connect the type blocks and primitives with the developer experience. SpringSource changed the development model with Inversion of Control (IoC) and simplified injecting infrastructure behavior. What is the proposed application development innovation for PaaS? Will the primitives be defined in a way which enables successful encapsulation and abstraction? You mention “limited *encapsulated* abstraction of infrastructure models are a great component for PaaS. “. Joel would agree that abstractions are limited

      Will the “abstractions wrapped in Service/APIs” hide complexity or leak infrastructure details? Without specifying the requirements (e.g. ACID, eventually consistent), API, language (e.g. functional, object, relational), and interaction model (e.g. functional invocation, message passing), we don’t yet know…

Leave a Reply

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

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

Facebook photo

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

Connecting to %s