So this is the story of a server admin called Paul and a network admin called Peter, and the story
talks about the frustrations Paul has with what Peter is telling him.
Paul feels that network engineers like Peter and let's use some sales and marketing terms just to make
the story funny, is not agile, is not dynamic, doesn't listen to his requests, takes too long,
is too slow, is too antiquated and seriously.
Needs to get out and play golf more often.
Paul can just not understand why Peter still configures switches and routers through a antiquated old
system, the CLI or command line interface.
So let's talk about Paul's frustrations.
Paul wants to deploy multiple iSCSI servers.
These could be different types of hypervisors, but let's use VMware ESXi because that's quite a popular
implementation.
He wants to have the servers in different parts of the data center.
Now, Peter, the network person, is telling Paul that to limit broadcasts and limit traffic propagation
in the network as well as to implement better security, these ESXi servers need to be in different
subnets.
Now, that's a problem for Paul.
Things have changed recently in iSCSI.
But let's assume for now that he wants to implement things such as the motion where he wants to dynamically
move a VM from one iSCSI server to another and is not able to do that across a routed infrastructure.
He doesn't want Peter to implement a layer three routing infrastructure.
He tells Peter, I need to have these iSCSI servers in the same subnet.
So let's give them IP addresses of ten 111 and ten 112.
Peter just laughs and says, No, you can't have that.
You need to have your servers in different subnets.
Now you can already start hopefully understanding the frustration and battles that are taking place
every day between server administrators and network administrators.
You yourself may be on the receiving end of this and involved in these kind of discussions and hopefully
not too heated battles between server people and network people.
So this is a problem for Paul, the server administrator.
So first problem, I can't have my ESXi servers in the same subnet, which means I can't use the motion,
but I want to use the motion, so that's a problem.
Next issue Paul wants to implement micro segmentation as an example.
He wants to put his VMs.
So let's assume we've got two VMs here in separate subnets, but let's assume that he's got hundreds
or thousands of VMs.
So he tells Peter the network admin, I need 5000 VLANs for argument's sake.
Now, Peter, the network guy says, Sorry, you can't have that.
8 to 1 queue only supports approximately about 4096 VLANs.
But you can't have all of those.
You can only have, let's say, 4000 VLANs.
So immediately, that's another problem for Paul because he is limited by the number of VLANs that he
can deploy.
Now, you might be thinking, well, in my network I would never use 4000 VLANs.
But remember, in a multi-tenant data center, you may very quickly end up with many VLANs being used
and taking it a step further.
You might, as an example, want to have a firewall in front of a web server which may be separated
by another firewall, protecting a database server in case the web server gets compromised.
So in many implementations with multi tier applications, you may want to put different servers in different
subnets and taking it to the extreme.
Why don't you have every VM in a separate VLAN and have a firewall in front of every VM?
So this is a problem for Paul.
Peter is telling him that he can't have a layer to infrastructure between his servers.
He's limited in the number of VLANs that he can use.
And to make it even worse when Paul does request a VLAN.
Let's say he wants to put this VM into VLAN 500 and he talks to Peter and says please implement this
VLAN on your network.
Peter says, Well, I need to manually configure each device through the CLI and we have to go through
a change control process to ensure that we don't cause problems on the network and we only make changes
on a Friday evening.
But today's Monday, says Paul, I want to implement these VMs today.
Peter simply says, Well, you should have asked last week.
Now, making light of this and there are ways that you may be working around these problems in your
environments, but try and see the first.
Duration that a server guy has with a network guy.
VMs can be deployed within seconds.
Networks take a long time to deploy.
VMs can have policies applied to them within seconds from a central management console.
I don't know about you, but I'm pretty sure that you don't manage virtual machines, especially when
you've got hundreds or thousands of them by manually typing commands into each device.
I'm pretty sure you use a orchestration tool like OpenStack or VMware's management tools to manage lots
and lots of VMs.
So why on earth are you configuring routers individually or switches individually through the CLI server?
Guys might be looking at network guys as Paula in this example, saying, you guys are still in the
stone ages.
You still doing things the way that you did 20 years ago.
But following along with our story and once again, just take it as a story.
US network guys are hard of hearing.
We refuse to listen to server guys because we know what we're doing.
We've been implementing networks for 1020 years.
The way we've deployed them is stable, robust and scalable in our opinion.
So why change it?
Server guys got tired of fighting with network guys and decided to change everything.
Remember the disruption that took place in a VoIP environment and how applications like WhatsApp changed
everything when setting up calls.
So the guys have had enough of fighting and dealing with network people, and the easiest solution is
to take them out of the equation so no longer deal with network people because as we know, network
people tend to be grumpy, tend to be very difficult to deal with, only see their way of doing things.
So server guy said Enough is enough.
Let's not deal with network people.
And I only say this as a joke because I am a network person.