Where does hardware make sense with network overlays?
In a follow-up post to a general network virtualization rant, blogger Jason Edelman explores the relationship between network overlays and hardware, and concludes that top-of-rack, end-of-row and core switches aren't needed to terminate traffic in fully virtualized environment for VM-to-VM traffic. Using these switches for overlays would be too similar to what a team can already do with virtual LANs, virtual routing and forwarding, and Generic Routing Encapsulation -- and that's not necessarily the point of overlay technology.
However, using hardware to terminate overlay traffic on other parts of the network -- such as the WAN edge -- does make sense.
Read Edelman's full post on where hardware makes sense in regard to network overlays.
Why vCloud alone is not the software-defined data center
On the Riverbed blog, writer Dormain Drewitz recounts a recent talk by Joe Sarabia, senior consultant in VMware's global center of excellence organization, at the Silicon Valley VMware User Group, where Sarabia explained the similarities between the vCloud suite and the idea of the software-defined data center (SDDC).
Where the two diverge, Drewitz writes, is the decoupling of network functions that SDN enables. This is a new element of SDDCs that hasn't always been part of the cloud. Drewitz also outlines what Sarabia called the essential elements of an SDDC: self-service, self-optimization and self-healing infrastructure.
View Drewitz' full post on software-defined data centers and other examples of SDN fiction that are becoming reality.
SDN kills the networking star?
On the Packet Pushers blog, writer and IT professional Steven Iveson addresses the concerns that many have regarding SDN and network virtualization: Automated provisioning and self-healing infrastructure are lovely, but what do those do to network engineers? Where do their jobs go?
Iveson explains that while basic networking skills could still valuable, a reality check might be in order as these skills get replaced by more-effective infrastructure. A barrier to entry into the field could arise, along with the loss of any real salary premium for IT roles in general. That said, while jobs might also be lost, the "removal of pain" associated with networking will increase its use. Somewhere along the way, network engineers and other IT pros may simply need to learn different skills to survive in the new world order.
Check out Iveson's full post on the benefits and hardships SDN could create for the networking industry.
OpenDaylight, OSGi and Maven
On his Network Static blog, author Brent Salisbury details some findings after working with OSGi (the Open Service Gateway Initiative) and Maven. Both had been foreign to him, he writes, until the introduction of the OpenDaylight Project. Salisbury lists his dev notes for setting OSGi log levels, building an individual specific OpenDaylight bundle with Maven, and making a new module to "hack on."
Salisbury also includes a brief definition of OSGi and how it fits into the theme of OpenDaylight, which, he writes, is allowing applications and protocols to plug into the framework to fit different use cases and vendor strategies. He explains Maven as well, and includes a few benefits pulled from the Maven project website. He goes on to explain enabling logging levels and traces in the OSGi console, building OpenDaylight modules individually after changing the code, creating your own module, and additional OpenDaylight how-tos.
Read Salisbury's full post detailing OpenDaylight, OSGi and Maven.
The SDN discussion needs to change
On the Embrane blog, author John V. writes a poignant post about how the talk surrounding SDN needs to shift from pinning down a definition to how the technology can truly help customers. John writes that it's typical for the industry to get so caught up in new terms and acronyms that it often loses sight of adoption and, in this case, the innovation that can come along with SDN.
At the end of the day, SDN is about helping customers create self-service environments so they can build better products, applications and services, John writes. SDN adoption, he says, has the potential to significantly reduce how long it takes to provision a network, along with virtualizing the network to make the data center more efficient. Another element that's rarely discussed, he adds, is how customers solve their problems without changing either the technology they have in place or existing people and processes. As an enterprise or service provider, he writes, you want to find technology that's disruptive but not destructive.
Read John V's full post on changing the SDN chatter from definitions and acronyms to use cases and solving customer problems.