Rational Survivability

It's awesome until you get to the lower right group of 12 rectangles encompassed in the dashed line rectangle. I *think* I know what you're going for there but I'd need documentation to fully understand. The rest of the diagram is clear and wonderfully self-evident.

I think I understand why you put data/meta/content where you did — but I'm not convinced that it needs to be there. That's a different post, however (I have strange ideas about "data portability"), so let it pass.
I like the de-coupling of the presentation + channels from the services. That's nice. And I like explicitly calling out the facilities stuff. Since you've gone that far, maybe it's worth thinking about surfacing all of the other "invisible" stuff that IaaS hides, but which are definitely part of a true fully loaded cost number — things like personnel, property taxes, and whatnot? Or do you already see all of that lurking inside of Facilities?
I'm not sure I agree with the all of the implications of the monster governance…billing box. It's politically incorrect to say so, but "everything, all the time" is not always an efficient solution…
And I don't get the Resource and Infrastructure boxes. The Infrastructure box seems redundant to me. And what's the Resource box? A nod to REST? Or what?

I should have left that (and the orange ones to the top/right) out as they are breaking the "no details" rule I set in the post…they are there to describe what I mean at each layer. They are grouped together with the dotted line (perhaps they should not be) as they make up the infrastructure chunk.
I'm going to break the larger diagram out for each of the *aaS — and give examples: AWS, Google Apps, Salesforce, GoGrid, etc…
Thanks!

Hmm… Reflecting on Alex's comment. For the record, I understood each layer in the left hand box (within IaaS) to correspond to the same layer in the right hand box. So, for example, Power, HVAC, and Space are examples of what Facilities is composed of. Hence, ym question above… Is that interpretation correct?

I don't think you need to remove them, just maybe labels. And specificity that will come with time. The Compute/Network/Storage layer is one that I'm fixating on, (assuming you don't mean the verb "compute") as I'm not sure how I'd start making divides between servers that "compute", servers that "network" and servers that "store".
Also, (and this is probably because I'm one of your "security" readers and not one of your "cloud" readers) – I'd need examples of what you mean by Grid/Cluster Utility.

Ah, the resource and infrastructure boxes were there to group/separate the various components in the blue and
orange…I think I should just make a larger box that encapsulates each "group" (blue/orange) instead of putting it
out to the side.
I get what you mean to the "monster" box…it's funny because these things are always implied…I should know better
but I don't have a better idea to suggest (at this level) how they should be represented.
As to the "invisible" stuff, it would get really busy, but I *do* intend to call out that stuff (some of it is to the right) in
the detail slide/page for IaaS.
Thanks Mark!

Yup, 'sactly.

Oh, and also – should it be application -> data -> presentation? I know it's a linear representation of a non-linear model, but usually I've seen data -> application -> presentation for some reason (and maybe that's because I've been immersed in the visual diagramming of BI stacks).

Within the context of and OSI-like representation, yes. I suppose I could reverse them and the PaaS and SaaS groupings
which is why I stuck 'em in that order…I can see why that would be less confusing.
Thanks.

Agreed with the comment regarding the "monster box". I would add that it doesn't quite fit the messaging of the rest of the diagram. Other than that it's very nice and succinct graphic.

Since you've gone to the trouble of listing everything down to facilities I think you should also consider listing "Operations", since this is one of the hardest parts of enabling a Cloud / SaaS service because it involves people, processes and technology to monitor and manage the whole environment and make sure all the lights stay on, always (if you get my drift?).
The boxes to the left don't help with the explanation and the 12 boxes to the right don't really explain anything either, particularly in context to the powerful groupings in the middle. Most of the posts above allude to this. The central grouping for me is very powerful – except it's missing the Ops piece in my opinion 😉

So I have a problem with the "Core Connectivity" being above abstraction. Does that mean core connectivity is not hardware (it's separated from the hardware)? That it is abstracted and enabled by the abstraction (a la virtualization) layer? It's also an issue because the abstraction layer requires core connectivity. A VM with no IP addy is useless. 😉 The infrastructure necessary to hand out/assign/deal with IPADM and the network over which that has to occur (and possibly the VM be loaded in the first place) has to exist before the VM can "spin up".
Also, you have Platform as a Service (PaaS) comprising everything through "applications". PaaS is really about providing application platforms, a la Joyent or some of MSFT's offerings. While that necessarily implies that applications are deployed in such environments, simply calling it "applications" implies more than just a platform. If that makes sense…
I do like how "Infrastructure" and "Resources" overlap at the API layer. That's a great depiction of where the two meet and combine/integrate.
Lori

I struggled with the CoreCon/Abstraction ordering, given that the abstraction (VMM, etc.) can be provided by software; it's an enabling layer and also describes how the atomic components are packaged (images) such as Amazon's AMI…from a bottom's up perspective, the virtualization layer (for an EXAMPLE) actually provides the elemental bridge between the upper level transport and the hardware below it…
Does that make sense?
In terms of the PaaS comment, I agree…perhaps I can label it "applications/application platforms"?
That overlap 'tween infrastructure and resources w/the API is really where I'd put an integration bubble…but I want to keep it clean…
THANKS!

Excellent work. As I think was already alluded to above, you should probably move "applications" out to the SaaS layer. Instead, in the PaaS layer you should probably have more middleware components: database services, messaging, clusters, etc. (some of the things that appear in the little boxes on the bottom right).
Also, I think you need to address the issue of "meta-clouds" or "inter-clouds". Vendors like RightScale seem to be moving to that notion, plus it was mentioned as a need in the recent Eli Lilly case study that Amazon published.

Ah, but I thought you had ordered them that (unusual) way on purpose, in order to emphasise the fact that data is king, not services. And to provide a way to talk about the "how do I get my data back out, if I want to?" problem. Which prompted me to (finally) sit down and write my weird thoughts about the whole data portability stuff down: http://www.jroller.com/MasterMark/entry/raic_pron…

The point about "Core Connectivity" is well taken, but if we convince Hoff to put it back where it traditionally is, where does VPN-Cubed (and other beasts of that ilk) now fit into the picture? The point being, I think, that connectivity, like compute and storage before it, is beginning to show up in two places.

AHA! It looks like the comments have been fixed. I've had like 30-40 via Twitter and email, so if what you want addressed is still not done, let 'em rip!
Thanks for your patience (and thanks, TypePad!)
/Hoff

This maybe outside of the scope of the diagram, but if you are doing high level, this could be useful for the CxO and exe types and they like diagrams that show the business need. So maybe a 'business delivery box' CRM or Governance as end service regardless of SaaS or PaaS. X product here maybe.
I think I saw operations, but what is actually being serviced here? The orchestration layer is like layer 7 which in a traditional OSI model is still below the actual application, and even then the application does not necessarily address the 'business' need or purpose.

Surely within cloud computing, security is effectively also being presented 'as a service'?
So do you need an additional dotted line around all the 'resource'/'infrastructure' components called 'Security As A Service' (SeAAS)?
To expand on this (likely lunatic) concept a bit, it may be necessary to purchase expanding IDS capability from a cloud service provider or expand VPN capacity due to an increase in remote users or migrate to two factor authentication due to a change in sensitivity of data being housed by the cloud service provider?
Does this therefore also make security 'a service'?

Mark:
There are many abstractions/couplings which could be designated *as a service. Security is certainly one of them; storage is another good example.
Both of those examples are also features/functions of other layers even though they spread up/down the model, too.
I have "security" as an overriding element on the lefthand "uber-bubble" but I'd probably call it out as a little square on the right on the "core connectivity/delivery" layer…
That's my thinking on the matter, not sure how anyone else feels…

Maybe you mean this or not but the boxes on the left imply that the "features" in those boxes cover the entire stack. I would offer that the infrastructure necessary to bind the bottom two facilities and hardware is very different from the infrastructure to bind presentations and applications.
If fact i believe that this is one of the areas where the devil is in the details. As you said in an earlier response security as a service is certainly one thing that might be present. But what one is going to have to do, when dealing with the cloud, is really understand, or trust in, the abstraction and binding that is going on.
What i fear will happen is that little fiefdoms will spring up that bind two or even three of your layers, and someone else will overlap, and now you have something that no one can ever understand or navigate through.
BTW i like the figure, it matches my internal thoughts on the cloud. I do not understand yet how to indicate that the left hand vertical boxes are the REALLY hard part and that if you let that one single box turn into a bunch of small boxes things go very wrong.

Excellent update – in pondering the orange API layer – it's not really a layer is it, it's a way of exposing a presentation concept?
Consider that presentation need not include "display logic" — it's merely "that which is consumed by the display device/system".
How is a Cloud App that exposes "HTML Presentation" different from one that exposes "XML Presentation" or REST or well… whatever the heck is going to be invented next year?

So the reason I added the Application API layer (I suppose I could have made a bubble next to applications) is that when one looks at the Web2.0 type apps. today, almost all of them are bundled with API's. These API's, one could argue, are part of the application, but at the same time, they often limit or even enhance the functionality of the app. by exposing functionality to other applications.
Specifically, think about mashups and web-based apps such as Twitter and Facebook that really differentiate from the App. and the way the App. interacts with others. It's not just about presentation when another app. can slice/dice information and consume it…not just present it.
Would it make more sense to put it NEXT to the applications on the same level/tier instead?
Does that make sense?

Yup – much like the data layer — it's three different ways of looking at the presentation of the stack:
– native — The Interface (ie: the one that you're supposed to use if you're a good corporate goober)
– non-native (user) — alt.interface — text_only, ADA_compatible, iPhone, other methods for access which are not "official" and may be supplied by the stack owner or may be comprised of other intermediary providers (ie: Yahoo Pipes, Mashups, etc.)
– non-native (machine) — The official method for provisioning machine-to-machine interfacing, supports inter-cloud operations (ie: Salesforce <-> GoogleAppsSpreadsheets), supports thick-client (ie: AIR apps for user interface)

I think I would add Physical Security to the Facilities layer. Quite often the sole differentiator that I have observed in the services offered by various CoLos/Data Centers/NAPs is the actual physical security.
In many instances, the technology, pipes, racks, computing power available for hire are all exactly the same, but the physical security from one facility to the next can range anywhere from requiring visitors to provide something that looks like an ID to visitors submitting to multi-factor biometrics and constant armed escorts.
Certainly the ability push physical security costs into the cloud and to choose the level of physical security you require is one of the value adds of the cloud.

I think this is a phenomenal body of work. Well through out. However, in my opinion, the API layer only belongs in the PaaS. APIs allow you to interact with the system without going through the application layer. In essence, if you have an API, you are providing a runtime engine, which means you are in the PaaS layer.

JP:
There's been a couple of discussions around that very point I've seen fly by over the last couple of days, so I'm going to go catch up on those to gain some more background. I see applications (such as those with web apps & web servers, etc. that also have API's, so that's why I added the API layer in the SaaS grouping also.
I think that's what the recent discussions were pointing out, also.
It may not be a direct "cloud" function to provide this capability, but many of those same apps are moving to the cloud.
How would you handle/diagram this notion?
/Hoff

I believe I addressed all of those elements/issues, Lori.
Thanks!

Joe:
I'd have to add "security" to each layer if I did with the physical; that's why it's currently in the uber-bubble to the left.
However, I built this into a slide for a preso. I did and called out/aligned each of the layers with a corresponding security function and physical security (including stantions, guards, CCTV, keypads, etc.) were listed.
Make sense?

OH! That discussion about APIs and PaaS was on your blog! 😉 Time to go read!

First, let me join the folks above in expressing my appreciation for your work, and bringing it to the community for feedback/evolution.
Not knowing the strictness of your layered architecture, I have one question. In the SaaS layer, is data only available via an application, or might it be offered/accessed directly, via an API, such as a stream of market data?
Thanks,
Brenda

So, this issue clearly shows that there is not a clean line between SaaS and PaaS as I outlined in my blog entry – http://www.jpmorgenthal.com/morgenthal/index.php?… . I'm also getting the feeling that the boat has left the station, but SaaS should really be AssS (application-as-a-service) since this is all software all the way down the stack until you reach HaaS. Then I could have an application (AaaS) deployed inside of a runtime container (PaaS) and the flow of an API would be
1. Received by PaaS layer
2. Routed to AaaS layer
3. Response sent through PaaS layer
Unless of course the AaaS layer actually create their own HTTP handlers, which of course would be redundant and a waste, but plausible. If we're going for best practices here, we can ignore this representation.

I think you need to simplify again. I am an old-school info architect. It seems like the boxes along the left side are superfluous and are denoted already by the coloring of the boxes and the dotted lines. This graphic is not entirely self-explanatory yet. I think the bones are there, but you may have gotten to the point where you need to remove stuff and maybe change some labels to clarify (eg in the Integration Layer sub-topic, you call out Database, but I see that as more a "data/metadata" piece of things).

Interesting blocks based on SIP. Please check out a stack for a broad range of *aaS and the conceptual view of the federated compostie cloud fabric at http://cloudonomic.blogspot.com

You'll probably end with an API layer over the middleware layer too. With that in mind, you may want to put APIs as a different dimension (a paralel box to the stack, like those for infrastructure and resource), as they can be available for direct interaction with almost all the other provided layers. Or you'll end up with an API box for almost all other layers there 🙂

This is great. You have modularized the infrastructure level more that I would think necessary. Then again you might be focused more on the infrastructure play. We have been taking a different approach to the taxonomy/ontology by focusing on the various vendors out there.
http://www.opencrowd.com/views/cloud.php/2 and this list is growing as we speak.