Incomplete Thought: The Other Side Of Cloud – Where The (Wild) Infrastructure Things Are…
This is bound to be an unpopular viewpoint. I’ve struggled with how to write it because I want to inspire discussion not a religious battle. It has been hard to keep it an incomplete thought. I’m not sure I have succeeded 😉
I’d like you to understand that I come at this from the perspective of someone who talks to providers of service (Cloud and otherwise) and large enterprises every day. Take that with a grain of whatever you enjoy ingesting. I have also read some really interesting viewpoints contrary to mine, many of which I find really fascinating, just not subscribed to my current interpretation of reality.
Here’s the deal…
While our attention has turned to the wonders of Cloud Computing — specifically the elastic, abstracted and agile delivery of applications and the content they traffic in — an interesting thing occurs to me related to the relevancy of networking in a cloudy world:
All this talk of how Cloud Computing commoditizes “infrastructure” and challenges the need for big iron solutions, really speaks to compute, perhaps even storage, but doesn’t hold true for networking.
The evolution of these elements run on different curves.
Networking ultimately is responsible for carting bits in and out of compute/storage stacks. This need continues to reliably intensify (beyond linear) as compute scale and densities increase. You’re not going to be able to satisfy that need by trying to play packet ping-pong and implement networking in software only on the same devices your apps and content execute on.
As (public) Cloud providers focus on scale/elasticity as their primary disruptive capability in the compute realm, there is an underlying assumption that the networking that powers it is magically and equally as scaleable and that you can just replicate everything you do in big iron networking and security hardware and replace it one-for-one with software in the compute stacks.
The problem is that it isn’t and you can’t.
Cloud providers are already hamstrung by how they can offer rich networking and security options in their platforms given architectural decisions they made at launch – usually the pieces of architecture that provide for I/O and networking (such as the hypervisor in IaaS offerings.) There is very real pain and strain occurring in these networks. In Cloud IaaS solutions, the very underpinnings of the network will be the differentiation between competitors. It already is today.
See Where Are the Network Virtual Appliances? Hobbled By the Virtual Network, That’s Where… or Incomplete Thought: The Cloud Software vs. Hardware Value Battle & Why AWS Is Really A Grid… or Big Iron Is Dead…Long Live Big Iron… and I Love the Smell Of Big Iron In the Morning.
With the enormous I/O requirements of virtualized infrastructure, the massive bandwidth requirements that rich applications, video and mobility are starting to place on connectivity, Cloud providers, ISPs, telcos, last mile operators, and enterprises are pleading for multi-terabit switching fabrics in their datacenters to deal with load *today.*
I was reminded of this today, once again, by the announcement of a 322 Terabit per second switch. Some people shrugged. Generally these are people who outwardly do not market that they are concerned with moving enormous amounts of data and abstract away much of the connectivity that is masked by what a credit card and web browser provide. Those that didn’t shrug are those providers who target a different kind of consumer of service.
Abstraction has become a distraction.
Raw networking horsepower, especially for those who need to move huge amounts of data between all those hyper-connected cores running hundreds of thousands of VM’s or processes, still know it as a huge need.
Before you simply think I’m being a shill because I work for networking vendor (and the one that just announced that big switch referenced above,) please check out the relevant writings on this viewpoint which I have held for years which is that we need *both* hardware and software based networking to scale efficiently and the latter simply won’t replace the former.
Virtualization and Cloud exacerbate the network-centric issues we’ve had for years.
I look forward to the pointers to the sustainable, supportable and scaleable 322 Tb/s software-based networking solutions I can download and implement today as a virtual appliance.
/Hoff
Related articles by Zemanta
- Does the Cloud Need a Specialized Chip? (gigaom.com)
- Dear Public Cloud Providers: Please Make Your Networking Capabilities Suck Less. Kthxbye (rationalsurvivability.com)
- Can We Secure Cloud Computing? Can We Afford Not To? (rationalsurvivability.com)
- NESSessary Question: Will Virtualization Undermine Network Equipment Vendors? (rationalsurvivability.com)
- Cloud: Over Subscription vs. Over Capacity – Two Different Things (rationalsurvivability.com)
- Cloud Computing Security: (Orchestral) Maneuvers In the Dark? (rationalsurvivability.com)
- From the X-Files – The Cloud in Context: Evolution from Gadgetry to Popular Culture (rationalsurvivability.com)
![Reblog this post [with Zemanta]](https://i0.wp.com/img.zemanta.com/reblog_e.png)
agreed,
but such things are in the realm of Enterprise Architecture. Obviously, in the cloud world it appears, EA (and governance) is merely an obstacle similar to an IT process framework such as ITIL. In reality, ignoring EA and IT process ensures cloud as not Enterprise ready (at least, a public one). Thus, if at all, private clouds will appear on the Enterprise horizon with a smaller scope. Enterprise apps are indeed complex for the cloud.
Needless to say, are you not really touching on centralization vesus decentralization where the best network is indeed no network (similar to the best I/O is no I/O).
All of this appears to be similar to the grand old debate about connection and connection-less oriented networking when, in those days, networks were unreliable. These days, it does appear that networks are not enough (bandwidth).
All the same, every provider has their hammer. Some have too many hammers and others forget to adapt their hammer.
@derik66
The first sentence of your post sounded intriguing, but I personally found myself in full agreement with your point of view, even though I am a lead engineer for a network virtual appliance (NVA) product 🙂 – I totally agree that NVAs are not going to displace big iron gear any time soon, and the need for big iron offering bigger throughput capacity is huge. Anybody who is saying otherwise is looking way into the future (15+ years ahead), which is not practical for today's tasks and needs.
I think that big iron networking gear and NVAs can, do and will most likely continue to co-exist quite happily side by side in the foreseeable future. Most importantly – they are solving different problems, for different audiences, at different price points, make totally different trade-offs, focus on totally different features. Neither is going to make the other obsolete any time soon. In fact, for the foreseeable future, NVAs will require big iron networking, and will run on top of it.
Your post has some parallels with the famous book The Innovator's Dilemma by Clayton Christensen, big iron being sustaining technological change and NVAs being disruptive. Following the author's thinking, disruptive technologies often start out at a huge disadvantage to sustaining ones based on some established metrics (in our case – throughput, supportability, scalability). But they are often finding a niche, develop in that niche, and then only time will tell how it's going to play out.
@somic
No. I hate to say it, but the apps are now the commodities. Innovation and investment is in infrastructure and platform. So many challenges still to be rsolved in network fabric, storage, management and security/GRC. Remember McDonalds once was defined by the food, but decades ago became all about the real estate (location) and brand (marketing).