Overlays: Wasting Away Again In Abstractionville…
(Photo credit: IvanWalsh.com)
I’m about to get in a metal tube and spend 14 hours in the Clouds. I figured I’d get something off my chest while I sit outside in the sun listening to some Jimmy Buffett.
[Network] overlays. They bug me. Let me tell you why.
The Enterprise, when considering “moving to the Cloud” generally takes one of two approaches depending upon culture, leadership, business goals, maturity and sophistication:
- Go whole-hog with an all-in Cloud strategy.
Put an expiration date on maintaining/investing in legacy apps/infrastructure and instead build an organizational structure, technology approach, culture, and operational model that is designed around building applications that are optimized for “cloud” — and that means SaaS, PaaS, and IaaS across public, private and hybrid models with a focus on how application delivery and information (including protecting) is very different than legacy deployments, or… - Adopt a hedging strategy to get to Cloud…someday.
This usually means opportunistically picking low risk, low impact, low-hanging fruit that can be tip-toed toward and scraping together the existing “rogue” projects already underway, sprinkling in some BYOD, pointing to a virtualized datacenter and calling a 3 day provisioning window with change control as “on-demand,” and “Cloud.” Oh, and then deploying gateways, VPNs, data encryption and network overlays as an attempt to plug holes by paving over them, and calling that “Cloud,” also.
See that last bit?
This is where so-called “software defined networking (SDN),” the myriad of models that utilize “virtualization” and all sorts of new protocols and service delivery mechanisms are being conflated into the “will it blend” menagerie called “Cloud.” It’s an “eyes wide shut” approach.
Now, before you think I’m being dismissive of “virtualization” or SDN, I’m not. I believe. Wholesale. But within the context of option #2 above, it’s largely a waste of time, money, and effort. It’s putting lipstick on a pig.
You either chirp or get off the twig.
Picking door #2 is where the Enterprise looks at shiny new things based on an article in the WSJ, Wired or via peer group golf outing and says “I bet if we added yet another layer of abstraction atop the piles of already rapidly abstracting piles of shite we already have, we would be more agile, nimble, efficient and secure.” We would be “cloud” enabled.
[To a legacy-minded Enterprise,] Cloud is the revenge of VPN and PKI…
The problem is that just like the folks in Maine will advise: “You can’t get there from here.” I mean, you can, but the notion that you’ll actually pull it off by stacking turtles, applying band-aids and squishing the tyranny of VLANs by surrounding them in layer 3 network overlays and calling this the next greatest thing since sliced bread is, well, bollocks.
Look, I think SDN, protocols like Openflow and VXLAN/NVGRE, etc. are swell. I think the separation of control and data planes and the notion that I can programmatically operate my network is awesome. I think companies like Nicira and Bigswitch are doing really interesting things. I think that Cloudstack, Openstack and VMWare present real opportunity to make things “better.”
Hey, look, we’re just like Google and Amazon Web Services Now!
But to an Enterprise without a real plan as to what “Cloud” really means to their business, these are largely overlays within the context of #2. Within the context of #1, they’re simply mom and apple pie and are, for the most part, invisible. That’s not where the focus actually is.
That said, for a transitional Enterprise, these things give them pause, but should be looked upon as breadcrumbs that indicate a journey, not the destination. They’re a crutch and another band-aid to solve legacy problems. They’re really a means to an end.
These “innovations” *are* a step in the right direction. They will let us do great things. They will let a whole new generation of operational models and a revitalized ecosystem flourish AND it will encourage folks to think differently. But about what? And to solve what problem(s)?
If you simply expect to layer them on your legacy infrastructure, operational models and people and call it “Cloud,” you’re being disingenuous.
Ultimately, to abuse an analogy, network overlays are a layover on the itinerary of our journey to the Cloud, but not where we should ultimately land. I see too many companies focusing on the transition…and by the time they get there, the target will have moved. Again. Just like it always does.
They’re hot now because they reflect something we should have done a long time ago, but like hypervisors, one day [soon] network overlays will become just a feature and not a focus.
/Hoff
Related articles
- Building/Bolting Security In/On – A Pox On the Audit Paradox! (rationalsurvivability.com)
- AwkwardCloud: Here’s Hopin’ For Open (rationalsurvivability.com)
Chris, I’m not sure I buy in to your premise. In my opinion, what you present as an either/or path can both be simultaneously true. And any strategy to pursue one over another is really just a matter of degree.
You’re clearly not arguing that these overlays won’t be part of Option #1 (‘they’re simply mom and apple pie and are, for the most part, invisible’). Yet you do argue that these same overlays are: ‘They’re a crutch and another band-aid to solve legacy problems’?
It can’t be both, can it?
Lets suppose you go down path #1. What’s the first thing you’re going to do with your new fandango S/P/Iaas Pub/Pri/Hybrid cloudamatron? Probably a simple, low risk, low impact application, right? Well, most of time (unless it’s *also* a new, stand-alone siloed app), it’s going to need to somehow interact with some kind of legacy system. How will it do that? Probably with a gateway of some kind, along with a VPN, of some kind, using a tunneling mechanism of some kind.
Doesn’t this sounds a little like path #2?
I think the technical distinction between the paths you present are minimal, at best. However, I’ll grant you that framing the solutions as either #1 or #2 might be useful, helpful and maybe even necessary when trying to get an organization to buy in to the plan.
Hoff,
Some very good points and stuff to think about. To me much of what you said is summed up in your two line:
“But to an Enterprise without a real plan as to what “Cloud” really means to their business,”
and
“If you simply expect to layer them on your legacy infrastructure, operational models and people and call it “Cloud,”
Whether a company takes the path of a 1, 1.25, 1.5, 2, etc. is more about their understanding of needs. Most of which, as you point out above, don’t have a clear “business objective” in mind, except to “use that cloud thing”. It will be interesting to see how the whole “network overlay” thing works it self out in the end. It seem that many (most? all?) providers are pushing that model as well to get the adoption. As yoda said “The dark side clouds everything. Impossible to see the future is.”
The one thing that does bother me a bit is that with the “this on that” reliance that is being built, the ability to secure it becomes much more of a task of peeling back the layers and making intelligent decisions on each of them. In reality, as complexity increases, the number of folks who can see clearly through the tangled web shrinks dramatically. The issues of trust and transparency becomes even more important IMHO.
Thanks for the post, got me thinking about soem things.
My experience with enterprise Cloud has been similar as I too find that VPN “enables” enterprise IT to say “Cloud” while keeping the wax in their ears and muting the Siren’s Song that is Cloud. It might be better to tie themselves to the mast and listen. To me VPNs foster the status quo and overlay and obscure both the problem domain as well as the growth and enlightenment possibly found in rearchitecting and rebuilding applications around the strong SOA requirements, as well as the ecosystem of services designed for such consumption.