Tag Archives: CloudGenix

SD-WAN and Technical Debt

Posted on by
2

Back during Networking Field Day 22, I was having a fun conversation with Phil Gervasi (@Network_Phil) and Carl Fugate (@CarlFugate) about SD-WAN and innovation. I mentioned that it was fascinating to see how SD-WAN companies kept innovating but that bigger, more established companies that had bought into SD-WAN seemed to be having issues catching up. As our conversation continued I realized that technical debt plays a huge role in startup culture in all factors, not just with SD-WAN. However, SD-WAN is a great example of technical debt to talk about here.

Any Color You Want In Black

Big companies have investments in supply chains. They have products that are designed in a certain way because it’s the least expensive way to develop the project or it involves using technology developed by the company that gives them a competitive advantage. Think about something like the Cisco Nexus 9000-series switches that launched with Cisco ACI. Every one of them came with the Insieme ASIC that was built to accelerate the policy component of ACI. Whether or not you wanted to use ACI or Insieme in your deployment, you were getting the ASIC in the switch.

Policies like this lead to unintentional constraints in development. Think back five years to Cisco’s IWAN solution. It was very much the precursor to SD-WAN. It was a collection of technologies like Performance Routing (PfR), Application Visibility Control (AVC), Policy Based Routing (PBR), and Network Based Application Recognition (NBAR). If that alphabet soup of acronyms makes you break in hives, you’re not alone. Cisco IWAN was a platform very much market by potential and complexity.

Let’s step back and ask ourselves an important question: “Why?” Why was IWAN so complicated? Why was IWAN hard to deploy? Why did IWAN fail to capture a lot of market share and ride the wave that eventually became SD-WAN? Looking back, a lot of the choices that were made that eventually doomed IWAN can come down to existing technical debt. Cisco is a company that makes design decisions based on what they’ve been doing for a while.

I’m sure that the design criteria for IWAN came down to two points:

  1. It needs to run on IOS.
  2. It needs to be an ISR router.

That doesn’t sound like much. But imagine the constraints you run into with just those two limitations. You have a hardware platform that may not be suited for the kind of work you want to do. Maybe you want to take advantage of x86 chipset acceleration. Too bad. You have to run what’s in the ISR. Which means it could be underpowered. Or incapable of doing things like crypto acceleration for VPNs, which is important for building a mesh of encrypted tunnels. Or maybe you need some flexibility to build a better detection platform for applications. Except you have to use IOS. Which uses NBAR. And anything you write to extend NBAR has to run on their platforms going forward. Which means you need to account for every possible permutation of hardware that IOS runs on. Which is problematic at best.

See how technical debt can creep in from the most simplistic of sources? All we wanted to do was build a platform to connect WANs together easily. Now we’re mired in a years-old hardware choice and an aging software platform that can’t help us do what needs to be done. Is it any wonder why IWAN didn’t succeed in the original form? Or why so many people involved with the first generation of SD-WAN startups were involved with IWAN, even if just tangentially?

Debt-Free Development

Now, let’s look at a startup like CloudGenix, who was a presenter at Networking Field Day 22 and was recently acquired by Palo Alto Networks. They started off on a different path when they founded the startup. They knew what they wanted to accomplish. They had a vision for what would later be called SD-WAN. But instead of shoehorning it into an existing platform, they had the freedom to build what they wanted.

No need to keep the ISR platform? Great. That means you can build on x86 hardware to make your software more universally deployable on a variety of boxes. Speaking of boxes, using commercial off-the-shelf (COTS) equipment means you can buy some very small devices to run the software. You don’t need a system designed to use ATM modules or T1 connections. If all you little system is ever going to use is Ethernet there’s no reason to include expansion at all. Maybe USB for something like a 4G/LTE modem. But those USB ports are baked into the board already.

A little side note here that came from Olivier Huynh Van of Gluware. You know the USB capabilities on a Cisco ISR? Yeah, the ISR chipset didn’t support USB natively. And it’s almost impossible to find USB that isn’t baked into an x86 board today. So Cisco had to add it to the ISR in a way that wasn’t 100% spec-supported. It’s essentially emulated in the OS. Which is why not every USB drive works in an ISR. Take that for what’s it’s worth.

Back to CloudGenix. Okay, so you have a platform you can build on. And you can build software that can run on any x86 device with Ethernet ports and USB devices. That means your software doesn’t need to do complicated things. It also means there are a lot of methods already out there for programming network operating systems for x86 hardware, such as Intel’s Data Plane Development Kit (DPDK). However CloudGenix chose to build their OS, they didn’t need to build everything completely from scratch. Even if they chose to do it there are still a ton of resources out there to help them get started. Which means you don’t have to restart your development every time you need to add a feature.

Also, the focus on building the functions you want into an OS you can bend to your needs means you don’t need to rely on other teams to build pieces of it. You can build your own GUI. You can make it look however you want. You can also make it operate in a manner that is easiest for your customer base. You don’t need to include every knob or button or bell and whistle. You can expose or hide functions as you wish. Don’t want customers to have tons of control over VPN creation or certificate authentication? You don’t need to worry about the GUI team exposing it without your permission. Simple and easy.

One other benefit of developing on platforms without technical debt? It’s easy to port your software from physical to virtual. CloudGenix was already successful in porting their software to run from physical hardware to the cloud thanks to CloudBlades. Could you imagine trying to get the original Cisco IWAN running in a cloud package for AWS or Azure? If those hives aren’t going crazy right now I’m sure you must have nerves or steel.

Tom’s Take

Technical debt is no joke. Every decision you make has consequences. And they may not be apparent for this generation of products. People you may never meet may have to live with your decisions as they try to build their vision. Sometimes you can work with those constraints. But more often than not brilliant people are going to jump ship and do it on their own. Not everyone is going to succeed. But for those that have the vision and drive and turn out something that works the rewards are legion. And that’s more than enough to pay off any debts, technical or not.

Sorting Through SD-WAN

Posted on by
14

lightspeed

SD-WAN has finally arrived. We’re not longer talking about it in terms of whether or not it is a thing that’s going to happen, but a thing that will happen provided the budgets are right. But while the concept of SD-WAN is certain, one must start to wonder about what’s going to happen to the providers of SD-WAN services.

Any Which Way You Can

I’ve written a lot about SDN and SD-WAN. SD-WAN is the best example of how SDN should be marketed to people. Instead of talking about features like APIs, orchestration, and programmability, you need to focus on the right hook. Do you see a food processor by talking about how many attachments it has? Or do you sell a Swiss Army knife by talking about all the crazy screwdrivers it holds? Or do you simply boil it down to “This thing makes your life easier”?

The most successful companies have made the “easier” pitch the way forward. Throwing a kitchen sink at people doesn’t make them buy a whole kitchen. But showing them how easy and automated you can make installation and management will sell boxes by the truckload. You have to appeal the opposite nature that SD-WAN was created to solve. WANs are hard, SD-WANs make them easy.

But that only works if your SD-WAN solution is easy in the first place. The biggest, most obvious target is Cisco IWAN. I will be the first to argue that the reason that Cisco hasn’t captured the SD-WAN market is because IWAN isn’t SD-WAN. It’s a series of existing technologies that were brought together to try and make and SD-WAN competitor. IWAN has all the technical credibility of a laboratory full of parts of amazing machines. What it lacks is any kind of ability to tie all that together easily.

IWAN is a moving target. Which platform should I use? Do I need this software to make it run correctly? How do I do zero-touch deployments? Or traffic control? How do I plug a 4G/LTE modem into the router? The answers to each of these questions involves typing commands or buying additional software features. That’s not the way to attack the complexity of WANs. In fact, it feeds into that complexity even more.

Cisco needs to look at a true SD-WAN technology. That likely means acquisition. Sure, it’s going to be a huge pain to integrate an acquisition with other components like APIC-EM, but given the lead that other competitors have right now, it’s time for Cisco to come up with a solution that knocks the socks off their longtime customers. Or face the very real possibility of not having longtime customers any longer.

Every Which Way But Loose

The first-generation providers of SD-WAN bounced onto the scene to pick up the pieces from IWAN. Names like Viptela, VeloCloud, CloudGenix, Versa Networks, and more. But, aside from all managing to build roughly the same platform with very similar features, they’ve hit a might big wall. They need to start making money in order for these gambles to pay off. Some have customers. Others are managing the migration into other services, like catering their offerings toward service providers. Still others are ripe acquisition targets for companies that lack an SD-WAN strategy, like HPE or Dell. I expect to see some fallout from the first generation providers consolidating this year.

The second generation providers, like Riverbed and Silver Peak, all have something in common. They are building on a business they’ve already proven. It’s no coincidence that both Riverbed and Silver Peak are the most well-known names in WAN optimization. How well known? Even major Cisco partners will argue that they sell these two “best of breed” offerings over Cisco’s own WAAS solution. Riverbed and Silver Peak have a definite advantage because they have a lot of existing customers that rely on WAN optimization. That market alone is going to net them a significant number of customers over the next few years. They can easily sell SD-WAN as the perfect addition to make WAN optimization even easier.

The third category of SD-WAN providers is the late comers. I still can’t believe it, but I’ve been reading about providers that aren’t traditional companies trying to get into the space. Talk about being the ninth horse in an eight horse race. Honestly, at this point you’re better off plowing your investment money into something else, like Internet of Things or Virtual Reality. There’s precious little room among the existing first generation providers and the second generation stalwarts. At best, all you can hope for is a quick exit. At worst, your “novel” technology will be snapped up for pennies after you’re bankrupt and liquidating everything but the standing desks.

Tom’s Take

Why am I excited about the arrival of SD-WAN? Because now I can finally stop talking about it! In all seriousness, when the boardroom starts talking about things that means it’s past the point of being a hobby project and now has become a real debate. SD-WAN is going to change one of the most irritating aspects of networking technology for us. I can remember trying to study for my CCNP and cramming all the DSL and T1 knowledge a person could fit into a brain in my head. Now, it’s all point-and-click and done. IPSec VPNs, traffic analytics, and application identification are so easy it’s scary. That’s the power of SD-WAN to me. Easy to use and easy to extend. I think that the landscape of providers of SD-WAN technologies is going to look vastly different by the end of 2017. But SD-WAN is going to be here for the long haul.

Hypermyopia In The World Of Networking

Posted on by
2

myopia

The more debate I hear over protocols and product positioning in the networking market today, the more I realize that networking has a very big problem with myopia when it comes to building products. Sometimes that’s good. But when you can’t even see the trees for the bark, let alone the forest, then it’s time to reassess what’s going on.

Way Too Close

Sit down in a bar in Silicon Valley and you’ll hear all kinds of debates about which protocols you should be using in your startup’s project. OpenFlow has its favorite backers. Others say things like Stateless Transport Tunneling (STT) are the way to go. Still others have backed a new favorite draft protocol that’s being fast-tracked at the IETF meetings. The debates go on and on. It ends up looking a lot like this famous video.

But what does this have to do with the product? In the end, do the users really care which transport protocol you used? Is the forward table population mechanism of critical importance to them? Or are they more concerned with how the system works? How easy it is to install? How effective it is at letting them do their jobs?

The hypermyopia problem makes the architecture and engineering people on these projects focus on the wrong set of issues. They think that an elegant and perfect solution to a simple technical problem will be the magical panacea that will sell their product by the truckload. They focus on such minute sets of challenges that they often block out the real problems that their product is going to face.

Think back to IBM in the early days of the Internet. Does anyone remember Blue Lightning? How about the even older MCA Bus? I bet if I said OS/2 I’d get someone’s attention. These were all products that IBM put out that were superior to their counterparts in many ways. Faster speeds, better software architecture, and even revolutionary ideas about peripheral connection. And yet all of them failed miserably in one way or another. Was it because they weren’t technically complete? Or was it because IBM had a notorious problem with marketing and execution when it came to non-mainframe computing?

Take A Step Back

Every writer in technology uses Apple as a comparison company at some point. In this case, you should take a look at their simplicity. What protocol does FaceTime use? Is it SIP? Or H.264? Does it even matter? FaceTime works. Users like that it works. They don’t want to worry about traversing firewalls or having supernodes available. They don’t want to fiddle with settings and tweak timers to make a video call work.

Enterprise customers are very similar. Think about WAN technologies for a moment. Entire careers have been built around finding easy ways to connect multiple sites together. We debate Frame Relay versus ATM. Should we use MPLS? What routing protocol should we use? The debates go on and on. Yet the customer wants connectivity, plain and simple.

At the recent Networking Field Day 9, two companies that specialize in software defined WAN (SD-WAN) had a chance to present. Velocloud and CloudGenix both showcased their methods for creating WANs with very little need for user configuration. The delegates were impressed that the respective company’s technologies “just worked”. No tuning timers. No titanic arguments about MPLS. Just simple wizards and easy configuration.

That’s what enterprise technology should be. It shouldn’t involve a need to get so close to the technology that you lose the big picture. It shouldn’t be a series of debates about which small technology choice to make. It should just work. Users that spend less time implementing technology spend more time using it. They spend more time happy with it. And they’re more likely to buy from you again.

Tom’s Take

If I hear one more person arguing the merits of their technology favorite again, I may throw up. Every time someone comes to me and tells me that I should bet on their horse in the race because it is better or faster or more elegant, I want to grab them by the shoulders and shake some sense into them. People don’t buy complicated things. People hate elegant but overly difficult systems. They just want things to work at the end of the day. They want to put as little thought into a system as they can to maximize the return they get from it. If product managers spent the next iteration of design focusing on ease-of-use instead of picking the perfect tunneling protocol, I think they would see a huge return on their investment in the long run. And that’s something you can see no matter how close you are.

 

Riding the SD-WAN Wave

Posted on by
2
Embed from Getty Images

Software Defined Networking has changed the way that organizations think about their network infrastructure.  Companies are looking at increasing automation of mundane tasks, orchestration of policy, and even using white box switches with the help of new unbound operating systems.  A new class of technologies that is coming to market hopes to reduce complexity and cost for the Achilles Heel of many enterprises: the Wide Area Network (WAN).

Do You WANt To Build A Snowman?

The WAN has always been a sore spot for enterprise networks.  It’s necessary to connect your organization to the world.  If you have remote sites or branch locations, it is critical for daily operations.  If you have an e-commerce footprint your WAN connection needs to be able to handle the generated traffic.  But good WAN connectivity costs money.  Lots of money.

WAN protocols are constantly being refined to come up with the fastest possible transmission and the highest possible uptime.  Frame Relay, Asynchronous Transfer Mode (ATM) and Multi-Protocol Label Switching (MPLS) are a succession of technologies that have shaped enterprise WAN connectivity for over a decade.  They have their strengths and weaknesses.  But it is difficult to build an enterprise WAN without one.

Some customers can’t get MPLS connectivity.  Or even Frame Relay for the matter.  Their locations are too remote or the cost of having the connection installed is far above the return on investment.  These customers are often forced to resort to consumer-class connections, like cable modems, Digital Subscriber Line (DSL), or even 4G/LTE modem uplinks.  While cheaper and easy to install, these solutions are often not as robust as their business-grade counterparts.  And when it comes to support on a down circuit…

Redefining the WAN

How does Software Defined WAN (SD-WAN) help?  SD-WAN technologies from companies like Silver Peak, CloudGenix, and Viptela function like overlay networks for the WAN.  They take the various inputs that you have, such as MPLS, cable, and 4G/LTE networks.  These inputs are then arranged in such a way as to allow you to intelligently program how traffic will behave on the links.  If you want only critical business traffic on the MPLS circuit during business hours you can do that.  If you want to ensure the 4G/LTE uplink is only used in the event of an emergency outage, you can do that too.  You can even program various costs and metrics into the system to help you make decisions about when a given link would be a better economic decision given the time of day or amount of transferred data.

You’re probably saying to yourself, “But I can do all of that today.” And you would be right. But all of this has to happen manually, or at the least require a lot of programming.  If you’ve ever tried to configure OER/PFR on a Cisco router you know what I’m talking about.  And that’s just one vendor’s equipment.  What if there are multiple devices in play?  How do you configure the edge routers for fifty sites?  What happens when a circuit goes down at 3 a.m.?  Having a simple interface for making decisions or even the ability to script actions based on inputs makes the system much more flexible and responsive.

It all comes down to a simple number for all parties involved.  For engineering, the amount of time spent configuring and maintaining complex WAN connectivity will be reduced.  Engineers love not needing to spend time on things.  For the decision makers (and bean counters), it all comes down to money.  SD-WAN technologies reduce costs by better utilizing existing infrastructure.  Eventually, their analysis can allow you to reduce or remove unnecessary connectivity.  That means more money in the pockets of the people that want the money.

Tom’s Take

I’ve referred to WAN applications as the “hello world” for SDN.  That’s because I saw so many people demoing them when SDN was first being talked about.  Cisco did this at Cisco Live 2012 in San Diego.  SD-WAN didn’t really become a concrete thing in my mind until is was the topic of discussion on the Spring ONUG meeting.  Those are the people with the money.  And they are looking at the cost savings and optimization from SD-WAN technologies.  You can better believe that the first wave of SD-WAN that you’ve seen in the last couple of months is just the precursor to a wider look at connectivity in general.  Better get ready to surf.