Of late, I am working on the cloud security mechanisms from multiple vantage points:

1. Cloud Security mechanics for the provider interface between a Cloud Service Provider and a Cloud Service Consumer (including various brokers)
   • Protocols, elements et al as part of the DMTF Cloud Incubator wg. Our white paper will explain a little further on the architectures
2. Embedding Cloud Security in the network, leveraging various network capabilities – available now and in the future
3. Cloud Analytics for compliance reporting and forensics
4. And finally, a comprehensive view of Cloud Security
   • On this front, I did a guest lecture [Is Secure Clouds An oxymoron?] at the Naval Postgraduate School, Monterey
   • My aim was to facilitate and provoke discussions than suggest any solutions – the deep discussions will come later …
   • The room was full, excellent audience, lots of participation and some very good questions …

I will write more on this topic, especially #1. There is good amount of work happening in the Cloud Service Provider <-> Cloud Service Consumer front …

And we are starting to prototype the Cloud OS/APIs with extended semantics (including interface into our own UCS compute and policy plane) in our Cloud Concept lab (in Ruby!).

I believe that Cloud Security would be more robust if we can interface *natively* from the Cloud OS layer, with the network, compute and  storage control/management/policy planes …

Cheers

<k/>

Took time off to celebrate the Navratri festival and the Gollu.It is an interesting festival – in the sense that it focuses on art as well as friendship. The first step is to have the Gollu which is an expression of art, with idols, and other creative imaginary stuff.

Our Gollu this year :

Gollu 2009

We ( little Kaushik did most of the work, Usha and I helped out) also finally finished the Lego Taj – ~5900 pieces, the largest number of pieces ever !

Lego Taj

Fellow comrade Chris Hoff has an interesting blog post on what exactly is a Cloud SaaS. Me thinks most of his points miss the mark. Let me elaborate -

• The dominant aspect of a Cloud eco system is the interface between the Cloud Service Provider & the Cloud Service Consumer – how the system is implemented is irrelevant
  • In Chris’s view “If a SaaS offering is not built upon an IaaS/PaaS offering ” then it shouldn’t be qualified as Cloud
  • He quotes NIST’s definitions as one authority.
    • While NIST has done a good job overall, I have a few problems with NIST’s definitions. They are not as crisp and crunchy in many places
    • Second, I am not that fan of prescriptive definitions. Definitions evolve
    • And finally Chris, later in the post, confuses definitions with requirements.
    • NIST’s work is a set of definitions not requirements.
  • Going back, the major advancement in the Cloud model is the independence from, abstraction/frangibility of the infrastructure from the offering.
  • In short one cannot define a cloud in terms of the infrastructure it is running, but define in terms of the interface, usage and programming model it offers

• Even when we add other actors like Cloud Service Developers, Cloud Service Brokers and Cloud Service Aggregators, the picture does not change. In fact extending the actors make the argument (that clouds are instance agnostic) more stronger.
  • For example a Cloud Service Broker can provide a Cloud Consumer Interface and under the covers wok across different implementations from different service providers
• Which brings us back to Larry Ellison’s question “What the he** is this Cloud Computing”? (Thanks Chris for the link and the question)
• I had, in an earlier post, iterated the essential traits of Cloud Computing
  • In this discussion, it is the elasticity, multi-tenancy and the pay-as-you go model that make a SaaS part of the Cloud eco system

• Chris is a little concerned about re-branding “old-world” services as Cloud Offerings. I am not. The Cloud Computing is a way of doing business, a model per se. There is no temporal aspect to it – i.e. if we were doing elasticity, multi-tenancy and so forth, years ago and didn’t call it Cloud then, doesn’t mean we cannot call it cloud now !
  • A Cloud by any other name …
  • Cloud is a moniker, an attribute of a service offering
  • Naturally the major argument is “if a Service Provider is implementing a CRM for multiple companies as separate instances (rather than a single multi-tenant instance), is it a Cloud ?
    
  • If an offering has interfaces like a Cloud, if we can pay for usage like a Cloud, if we can expand (or contract) usage like a Cloud and if many companies use the service like a Cloud, let us then call it a Cloud (irrespective of what is under the covers …)

• Finally let us take the specific example of MX Logic and explore if their service offerings fit the Cloud moniker
  • Their e-mail archiving service is elastic, multi-tenant and pay-as-you-go. FIts the Cloud moniker (An I do not care how they implement it)
  • I agree that their e-mail filtering does not seem completely like any “accepted” Cloud services
  • But if you read thru their solution brief, it has all the thrills and chills of a cloud offering viz. no hardware, no licenses, no dedicated management et al
  • Well, it is not AWS but then the Cloud moniker is not restricted to AWS either, it is much more than that …
  • In short, Yes they do (and they can ;o)) , and I rest my case (and start the hassle ;o))

I have a few more thoughts, will update as I get time  … We are off to Alaska till the 17th … so need to pack …

And Of course, thanks to Chris for raising this topic – the overarching concepts are very important because they influence our view, the architectures we develop and  …
Till then … Don’t trouble trouble when trouble troubles you …
Cheers

<k/>

A funny thing happened on our way from virtualization to the cloud world ! The domain of cloud application developers and network started to converge. Converge might not be the right word – because network builders continue to build robust networks and that has not been antiquated; application developers will continue to develop interesting applications. But what has happened is a common layer and a convergence of interests between cloud application builders and network builders is happening.

Few points to note:

• I said and meant Cloud Application Builders – I do believe that there are many roles in the application domain and the role of an Application Builder is slightly different from Application Developer . I think I need a blog dedicate to this, for now the difference is in the focus – Cloud Application Builders will focus more on the infrastructure of applications – including scalability, availability, …
• Also, cloud application builders literally have to worry about the essential cloud monikers

… more at my blog at vmworld.

I have been working on a simple Cloud RA – of course based on discussions and insights from many inside and outside my organization. Here it is:

Cloud Reference Architecture

I will write more as I get time. In the meantime, let me know what you think …

Cheers

<k/>

Context:

There have been lots of discussions on McKinsey’s “Clearing the air on Cloud Computing”[1]. So I decided to take a close look at it.

In short, paraphrasing a colleague and a good friend, Chris Wiborg, “There is a reason McKinsey is in Management/Business Consulting and not Technology Consulting !”

Summary:

• The folks at McKinsey got the drivers and strategic value right, but totally missed the technology and are dead wrong on the tactics.
• First of all, while complaining that there are 22 definitions, the McKinsey folks added one more ! Looks like they are not satisfied with the other 22 !
• They didnot understand the significance of private clouds and focused narrowly on EC2 as THE alternative. Again, like the Berkeley study, very anemic cost models.
• Their recommendation to CIOs is dead wrong. I wish these folks stayed at the management consulting level (which they are very good at) and not try to make sense of something they are still learning … ;o)
  • Reading assignment : The RESERVOIR architecture document. Read, chew on it (not literally, of course), debate and then pontify !

Clint (a.k.a The Good):

• Excellent analysis – over-hyped, with potential for unrealistic expectations, significant hurdles for big enterprises, …
• They are right on the dot on the tremendous promise of cloud computing (P.4) viz: Faster Time To market, Lower upfront costs, Easier to scale out and most importantly creation of new value chains.
  • Good work folks …
• They are right on the adoption – Clouds are most attractive to start-ups and small businesses

Lee Van Cleef (a.k.a. The Bad):

• MkKinsey’s first observation was that there is no one definition of cloud computing. They found 22 definitions.
  • So what do they do ? They added a 23rd one ! As if that would solve all the definition problems ;o(
  • First of all there is no need for THE definition of Cloud Computing. Multitude of definition means that different constituents find value in different ways … which is a good thing. And a 23rd definition is not going to make all the 22 go away and make everybody fall in line !
  • My humble suggestion is to leave the definitions alone -Let folks, who are on the ground, define it the way they see value and utility
• Another very important distinction is the public clouds vs. private clouds. McKinsey totally ignored the private cloud space. This has been symptomatic – even the high minds in UCB missed this.
  • In the eyes of McKinsey, it is either virtualization inside one’s data center or Amazon’s EC3. Such a narrow view – total lack of understanding of the domain. Sorry

Eli Wallach (a.k.a. The Ugly):

• In McKinsey’s view, “Rather than create unrealizable expectations, CIOs should focus on virtualization”. Yikes, as ScoobeDoo would say it.
  • A recommendation only a management consultant (with no practical experience) can give
• “Aggressive virtualization” as they call it is the wrong strategy
  • What happens is that if CIOs follow this narrow-minded totally impractical strategy, the respective organizations will spend resources (narrowly focused on virtualization) and will miss the bigger benefits of Cloud Computing.
  • After all the effort in virtualization (like ROI calculations, budget negotiations, evaluation, software and hardware purchase, and so forth) they will have to start Cloud Computing all over again, yet another cycle of  ROI calculations, budget negotiations,… an approach that would bring tears of joy in the eyes of a management consultant ;o)

• My recommendation to CIOs would be -
  • Embrace Cloud Computing Infrastructure as the overall architecture with virtualization being one aspect.  If a CIO is initiating new infrastructure work, it should be Cloud Computing not virtualization.
    
  • They will not only be able to realize the economies of virtualization but also leverage the opportunity to create new applications based on the Cloud paradigm.
    

References:

[1] http://uptimeinstitute.org/content/view/353/319
[2] http://www.decisionstats.com/2009/04/mckinsey-attacks-cloud-computing-having-no-sense/
[3] http://bits.blogs.nytimes.com/2009/04/15/when-cloud-computing-doesnt-make-sense/

Personal Note:

After writing the blog, for some reason I got the urge to listen to the sound tracks of the title music for “For A Few Dollars More” and “The Good, The Bad and the Ugly”. I bought the mp3 tracks from AMZ and so finally they came out ahead ! They have found ways of monetizing even cloud blogging !

Context

There are many ways of defining and talking about a cloud infrastructure. Dave Malcolm has a set of characteristics in his blog. And Mike has more insighst in his blog.

The view from an Enterprise (so called private clouds) and the capability to extend to clouds provided by service providers (so called Cloudbursting)  is a little different from the pure play internet-based clouds (so called public clouds)  Let me take this view and define what an Enterprise Cloud Infrastructure backbone would be, without actually defining it !

Essential Traits

• Elasticity – This, of course, is given. A cloud essentially is an elastic infrastructure
• Multi-tenancy – Naturally, somebody should be using the extra capacity. This functionality is usually at the SP (Cloud Service Provider) side. An enterprise can also have multi-tenancy when it offers cloud capability to it’s organizations – whether they are business units or functional units (like HR and finance)
• Abstraction- The level of functionality from IaaS (Infrastructure As A Service)  to PaaS (Platform As A Service) to SaaS (Software As A Service)
• Federation – The span – whether it is inside one datacenter or across multiple datacenters of an enterprise or extends to an SP
• Extension of Security Context/Scope – If we assume spanning across Service Providers with compatible infrastructure and with existing relationships, then we are extending the security context – a pragmatic approach
• Spanning Ownership domains – The enterprise has ownership if it is inside it’s firewalls and the ownsersip boundary is crossed to a cloud owned by an SP

CloudBursting

Let us define Cloud Bursting in context of the six traits. It is very easy – Elastic, multi-tenant at the SP side, extending the security domain and a different ownership domain.

Supporting Traits

Careful observers would note that this is missing two traits (mentioned below) that is near and dear to the likes of Amazon and Azure. It is deliberate that I did not include them in the essential traits. While Enterprises can (and will) use public clouds for many projects, for the near future public clouds will not be a *native* part of an Enterprise Cloud Infrastructure backbone …

• Raw Internet – I do not think “raw” Internet is an essential trait of Enterprise Clouds. Meaning, the communication between the Enterprise and the SP would be via some form of overlay (or leased line or similar mechanisms) that has security, QoS, policy and other characteristics
• Pay-per-usage – I do not think an Enterprise Cloud Infrastructure backbone would be pay-per-use.

Notes:

1. This blog is from my presentation at the OMG SATCCI (“Strategies & Technologies for Cloud Computing Interoperability”) BTW, there are a few good presentations from the workshop.

My first attempt draft-sankar-oauth-headerhash-00a

We can probably find enough evidence to argue this point.  An interesting waypoint is the project ESME

<exec_summary>

• Enterprise Social Messaging Experiment (ESME) is an Open Source tool designed by Siemens IT Solutions and Services together with SAP Community specialists.
• One client to the ESME system is,… yep you guessed it – ABAP, which is the programming language for SAP. So literally the ESME is an extension to ERP !
• And as SAP matures it’s cloud products and (inevitably) move into SaaS/Cloud models, an ERP-based social media interface which leverages the multi-tenant capabilities (thus deriving the social graph across enterprises)  is not far behind !
• ESME is a “self organizing communication group” which is interesting, as this is the only way collaboration/communication can scale. They need to acquire context as well as intelligently derive connectivity inferences
• “It serves to identify company employees with particular knowledge or expertise, and networks these experts together so that they can exchange information”
• And it is an open source Apache project . I might contribute … may be an *OpenSocial* interface, which the project lacks now. Also need to see how they are organizing the knowledge graph and social graph.

</exec_summary>

<for-those-who-are-more-technically-oriented>
ESME is written in *Scala* – a programming language which combines the object oriented world and the functional programming world. It also has primitives from Erlang, a very scalable language system – see my blog for a quick review

</for-those-who-are-more-technically-oriented>

Cheers & happy Pi day (3/14)
<k/>

In the last couple of days there have been a few good posts on Cloud Interoperability from Reuven, Greg and Stu. I also had written a blog about standard cloud couple of months ago. To understand the cloud interoperability, we do not have to go that far – from the clouds I mean – just taking a cue from the world of UFOs would be enough !

Cloud Interoperability of the 1st Kind => Clouds exist and can be observed. This is the state we are in

Cloud Interoperability of the 2nd Kind => Cloud services can talk to each other

Cloud Interoperability of the 3rd Kind => Clouds can observe each other and some form of intelligent communication can happen

Cloud Interoperability of the 4th Kind => Cloud are abducted by each other – just VM movement from one cloud to another

Cloud Interoperability of the 5th Kind => This is where “joint, bilateral contact events produced through the conscious, voluntary and proactive … cooperative communication” happens. In essence, the clouds can work together

With this enlightenment, we can examine the POV of the cloud luminaries …

• Reuven says “Cloud Interoperability is to make it easier to use multiple cloud providers who share a common set of application interfaces as well as a consensus on the terminology / taxonomies that describe them” – Yes aliens and earthlings can talk the same language and understand each other, but we cannot change the fundamental nature of aliens and earthlings. So a common API layer does not work here and it should not.We do not want to convert aliens to earthlings or vice-versa. They both have their place in the universe and we should respect that. So Common API is a non-starter.
• Reuven defines “Cloud Portability” as mobility irrespective of OS/technology platform and format. Portability is Cloud interoperability of the 4th kind – mobility between homogeneous format and OS/technology platforms. We are not looking for antidote against platform lock-in, but are looking for cloud provider/vendor lock-in and btw, there is nothing like a cloud lock in. Unfortunately Reuven, in his blog, has a little confusion on this aspect. One has a choice of multiple OS platforms and one can always choose to write apps in one platform, if one wishes so. There are valid reasons for choosing one or more platforms. Windows folks will write in Azure, Google folks would like to work with Python and rest of the folks will use EC2. A cloud substrate should not mitigate the OS platform difference.
• Stu first talks about protocol interoperability only a network engineer can love, Yummy Stu ;o)
• His startling observation, that Microsoft has a clue, based on the .NET services architecture, itself is startling ! It is just interfaces between services. I do not think that is interoperability in any sense. OK, I will give it the Cloud Interoperability of the 2nd kind, if a cloud service on another OS/technology platform can talk to Azure services, and they can (I think)
• I liked Stu’s deployment flexibility and that is one of the key components for interoperable clouds – not translation, semantic or not, not common APIs but just deployment flexibility between cloud providers, on the same OS/technology platform.
• Stu has some interesting predictions – yep, no new run time (read my lips – those who remember that)
• As I have said earlier, we have to look at this from the four planes viz: policy, control, management & data. For Cloud Interoperability of the fifth kind, we need :
  • A declarative policy plane that can be interpreted in a common way but implemented in proprietary ways as the platform sees fit
  • A control plane that can be dynamic with rich attributes that are semantically equivalent across clouds (I do not care if they talk the same words so long as I know how to map them and do equivalence)
  • A management plane – again built on semantically equivalent attributes so that I can make (collective and individual) inferences as and when needed
  • And A data path which is the OS/technology of my choice and I do not want the cloud to change my data path characteristics.
  • And A mature metering plane [Update - March 15,09 : James Urquhart convinced me that this is a fundamental requirement!]
    

Cheers

<k/>