Posts Tagged ‘Virtualization’
Cloud & Virtualization Stacks: Users Fear Lock-In, Ecosystem Fears Lock-Out…
Last Updated on Monday, 12 March 2012 01:18 Written by Celframe Security Team Monday, 28 May 2012 12:15
I don’t think I’m verbalizing something very well…so I decided to write it down. I still don’t think I’m managing to stick my point, but perhaps clarity will come by discussion.
Simon Wardley has written about market dynamics and behaviors associated with the emergence and ultimate commoditization of things many, many times, but I’m not sure that I’ve found satisfaction in being able to accurately describe the dysfunctional co-dependency between consumer, leading vendor and ecosystem supporters to my liking.
Here’s an example…
There’s an uneasy tension that seems to often become nothing more than wink-and-nod-subtext in discussions relating to the various stacks offered by leading cloud and virtualization vendors. Even those efforts with the “open” or “open source” descriptor bolted on for good measure.
It occurs to me that this can be attributed to many things; the business and licensing model of the solution provider, the ultimate “consumer” the offering targets, the area(s) of differentiation around technology, the maturity of the ecosystem, and the amount of self-integration versus vendor support required to successfully operationalize and maintain the solution.
More directly, the tension I refer to is the desire (or at least oft-verbalized complaints) on the behalf of “consumers” of cloud and virtualization stacks to not be “locked in” to a single vendor balanced against the odd juxtaposition — but not entirely unreasonable requirement — of simultaneously not being subject to the “integrator’s dilemma,” and having to support it all themselves.
Stir in the ecosystem of ISVs and solutions providers who orbit around these stacks, adding value where they have the “permission” to do so before either the stack provider obviates their existence by baking those features in directly, or simply makes it increasingly more difficult to roadmap given engineering dependencies they can’t control or count on.
I alluded to some of this in my blog titled Cloud Computing, Open* and the Integrator’s Dilemma wherein I mused:
I am just as worried about the fate of OpenStack and its enterprise versus service provider audience and how it’s being perceived as they watch the mad scramble by tech companies to add value and get a seat at the table.
Each of these well-intentioned projects are curated by public cloud operators and technology vendors and are indirectly positioned for the benefit of enterprises, but not really meant for their consumption — at least not if they don’t end up putting enterprises right back where they were trying to escape from in the first place with cloud computing: the integrator’s dilemma.
If you look at the underlying premise of OpenStack — it’s modularity, flexibility and open design — what you get is the ability to craft a solution finely tuned to an operating environment of your design. Integrate solutions into the stack as you see fit. Contribute code. Develop an ecosystem. Integrate, manage, maintain…
This is as much a problem as it is a solution for an enterprise. This is why, in many cases, enterprises choose to use a single vendor with a single neck to choke in order to avoid having to act as an integrator in the first place or simply look to outsource to one or more public cloud providers and avoid this in the first place.
Chances are, most are realistically caught up somewhere in the nether-regions in between the two.
This all sounds so eerily familiar…
Revisiting Virtualization & Cloud Stack Security – Back to the Future (Baked In Or Bolted On?)
Last Updated on Monday, 12 March 2012 12:25 Written by Celframe Security Team Saturday, 7 April 2012 04:26
[Like a good w[h]ine, this post goes especially well with a couple of other courses such as Hack The Stack Or Go On a Bender With a Vendor?, Incomplete Thought: Why Security Doesn’t Scale…Yet, What’s The Problem With Cloud Security? There’s Too Much Of It…, Incomplete Thought: The Other Side Of Cloud – Where The (Wild) Infrastructure Things Are… and Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where…]
There are generally three dichotomies of thought when it comes to the notion of how much security should fall to the provider of the virtualization or cloud stack versus that of the consumer of their services or a set of third parties:The virtualization/cloud stack provider should provide a rich tapestry of robust security capabilities “baked in” to the platform itself, orThe virtualization/cloud stack provider should provide security-enabling hooks to enable an ecosystem of security vendors to provide the bulk of security (beyond isolation) to be “bolted on,” orThe virtualization/cloud stack provider should maximize the security of the underlying virtualization/cloud platform and focus on API security, isolation and availability of service only while pushing the bulk of security up into the higher-level programatic/application layers, or
So where are we today? How much security does the stack, itself, need to provide. The answer, however polarized, is somewhere in the murkiness dictated by the delivery models, deployment models, who owns what part of the real estate and the use cases of both the virtualization/cloud stack provider and ultimately the consumer.
I’ve had a really interesting series of debates with the likes of Simon Crosby (of Xen/Citrix fame) on this topic and we even had a great debate at RSA with Steve Herrod from VMware. These two “infrastructure” companies and their solutions typify the diametrically opposed first two approaches to answering this question while cloud providers who own their respective custom-rolled “stacks” at either end of IaaS and SaaS spectrums such as Amazon Web Services and Salesforce bringing up the third.
As with anything, this is about the tenuous balance of “security,” compliance, cost, core competence and maturity of solutions coupled with the sensitivity of the information that requires protection and the risk associated with the lopsided imbalance that occurs in the event of loss.
There’s no single best answer which explains why were have three very different approaches to what many, unfortunately, view as the same problem.
Today’s “baked in” security capabilities aren’t that altogether mature or differentiated, the hooks and APIs that allow for diversity and “defense in depth” provide for new and interesting ways to instantiate security, but also add to complexity, driving us back to an integration play. The third is looked upon as proprietary and limiting in terms of visibility and transparency and don’t solve problems such as application and information security any more than the other two do.
Will security get “better” as we move forward with virtualization and cloud computing. Certainly. Perhaps because of it, perhaps in spite of it.
One thing’s for sure, it’s going to be messy, despite what the marketing says.