Home > Blogs > OpenStack Blog for VMware


The Future For Network Engineers: Where We Are Today

A little over 7 years ago, shortly after joining VMware as a Network Virtualization Engineer, I published a blog post where I speculated on the possible evolution of the Network and Security Engineer roles, both key positions within IT staffs around the world tasked with designing, deploying and maintaining datacenter networks and firewalls.

 

The post generated some lighthearted controversy, as evidenced by the passionate comments you can read below that article. As a side note, you should know that I am super friendly with most of the folks who opined on my thoughts, as we keep meeting in the field, for various reasons.

 

Given that a lot has happened since that post, I thought it would be a good idea to reflect on the statements I made back then, check if they were right, or not, and take a guess again in terms of what the future holds. Let’s start with the concept of Network Virtualization itself and then explore some of the other predictions:

 

Is Network Virtualization a reality today?

 

Network Virtualization, this notion that one can simulate a network topology different from the physical one in order to provision connectivity for applications a lot faster, WAS a reality even at the time of my post. For years, networking vendors had been providing solutions that leveraged various encapsulation techniques, in order to propagate L2 or L3 traffic over trusted or untrusted transit networks (think “datacenter” vs. “the Internet”). IPsec, MPLS, VXLAN, Nicira’s Stateless TCP Transport (STT), etc., were all means used to achieve this goal, covering a wide array of use cases and justifications.

 

What we did at VMware was different though, and very revolutionary. We decided to decouple these encapsulation techniques from the network hardware and offer a virtual fabric that would work on top of literally any physical fabric, irrespective of the vendor who provided it. It is because of this decision that today you can use NSX to extend consistent application connectivity across clouds (private, hybrid and public), form factors (VMs running on multiple hypervisors, bare metal, containers and cloud native) and locations (datacenter, remote office or edge). The industry momentum behind SD-WAN, with VMware as one of the leaders in this space, is also proof that Network Virtualization goes beyond the datacenter.

 

What about security? What is the current state of affairs?

 

In my post, I imagined a world in which a particular security posture, let’s call it “a micro-segmentation policy”, could be defined and applied to target workloads regardless of cloud, location or format. Has that promised materialized itself in 2020?

 

Fortunately, the answer is yes.

 

Today, you can use NSX to define a security policy that is aligned with your business intent or compliance requirements, and then enforce it without worrying about where the application lives. I routinely demonstrate this multi-cloud support by showing a top-level security ruleset that looks and works the same for on-prem, AWS, Azure and some of the other public cloud offerings. What is more important, we now see technology that leverages the power of Machine Learning (ML) and Artificial Intelligence (AI) to help automate the creation and dissemination of such policies, while providing additional capabilities like malware and anomaly detection, next-gen antivirus and compliance attestation. Examples of these offerings are: vRealize Network Insight (holistic network and security visibility), NSX Intelligence (distributed analytics for providing granular network security policy recommendations), VMware Carbon Black Cloud (cloud-based analytics for providing endpoint security and protection) and VMware Secure State (cloud-native compliance engine).

 

Even more significant is the fact that this security is intrinsic. This means security is built-in and not bolted-on. These policies are embedded in the infrastructure (they are agentless), and they live, evolve and are decommissioned following the same lifecycle of the application. If an application is created, so is its security posture. If the application changes, or moves, so does its security posture. And finally, when an app is destroyed, the policy is automatically removed. From an operations perspective, this model has proven to be more efficient, less error-prone and obviously, more consistent than the alternatives.

 

What about the role of the Network Engineer itself? How has that changed?

 

In terms of how the role of a Network Engineer has evolved, I am going to go ahead and say that I was spot-on. This might sound like a boast, but bear with me.

 

Network Engineers, in particular Network Virtualization Engineers, have adopted operational models aligned with the core principles of DevOps and have acquired skills that leverage modern instrumentation, which allows them to create, manage and troubleshoot connectivity, security and elasticity policies in a consistent and repeatable manner. Current Network Engineers understand the application geometry and treat the network infrastructure that supports it as code. Furthermore, the rapid adoption of microservices has catapulted the importance of the Network Engineer role. The distributed nature of a microservices architecture means that a network is required to efficiently connect all these disparate services. Who better than an expert in networking to help design and operate the fabric that ties them all together?

 

VMware has open source and commercial solutions for all of the above: providers for the most popular DevOps frameworks (Terraform, Ansible, PowerShell, vRealize Automation, OpenStack Neutron, Public Cloud IaaS, Kubernetes and several others), and Service Mesh solutions, like Tanzu Service Mesh for automatic service discovery, service-to-service encryption, multi-cloud federation, observability and Service Level Objective (SLO) tracking, all leveraging the revolutionary concept of Global Namespaces.

 

So, was I right? If so, what’s next?

 

I think that my predictions were pretty accurate. The reason is very simple: my predictions were not mine alone. I rely on a fantastic team of thought leaders, amazing engineers and sales staffs that have all helped forge our own path. When you have access to this talent and this passion for an industry, you hard work pays off. This is why I believe that we have influenced our own destiny. This outcome is, in a way, a self-fulfilling prophecy.

 

In terms of what’s next, I will leave you with a teaser. Come join me and Dr. Bruce Davie, at VMworld 2020. For several years now, I have helped build and present the demos that accompany his daring predictions and thoughts with regards to our industry. The name of the breakout is, very apropos, “The Future of Networking with VMware NSX” and you can find it on the VMworld 2020 Content Catalog.

 

So maybe in another 7 years I will be checking in with you again to see if what we anticipated today becomes a reality then. In the meantime, keep investing in your network expertise, and keep innovating.

 

Marcos Hernandez

Chief Technologist, Network and Security

VMware

This entry was posted in Products, VMworld and tagged , , , on by .
hernandezm

About hernandezm

Marcos Hernandez is VMware’s Network and Security Chief Technologist. He joined VMware (Nicira) and the Network and Security Business Unit (NSBU) in early 2013. He is responsible for supporting large Global Enterprise accounts and providing technical guidance around VMware's suite of networking products, including NSX. As a Chief Technologist, Marcos also participates in M&A due diligence panels, support of New Product Introductions (NPI) and partnering opportunities to help augment VMware’s relevance in the network and security space. Marcos has a background in datacenter networking design and expert knowledge in routing and switching technologies. Marcos holds CCIE certification #8283 and a Master’s Degree in Telecommunications from Universidad Politécnica de Madrid.

Leave a Reply

Your email address will not be published. Required fields are marked *