Getting into a long thread on Twitter is entertaining. You have to keep your thoughts short and concise and sometimes it’s hard to list every descriptive phrase known to man to articulate what you mean. But…that also makes it fun! One example is the thread that happened last Saturday that I jumped into a little late.
I’ve stated recently I’m an advocate of network virtualization (fully de-coupled from hardware), but I still believe if a vendor wants to invest in hardware development to differentiate their total solution, have at it. As a network architect, you can go down the path only architecting virtual network stacks, only architecting physical fabrics, or doing both. If you are doing both or just physical fabrics (still in 2013), you will want solid and proven hardware. It’s too early to tell what the future will be after 2 or 3 more refresh cycles.
So what characteristics do we need in the data center?
- Solution foundation using hardware (don’t forget the hardware, please)
- Fully de-coupled network virtualization solution ------- This should without a doubt inherently offer network abstraction, independence, and isolation.
- We can’t forget about fully automated and orchestrated -------- They should be able to be automated and orchestrated independently (meaning physical network and virtual network), but if they are coming from the same vendor, the ability to unify this would be a value add. I don’t mean inter-dependence. And if platforms are de-coupled, this does mean minimal change to the physical network, but whatever change there will be, let’s seamlessly automate that and at the same time make it easy to extract information and statistics from the network.
- Integration – both networks do not need to be integrated. They could and should be able to be deployed independently, but again, if it’s the same vendor offering a single solution, I’d expect some value add here. Maybe it’s enhanced visibility, maybe it’s provisioning, but I do not mean inter-dependence when I say integrated. I’m referring to the feedback loop that should be easier to implement because it is a single vendor like Cisco physical + Cisco virtual + NAM/NetFlow data (general thought – haven’t seen this). However, if there is integration between two companies using a third company to provide this *GLUE* via APIs, SDKs, connectors or whatever, that’s great too because it gives choice across hardware and software networks and also config/automation stacks.
Why can’t I want two networks that can be built independently, but have the opportunity to provide more value by means of feature/functionality/usability or by reduced OpEx if offered together by the same vendor or using some pretty cool glue from another?
It doesn't have to be "either or," but it can be if you'd like.
-Jason
Twitter: @jedelman8