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 http://www.joelonsoftware.com/articles/LeakyAbstractions.html

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…

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.

.nick

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 http://blog.cobia.net/cobiacomm/2011/11/25/searching-for-cloud-architecture/ ), 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 http://www.saasblogs.com/saas/the-hijacking-of-paas/ and http://blog.cobia.net/cobiacomm/2011/11/02/paas-evaluation-framework-for-cios-and-architects/

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 SalesForce.com? The platform determines the ideal infrastructure composition. Again, the interface simplifies complexity.

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

.nick

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.

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?

I have previously outlined such an scenario in a blog entry titled “Metering in the Cloud: Visualizations Part 1″ in which a customer instructs Salesforce to direct its storage/querying requirements to an external provider in this case AWS S3.

http://opencore.jinspired.com/?p=1583