In this week’s episode of Engineers Unplugged, we welcome for the first time (and not the last) guest host Janel Kratky (follow her @jlkratky)! She’s hosting Jason Pfeifer and Glue Network’s Gregg Wyant as they discuss onePK and how to apply it to the real world. You don’t want to miss this one, it ends with a Glunicorn.
If you would like to become Internet Famous, and strut your unicorn talents, join us for our next filming session at VMworld 2014. Tweet me for details!
This is 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)
Software Defined Networking is at the center of many discussions and debates regarding networking, and right fully so. It means many different things to many different people, and there is a lot of confusion and discrepancy in the term. You can ask 10 different people what SDN means, and you will get 10 different answers. If you ask me, SDN is today what cloud was five years ago. I won’t attempt to define what exactly SDN means, but what I will say is that like cloud, the value of SDN will clarify itself over time with powerful use cases and meaningful applications. Case in point, at the Spring 2014 Open Networking User Group (ONUG) meeting in New York City, the ONUG board of directors proposed nine different use cases that were most likely to be in an RFI/RFQ in the next 12 months. From these use cases, the IT business leader community at ONUG chose Software Defined WAN as the most critical use case in open networking today.
While the idea of SDN in general is exciting and powerful, most companies are in the planning stages of their SDN and automation vision. Most believe it will take at least two to three years to architect and realize the benefits of automation across the enterprise. What’s driving SDN is the promise of the following benefits:
Management: Manual -> Automated Networks
Configuration: Box Centric -> Network Wide
Speed/Agility: Weeks/months -> Minutes
Interoperable: Closed system -> Open System
Currently, there are very few, if any, companies who have completed their SDN strategy. Partially because it’s quite complex with many permutations, and partially because it’s so important to get it right. While planning for SDN and automation in the enterprise, there are two key things to consider:
SDN applications must add value to the existing network today
SDN applications must be able to integrate into the customer’s vision for SDN and automation.
There will be a transition between beginning and end state, but any SDN tool being considered must show value on the network as it is currently deployed and allow for integration with future architectures and platforms. If these considerations can be met, there is a clear reason to begin deployment today. Companies desire a mature solution in global production that enables value through SD WAN, meeting all of the benefits above, not just the promise of those benefits. Glue Networks can provide these benefits. Read More »
Network optimization is a touchy subject for many in the IT world, and a particularly thorny issue for the Wide Area Network (WAN). The idea that the network architecture as designed cannot meet the needs of tomorrow is the cause of much discussion, anxiety and in some cases, gnashing of teeth. However, the reality is that the rate of change of applications and ways the WAN is utilized is accelerating, and the methods of designing, testing, implementing and troubleshooting of today are not keeping pace. In addition, traditional services offered throughout the WAN only offer a partial view of the capabilities of what may be available.
Network Operations Centers can be somber places. I’ve seen quite a few during my last two decades in technology. To monitor and manage a vast network is equal parts nerve racking and mind numbing boredom as you stare at wall-to-wall screens, waiting for an alarm to go off.
Over the years, networks have grown to be more and more complex because there are so many interdependent factors that affect their behavior. These factors include traffic flows, network typologies, network protocols, hardware, software, and most importantly, the interactions among them.
More frightening, the steps required to do these very complex network-wide changes are in many cases still manual. In most enterprises this is done box-by-box one at a time – both time consuming and error prone. On top of that you’ve got to make sure that you’ve calculated for variance with lots of different flavors of swtiches and routers in the field. For example, to leverage a powerful feature such as Performance Routing (PfR), which can double your capacity, each WAN router must be properly configured and the overall WAN architecture adapted to the applications requirements. This can take many man-hours to implement, troubleshoot and optimize – which explains why most IT organizations spend 80-90% on operations, leaving little time for much needed innovation. Add in security, QoS, and mission critical applications and within seconds you can see this akin to kicking a sleeping beast. Once we move to the massive number of devices that are expected for the Internet of Things (IoT), then it simply becomes an unsustainable exercise in failure. Read More »
Before recently taking on a new role as Cisco’s vice president and general manager of Software-Defined Network (SDN) with the enterprise networking group, I served as the vice president and general manager of Cisco’s Unified Access portfolio and led the expansion of the Catalyst 2k, 3k and 4k series product line, which has seen a lot of growth and developed a strong customer base over the past couple of years. Cisco invests heavily in R&D for these products, and has introduced many innovations improving security, application visibility/control, energy savings and converged wired and wireless infrastructure over the past few years.
But as I shifted into my new role and looked back at some of the new Unified Access solutions we introduced alongside our system architecture, I saw a curious disconnect: in some cases, it was getting more difficult for our customers to quickly take advantage of our new innovations.
At Cisco, we design products to make customers’ lives easier and more productive. Not to gather dust because they’re too hard to figure out!