Earlier in my career there is one project that really stood out to me. It involved me, from the server team, working closely with the network team to try to get some new technologies up and running. It was something I was looking forward to because I had a networking background (but had ended up working on a server team, just because that’s how it worked out at the time).
Let me tell you that experience did not go as I had expected. I was met with almost immediate distrust because I was one of those server people trying to tell them what to do. The truth of the matter is it was a brand-new technology to our company that no one had used before, and I was trying just as hard as the network team was to make all those pieces work together.
At the end of the day, everything worked out , and I proved that I wasn’t one of those annoying server people that just wanted to point fingers. It worked out so well that let’s just say many of my networking requests would get bumped to the front of the line after that project.
However, it is funny how many things stay the same no matter how much time passes.
Server Team vs Networking Team: Who Will Win?
I picked up on this notion early in my career thanks to that project. If something happens on the server side, the finger pointing game usually starts pretty quickly. As virtualization continued to grow, so did the size of the outages.
Let’s say there’s an issue with a 24-port switch, and I have 20 ports plugged in. For arguments sake, let’s just say that’s 20 servers impacted.
Now if 20 ESXi hosts are connected to that switch, with 50 virtual machines on them each, we’re now talking about over 1,000 servers impacted, with a good chance there’s something pretty important in that mix.
That just means more stress, and more finger pointing. Everyone is quick to say the network must be the problem (or the storage, which if it is IP-based storage, the poor network team is going to take another hit for that one). The network team is often on the defensive because they’re used to getting the blame (even when it isn’t their fault).
While it seems the server virtualization and the networking teams didn’t really get each other in the past, times have changed in recent years with the rise of software defined networking. In some cases, there’s been some harmony between the groups since hey, the server folks already dealt with this whole virtualization thing!
I took to Twitter to test this theory, and the results were spot on:
Let’s talk two of my favorites: vSphere and networking. What’s the biggest obstacle in making data center operations more cloud-like?
— vmiss (@vmiss33) September 1, 2021
The poll results had a pretty even split between some of the things we see every day. When I asked people to elaborate the response as well, people!
Everyone Loses
When you’re on an outage call and the blame game starts, everyone loses. We all know how it goes, a bunch of teams that don’t usually talk to each other are trying to figure out what’s going on as quickly as possible, and everyone is looking at their own tools.
While of course, different tools are needed for a number of reasons, a unified view between teams can really help the initial phases of troubleshooting, especially when it comes to the network.
What if you had a way to provide visibility between the virtual and physical networks?
Connecting the Physical and Virtual Network Worlds
One tool that can streamline operations between the VMware team and networking team is Juniper Apstra. Combining the physical and virtual world with Apstra streamlines common operations like onboarding new ESXi servers, and making sure everything is working correctly.
Besides providing a unified view of what’s going on in the physical and virtual environment for everyone involved Apstra can even take action to automatically fix common misconfiguration issues.
No finger pointing! Apstra’s integration helps facilitate work between the server and networking teams: two teams that are often missing common language and understanding between their separate domains. Those things that always seem to cause problems (I’m looking at you MTUs and VLANs) can be fixed before the finger pointing begins.
Juniper Apstra makes it a two way street, through Apstra, the network team has visibility into the virtual environment, and the server team has visibility into the network environment.
This is some seriously cool stuff. I hope you’ll join me on September 21 to take a deeper dive into Juniper Apstra in a VMware environment. I’ll be joined by Claire Delcourt, a senior product manager at Juniper and we’ll take a look at just how simple Apstra is to use, and how it streamlines not only operations, but the relationship between the network team and the server team.
RSVP here!
Melissa is an Independent Technology Analyst & Content Creator, focused on IT infrastructure and information security. She is a VMware Certified Design Expert (VCDX-236) and has spent her career focused on the full IT infrastructure stack.