Rational Survivability

Greg Ness touched off an interesting discussion when he asked “Will Virtualization Undermine Network Equipment Vendors?”  It’s a great read summarizing how virtualization (and Cloud) are really beginning to accelerate how classical networking equipment vendors are re-evaluating their portfolios in order to come to terms with these disruptive innovations.

I’ve written so much about this over the last three years and my response is short and sweet:

Virtualization has actually long been an enabler for network equipment vendors — not server virtualization, mind you, but network virtualization.  The same goes in the security space. The disruption caused by server virtualization is only acting as an accelerant — pushing the limits of scale, redefining organizational and operational boundaries, and acting as a forcing function causing wholesale reconsideration of archetypal network (and security) topologies.

The compressed timeframe associated with the disruption caused by virtualization and its adoption in conjunction with the arrival of Cloud Computing may seem unnatural given the relatively short window associated with its arrival, but when one takes the longer-term view, it’s quite natural.  We’ve seen it before in vignettes across the evolution of computing, but the convergence of economics, culture, technology and consumerism have amplified its relevance.

To answer Greg’s question, Virtualization will only undermine those network equipment vendors who were not prepared for it in the first place.  Those that were building highly virtualized, context-enabled routing, switching and security products will embrace this swing in the hardware/software pendulum and develop hybrid solutions that span the physical and virtual manifestations of what the “network” has become.

As I mentioned in my blog titled “Quick Bit: Virtual & Cloud Networking – Where It ISN’T Going…”

Specifically, as it comes to understanding how the network plays in virtual and Cloud architectures, it’s not where the network *is* in the increasingly complex virtualized, converged and unified computing architectures, it’s where networking *isn’t.*

Where ISN'T The Network?

Take a look at your network equipment vendors.  Where do they play in that stack above?  Compare and contrast that with what is going on with vendors like Citrix/Xen with the Open vSwitch, Vyatta, Arista with vEOS and Cisco with the Nexus 1000v*…interesting times for sure.

/Hoff

*Disclosure: I work for Cisco.

Balakrishna Narasimh and I were discussing the recent hoohaa on Public and Private Clouds when he made an observation on Twitter:

Starting to think public vs private clouds is misleading terminology. more meaningful distinction is single-tenant vs multi-tenant clouds.

I suggested that multitenancy can certainly be an attribute of Cloud deployment, but that I don’t see it as being a differentiator.  I responded thusly:

So different business units in an enterprise don’t represent different “tenants?” They can be governed w/ diff. SLA, policy, $

My point here was that trying to use multitenancy as a way to distinguish between Public and Private Cloud deployments ignores the reality that in many large enterprises — many of whom who are beginning to architect and deploy Private Clouds — they think of their business constituencies as individual “tenants.”  Each of these “tenants” often have different business requirements, service level requirements, cost structure and chargeback rates, policies, etc.

Food for thought.

/Hoff

Werner Vogels brought a smile to my face today with his blog titled “Seamlessly Extending the Data Center – Introducing Amazon Virtual Private Cloud.”  In short:

We have developed Amazon Virtual Private Cloud (Amazon VPC) to allow our customers to seamlessly extend their IT infrastructure into the cloud while maintaining the levels of isolation required for their enterprise management tools to do their work.

In one fell swoop, AWS has:

• Legitimized Private Cloud as a reasonable, needed, and prudent step toward Cloud adoption for enterprises,
• Substantiated the value proposition of Private Cloud as a way of removing a barrier to Cloud entry for enterprises, and
• Validated the ultimate vision toward hybrid Clouds and Inter-Cloud

They made this announcement from the vantage point of operating as a Public Cloud provider — in many cases THE Public Cloud provider of choice for those arguing from an exclusionary perspective that Public Cloud is the only way forward.

Now, it’s pretty clear on AWS’ position on Private Cloud; straight form the horse’s mouth Werner says “Private Cloud is not the Cloud” (see below) — but it’s also clear they’re willing to sell you some 😉

The cost for VPC isn’t exorbitant, but it’s not free, either, so the business case is clearly there (see the official VPC site)– VPN connectivity is $0.05 per VPN connection with data transfer rates of $0.10 per GB inbound and ranging from $0.17 per GB – $0.10 per GB outbound depending upon volume (with heavy data replication or intensive workloads people are going to need to watch the odometer.)

I’m going to highlight a couple of nuggets from his post:

We continuously listen to our customers to make sure our roadmap matches their needs. One important piece of feedback that mainly came from our enterprise customers was that the transition to the cloud of more complex enterprise environments was challenging. We made it a priority to address this and have worked hard in the past year to find new ways to help our customers transition applications and services to the cloud, while protecting their investments in their existing IT infrastructure. …

Private Cloud Is Not The Cloud – These CIOs know that what is sometimes dubbed “private cloud” does not meet their goal as it does not give them the benefits of the cloud: true elasticity and capex elimination. Virtualization and increased automation may give them some improvements in utilization, but they would still be holding the capital, and the operational cost would still be significantly higher.

…

We have been listening very closely to the real requirements that our customers have and have worked closely with many of these CIOs and their teams to understand what solution would allow them to treat the cloud as a seamless extension of their datacenter, where their standard management practices can be applied with limited or no modifications. This needs to be a solution where they get all the benefits of cloud as mentioned above [Ed: eliminates cost, elastic, removes “undifferentiated heavy lifting”] while treating it as a part of their datacenter.

We have developed Amazon Virtual Private Cloud (Amazon VPC) to allow our customers to seamlessly extend their IT infrastructure into the cloud while maintaining the levels of isolation required for their enterprise management tools to do their work.

With Amazon VPC you can:

• Create a Virtual Private Cloud and assign an IP address block to the VPC. The address block needs to be CIDR block such that it will be easy for your internal networking to route traffic to and from the VPC instance. These are addresses you own and control, most likely as part of your current datacenter addressing practice.
• Divide the VPC addressing up into subnets in a manner that is convenient for managing the applications and services you want run in the VPC.
• Create a VPN connection between the VPN Gateway that is part of the VPC instance and an IPSec-based VPN router on your own premises. Configure your internal routers such that traffic for the VPC address block will flow over the VPN.
• Start adding AWS cloud resources to your VPC. These resources are fully isolated and can only communicate to other resources in the same VPC and with those resources accessible via the VPN router. Accessibility of other resources, including those on the public internet, is subject to the standard enterprise routing and firewall policies.

Amazon VPC offers customers the best of both the cloud and the enterprise managed data center:

• Full flexibility in creating a network layout in the cloud that complies with the manner in which IT resources are managed in your own infrastructure.
• Isolating resources allocated in the cloud by only making them accessible through industry standard IPSec VPNs.
• Familiar cloud paradigm to acquire and release resources on demand within your VPC, making sure that you only use those resources you really need.
• Only pay for what you use. The resources that you place within a VPC are metered and billed using the familiar pay-as-you-go approach at the standard pricing levels published for all cloud customers. The creation of VPCs, subnets and VPN gateways is free of charge. VPN usage and VPN traffic are also priced at the familiar usage based structure

All the benefits from the cloud with respect to scalability and reliability, freeing up your engineers to work on things that really matter to your business.

Jeff Barr did a great job of giving a little more detail on his blog but also brought up a couple of points I need to noodle on from a security perspective:

Because the VPC subnets are used to isolate logically distinct functionality, we’ve chosen not to immediately support Amazon EC2 security groups. You can launch your own AMIs and most public AMIs, including Microsoft Windows AMIs. You can’t launch Amazon DevPay AMIs just yet, though.

The Amazon EC2 instances are on your network. They can access or be accessed by other systems on the network as if they were local. As far as you are concerned, the EC2 instances are additional local network resources — there is no NAT translation. EC2 instances within a VPC do not currently have Internet-facing IP addresses.

We’ve confirmed that a variety of Cisco and Juniper hardware/software VPN configurations are compatible; devices meeting our requirements as outlined in the box at right should be compatible too. We also plan to support Software VPNs in the near future.

The notion of the VPC and associated VPN connectivity coupled with the “software VPN” statement above reminds me of Cohesive F/T’s VPN-Cubed solution.  While this is an IaaS-focused discussion, it’s only fair to bring up Google’s Secure Data Connector that was announced some moons ago from a SaaS/PaaS perspective, too.

I would be remiss in my musings were I not to also suggest that Cloud brokers and Cloud service providers such as RightScale, GoGrid, Terremark, etc. were on the right path in responding to customers’ needs well before this announcement.

Further, it should be noted that now that the 800lb Gorilla has staked a flag, this will bring up all sorts of additional auditing and compliance questions, as any sort of broad connectivity into and out of security zones and asset groupings always do.  See the PCI debate (How to Be PCI Compliant In the Cloud)

At the end of the day, this is a great step forward toward — one I am happy to say that I’ve been talking about and presenting (see my Frogs presentation) for the last two years.

/Hoff

I was invited to add my comments to Appirio’s corporate blog in response to my opinions of their 2009 prediction “Rise and Fall of the Private Cloud,” but as I mentioned in kind on Twitter, debating a corporate talking point on a company’s blog is like watch two monkeys trying to screw a football; it’s messy and nobody wins.

However, in light of the fact that I’ve been preaching about the realities of phased adoption of Cloud — with Private Cloud being a necessary step — I thought I’d add my $0.02.  Of course, I’m doing so while on vacation, sitting on an ancient lava flow with my feet in the ocean in Hawaii, so it’s likely to be tropical in nature.

Short and sweet, here’s Appirio’s stance on Private Cloud:

Here’s the rub: Private clouds are just an expensive data center with a fancy name. We predict that 2009 will represent the rise and fall of this over-hyped concept. Of course, virtualization, service-oriented architectures, and open standards are all great things for every company operating a data center to consider. But all this talk about “private clouds” is a distraction from the real news: the vast majority of companies shouldn’t need to worry about operating any sort of data center anymore, cloud-like or not.

It’s clear that we’re talking about very different sets of companies. If we’re referring to SME/SMB’s, then I think it’s fair to suggest the sentiment above is valid.

If we’re talking about a large, heavily-regulated enterprise (pick your industry/vertical) with sunk costs and the desire/need to leverage the investment they’ve made in the consolidation, virtualization and enterprise modernization of their global datacenter footprints and take it to the next level, leveraging capabilities like automation, elasticity, and chargeback, it’s poppycock.

Further, it’s pretty clear that the hybrid model of Cloud will ultimately win in this space with the adoption of BOTH Public and Private Clouds where and when appropriate.

The idea that somehow companies can use “private cloud” technology to offer their employees web services similar to Google, Amazon, or salesforce.com will lead to massive disappointment.

So now the definition of “Cloud” is limited to “web services” and is defined by “Google, Amazon, or Salesforce.com?”

I call this MyopiCloud.  If this is the only measure of Cloud success, I’d be massively disappointed, also.

Onto the salient points:

Here’s why:

• Private clouds are sub-scale: There’s a reason why most innovative cloud computing providers have their roots in powering consumer web technology—that’s where the numbers are. Very few corporate data centers will see anything close to the type of volume seen by these vendors. And volume drives cost—the world has yet to see a truly “at scale” data center.

Interesting. If we hang the definition of “at scale” solely on Internet-based volume, I can see how this rings true.  However, large enterprises with LANs and WANs with multi-gigabit connectivity feeding server farms and client bases of internal constituents (not to mention extranet connections) need to be accounted for in that assessment, especially if we’re going to be honest about volume.  Limiting connectivity to only the Internet is unreasonable.

Certainly most enterprises are not autonomically elastic (neither are most Cloud providers today) but that’s why comparing apples to elephants is a bit silly, even with the benefits that virtualization is beginning to deliver in the compute, network and storage realms.

I know of an eCommerce provider who reports trafficing in (on average) 15 Gb/s of sustained HTTP traffic via its Internet feeds.  Want to guess what the internal traffic levels are inside what amounts to it’s Private Cloud at that level of ingress/egress?  Oh, did I just suggest that this “enterprise” is already running a “Private Cloud?”  Why yes, yes I did.  See James Watter’s interesting blog on something similar titled “Not So Fast Public Cloud: Big Players Still Run Privately.”

There’s no secret sauce: There’s no simple set of tricks that an operator of a data center can borrow from Amazon or Google. These companies make their living operating the world’s largest data centers. They are constantly optimizing how they operate based on real-time performance feedback from millions of transactions. (check out this presentation from Jeff Barr and Peter Coffee at the Architecture and Integration Summit). Can other operators of data centers learn something from this experience? Of course. But the rate of innovation will never be the same—private data centers will always be many, many steps behind the cloud.

Really? So technology such as Eucalyptus or VMware’s vCloud/Project Redwood doesn’t play here?  Certainly leveraging the operational models and technology underpinnings (regardless of volume) should allow an enterprise to scale massively, even it it’s not at the same levels, no?  The ability to scale to the needs of the business are important, even if you never do so at the scale of an AWS.  I don’t really understand this point.  My bandwidth is bigger than your bandwidth?

You can’t teach an old dog new tricks: What do you get when you move legacy applications as-is to a new and improved data center? Marginal improvements on your legacy applications. There’s only so much you can achieve without truly re-platforming your applications to a cloud infrastructure… you can’t teach an old dog new tricks. Now that’s not entirely fair…. You can certainly teach an old dog to be better behaved. But it’s still an old dog.

Woof! It’s really silly to suggest that the only thing an enterprise will do is simply move “legacy applications as-is to a new and improved data center” without any enterprise modernization, any optimization or the ability to more efficiently migrate to new and improved applications as the agility, flexibility and mobility issues are tackled.  Talk about pissing on fire hydrants!

On-premise does not equal secure: the biggest driver towards private clouds has been fear, uncertainty, and doubt about security. For many, it just feels more secure to have your data in a data center that you control. But is it? Unless your company spends more money and energy thinking about security than Amazon, Google, and Salesforce, the answer is probably “no.” (Read Craig Balding walk through “7 Technical Security Benefits of Cloud Computing”)

I’ve got news for you, just as on-premise does “…not equal secure,” neither does off-premise assure such.  I offer you this post as an example with all it’s related posts for color.

Please show me empirically that Amazon, Google or Salesforce spends “…more money and energy thinking about security” than, say, a Fortune 100 company.  Better yet, please show me how I can be, say, PCI compliant using AWS?  Oh, right…Please see the aforementioned posts…especially the one that demonstrates how the most public security gaffes thus far in Cloud are related to the providers you cite in your example.

May I suggest that being myopic and mixing metaphors broadly by combining the needs and business drivers of the SME/SMB and representing them as that of large enterprises is intellectually dishonest.

Let’s be real, Appirio is in the business of “Enabling enterprise adoption of on-demand for Salesforce.com and Google Enterprise” — two examples of externally hosted SaaS offerings that clearly aren’t aimed at enterprises who would otherwise be thinking about Private Cloud.

Oops, the luau drums are sounding.

Aloha.

Allan Leinwand from GigaOm wrote a really interesting blog the other day titled: “Do Enterprises Need a Toll Road to the Cloud?” in which he suggested that perhaps what is needed to guarantee high performance and high security Cloud connectivity is essentially a middleman that maintains dedicated aggregate connectivity between “…each of the public cloud providers:”

One solution would be for cloud services providers to offer dedicated leased line connections to their clouds. Though for many enterprises the cost of these leased lines over large geographies would be enough to eat into any savings they’d be getting by using the cloud in the first place. Another solution would come in the form of a service provider that aggregated dedicated connections to each of the public cloud providers.
…
This new provider — let’s call it CloudNAP (Cloud Network Access Point) — would solely be in the business of providing a toll road between the enterprise and the public cloud providers. The business of selling connectivity to the Internet, or transit, is a common ISP offering.  The CloudNAP transit service would be different, however, in that it would be focused on delivering connectivity solely between enterprises and cloud services providers and not between enterprises or between clouds.
…
The CloudNAP network could guarantee  performance between the enterprise and the cloud by working with the service providers to enable the use of quality-of-service techniques that are not available over the public Internet such a Multiprotocol Label Switching (MPLS) classes for WAN connections or IEEE 802.1p priorities for LAN connections. Perhaps CloudNAP could even restrict the use of connections to cloud service protocols and services like REST (representational state transfer) or HTTPS (Hypertext Transfer Protocol Secure) -– thus preserving the network for its intended use by the enterprise.

While I have many opinions on multiple points within the article, I’ll focus briefly on just a couple, starting with the boldfaced section (emphasis is mine) above.  Specifically, monetizing connectivity between providers as a sole value add seems quite limited in terms of a business model.  Furthermore, I really see that this is just another feature of what the emerging class of service brokers will offer.

As to the notion of privatizing transport for the purpose of applying QoS, that’s really just a fancy way of describing private Cloud peering and interconnects on the backside of Public Cloud service providers.  The challenge will come when these service providers (with the SP’s directly or brokers) end up managing what amounts to massive numbers of “extranet” connections in current-day parlance; it’s simply taking the overlay architectures of DMZ’s as we know it today and flipping it outward.  I’m not going to tackle the issue of Net Neutrality in this piece because, well, I’m on vacation in Hawaii and I want to keep my blood pressure down 😉

The blog mentioned many times about the lack of a “…standard products that allow enterprises to install private network connections (either paid, dedicated leased lines or VPNs) that would provide predictable network performance and security,” but I’d suggest that’s wholly inaccurate — depending upon your definition of a “standard product.”

In the long term the notion of an open market for hybrid Cloud connectivity — the Inter-Cloud — will take form, and much of the evolving work being done with open protocols and those in the works by loose federations of suppliers with common goals and technology underpinnings will emerge.

In the long term do we need CloudNAP’s? No. Will we get something similar by virtue of what we already do today? Probably.

/Hoff

Update 2/1/10: The A6 effort is in full-swing.  You can find out more about it at the Google Groups here.

A few weeks ago I penned a blog discussing an idea I presented at a recent Public Sector Cloud gathering that later inherited the name “Audit, Assertion, Assessment, and Assurance API (A6)”

The case for A6 is straightforward:

…take the capabilities of something like SCAP and embed a standardized and open API layer into each IaaS, PaaS and SaaS offering [Ed: At the API layer of each deployment model] to provide not only a standardized way of scanning for network vulnerabilities, but also configuration management, asset management, patch remediation, compliance, etc.

This way you win two ways: automated audit and security management capability for the customer/consumer and a a streamlined, cost effective, and responsive way of automating the validation of said controls in relation to compliance, SLA and legal requirements for service providers.

Much discussion ensued on Twitter and via email/blogs explaining A6 in better detail and with more specificity.

The idea has since grown legs and I’ve started to have some serious discussions with “people” (*wink wink*) who are very interested in making this a reality, especially in light of business and technical use cases bubbling to the surface of late.

To that end, Ben (@ironfog) has taken the conceptual mumblings and begun work on a RESTful interface for A6. You can find the draft documentation here.  You can find his blog and awesome work on making A6 a reality here.  Thank you so much, Ben.

NOTE: The documentation/definitions below are conceptual and stale. I’ve left them here because they are important and relevant but are likely not representative of the final work product.

A6 API Documentation – Draft 0.11

I’m thinking of pulling together a more formalized working group for A6 and push hard with some of those “people” above to get better definition around its operational realities as well as understand the best way to create an open and extensible standard going forward.

If you’re interested in participating, please contact me ( choff @ packetfilter . com ) and let’s capitalize on the momentum, need and fortuitous timing to make A6 work.

Thanks,

/Hoff

Related articles by Zemanta

• A6 Workgroup On The Way Soon (cloudave.com)

The talk I was scheduled to give at Blackhat in Vegas had that title.  Due to a timing issue, I couldn’t make Vegas.

The summary of CI^6 goes something like this:

What was in is now out.

This metaphor holds true not only as an accurate analysis of what happens to our data with the adoption trends of disruptive technology and innovation in the enterprise, but also parallels the amazing velocity of how our datacenters are being re-perimiterized and quite literally turned inside out thanks to Cloud computing and virtualization.

One of the really interesting things happening with the massive convergence of virtualization and cloud computing is its effect on security models, the corresponding compensating controls and the information they are designed to protect.

Where and how our data is created, processed, accessed, stored, backed up and destroyed in what is sure to become massively overlaid cloud-based services — and by whom and using whose infrastructure — yields significant concerns related to security, privacy, compliance and survivability.

Further, the “stacked turtle” problem becomes more visible as the notion of nested clouds becomes reality: cloud SaaS providers depending on Cloud IaaS providers which rely on Cloud network providers. It’s a house of, well, turtles.

The fragile application layer of infostructure, sitting atop infrastructure and held together with the bailing-wire and bubble gum of outdated metastructure yields unintended information intercourse.

We will show multiple cascading levels of failure associated with relying on cloud-on-cloud infostructure/metastructure/infrastructure including exposing flawed assumptions and untested theories as it relates to security, privacy and confidentiality in the Cloud with some unique attack vectors.

The gist of the talk shows examples of the fragility at each of the largely independent info-/meta-/infra-structure layers and then as a whole.

I spend quite a bit of time on the Metastructure layer:

While I plan to give the talk publicly soon at a venue which I will announce shortly, thematically, the talk’s content is already playing itself out in the real world.  If you need good examples as to what I am talking about, I’ll use the two I focus in on with the presentation: DNS and BGP.

You need only look at the latest set of DDoS attacks on social media sites to see how relevant this continues to be.

Much of what holds the Internet and our Intranets together are based upon protocols and architecture never designed to
scale to the levels they are going to get pushed to with Cloud.  Further, the inherent trust in the models used to frame fair play are equally as kaput.

The canaries in the coal mine are starting to chirp very loudly…

I find that people spend a lot of time criticizing the styles of delivery and presentation around securing the Metastructure layer.

They say there’s nothing new.  They say it’s just a way of seeking attention.

I’d suggest listening to the message regardless of what you think of the messengers.*

Talk amongst yourselves.

/Hoff

*Lori Macvittie has an interesting post highlighting this.

There I was in the middle of a half moon yoga pose when the thought hit…

I was on a Telepresence the other day with @jamesurquhart and a couple of other colleagues and we were discussing the notion of Cloud services and multitenancy again.

I brought up a well-known Cloud provider who serves thousands (if not tens of thousands) of unique customers.  I argued that based upon what I was told by system architects, the service was never really designed with multitenancy in mind.  James argued to the contrary maintaining that he has had numerous discussions with the same architects and was convinced my point was invalid.

This got me thinking as to how, if we were talking to the same architects, we came away with a diametrically opposed understanding.

It should be noted that this vendor does not use server/OS virtualization in their offering and since multitenancy is often (improperly) associated directly with server/OS virtualization, we recognized that this wasn’t our disconnect.

Then it dawned on me (well today, during Yoga.)  I was talking about the notion of application multitenancy and James was talking about the database/datastore aspects of multitenancy!  The front-end versus the back-end versus the entire stack…

So of course from James’ perspective, the architects definitely built the database, schemas and table structures to support isolated, discrete and “secure” multitenancy.

However from my perspective, the application itself — a single application — isn’t “multitenant” insomuch as it is multi-user.  The application provides a common programmatic entry point (however customized in presentation) to a specific dataset to which James was referring.

Aha!  Seems simple and somewhat silly, but it never occurred to me that we were just thinking from different ends of the stack; this time I was top-down and James was bottoms-up.  Funny as James is the app. guy and I am the Infrastructure bobblehead.  Stupid siloed thinking on my part distracted me from what I know is a larger system architecture artifact that is easy to spot if I had only taken the goggles off.

This is important because when we apply Cloud definitions to SaaS providers wherein the required characteristics “require” multitenancy (see my post here,) many if not most SaaS offerings fail to meet the criterion.  If we think along the lines of not just qualifying the ‘application’ but expand ‘software’ in SaaS to more broadly include the entire stack including the database, it passes the sniff test.

I have to tell you that this was, despite my own taxonomy diagrams which point out this very fact, a block in my vision which was causing me angst.

So, remember, when we’re talking about SaaS, just because the application front-end may not smell of multitenancy, the underlying platform and database probably will — especially if it’s going to scale to elastic cloud levels.

Silly little lightbulbs go off in the most interesting of times.

/Hoff

Introducing the “Cloud For Clunkers Program”

Cloud providers are advertising the equivalent of the U.S. Government’s “Cash for Clunkers” program:

“You give up your tired, inefficient, polluting, hard to maintain and costly data centers and we’ll give you PFM in the form of a global, seamless, elastic computing capability for less money and with free undercoating.  The value proposition is fantastic: cost-savings, agility, the illusion of infinite scale, flexibility, reliability, and “green.”

There are some truly amazing Cloud offerings making their way to market and it’s interesting to see that the parallels offered up by the economic incentives in both examples are generating a tremendous amount of interest.

The case remains to be seen as to whether or not this increase in interest is a short-term burst that’s simply shortening the cycle for early adopters or if it will deliver sustainable attention over time and drive people to the “showroom floor” that weren’t considering kicking the tires in the first place.

As compelling as the offer of Cloud may be, in order to pull off incentivizing large enterprises to think differently, it requires an awful lot going on under the covers to provide this level of abstracted awesomeness; a ton of heavy lifting and the equipment and facilities to go with it.

To get ready for the gold rush, most of the top-tier IaaS/PaaS Cloud providers are building data processing MegaCenters around the globe in order to provide these services, investing billions of dollars to do so…all supposedly so you don’t have to.

Remember, however, that service providers make money by squeezing the most out of you while providing as little as they need to in order to ensure the circle of life continues.  Note, this is not an indictment of that practice, as $deity knows I’ve done enough of that myself, but just because it has the word “Cloud” in front of it does not make it any different from a business case.  Live by the ARPU, die by the ARPU.

Cloudiness Is Next To Godliness…

What happens then, when something outside of the providers’ control changes the ability or desire to operate from one of these billion-dollar Cloud centers?  No, I don’t mean like a natural disaster or an infrastructure failure.  I mean something far more insidious.

Like what you say?  Funny you should ask.  The Data Center Knowledge blog details how Microsoft is employing the teleportation equivalent of vMotion by pMotioning (physically) an entire Azure Cloud data center to deal with changing tax codes thanks to a game of chicken with a local state government:

“Due to a change in local tax laws, we’ve decided to migrate Windows Azure applications out of our northwest data center prior to our commercial launch this November,” Microsoft say on its Windows Azure blog (link via OakLeaf Systems). ” This means that all applications and storage accounts in the “USA – Northwest” region will need to move to another region in the next few months, or they will be deleted.” Azure applications will shift to the USA – Southwest region, which is housed in Microsoft’s 470,000 square foot San Antonio data center, which opened last September.

The move underscores how the economics of data center site location can change quickly – and how huge companies are able to rapidly shift operations to chase the lowest operating costs

Did you see the part that said “…all applications and storage accounts in the “USA – Northwest” region will need to move to another region in the next few months, or they will be deleted.”  Sounds rather Un-Cloudlike, no?  Remember the Coghead shutdown?

Large scale providers and their MegaCenters face some amazing challenges such as the one presented above.  As these issues become public and exposed to due diligence, they are in turn causing enterprises to take stock in how they evaluate their migration to Cloud.  They aren’t particularly new issues, it’s just that people are having a hard time reconciling reality from the confusing anecdote of Cloudy goodness that requires zero-touch and just works…always.

Om Malik chronicled some of these challenges:

And while cloud computing is all the rage in Washington D.C., it seems the state of Washington doesn’t much care for cloud computing. Instead of buying cloud computing services from home-grown cloud computing giant Amazon, (or newly emergent cloud player, Microsoft), the state has opted to build a brand-new, $180 million data center, despite reservations from some state representatives. Microsoft is moving the data center that houses its Azure cloud services to San Antonio, Texas, from Quincy, Wash. — mostly because of unfavorable tax policies. Apparently, the data centers are no longer covered by sales tax rebates — a costly proposition for Microsoft, which plans to spend many millions on new hardware for the Azure-focused data center.

By the way, Washington is the second state that has decided to build its own data center. In June, Massachusetts decided that it was going to build a $100 million data center. The Sox Nation is home to Nick Carr, author of “The Big Switch,” arguably the most influential book on cloud computing and its revolutionary capabilities.

These aforementioned states are examples of a bigger trend: Most large organizations are still hesitant to go all in when it comes to cloud computing. That’s partly because the cloud revolution still has a long way to go. But much of it is fear of the unknown.

Some of that “unknown” is more about being “unsolved” since we understand many of the challenges but simply don’t have solutions to them yet.

But I Don’t Want My Data In Hoboken!

I’ve spoken about this before, but while a provider may be pressured to move an entire datacenter (or even workloads within it) for their own selfish needs, what might that mean to customers in terms of privacy, security, SLA and compliance requirements?

We have no doubt all heard of requirements that prevent certain data from leaving geographic boundaries.  What if one of these moves came into conflict with regulations such as these?  What happens if the location chosen to replace the existing once causes a legal exception?

This is clearly an inflection point for Cloud and underscores the need to drive for policy-driven portability and interoperability sooner than later.

Even if we have the technical capability to make portable our workloads, we’re not in a position to instantiate policy as an expression of business logic need to govern whether they should, can, or ought to be moved.

If we can’t/dont’/won’t work to implement open standards to provide for workload security, portability & interoperability with the functionality for “consumers” to assert requirements and “providers” to attest to their capabilities based upon a common expression of such, this will surely add to the drive for large enterprises to consider either wholly-private or virtual private Clouds in order to satisfy their needs under an umbrella they can control.

I’ll Take “Go With What You Know” For $200, Alex

In the short term, customers who are mature in their consolidation, virtualization, optimization and automation practices and are looking to move to utilize IaaS/PaaS services from third party providers will likely demand homogeneity from 1-2 key providers with a global footprint in potential combination with their own footprint to pull this off whilst they play the waiting game for open standards.

The reason for the narrowing of providers and platforms is simple: continuity of service across all dimensions and the ability to control one’s fate, even if it means vendor lock-in driven by feature/function maturity.

Randy Bias alluded to this in a recent post titled “Bifurcating Clouds” in which he highlighted some of the differences in the spectrum of Cloud providers and the platforms they operate from.  There are many choices when it comes to virtualization and Cloud operating platforms, but customers are becoming much more educated about what those choices entail and often times arrive at the fact that cost isn’t always the most pressing driver.  The Total Cloud Ownership* calculation is a multi-dimensional problem…

This poses an interesting set of challenges for service providers looking to offer IaaS/PaaS Cloud services: build your own or re-craft available OSS platforms and drive for truly open standards or latch on to a market leader’s investment and roadmap and adopt it as such.

Ah, Lock-In.  Smells Like Teen Spirit…

From the enterprises’ perspective,  many are simply placing bets that the provider they chose for their “internal” virtualization and consolidation platform will also be the one to lead them to Cloud as service providers adopt the same solution.

This would at least — in the absence of an “open standard” — give customers the ability to provide for portability should a preferred provider decide to move operations to somewhere which may or may not satisfy business requirements; they could simply pick another provider that runs on the same platform instead.  You get De Facto portability…and the ever-present “threat” of vendor lock-in.

It’s what happens when you play spin the bottle with your data, I’m afraid.

So before you trade in your clunker, it may make sense to evaluate whether it’s simply cheaper in the short term to keep on paying the higher gas tax and drive it into the ground, pull the motor for a rebuild and get another 100,000 miles out of the old family truckster or go for broke and get the short term cash back without knowing what it might really cost you down the road.

This is why private Cloud and virtual private Clouds make sense.  It’s not about location, it’s about control.

Both hands on the wheel…10 and 2, kids….10 and 2.

/Hoff

*I forgot to credit Vinnie Mirchandani from Deal Architect and his blog entry here for the Total Cloud Ownership coolness. Thanks to @randybias for the reminder.

I am working on laying down the vocals over the music,

For the love of all that is audible, don’t say you weren’t warned…

The first couple of verses are recorded for your, um, pleasure here.

Here’s  an overview of Defcon sung to the tune of Nickleback’s “Rockstar:”

I’m through with standing in line

for talks I’ll never get in

Didn’t make the top 3 in CTF again

Seems Defcon hasn’t turned out

quite the way I want it to be

(tell me what you want)

I want a brand new netbook

that runs Ubuntu

a 3G channel no one can hack into

And a 4 socket server big enough

to crack passwords for me

(yeah, so what you need)

I’ll need a credit card with someone else’s limit

And a wallet from a fed with nice badge in it

Gonna join the wall of sheep club

everyone makes fun of me

(Been there done that)

I want a bootable CD full of old hack tools

and a way to bypass pesky firewall rules

Need to tunnel SSH…DNS and RPC

(So how you gonna do it?)

I’m gonna trade this life for fortune and fame

gonna grow long hair and use a hacker name

[CHORUS]

‘Cause we all just wanna be security rockstars

Hacking parking meters,

windows-powered smart cars

The girls ain’t easy but the caffeine’s cheap

We’ll all stay skinny, can’t afford to eat

And we’ll hang out in the coolest bars

moochin off those vendors

and their sales whores

Every good script kiddie

Gonna wind up there

No pretty people

but we just wont care

Hey hey I’ll be a security rockstar

Hey hey I’ll be a security rockstar

Wanna be…great like Mitnick

with no stay in the pen

Hire a PR firm to make me cool again

Sign-a couple autographs

buy my book ‘cos it’s not free

(I’ll have the quesadilla… ha ha)

Piss off Apple fanbois

cause quite a mess

pwn your precious iPhone

with an SMS

Escape from a VM

cos you’ve got crappy entropy

(So how you gonna do it?)

I’m gonna trade this life for fortune and fame

gonna grow long hair and use a hacker name

‘Cause we all just wanna be security rockstars

Hacking parking meters,

windows-powered smart cars

The girls ain’t easy but the caffeine’s cheap

We’ll all stay skinny, can’t afford to eat

And we’ll hang out in the coolest bars

moochin off those vendors

and their sales whores

Every good script kiddie

Gonna wind up there

No pretty people

but we just wont care

Hey hey I’ll be a security rockstar

Hey hey I’ll be a security rockstar

Have a big pool party

with killer bees

a bread makin’ panel

with robots that freeze

lock picking fu

and hacker jeopardy

I’m gonna write those sploits

that offend the censors

Gonna pop those boxes

like a Pez dispenser

Get washed-up hackers

rewriting my tools for free

I’m gonna dress my ass

in the black shirt fashion

Donate to the EFF

and promote stack smashin’

Gonna date a sysadmin

blow my money on a brand new Wii

(So how you gonna do it?)

I’m gonna trade this life for fortune and fame

gonna grow long hair and use a hacker name

‘Cause we all just wanna be security rockstars

Hacking parking meters,

windows-powered smart cars

The girls ain’t easy but the caffeine’s cheap

We’ll all stay skinny, can’t afford to eat

And we’ll hang out in the coolest bars

moochin off those vendors

and their sales whores

Every good script kiddie

Gonna wind up there

No pretty people

but we just wont care

Hey hey I’ll be a security rockstar

Hey hey I’ll be a security rockstar

I’m gonna give your mama

quite a fright

when I steal her account

on that Facebook site

If Satan’s on her friend’s list

Jesus really ought to be

You’ve got

“Clobber the Cloud”

Chicks pillow fighting

and even the odd

TV celebrity sighting

Korean spies in disguise

get your bail money for free

Fake ATM’s in the lobby

stealin’ your cash

suicidal cab drivers

who think it’s cool to crash

haxors getting pwned

posting your twitter feeds

I’m gonna trade this life for fortune and fame

gonna grow long hair and use a hacker name

‘Cause we all just wanna be security rockstars

Hacking parking meters,

windows-powered smart cars

The girls ain’t easy but the caffeine’s cheap

We’ll all stay skinny, can’t afford to eat

And we’ll hang out in the coolest bars

moochin off those vendors

and their sales whores

Every good script kiddie

Gonna wind up there

No pretty people

but we just wont care

Hey hey I’ll be a security rockstar

Hey hey I’ll be a security rockstar