Search Results

Keyword: ‘private cloud’

Dear SaaS Vendors: If Cloud Is The Way Forward & Companies Shouldn’t Spend $ On Privately-Operated Infrastructure, When Are You Moving Yours To Amazon Web Services?

April 30th, 2010 6 comments

We’re told repetitively by Software as a Service (SaaS)* vendors that infrastructure is irrelevant, that CapEx spending is for fools and that Cloud Computing has fundamentally changed the way we will, forever, consume computing resources.

Why is it then that many of the largest SaaS providers on the planet (including firms like, Twitter, Facebook, etc.) continue to build their software and choose to run it in their own datacenters on their own infrastructure?  In fact, many of them are on a tear involving multi-hundred million dollar (read: infrastructure) private datacenter build-outs.

I mean, SaaS is all about the software and service delivery, right?  IaaS/PaaS is the perfect vehicle for the delivery of scaleable software, right?  So why do you continue to try to convince *us* to move our software to you and yet *you* don’t/won’t/can’t move your software to someone else like AWS?

Hypocricloud: SaaS firms telling us we’re backwards for investing in infrastructure when they don’t eat the dog food they’re dispensing (AKA we’ll build private clouds and operate them, but tell you they’re a bad idea, in order to provide public cloud offerings to you…)

Quid pro quo, agent Starling.


* I originally addressed this to via Twitter in response to Peter Coffee’s blog here but repurposed the title to apply to SaaS vendors in general.

Reblog this post [with Zemanta]

The Vagaries Of Cloudcabulary: Why Public, Private, Internal & External Definitions Don’t Work…

April 5th, 2009 19 comments

Updated again at 13:43pm EST – Please see bottom of post

Hybrid, Public, Private, Internal and External.

The HPPIE model; you’ve heard these terms used to describe and define the various types of Cloud.

What’s always disturbed me about using these terms singularly is that separetely they actually address scenarios that are orthogonal and yet are often used to compare and contrast one service/offering to another.

The short story: Hybrid, Public, and Private denote ownership and governance whilst Internal and External denote location.

The longer story: Hybrid, Public, Private, Internal and External seek to summarily describe no less than five different issues and categorize a cloud service/offering into one dumbed-down term for convenience.  In terms of a Cloud service/offering, using one of the HPPIE labels actually attempts to address in one word:

  1. Who manages it
  2. Who owns it
  3. Where it’s located
  4. Who has access to it
  5. How it’s accessed

That’s a pretty tall order.  I know we’re aiming for simplicity in description by using a label analogous to LAN, WAN, Intranet or Internet , but unfortunately what we’re often describing here is evolving to be much more complex.

Don’t get me wrong, I’m not aiming for precision but instead  accuracy.  I don’t find that these labels do a good enough job when used by themselves.

Further, you’ll find most people using the service deployment models (Hybrid, Public, Private) in absence of the service delivery models (SPI – Saas/PaaS/IaaS) while at the same time intertwining the location of the asset (internal, external) usually relative to a perimeter firewall (more on this in another post.)

This really lends itself to confusion.

I’m not looking to rename the HPPIE terms.  I am looking to use them more accurately.

Here’s a contentious example.  I maintain you can have an IaaS service that is Public and Internal.  WHAT!?  HOW!?

Let’s take a look at a summary table I built to think through use cases by looking at the three service deployment models (Hybrid, Public and Private):

The HPPIE Table


The blue separators in the table designate derivative service offerings and not just a simple and/or; they represent an actual branching of the offering.

Back to my contentious example wherein I maintain you can have an IaaS offering which is Public and yet also Internal. Again How?

Remember how I said “Hybrid, Public, and Private denote ownership and governance whilst Internal and External denote location?” That location refers to both the physical location of the asset as well as the logical location relative to an organization’s management umbrella which includes operations, security, compliance, etc.

Thus if you look at a managed infrastructure service (name one) that utilizes Cloud Computing principles, there’s no reason that a third party MSP could not deploy said service internally on customer premises equipment which the third party owns but operates and manages on behalf of an organization with the scale and pay-by-use model of Cloud internally that can include access from trusted OR untrusted sources, is there?

Some might call it a perversion of the term “Public.” I highlight it to illustrate that “Public” is a crappy word for the example because just as it’s valid in this example, it’s equally as valid to suggest that Amazon’s EC2 can also share the “Public” moniker, despite being External.

In the same light, one can easily derive examples of SaaS:Private:Internal offerings…You see my problem with these terms?

Moreover, the “consumer” focus of the traditional HPPIE models means that using broad terms like these generally implies that people are describing access to a service/offering by a human operating a web browser, and do not take into account access to services/offerings via things like API’s or programmatic interfaces.

This is a little goofy, too. I don’t generally use a web browser  (directly) to access Amazon’s S3 Storage-as-a-Service offering just like I don’t use a web browser to make API calls in GoogleGears.  Other non-interactive elements of the AppStack do that.

I don’t expect people to stop using these dumbed down definitions, but this is why it makes me nuts when people compare “Private” Cloud offerings with “Internal” ones. It’s like comparing apples and buffalo.

What I want is for people to at least not include Internal and External as Cloud models, but rather used them as parameters like I have in the table above.

Does this make any sense to you?

Update: In a great set of discussions regarding this on Twitter with @jamesurquhart from Cisco and @zhenjl from VMware, @zhenjl came up with a really poignant solution to the issues surrounding the redefinition of Public Cloud and their ability to be deployed “internally.”  His idea which highlights the “third party managed” example I gave is to add a new category/class called “Managed” which is essentially the example which I highlighted in boldface above:


This means that we would modify the table above to look more like this (updated again based on feedback on Twitter & comments) — Ultimately revised as part of the work I did for the Cloud Security Alliance in alignment to the NIST model, abandoning the ‘Managed’ section:

Revised Model

This preserves the notion of how people generally define “Public” clouds but also makes a critical distinction between what amounts to managed Cloud services which are provided by third parties using infrastructure/services located on-premise. It also still allows for the notion of Private Clouds which are distinct.


Related articles by Zemanta

Enhanced by Zemanta
Categories: Cloud Computing, Cloud Security Tags:

Internal v. External/Private v. Public/On-Premise v. Off- Premise: It’s all Cloud But How You Get There Is Important.

February 24th, 2009 No comments

I've written about the really confusing notional definitions that seem to be hung up on where the computing actually happens when you say "Cloud:" in your datacenter or someone else's.  It's frustrating to see how people mush together "public, private, internal, external, on-premise, off-premise" to all mean the same thing.

They don't, or at least they shouldn't, at least not within the true context of Cloud Computing.

In the long run, despite all the attempts to clarify what we mean by defining "Cloud Computing" more specifically as it relates to compute location, we're going to continue to call it "Cloud."  It's a sad admission I'm trying to come to grips with.  So I'll jump on this bandwagon and take another approach.

Cloud Computing will simply become ubiquitous in it's many forms and we are all going to end up with a hybrid model of Cloud adoption — a veritable mash-up of Cloud services spanning the entire gamut of offerings.  We already have today.

Here are a few, none-exhaustive examples of what a reasonably-sized enterprise can expect from the move to a hybrid Cloud environment:
  1. If you're using one or more SaaS vendors who own the entire stack, you'll be using their publicly-exposed Cloud offerings.  They manage the whole kit-and-kaboodle, information and all. 
  2. SaaS and PaaS vendors will provide ways of integrating their offerings (some do today) with your "private" enterprise data stores and directory services for better integration and business intelligence.
  3. We'll see the simple evolution of hosting/colocation providers add dynamic scalability and utility billing and really push the Cloud mantra.  
  4. IaaS vendors will provide (ala GoGrid) ways of consolidating and reducing infrastructure footprints in your enterprise datacenters by way of securely interconnecting your private enterprise infrastructure with managed infrastructure in their datacenters. This model simply calls for the offloading of the heavy tin. Management options abound: you manage it, they manage it, you both do…
  5. Other IaaS players will continue to offer a compelling suite of soup-to-nuts services (ala Amazon) that depending upon your needs and requirements, means you have very little (or no) infrastructure to speak of.  You may or may not be constrained by what you can or need to do as you trade of flexibility for conformity here.
  6. Virtualization platform providers will no longer make a distinction in terms of roadmap and product positioning between internal/external or public/private. What is enterprise virtualization today simply becomes "Cloud."  The same services, split along virtualization platform party lines, will become available regardless of location. 
  7. This means that vendors who today offer proprietary images and infrastructure will start to drive or be driven to integrate more open standards across their offerings in order to allow for portability, interoperability and inter-Cloud scalability…and to make sure you remain a customer.
  8. Even though the Cloud is supposed to abstract infrastructure from your concern as a customer, brand-associated moving parts will count; customers will look for pure-play vetted integration between the big players (networking, virtualization, storage) in order to fluidly move information and applications into and out of Cloud offerings seamlessly 
  9. The notion of storage is going to be turned on its head; the commodity of bit buckets isn't what storage means in the Cloud.  All the chewy goodness will start to bubble to the surface as value-adds come to light: DeDup, backup, metadata, search, convergence with networking, security…
  10. More client side computing will move to the cloud (remember, it doesn't matter whether it's internal or external) with thin client connectivity while powerful smaller-footprint mobile platforms (smartphones/netbooks) with native virtualization layers will also accelerate in uptake

Ultimately, what powers your Cloud providers WILL matter.  What companies adopt internally as their virtualization, networking, application delivery, security and storage platforms internally as they move to consolidate and then automate will be a likely choice when evaluating top-rung weighting when they identify what powers many of their Cloud providers' infrastructure.

If a customer can take all the technology expertise, the organizational and operational practices they have honed as they virtualize their internal infrastructure (virtualization platform, compute, storage, networking, security) and basically be able to seamlessly apply that as a next step as the move to the Cloud(s), it's a win.

The two biggest elements of a successful cloud: integration and management. Just like always.

I can't wait.


*Yes, we're concerned that if "stuff" is outside of our direct control, we'll not be able to "secure" it, but that isn't exactly a new concept, nor is it specific to Cloud — it's just the latest horse we're beating because we haven't made much gains in being able to secure the things that matter most in the ways most effective for doing that.

How To Be a Cloud Mogul(l) – Our 2014 RSA “Dueling Banjos/Cloud/DevOps” Talk

March 27th, 2014 No comments

dueling_banjosRich Mogull (Securosis) and I have given  a standing set of talks over the last 5-6 years at the RSA Security Conference that focus on innovation, disruption and ultimately making security practitioners more relevant in the face of all this churn.

We’ve always offered practical peeks of what’s coming and what folks can do to prepare.

This year, we (I should say mostly Rich) built a bunch of Ruby code that leveraged stuff running in Amazon Web Services (and using other Cloud services) to show how security folks with little “coding” capabilities could build and deploy this themselves.

Specifically, this talk was about SecDevOps — using principles that allow for automated and elastic cloud services to do interesting security things that can be leveraged in public and private clouds using Chef and other assorted mechanisms.

I also built a bunch of stuff using the RackSpace Private Cloud stack and Chef, but didn’t have the wherewithal or time to demonstrate it — and doing live demos over a tethered iPad connection to AWS meant that if it sucked, it was Rich’s fault.

You can find the presentation here (it clearly doesn’t include the live demos):

Dueling Banjos – Cloud vs. Enterprise Security: Using Automation and (Sec)DevOps NOW



Cloud Service Providers and the Dual Stack Dilemma

September 20th, 2012 1 comment

I wrote this blog and then jumped on Twitter to summarize/crystallize what I thought were the most important bits:

…and thus realized I didn’t really need to finish drafting the blog since I’d managed to say it in three tweets.

Twitter has indeed killed the WordPress star…

More detailed version below.  Not finished.  TL;DR


—– (below unedited for tense, grammar, logical thought or completeness…) —–

Read more…

Categories: Cloud Computing, Cloud Security Tags:

PrivateCore: Another Virtualization-Enabled Security Solution Launches…

June 21st, 2012 No comments

On the heels of Bromium’s coming-out party yesterday at Gigamon’s Structure conference, PrivateCore — a company founded by VMware vets Oded Horovitz and Carl Waldspurger and Google’s Steve Weis — announced a round of financing and what I interpret as a more interesting and focused Raison d’être.

Previously in videos released by Oded, he described the company’s focus around protecting servers (cloud, otherwise) against physical incursion whilst extracting contents from memory, etc. where physical access is required.

From what I could glean, the PrivateCore solution utilizes encryption and CPU cache (need to confirm) to provide memory isolation to render these attack vectors moot.

What’s interesting is the way in which PrivateCore is now highlighting the vehicle for their solution; a “hardened hypervisor.”

It will be interesting to see how well they can market this approach/technology (and to whom,) what sort of API/management planes their VMM provides and how long they stand-alone before being snapped up — perhaps even by VMware or Citrix.

More good action (and $2.25M in funding) in the virtual security space.


Enhanced by Zemanta

Incomplete Thought: On Horseshoes & Hand Grenades – Security In Enterprise Virt/Cloud Stacks

May 22nd, 2012 7 comments

It’s not really *that* incomplete of a thought, but I figure I’d get it down on vPaper anyway…be forewarned, it’s massively over-simplified.

Over the last five years or so, I’ve spent my time working with enterprises who are building and deploying large scale (relative to an Enterprise’s requirements, that is) virtualized data centers and private cloud environments.

For the purpose of this discussion, I am referring to VMware-based deployments given the audience and solutions I will reference.

To this day, I’m often shocked with regard to how many of these organizations that seek to provide contextualized security for intra- and inter-VM traffic seem to position an either-or decision with respect to the use of physical or virtual security solutions.

For the sake of example, I’ll reference the architectural designs which were taken verbatim from my 2008 presentationThe Four Horsemen of the Virtualization Security Apocalypse.

If you’ve seen/read the FHOTVA, you will recollect that there are many tradeoffs involved when considering the use of virtual security appliances and their integration with physical solutions.  Notably, an all-virtual or all-physical approach will constrain you in one form or another from the perspective of efficacy, agility, and the impact architecturally, operationally, or economically.

The topic that has a bunch of hair on it is where I see many enterprises trending: obviating virtual solutions and using physical appliances only:


…the bit that’s missing in the picture is the external physical firewall connected to that physical switch.  People are still, in this day and age, ONLY relying on horseshoeing all traffic between VMs (in the same or different VLANs) out of the physical cluster machine and to an external firewall.

Now, there are many physical firewalls that allow for virtualized contexts, zoning, etc., but that’s really dependent upon dumping trunked VLAN ports from the firewall/switches into the server and then “extending” virtual network contexts, policies, etc. upstream in an attempt to flatten the physical/virtual networks in order to force traffic through a physical firewall hop — sometimes at layer 2, sometimes at layer 3.

It’s important to realize that physical firewalls DO offer benefits over the virtual appliances in terms of functionality, performance, and some capabilities that depend on hardware acceleration, etc. but from an overall architectural positioning, they’re not sufficient, especially given the visibility and access to virtual networks that the physical firewalls often do not have if segregated.

Here’s a hint, physical-only firewall solutions alone will never scale with the agility required to service the virtualized workloads that they are designed to protect.  Further, a physical-only solution won’t satisfy the needs to dynamically provision and orchestrate security as close to the workload as possible, when the workloads move the policies will generally break, and it will most certainly add latency and ultimately hamper network designs (both physical and virtual.)

Virtual security solutions — especially those which integrate with the virtualization/cloud stack (in VMware’s case, vCenter & vCloud Director) — offer the ability to do the following:

…which is to say that there exists the capability to utilize  virtual solutions for “east-west” traffic and physical solutions for “north-south” traffic, regardless of whether these VMs are in the same or different VLAN boundaries or even across distributed virtual switches which exist across hypervisors on different physical cluster members.

For east-west traffic (and even north-south models depending upon network architecture) there’s no requirement to horseshoe traffic physically. 

It’s probably important to mention that while the next slide is out-of-date from the perspective of the advancement of VMsafe APIs, there’s not only the ability to inject a slow-path (user mode) virtual appliance between vSwitches, but also utilize a set of APIs to instantiate security policies at the hypervisor layer via a fast path kernel module/filter set…this means greater performance and the ability to scale better across physical clusters and distributed virtual switching:

Interestingly, there also exists the capability to actually integrate policies and zoning from physical firewalls and have them “flow through” to the virtual appliances to provide “micro-perimeterization” within the virtual environment, preserving policy and topology.

There are at least three choices for hypervisor management-integrated solutions on the market for these solutions today:

  • VMware vShield App,
  • Cisco VSG+Nexus 1000v and
  • Juniper vGW

Note that the solutions above can be thought of as “layer 2” solutions — it’s a poor way of describing them, but think “inter-VM” introspection for workloads in VLAN buckets.  All three vendors above also have, or are bringing to market, complementary “layer 3” solutions that function as virtual “edge” devices and act as a multi-function “next-hop” gateway between groups of VMs/applications (nee vDC.)  For the sake of brevity, I’m omitting those here (they are incredibly important, however.)

They (layer 2 solutions) are all reasonably mature and offer various performance, efficacy and feature set capabilities. There are also different methods for plumbing the solutions and steering traffic to them…and these have huge performance and scale implications.

It’s important to recognize that the lack of thinking about virtual solutions often seem to be based largely on ignorance of need and availability of solutions.

However, other reasons surface such as cost, operational concerns and compliance issues with security teams or assessors/auditors who don’t understand virtualized environments well enough.

From an engineering and architectural perspective, however, obviating them from design consideration is a disappointing concern.

Enterprises should consider a hybrid of the two models; virtual where you can, physical where you must.

If you’ve considered virtual solutions but chose not to deploy them, can you comment on why and share your thinking with us (even if it’s for the reasons above?)


Enhanced by Zemanta

Incomplete Thought: Will the Public Cloud Create a Generation Of Network Stupid?

March 26th, 2012 31 comments

Short and sweet…

With the continued network abstraction and “simplicity” presented by public cloud platforms like AWS EC2* wherein instances are singly-homed and the level of networking is so dumbed down so as to make deep networking knowledge “unnecessary,” will the skill sets of next generation operators become “network stupid?”

The platform operators will continue to hire skilled network architects, engineers and operators, but the ultimate consumers of these services are being sold on the fact that they won’t have to and in many cases this means that “networking” as a discipline may face a skills shortage.

The interesting implications here is that with all this abstraction and opaque stacks, resilient design is still dependent upon so much “networking” — although much of it is layer 4 and above.  Yep, it’s still TCP/IP, but the implications that the dumbing down of the stack will be profound, especially if one recognizes that ultimately these Public clouds will interconnect to Private clouds, and the two networking models are profoundly differentiated.

…think VMware versus AWS EC2…or check out the meet-in-the-middle approach with OpenStack and Quantum…

I’m concerned that we’re still so bifurcated in our discussions of networking and the Cloud.

One the one hand we’re yapping at one another about stretched L2 domains, fabrics and control/data plane separation or staring into the abyss of L7 proxies and DPI…all the while the implications of SDN and emergence of new protocols, the majority of which are irrelevant to the consumers deploying VMs and apps atop IaaS and PaaS (not to mention SaaS,) makes these discussions seem silly.

On the other hand, DevOps/NoOps folks push their code to platforms that rely less and less on needing to understand or care how the underlying “network” works.

Its’ hard to tell whether “networking” in the pure sense will be important in the long term.

Or as Kaminsky so (per usual) elegantly summarized:

What are your thoughts?


*…and yet we see more “complex” capabilities emerging in scenarios such as AWS VPC…


Enhanced by Zemanta
Categories: Cloud Computing, Networking Tags:

Security As A Service: “The Cloud” & Why It’s a Net Security Win

March 19th, 2012 3 comments
Cloud Computing Image

Cloud Computing Image (Photo credit: Wikipedia)

If you’ve been paying attention to the rash of security startups entering the market today, you will no doubt notice the theme wherein the majority of them are, from the get-go, organizing around deployment models which operate from “The Cloud.”

We can argue that “Security as a service” usually refers to security services provided by a third party using the SaaS (software as a service) model, but there’s a compelling set of capabilities that enables companies large and small to be both effective, efficient and cost-manageable as we embrace the “new” world of highly distributed applications, content and communications (cloud and mobility combined.)

As with virtualization, when one discusses “security” and “cloud computing,” any of the three perspectives often are conflated (from my post “Security: In the Cloud, For the Cloud & By the Cloud…“):

In the same way that I differentiated “Virtualizing Security, Securing Virtualization and Security via Virtualization” in my Four Horsemen presentation, I ask people to consider these three models when discussing security and Cloud:

  1. In the Cloud: Security (products, solutions, technology) instantiated as an operational capability deployed within Cloud Computing environments (up/down the stack.) Think virtualized firewalls, IDP, AV, DLP, DoS/DDoS, IAM, etc.
  2. For the Cloud: Security services that are specifically targeted toward securing OTHER Cloud Computing services, delivered by Cloud Computing providers (see next entry) . Think cloud-based Anti-spam, DDoS, DLP, WAF, etc.
  3. By the Cloud: Security services delivered by Cloud Computing services which are used by providers in option #2 which often rely on those features described in option #1.  Think, well…basically any service these days that brand themselves as Cloud… ;)

What I’m talking about here is really item #3; security “by the cloud,” wherein these services utilize any cloud-based platform (SaaS, PaaS or IaaS) to delivery security capabilities on behalf of the provider or ultimate consumer of services.

For the SMB/SME/Branch, one can expect a hybrid model of on-premises physical (multi-function) devices that also incorporate some sort of redirect or offload to these cloud-based services. Frankly, the same model works for the larger enterprise but in many cases regulatory issues of privacy/IP concerns arise.  This is where the capability of both “private” (or dedicated) versions of these services are requested (either on-premises or off, but dedicated.)

Service providers see a large opportunity to finally deliver value-added, scaleable and revenue-generating security services atop what they offer today.  This is the realized vision of the long-awaited “clean pipes” and “secure hosting” capabilities.  See this post from 2007 “Clean Pipes – Less Sewerage or More Potable Water?”

If you haven’t noticed your service providers dipping their toes here, you certainly have seen startups (and larger security players) do so.  Here are just a few examples:

  • Qualys
  • Trend Micro
  • Symantec
  • Cisco (Ironport/ScanSafe)
  • Juniper
  • CloudFlare
  • ZScaler
  • Incapsula
  • Dome9
  • CloudPassage
  • Porticor
  • …and many more

As many vendors “virtualize” their offers and start to realize that through basic networking, APIs, service chaining, traffic steering and security intelligence/analytics, these solutions become more scaleable, leveragable and interoperable, the services you’ll be able to consume will also increase…and they will become more application and information-centric in nature.

Again, this doesn’t mean the disappearance of on-premises or host-based security capabilities, but you should expect the cloud (and it’s derivative offshoots like Big Data) to deliver some really awesome hybrid security capabilities that make your life easier.  Rich Mogull (@rmogull) and I gave about 20 examples of this in our “Grilling Cloudicorns: Mythical CloudSec Tools You Can Use Today” at RSA last month.

Get ready because while security folks often eye “The Cloud” suspiciously, it also offers up a set of emerging solutions that will undoubtedly allow for more efficient, effective and affordable security capabilities that will allow us to focus more on the things that matter.


Related articles by Zemanta

Enhanced by Zemanta

AwkwardCloud: Here’s Hopin’ For Open

February 14th, 2012 3 comments


There’s no way to write this without making it seem like I’m attacking the person whose words I am about to stare rudely at, squint and poke out my tongue.

No, it’s not @reillyusa, featured to the right.  But that expression about sums up my motivation.

Because this ugly game of “Words With Friends” is likely to be received as though I’m at odds with what represents the core marketing message of a company, I think I’m going to be voted off the island.

Wouldn’t be the first time.  Won’t be the last.  It’s not personal.  It’s just cloud, bro.

This week at Cloud Connect, @randybias announced that his company, Cloudscaling, is releasing a new suite of solutions branded under the marketing moniker of  “Open Cloud.”

I started to explore my allergy to some of these message snippets as they were strategically “leaked” last week in a most unfortunate Twitter exchange.  I promised I would wait until the actual launch to comment further.

This is my reaction to the website, press release and blog only.  I’ve not spoken to Randy.  This is simply my reaction to what is being placed in public.  It’s not someone else’s interpretation of what was said.  It’s straight from the Cloud Pony’s mouth. ;p


“Open Cloud” is described as a set of solutions for those looking to deploy clouds that provide “… better economics, greater flexibility, and less lock-in, while maintaining control and governance” than so-called Enterprise Clouds that are based on what Randy tags are more proprietary foundations.

The case is made where enterprises will really want to build two clouds: one to run legacy apps and one to run purpose-built cloud-ready applications.  I’d say that enterprises that have a strategy are likely looking forward to using clouds of both models…and probably a few more, such as SaaS and PaaS.

This is clearly a very targeted solution which looks to replicate AWS’ model for enterprises or SP’s who are looking to exercise more control over the fate over their infrastructure.  How much runway this serves against the onslaught of PaaS and SaaS will play out.

I think it’s a reasonable bet there’s quite a bit of shelf life left on IaaS and I wonder if we’ll see follow-on generations to focus on PaaS.

Yet I digress…

This is NOT going to be a rant about the core definition of “Open,” (that’s for Twitter) nor is this going to be one of those 40 pagers where I deconstruct an entire blog.  It would be fun, easy and rather useful, but I won’t.

No. Instead I  will suggest that the use of the word “Open” in this press release is nothing more than opportunistic marketing, capitalizing on other recent uses of the Open* suffix such as “OpenCompute, OpenFlow, Open vSwitch, OpenStack, etc.” and is a direct shot across the bow of other companies that have released similar solutions in the near past (, Piston, Nebula)

If we look at what makes up “Open Cloud,” we discover it is framed upon on four key solution areas and supported by design blueprints, support and services:

  1. Open Hardware
  2. Open Networking
  3. Open APIs
  4. Open Source Software

I’m not going to debate the veracity or usefulness of some of these terms directly, but we’ll come back to them as a reference in a second, especially the notion of “open hardware.”

The one thing that really stuck under my craw was the manufactured criteria that somehow defined the so-called “litmus tests” associated with “Enterprise” versus “Open” clouds.

Randy suggests that if you are doing more than 1/2 of the items in the left hand column you’re using a cloud built with “enterprise computing technology” versus “open” cloud should the same use hold true for the right hand column:

So here’s the thing.  Can you explain to me what spinning up 1000 VM’s in less than 5 minutes has to do with being “open?”  Can you tell me what competing with AWS on price has to do with being “open?” Can you tell me how Hadoop performance has anything to do with being “open?”  Why does using two third-party companies management services define “open?”

Why on earth does the complexity or simplicity of networking stacks define “openness?”

Can you tell me how, if Cloudscaling’s “Open Cloud” uses certified vendors from “name brand” vendors like Arista how this is any way more “open” than using an alternative solution using Cisco?

Can you tell me if “Open Cloud” is more “open” than Piston Cloud which is also based upon OpenStack but also uses specific name-brand hardware to run?  If “Open Cloud” is “open,” and utilizes open source, can I download all the source code?

These are simply manufactured constructs which do little service toward actually pointing out the real business value of the solution and instead cloaks the wolf in the “open” sheep’s clothing.  It’s really unfortunate.

The end of my rant here is that by co-opting the word “open,” this takes a perfectly reasonable approach of a company’s experience in building a well sorted, (supposedly more) economical and supportable set of cloud solutions and ruins it by letting its karma get run over by its dogma.

Instead of focusing on the merits of the solution as a capable building block for building plain better clouds, this reads like a manifesto which may very well turn people off.

Am I being unfair in calling this out?  I don’t think so.  Would some prefer a private conversation over a beer to discuss?  Most likely.  However, there’s a disconnect here and it stems from pushing public a message and marketing a set of solutions that I hope will withstand the scrutiny of this A-hole with a blog.

Maybe I’m making a mountain out of a molehill…

Again, I’m not looking to pick on Cloudscaling.  I think the business model and the plan is solid as is evidenced by their success to date.  I wish them nothing but success.

I just hope that what comes out the other end is being “open” to consider a better adjective and more useful set of criteria to define the merits of the solution.


Enhanced by Zemanta