Broadening Your Horizons, or Why Broadcom Won’t Get VMware

You might have missed the news over the weekend that Broadcom is in talks to buy VMware. As of right now this news is still developing so there’s no way of knowing exactly what’s going to happen. But I’m going to throw my hat into the ring anyway. VMware is what Broadcom really wants and they’re not going to get it.

Let’s break some of this down.

Broad Street

Broadcom isn’t just one of the largest chip manufactures on the planet. Sure, they make networking hardware that goes into many of the products you buy. Yes, they do make components for mobile devices and access points and a whole host of other things, including the former Brocade fibre channel assets. So they make a lot of chips.

However, starting back in November 2018, Broadcom has been focused on software acquisitions. They purchased CA Technologies for $19 billion. They bought Symantec the next year for $10 billion. They’re trying to assemble a software arm to work along with their hardware aspirations. Seems kind of odd, doesn’t it?

Ask IBM how it feels to be the dominant player in mainframes. Or any other dominant player in a very empty market. It’s lonely and boring. And boring is the exact opposite of what investors want today. Mainframes and legacy computing may be the only thing keeping IBM running right now. And given that Broadcom’s proposed purchase of Qualcomm was blocked a few years ago you can see that Broadcom is likely at the limit of what they’re going to be able to do with chipsets.

Given the explosion of devices out there you’d think that a chip manufacturer would want to double and triple down on development, right? Especially given the ongoing chip shortage. However, you can only iterate on those chips so many times. There’s only so much you can squeeze before you run out of juice. Ask Intel and AMD. Or, better yet, see how they’ve acquired companies to diversify into things like FPGAs and ARM-based DPUs. They realize that CPUs alone aren’t going to drive growth. There have to be product lines that will keep the investor cash flowing in. And that doesn’t come from slow and steady business.

Exciting and New

VMware represents a huge potential business arena for Broadcom. They get to jump into the data center with both feet and drive hybrid cloud deployments. They can be a leader in the on-prem software market overnight with this purchase. Cloud migrations take time. Software needs to be refactored. And that means running it in your data center for a while until you can make it work in the cloud. You could even have software that is never migrated for technical or policy-based reasons.

However, that very issue is going to cause problems for VMware and Broadcom. Is there a growth market in the data center in an enterprise? Do you see companies adding new applications and resources to their existing enterprise data centers? Or do you see them migrating to the cloud first? Do you imagine given the choice between building more compute cluster in the existing hybrid data center or developing for the cloud the first time that companies are going to choose the former?

To me, the quandary of VMware isn’t that different from the one faced by IBM. Yes, you can develop new applications to run on mainframes or on-prem data centers. But you can also not do that too. Which means you have to persuade people to use your technology. Maybe it’s for ease-of-management for existing operations teams. Could be an existing relationship that allows you to execute faster. But no matter what choice you make you’re incurring some form of technical debt when you choose to use existing technology to do something that could also be accomplished with new ideas.

Know who else hates the idea of technical debt and slow steady growth? That’s right, investors. They want flashy year-over-year numbers every quarter to prove they’re right. They want to see that stock price climb so they can eventually sell it and invest in some other growth market. Gone are the days when people were proud to own a bit of company and see it prosper over time. Instead, investors have a vision that lasts about 90 days and is entirely focused on the bottom line. If you aren’t delivering growth you don’t have value. It’s not even about making money any more. You have to make more all the time.

The Broad Elephant

The two biggest shareholders of VMware would love to see it purchased for a ton of money. Given the current valuation north of $40 billion, Dell and Silver Lake would profit handsomely from a huge acquisition. That could be used to pay down even more debt and expand the market for Dell solutions. So they’re going to back it if the numbers look good.

The other side of this equation is the rest of the market that thinks Broadcom’s acquisition is a terrible idea. Twitter is filled with analysts and industry experts talking about how terrible this would be for VMware customers. Given that Symantec and CA haven’t really been making news recently would tend to lend credence to that assessment.

The elephant in the room is what happens when customers don’t want VMware to sell? Sure, if VMware is allowed to operate as an independent entity like it was during the EMC Federation days things are good. They’ll continue to offer support and make happy customers. However, there is always the chance something will change down the road and force the status quo to change. And that’s the thing no one wants to talk about. Does VMware reject a very good offer in favor of autonomy? They just got out from under the relationship with Dell Technologies that was odd to say the least. Do they really want to get snapped up right away?


Tom’s Take

My read on this is simple but likely too simple. Broadcom is going to make a big offer based on stock price so they can leverage equity. The market has already responded favorably to the rumors. Dell and Silver Lake will back the offer because they like the cash to change their leverage situation. Ultimately, regulators will step in and decide the deal. I’m betting the regulators will say “no” like they did with Qualcomm. When the numbers are this big there are lots of eyeballs on the deal.

Ultimately Broadcom may want VMware and the biggest partners may be on board with it. But I think we’re going to see it fall apart because the approvals will either take too long and the stock price will fall enough to make it no longer worth it or the regulators will just veto the deal outright. Either way we’re going to be analyzing this for months to come.

Managing Leaders, Or Why Pat Gelsinger Is Awesome

In case you missed it, Intel CEO Bob Swan is stepping down from his role effective February 15 and will be replaced by current VMware CEO Pat Gelsinger. Gelsinger was the former CTO at Intel for a number of years before leaving to run EMC and VMware. His return is a bright spot in an otherwise dismal past few months for the chip giant.

Why is Gelsinger’s return such a cause for celebration? The analysts that have been interviewed say that Intel has been in need of a technical leader for a while now. Swan came from the office of the CFO to run Intel on an interim basis after the resignation of Brian Krzanich. The past year has been a rough one for Intel, with delays in their new smaller chip manufacturing process and competition heating up from long-time rival AMD but also from new threats like ARM being potentially sold to NVIDIA. It’s a challenging course for any company captain to sail. However, I think one key thing makes is nigh impossible for Swan.

Management Mentality

Swan is a manager. That’s not meant as a slight inasmuch as an accurate label. Managers are people that have things and look after them. Swan came from the financial side of the house where you have piles of resources and you do your best to account for them and justify their use. It’s Management 101. Managers make good CEOs for a variety of companies. They make sure that the moves are small and logical and will pay off in the future for the investors and eventually the workers as well. They are stewards first and foremost. When their background comes from something with inherent risk they are especially stewardly.

You know who else was a manager? John Sculley, the man who replaced Steve Jobs at Apple back in 1983. Sculley was seen as a moderating force to Jobs’ driving vision and sometimes reckless decision making skills. Sculley piloted the ship into calm waters at first but was ultimately sent packing because his decisions were starting to make less and less sense, such as exploring options to split Apple into separate companies and taking on IBM head-to-head on their turf.

Sculley was ousted and Jobs returned to Apple in 1993. It wasn’t easy at first but eventually the style of Jobs started producing results. Things like the iPod, iMac, and eventually the iPhone came from his vision. He’s a leader in that regard. Leaders are the ones that jump out and take risks to make big results. Leaders are people like John Kennedy that give a vision of going to the moon in a decade without the faintest idea how that might happen. Leadership is what drives companies.

Leaders, however, are a liability without managers. Leaders say “let’s go to the moon!” Managers sit down and figure out how to make that happen without breaking the budgets or losing too many people along the way. Managers are the grounded voices that guide leaders. Without someone telling a leader of the challenges to overcome they won’t see the roadblocks until the drive right into them.

Leaders without brakes on their vision have no reality to shape it. Every iMac has an Apple Lisa. Every iPod has the iPod Hi-Fi. Even the iPhone wasn’t the iPhone until the App Store came around against the original vision of Apple’s driving force. To put it another way, George Lucas is a visionary leader in filmmaking. However, when he was turned loose without management of his process we ended up with the messy prequel trilogy. Why was Empire Strikes Back such a good film? Because it had people like Lawrence Kasdan involved managing the process of Lucas creating art. They helped focus the drive of a leader and make the result something great.

Tech Leadership

Let’s bring this discussion back to Intel and Pat Gelsinger. I know he is the best person to lead Intel right now. I know that because Gelsinger is very much a tech leader. He has visions for how things need to be and he can see how to get there. He knows that reducing costs and reaving product lines at Intel isn’t going to make them a better company down the road no matter what the activist investors have to say on the matter. They may have wanted regime change when they petitioned the board back in December, but they may find the new king a bit harder to deal with.

Gelsinger is also a manager. Going from CTO to being COO at EMC and eventually CEO at VMware has tempered his technical chops. You can’t hope to run a company on crazy ideas and risky bets. Steve Jobs had people like Tim Cook in the background keeping him as grounded in reality as possible. Gelsinger picked up these skills in helming VMware and I think that’s going to pay off for him at Intel. Rather than running out to buy another company to augment capabilities that will never see the light of day, someone like him can see the direction that Intel needs to go and make it happen in a collected manner. No more FPGA acquisitions that never bear fruit. No more embarrassing sales of the mobile chip division because no one could capitalize on it.

Pat Gelsinger is the best kind of technical manager. I saw it in the one conversation I was involved in with him during an event. He stepped in to a talk between myself and a couple of analysts. He listened to them and to me and when he was asked for his opinion, he stopped for a moment to think. He asked a question to clarify and then gave his answer. That’s a tempered leader approach to things. He listened. He thought. He clarified. And then he made a decision. That means there is steel behind the fire. That means the driving factors of the decision-making process aren’t just “cool stuff” or “save as much money as we can”. What will happen is the fusion of the two that the company needs to stay relevant in a world that seems bent on passing it by.


Tom’s Take

I’ve worked for managers and I’ve worked for leaders. I don’t have a preference for one or the other. I’ve seen leaders sell half their assets to save their company. I’ve also seen them buy ridiculous stuff in an effort to build something that no one would buy. I’ve seen managers keep things calm in the middle of a chaotic mess. I’ve also seen them so wracked with indecision that the opportunities they needed to capitalize on sailed off into the sunset. If you want to be the best person to run a company as the CEO, whether it’s a hundred people or a hundred thousand, you should look to someone like Pat Gelsinger. He’s the best combination of a manager and leader that I’ve seen in a long time. In five years we will be talking about how he was the one to bring Intel back to the top of the mountain, both through his leadership and his management skills.

Fast Friday Random Thoughts

It’s Friday and we’re technically halfway into the year now. Which means things should be going smoother soon, right? Here’s hoping, at least.

  • I posted a new episode of Tomversations yesterday. This one is about end-to-end encryption. Here’s hoping the Department of Justice doesn’t find a way to screw this up. And here’s hoping the Senate stops helping.
  • I saw a post that posits VMware may be looking to buy BitGlass. I know VMware’s NSX team pretty well. I also talked to the BitGlass team at RSA this year. I think this is something that VMware needs to pick up to be honest. They need to round out their SASE portfolio with a CASB. BitGlass is the best one out there to make that happen. I think we’re going to see a move here before we know it.
  • There are a lot of other acquisitions going on in the market. VMware bought Datrium. Uber bought Postmates. It’s typical to see these kinds of acquisitions during downturns because it becomes way cheaper to snap up your competition. I expect Q3 is going to be full of consolidation in the networking space. Cisco won’t start doing anything until August at the earliest, but once their numbers are finalized I’m sure we’re going to see them snap up a hot startup or two.

Tom’s Take

Here’s hoping the next six months are a little less crazy. I doubt that will be the case, but we’ll see!

Really Late Company Christmas Shopping

I’m headed out to Cisco Live Europe today, so I’m trying to get everything packed before I head to the airport. I also realize I need to go buy a few things for my suitcase. Which must be the same thing that a bunch of companies thought this week as they went on a buying spree! Seriously:

I don’t think we’re quite done yet, either. An oblique tweet from a friend with some inside sources leads me to believe that the reason why this is happening right now is because some of the venture funds are getting antsy and are calling in their markers. Maybe they need the funds to cash out investors? Maybe they’re looking to reduce their exposure to other things? Maybe they’re ready to jump on a plane to an uncharted island somewhere?

This is one of the challenges when you’re beholden to investors. Sure, not all of us are independently wealthy and capable of bootstrapping our own startup. We need some kind of funding to make that happen. But as soon as we do we are going to find ourselves at the mercy of their decisions and be forced to play by their rules.

If it’s time for them to get out of the position they have in a company, you’d better have the money. And if you don’t, they’re going to get it. I don’t know for sure what the situation is in both of those cases, but no one had really been talking publicly about buying Nyansa or Big Switch in the last few months. I had always figured that Nyansa would go to a bigger company, much like Aruba buying Rasa Networks in 2016. VMware is an interesting fit for them and a much better enterprise use of the technology in the long term.

Big Switch is puzzling for sure. From what I’ve heard they were profitable last quarter and bullish on the entire outlook for 2020. Did something change? Did the investors decide they wanted out? Or did some other market force push Big Switch to find a new home? When you look at the list of companies that were interested in buying them it’s not surprising. Dell Technologies would have been my first guess given their close working relationship. VMware would have been the second. Juniper and Extreme were interesting options but I’m not quite sure where the fit would be with them. And Cisco would have purchased as a purely defensive measure. So Arista is an interesting fit. I’m still waiting to hear some more details given how fresh this story is.

We’re into Q1 for most companies now. Or at least the ones that don’t have an odd FY schedule. So they’re realizing they either need to catch up on some R&D or that they have enough cash or equity lying around to go shopping. And if some of the companies on the market are selling at lower prices, it only makes sense to snap them up. Even if the integration pieces are going to take a while. Nyansa has great analytics, but it’s focused on the endpoint side. It’s going to take some work to make it all play nice with the other analytics pieces of VMware. That’s not cheap, but if the price of doing it through acquisition is cheaper than doing it through in-house efforts then buying your way in looks better in the long run. And if some venture fund is looking for cash at the same time, it could be a match made in heaven.


Tom’s Take

I’m a tech person. Even through the stuff I’ve done with Tech Field Day where I’ve had to learn more about financing and such I still consider myself a tech grunt first and foremost. When the talk turns to preferred share options and funding rounds and other such stuff I tend to look back at technology and figure out where that stuff is going. People that work with money for a living have a much different opinion of technology than tech people do. If that weren’t the case, we’d be talking about Betamax and HD-DVD more than we do now. But, money is still the way that tech gets done. And sometimes you need to do a little shopping to get the tech you need to keep building.

VMware and VeloCloud: A Hedge Against Hyperconvergence?

VMware announced on Thursday that they are buying VeloCloud. This was a big move in the market that immediately set off a huge discussion about the implications. I had originally thought AT&T would buy VeloCloud based on their relationship in the past, but the acquistion of Vyatta from Brocade over the summer should have been a hint that wasn’t going to happen. Instead, VMware swooped in and picked up the company for an undisclosed amount.

The conversations have been going wild so far. Everyone wants to know how this is going to affect the relationship with Cisco, especially given that Cisco put money into VeloCloud in both 2016 and 2017. Given the acquisition of Viptela by Cisco earlier this year it’s easy to see that these two companies might find themselves competing for marketshare in the SD-WAN space. However, I think that this is actually a different play from VMware. One that’s striking back at hyperconverged vendors.

Adding The Value

If you look at the marketing coming out of hyperconvergence vendors right now, you’ll see there’s a lot of discussion around platform. Fast storage, small footprints, and the ability to deploy anywhere. Hyperconverged solutions are also starting to focus on the hot new trends in compute, like containers. Along the way this means that traditional workloads that run on VMware ESX hypervisors aren’t getting the spotlight they once did.

In fact, the leading hyperconvergence vendor Nutanix has been aggressively selling their own hypervisor, Acropolis as a competitor to VMware. They tout new features and easy configuration as the major reason to use Acropolis over ESX. The push by Nutanix is to get their customers off of ESX and on to Acropolis to get a share of the VMware budget that companies are currently paying.

For VMware, it’s a tough sell to keep their customers on ESX. There’s a very big ecosystem of software out there that runs on ESX, but if you can replicate a large portion of it natively like Acropolis and other hypervisors do there’s not much of a reason to stick with ESX. And if the VMware solution is more expensive over time you will find yourself choosing the cheaper alternative when the negotiations come up for renewal.

For VMware NSX, it’s an even harder road. Most of the organizations that I’ve seen deploying hyperconverged solutions are not huge enterprises with massive centralized data centers. Instead, they are the kind small-to-medium businesses that need some functions but are very budget conscious. They’re also very geographically diverse, with smaller branch offices taking the place of a few massive headquarters locations. While NSX has some advantages for these companies, it’s not the best fit for them. NSX works optimally in a data center with high-speed links and a well-built underlay network.

vWAN with VeloCloud

So how is VeloCloud going to play into this? VeloCloud already has a lot of advantages that made them a great complement to VMware’s model. They have built-in multi tenancy. Their service delivery is virtualized. They were already looking to move toward service providers as their primary market, but network services and managed service providers. This sounds like their interests are aligning quite well with VMware already.

The key advantage for VMware with VeloCloud is how it will allow NSX to extend into the branch. Remember how I said that NSX loves an environment with a stable underlay? That’s what VeloCloud can deliver. A stable, encrypted VPN underlay. An underlay that can be managed from one central location, or in the future, perhaps even a vCenter plugin. That gives VeloCloud a huge advantage to build the underlay to get connectivity between branches.

Now, with an underlay built out, NSX can be pushed down into the branch. Branches can now use all the great features of NSX like analytics, some of which will be bolstered by VeloCloud, as well as microsegmentation and other heretofore unseen features in the branch. The large headquarters data center is now available in a smaller remote size for branches. That’s a huge advantage for organizations that need those features in places that don’t have data centers.

And the pitch against using other hypervisors with your hyperconverged solution? NSX works best with ESX. Now, you can argue that there is real value in keeping ESX on your remote branches is not costs or features that you may one day hope to use if your WAN connection gets upgraded to ludicrous speed. Instead, VeloCloud can be deployed between your HQ or main office and your remote site to bring those NSX functions down into your environment over a secure tunnel.

While this does compete a bit with Cisco from a delivery standpoint, it still doesn’t affect them with complete overlap. In this scenario, VeloCloud is a service delivery platform for NSX and not a piece of hardware at the edge. Absent VeloCloud, this kind of setup could still be replicated with a Cisco Viptela box running the underlay and NSX riding on top in the overlay. But I think that the market that VMware is going after is going to be building this from the ground up with VMware solutions from the start.


Tom’s Take

Not every issues is “Us vs. Them”. I get that VMware and Cisco seem to be spending more time moving closer together on the networking side of things. SD-WAN is a technology that was inevitably going to bring Cisco into conflict with someone. The third generation of SD-WAN vendors are really companies that didn’t have a proper offering buying up all the first generation startups. Viptela and VeloCloud are now off the market and they’ll soon be integral parts of their respective parent’s strategies going forward. Whether VeloCloud is focused on enabling cloud connectivity for VMware or retaking the branch from the hyperconverged vendors is going to play out in the next few months. But instead of focusing on conflict with anyone else, VeloCloud should be judged by the value it brings to VMware in the near term.

Short Take – The Present Future of the Net

A few random thoughts from ONS and Networking Field Day 15 this week:

  • Intel is really, really, really pushing their 5 generation (5G) wireless network. Note this is not Gen5 fibre channel or 5G 802.11 networking. This is the successor to LTE and capable of pushing a ridiculous amount of data to a very small handset. This is one of those “sure thing” technologies that is going to have a huge impact on our networks. Carriers and service providers are already trying to cope with the client rates we have now. What happens when they are two or three times faster?
  • PNDA has some huge potential for networking a data analytics. Their presentation had some of the most technical discussion during the event. They’re also the basis for a lot of other projects that are in the pipeline. Make sure you check them out. The project organizers suggest that you get started with the documentation and perhaps even help contribute some writing to get more people on board.
  • VMware hosted a dinner for us that had some pretty luminary speakers like Bruce Davie and James Watters. They talked about the journey from traditional networking to a new paradigm filled with microservices and intelligence in the application layer. While I think this is the golden standard that everyone is looking toward for the future, I also think there is still quite a bit of technical debt to unpack before we can get there.
  • Another fun thought kicking around: When we look at these new agile, paradigm shifting deployments, why are they always on new hardware? Would you see the similar improvement of existing processes on new hardware? What would these new processes look like on existing things? I think this one is worth investigating.

Nutanix and Plexxi – An Affinity to Converge

nutanix-logo

Nutanix has been lighting the hyperconverged world on fire as of late. Strong sales led to a big IPO for their stock. They are in a lot of conversations about using their solution in place of large traditional virtualization offerings that include things like blade servers or big boxes. And even coming off the recent Nutanix .NEXT conference there were some big announcements in the networking arena to help them complete their total solution. However, I think Nutanix is missing a big opportunity that’s right in front of them.

I think it’s time for Nutanix to buy Plexxi.

Software Says

If you look at the Nutanix announcements around networking from .NEXT, they look very familiar to anyone in the server space. The highlights include service chaining, microsegmentation, and monitoring all accessible through an API. If this sounds an awful lot like VMware NSX, Cisco ACI, or any one of a number of new networking companies then you are in the right mode of thinking as far as Nutanix is concerned.

SDN in the server space is all about overlay networking. Segmentation of flows and service chaining are the reason why security is so hard to do in the networking space today. Trying to get traffic to behave in a certain way drives networking professionals nuts. Monitoring all of that to ensure that you’re actually doing what you say you’re doing just adds complexity. And the API is the way to do all of that without having to walk down to the data center to console into a switch and learn a new non-Linux CLI command set.

SDN vendors like VMware and Cisco ACI would naturally have jumped onto these complaints and difficulties in the networking world and both have offered solutions for them with their products. For Nutanix to have bundled solutions like this into their networking offering is no accident. They are looking to battle VMware head-to-head and need to offer the kind of feature parity that it’s going to take a make medium to large shops shift their focus away from the VMware ecosystem and take a long look at what Nutanix is offering.

In a way, Nutanix and VMware are starting to reinforce the idea that the network isn’t a magical realm of protocols and tricks that make applications work. Instead, it’s a simple transport layer between locations. For instance, Amazon doesn’t rely on the magic of the interstate system to get your packages from the distribution center to your home. Instead, the interstate system is just a transport layer for their shipping overlays – UPS, FedEX, and so on. The overlay is where the real magic is happening.

Nutanix doesn’t care what your network looks like. They can do almost everything on top of it with their overlay protocols. That would seem to suggest that the focus going forward should be to marginalize or outright ignore the lower layers of the network in favor of something that Nutanix has visibility into and can offer control and monitoring of. That’s where the Plexxi play comes into focus.

Plexxi Logo

Affinity for Awesome

Plexxi has long been a company in search of a way to sell what they do best. When I first saw them years ago, they were touting their Affinities idea as a way to build fast pathways between endpoints to provide better performance for applications that naturally talked to each other. This was a great idea back then. But it quickly got overshadowed by the other SDN solutions out there. It even caused Plexxi to go down a slightly different path for a while looking at other options to compete in a market that they didn’t really have a perfect fit product.

But the Affinities idea is perfect for hyperconverged solutions. Companies like Nutanix are marking their solutions as the way to create application-focused compute nodes on-site without the need to mess with the cloud. It’s a scalable solution that will eventually lead to having multiple nodes in the future as your needs expand. Hyperconverged was designed to be consumable per compute unit as opposed to massively scaling out in leaps and bounds.

Plexxi Affinities is just the tip of the iceberg. Plexxi’s networking connectivity also gives Nutanix the ability to build out a high-speed interconnect network with one advantage – noninterference. I’m speaking about what happens when a customer needs to add more networking ports to support this architecture. They need to make a call to their Networking Vendor of Choice. In the case of Cisco, HPE, or others, that call will often involve a conversation about what they’re doing with the new network followed by a sales pitch for their hyperconverged solution or a partner solution that benefits both companies. Nutanix has a reputation for being the disruptor in traditional IT. The more they can keep their traditional competitors out of the conversation, the more likely they are to keep the business into the future.


Tom’s Take

Plexxi is very much a company with an interesting solution in need of a friend. They aren’t big enough to really partner with hyperconverged solutions, and most of the hyperconverged market at this point is either cozy with someone else or not looking to make big purchases. Nutanix has the rebel mentality. They move fast and strike quickly to get their deals done. They don’t take prisoners. They look to make a splash and get people talking. The best way to keep that up is to bundle a real non-software networking component alongside a solution that will make the application owners happy and keep the conversation focused on a single source. That’s how Cisco did it back and the day and how VMware has climbed to the top of the virtualization market.

If Nutanix were to spend some of that nice IPO money on a Plexxi Christmas present, I think 2017 would be the year that Nutanix stops being discussed in hushed whispers and becomes a real force to be reckoned with up and down the stack.

The Death of TRILL

wasteland_large

Networking has come a long way in the last few years. We’ve realized that hardware and ASICs aren’t the constant that we could rely on to make decisions in the next three to five years. We’ve thrown in with software and the quick development cycles that allow us to iterate and roll out new features weekly or even daily. But the hardware versus software battle has played out a little differently than we all expected. And the primary casualty of that battle was TRILL.

Symbiotic Relationship

Transparent Interconnection of Lots of Links (TRILL) was proposed as a solution to the complexity of spanning tree. Radia Perlman realized that her bridging loop solution wouldn’t scale in modern networks. So she worked with the IEEE to solve the problem with TRILL. We also received Shortest Path Bridging (SPB) along the way as an alternative solution to the layer 2 issues with spanning tree. The motive was sound, but the industry has rejected the premise entirely.

Large layer 2 networks have all kinds of issues. ARP traffic, broadcast amplification, and many other numerous issues plague layer 2 when it tries to scale to multiple hundreds or a few thousand nodes. The general rule of thumb is that layer 2 broadcast networks should never get larger than 250-500 nodes lest problems start occurring. And in theory that works rather well. But in practice we have issues at the software level.

Applications are inherently complicated. Software written in the pre-Netflix era of public cloud adoption doesn’t like it when the underlay changes. So things like IP addresses and ARP entries were assumed to be static. If those data points change you have chaos in the software. That’s why we have vMotion.

At the core, vMotion is a way for software to mitigate hardware instability. As I outlined previously, we’ve been fixing hardware with software for a while now. vMotion could ensure that applications behaved properly when they needed to be moved to a different server or even a different data center. But they also required the network to be flat to overcome limitations in things like ARP or IP. And so we went on a merry journey of making data centers as flat as possible.

The problem came when we realized that data centers could only be so flat before they collapsed in on themselves. ARP and spanning tree limited the amount of traffic in layer 2 and those limits were impossible to overcome. Loops had to be prevented, yet the simplest solution disabled bandwidth needed to make things run smoothly. That caused IEEE and IETF to come up with their layer 2 solutions that used CLNS to solve loops. And it was a great idea in theory.

The Joining

In reality, hardware can’t be spun that fast. TRILL was used as a reference platform for proprietary protocols like FabricPath and VCS. All the important things were there but they were locked into hardware that couldn’t be easily integrated into other solutions. We found ourselves solving problem after problem in hardware.

Users became fed up. They started exploring other options. They finally decided that hardware wasn’t the answer. And so they looked to software. And that’s where we started seeing the emergence of overlay networking. Protocols like VXLAN and NV-GRE emerged to tunnel layer 2 packets over layer 3 networks. As Ivan Pepelnjak is fond of saying layer 3 transport solves all of the issues with scaling. And even the most unruly application behaves when it thinks everything is running on layer 2.

Protocols like VXLAN solved an immediate need. They removed limitations in hardware. Tunnels and fabrics used novel software approaches to solve insurmountable hardware problems. An elegant solution for a thorny problem. Now, instead of waiting for a new hardware spin to fix scaling issues, customers could deploy solutions to fix the issues inherent in hardware on their own schedule.

This is the moment where software defined networking (SDN) took hold of the market. Not when words like automation and orchestration started being thrown about. No, SDN became a real thing when it enabled customers to solve problems without buying more physical devices.


Tom’s Take

Looking back, we realize now that building large layer 2 networks wasn’t the best idea. We know that layer 3 scales much better. Given the number of providers and end users running BGP to top-of-rack (ToR) switches, it would seem that layer 3 scales much better. It took us too long to figure out that the best solution to a problem sometimes takes a bit of thought to implement.

Virtualization is always going to be limited by the infrastructure it’s running on. Applications are only as smart as the programmer. But we’ve reached the point where developers aren’t counting on having access to layer 2 protocols that solve stupid decision making. Instead, we have to understand that the most resilient way to fix problems is in the software. Whether that’s VXLAN, NV-GRE, or a real dev team not relying on the network to solve bad design decisions.

The Marriage of the Ecosystem

 

marriage

A recent discussion with Greg Ferro (@EtherealMind) of Packet Pushers and Nigel Poulton (@NigelPoulton) of In Tech We Trust got me thinking about product ecosystems. Nigel was talking about his new favorite topic of Docker and containers. He mentioned to us that it had him excited because it felt like the good old days of VMware when they were doing great things with the technology. That’s when I realized that ecosystems aren’t all they are cracked up to be.

Courting Technology

Technology is a huge driver for innovation. New ideas are formed into code that runs to accomplish a task. That code is then disseminated to teams and built upon to create toolsets to accomplish even more tasks. That’s how programs happen. Almost every successful shift in technology starts with the courtship of focused code designed to accomplish a simple task or solve a quick problem.

The courtship evolves over time to include other aspects of technology. Development work extends the codebase to accept things like plugins to provide additional functionality. Not core functions though. The separation comes when people want to add additional pieces without compromising the original program. Bolting additional non-core pieces on to existing code causes all kinds of headaches.

That’s how ecosystems start. People build new functions to augment and support the new problems the crop up around those solved by the original tool. Finding new problems is key to driving the ecosystem forward. Without problems to solve, the environment around a particular program starts to contract and disappear.

The Old Ball And Chain

Ecosystems eventually reach the point of stagnation, however. This usually comes when the ecosystem around a product becomes more important than the actual program itself. Think about the ecosystem around Microsoft Office. Office was originally a word processor. That drove additional programs to solve spreadsheets and presentations. Now, people buy the Office productivity suite for more than the word processor. More than a few buy it for the email program. But very little innovation is going into the word processor any longer. Aside from some UI design changes and few minor function additions the majority of the work is being driven around other programs.

This is also the problem with VMware today. The development around the original hypervisor is mostly moot. That problem has been solved completely. Today, all of the marketing hype around the VMware is on other things. Public cloud architectures. Storage virtualization. Networking virtualization. None of these things have anything to do with they hypervisor beyond tying into the ecosystem created around it.

Ecosystems can’t exist without recognizing the original problems being solved and why they are so important. If you build an environment around a product and then leave that product to wither on the vine, your ecosystem will eventually collapse. When your company pivots away from what makes it successful in the first place you run the risk of disaster.

Note that this doesn’t include what happens when the technology landscape forces you to shift your focus. Token ring networking doesn’t solve a big problem today. Companies focusing on it needed to pivot away from it to solve new problems. As such, there really isn’t a token ring ecosystem today.

Now, look at tape backup units as a counterpoint. They still solve a problem – backing up large amounts of data at low cost. Quite a few of the old tape backup vendors have moved away from the market and are concentrating on new solutions. A few of the old vendors, such as SpectraLogic, still support tape solutions and are continuing to drive the tape ecosystem with new ideas. But those ideas still manage to come back to tape. That’s how they can keep the ecosystem grounded and relevant.


Tom’s Take

New technology is like dating. You get excited and giddy about where things are going and all the potential you see. You enjoy spending time together just talking or existing. As you start to get more serious you start to see issues crop up the need to be solved. Eventually you take the plunge and make things super serious. What you don’t want to have happen at this point is the trap that some people fall into. When you concentrate on the issues that crop up around things you start to lose focus. It’s far to easy to think about bills and schools and other ancillary issues and lose sight of the reason why you’re together in the first place.

Ecosystems are like that. People start focusing on the ecosystem at the expense of the technology that brought everyone together in the first place. When you do that you forget about all the great things that happened in the beginning and you concentrate on the problems that have appeared and not the technology. In order to keep your ecosystem vibrant and relevant, you have to step back and remember the core technology from time to time.

 

 

Disruption in the New World of Networking

This is the one of the most exciting times to be working in networking. New technologies and fresh takes on existing problems are keeping everyone on their toes when it comes to learning new protocols and integration systems. VMworld 2013 served both as an annoucement of VMware’s formal entry into the larger networking world as well as putting existing network vendors on notice. What follows is my take on some of these announcements. I’m sure that some aren’t going to like what I say. I’m even more sure a few will debate my points vehemently. All I ask is that you consider my position as we go forward.

Captain Over, Captain Under

VMware, through their Nicira acquisition and development, is now *the* vendor to go to when you want to build an overlay network. Their technology augments existing deployments to provide software features such as load balancing and policy deployment. In order to do this and ensure that these features are utilized, VMware uses VxLAN tunnels between the devices. VMware calls these constructs “virtual wires”. I’m going to call them vWires, since they’ll likely be called that soon anyway. vWires are deployed between hosts to provide a pathway for communications. Think of it like a GRE tunnel or a VPN tunnel between the hosts. This means the traffic rides on the existing physical network but that network has no real visibility into the payload of the transit packets.

Nicira’s brainchild, NSX, has the ability to function as a layer 2 switch and a layer 3 router as well as a load balancer and a firewall. VMware is integrating many existing technologies with NSX to provide consistency when provisioning and deploying a new sofware-based network. For those devices that can’t be virtualized, VMware is working with HP, Brocade, and Arista to provide NSX agents that can decapsulate the traffic and send it to an physical endpoint that can’t participate in NSX (yet). As of the launch during the keynote, most major networking vendors are participating with NSX. There’s one major exception, but I’ll get to that in a minute.

NSX is a good product. VMware wouldn’t have released it otherwise. It is the vSwitch we’ve needed for a very long time. It also extends the ability of the virtualization/server admin to provision resources quickly. That’s where I’m having my issue with the messaging around NSX. During the second day keynote, the CTOs on stage said that the biggest impediment to application deployment is waiting on the network to be configured. Note that is my paraphrasing of what I took their intent to be. In order to work around the lag in network provisioning, VMware has decided to build a VxLAN/GRE/STT tunnel between the endpoints and eliminate the network admin as a source of delay. NSX turns your network in a fabric for the endpoints connected to it.

Under the Bridge

I also have some issues with NSX and the way it’s supposed to work on existing networks. Network engineers have spent countless hours optimizing paths and reducing delay and jitter to provide applications and servers with the best possible network. Now, that all doesn’t matter. vAdmins just have to click a couple of times and build their vWire to the other server and all that work on the network is for naught. The underlay network exists to provide VxLAN transport. NSX assumes that everything working beneath is running optimally. No loops, no blocked links. NSX doesn’t even participate in spanning tree. Why should it? After all, that vWire ensures that all the traffic ends up in the right location, right? People would never bridge the networking cards on a host server. Like building a VPN server, for instance. All of the things that network admins and engineers think about in regards to keeping the network from blowing up due to excess traffic are handwaved away in the presentations I’ve seen.

The reference architecture for NSX looks pretty. Prettier than any real network I’ve ever seen. I’m afraid that suboptimal networks are going to impact application and server performance now more than ever. And instead of the network using mechanisms like QoS to battle issues, those packets are now invisible bulk traffic. When network folks have no visibility into the content of the network, they can’t help when performance suffers. Who do you think is going to get blamed when that goes on? Right now, it’s the network’s fault when things don’t run right. Do you think that moving the onus for server network provisioning to NSX and vCenter is going to forgive the network people when things go south? Or are the underlay engineers going to be take the brunt of the yelling because they are the only ones that still understand the black magic outside the GUI drag-and-drop to create vWires?

NSX is for service enablement. It allows people to build network components without knowing the CLI. It also means that network admins are going to have to work twice as hard to build resilient networks that work at high speed. I’m hoping that means that TRILL-based fabrics are going to take off. Why use spanning tree now? Your application and service network sure isn’t. No sense adding any more bells and whistles to your switches. It’s better to just tie them into spine-and-leaf CLOS fabrics and be done with it. It now becomes much more important to concentrate on the user experience. Or maybe the wirless network. As long as at least one link exists between your ESX box and the edge switch let the new software networking guys worry about it.

The Recumbent Incumbent?

Cisco is the only major networking manufacturer not publicly on board with NSX right now. Their CTO Padma Warrior has released a response to NSX that talks about lock-in and vertical integration. Still others have released responses to that response. There’s a lot of talk right now about the war brewing between Cisco and VMware and what that means for VCE. One thing is for sure – the landscape has changed. I’m not sure how this is going to fall out on both sides. Cisco isn’t likely to stop selling switches any time soon. NSX still works just fine with Cisco as an underlay. VCE is still going to make a whole bunch of money selling vBlocks in the next few months. Where this becomes a friction point is in the future.

Cisco has been building APIs into their software for the last year. They want to be able to use those APIs to directly program the network through devices like the forthcoming OpenDaylight controller. Will they allow NSX to program them as well? I’m sure they would – if VMware wrote those instructions into NSX. Will VMware demand that Cisco use the NSX-approved APIs and agents to expose network functionality to their software network? They could. Will Cisco scrap OnePK to implement NSX? I doubt that very much. We’re left with a standoff. Cisco wants VMware to use their tools to program Cisco networks. VMware wants Cisco to use the same tools as everyone else and make the network a commodity compared to the way it is now.

Let’s think about that last part for a moment. Aside from some speed differences, networks are largely going to be identical to NSX. It won’t care if you’re running HP, Brocade, or Cisco. Transport is transport. Someone down the road may build some proprietary features into their hardware to make NSX run better but that day is far off. What if a manufacturer builds a switch that is twice as fast as the nearest competition? Three times? Ten times? At what point does the underlay become so important that the overlay starts preferring it exclusively?


Tom’s Take

I said a lot during the Tuesday keynote at VMworld. Some of it was rather snarky. I asked about full BGP tables and vMotioning the machines onto the new NSX network. I asked because I tend to obsess over details. Forgotten details have broken more of my networks than grand design disasters. We tend to fuss over the big things. We make more out of someone that can drive a golf ball hundreds of yards than we do about the one that can consistently sink a ten foot putt. I know that a lot of folks were pre-briefed on NSX. I wasn’t, so I’m playing catch up right now. I need to see it work in production to understand what value it brings to me. One thing is for sure – VMware needs to change the messaging around NSX to be less antagonistic towards network folks. Bring us into your solution. Let us use our years of experience to help rather than making us seem like pariahs responsible for all your application woes. Let us help you help everyone.