In this week’s episode of Engineers Unplugged, Bas Raayman from EMC and Caroline Orloff from ServiceMesh take on “what is the software defined data center and how is it like/different from the cloud”? Let’s watch and see what they conclude:
Bas Raayman, Caroline Orloff, and the First Ever Cloud Management Platform Unicorn.
Welcome to Engineers Unplugged, where technologists talk to each other the way they know best, with a whiteboard. The rules are simple:
Episodes will publish weekly (or as close to it as we can manage)
Back in May 2012 Mike Fratto predicted in his blog that SDN will be “Reborn in Network Management”. There is a lot of truth to his statement. The words “software defined” in “Software Defined Networking (SDN)” inspired people to rethink the overall control plane architecture of the network making the case for infrastructure software that complements software already embedded in virtual and physical devices, (e.g., the software and protocols running in and between network elements).
We are evolving our treatment of the network. What once was a discrete set of loosely coupled devices will now be interacted with as a system. To get there means the network must be represented by an overall system model. Classic network management functions become an integral part of the infrastructure software, and will spawn their own management requirements. SDN makes network management a first class citizen. Effectively we’re past the time when network management was an afterthought, or when network management was an operational silo. The coming integration of network management into the larger network software domain means infrastructure managers will not only manage and operate, but also actively contribute to the overall business proposition of the IT infrastructure. Read More »
For those who are on the learning curve on various aspects of network programmability, open networking and SDN (like we are), I’d like to invite you to the third in a series of educational webicasts on these topics. Brought under the umbrella of the Cisco Open Network Environment, this particular webcast focuses on “An introduction to onePK”, and will be broadcast on April 9th, 2013 at 9 AM PST. You can registerhere.
The Cisco Open Network Environment is all about bringing the network closer to applications. One way of doing that is by exposing network devices to applications through a rich set of APIs, that can help tap into the intelligence inherent in the hardware and ASICs as well as in the network operating systems. This is what onePK is all about – it’s a single platform kit that will span all of Cisco’s network infrastructure portfolio across Enterprise and Service Provider, exposing them to applications in a homogenous way, allowing app developers to tap into the power of the open network.
Cisco announced its Open Network Environment or Cisco ONE strategy on June 2012 and has been in execution mode since then. onePK happens to be a key proofpoint of this cross-architectural strategy.
Join me on this webcast, as I host Ayman Sayed, SVP of Cisco’s Network Operating Systems Group as the lead Cisco expert on this topic. We will also be joined by two of the development partners that are working on onePK trials including Brendon Whateley, Principal Solution Architect at Starview Inc., and Kamil Knotek, Chielf of R&D at Pramacomm Prague spol s.r.o, as well as some new demos.
If you missed the last webcast on “An Introduction to OpenFlow” with David Ward, CTO, Cisco Engineering and Chief Architect, we had a turnout from 84 countries and over 120+ questions answered by our question managers in a one-hour period. You can watch a reply of the webcast here.
So, we wrapped up our day with the Networking Field Day crew last week with a free form discussion on where we go next with SDN. To be honest, the session did not go quite as I envisioned, but, in retrospect, I would not changed anything. As Ethan Banks (of PacketPushers fame) noted in Twitter, this session was more about shooting the unicorns than letting them run free. It seems that if we are going to convert our SDN unicorns into SDN plough horses, we are going to shed a little blood. At the end of the day, the market will be served by frank conversations—we need to move beyond painting SDN acolytes as starry-eyed and SDN detractors as being heretical and reactionary.
In the interest of keeping the conversation going, here are some of the things I walked away with after the conversation on Wednesday (in no particular order):
Is Hardware Innovation is Over?
This industry has always been one big pendulum and, currently, the pendulum is firmly in the software camp. Today, many of the truly interesting things in networking are going on with software. While most would agree we are at an inflection point with programmability, there are no clear directions for the evolution of SDN. Certainly there are pieces in place like OpenFlow and OpenStack, but OF 1.3 in unlikely to be the zenith of OF evolution let alone SDN evolution—current technologies will continue to mature and new ones will inevitably emerge. More importantly, the “how we do things” and “what do want to accomplish” of SDN will most certainly continue to evolve and as long as that is the case, software will rule because it’s simply easier and faster to experiment with software. But, once some clear directions begin to emerge, I guarantee you the action will swing back towards the hardware because doing things in hardware tends to be faster and more efficient. I could point to Cisco examples of this, but instead look at what Intel, the poster child for general purpose processors, has done with VT extensions to support virtualization or QuickSync for video transcoding.
Is OpenFlow Ready for PrimeTime?
One of the more contentious points yesterday is if OpenFlow is production ready. I think it’s a flawed “do these jeans make me e look fat” kind of question. There are certainly folks out there using OF to handle production traffic—for example, some of the cool things Brent Salisbury is doing. So, it’s not a binary question, but more a matter of assessing scope and scale. The better question to ask is what is the operational and performance envelope of OpenFlow and how does that match my needs, priorities, and capabilities. The risk with any emerging technology is that, often, the only way you find the edge of the envelope is once you’re on the other side, usually with colorful and memorable results. Regardless, I don’t see this question existing in another year or so.