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.
Disclaimer: Our publication of this post doesn’t mean we agree/disagree with the thoughts. We just want to kick start a conversation around this topic.
Author Bio: This is a guest post by Dave McCrory. Dave is part of CloudFoundry team at VMware. He was also founder of Surgient and Hyper9. He is the original thinker who wrote extensively about data gravity in his blog. You can read his previous posts at his blog. This post is also syndicated from the original post in his blog.
