Is network engineering dead? The answer is: It’s complicated. Like everything else in technology, network engineering is changing rapidly and the role of human engineers is evolving.
In the age of cloud computing, managed services, and especially artificial intelligence, many devops engineers and SREs thought network engineering would quickly be a relic of the past. Like the demise of other complex tasks, however, this prediction has not yet materialized. Or has it? In this post, I will clarify whether we still really need to spend time and effort designing a network in our cloud environments, and if we do, what is our role?
A brief history of network design & engineering
Once upon a time, all networking was done by ordering servers, switches, and routers, then racking them in a data center. Technically speaking, it still is done this way, but most of us don’t see any of that equipment anymore. We work with virtual machines and managed services on hardware installed and maintained by someone else. That someone else is, statistically speaking, probably Amazon (AWS), Google (GCP) or Microsoft (Azure).
The network had to be carefully architected both physically and virtually. CIDR blocks had to be allocated, routers had BGP or other routing protocols configured, switches segmented the network into VLANs and finally, each machine had one or more IP addresses assigned. If your organization runs its own equipment now, you are familiar with these tasks. When most organizations had to be responsible for their own hardware, network engineering was a critical, valuable and complex skill. This is still true today, but much of the work has been abstracted for the vast majority of us that now run our application workloads in a cloud.
As virtual networks became increasingly popular, configuration management emerged. Tools like Puppet, Ansible, Terraform and CloudFormation meant that we could declare how we wanted our systems to be configured and how they should interact by writing and applying scripts and templates. We still designed the network, but now we did it in code where it could live in version control, we could reuse or share modules, and everything was deployed like software.
Abstracting the network
For those of us working strictly with software-designed networks now, however, do we really need network engineering skills?
Let’s look at some of the primary tasks we still perform in devops engineering when creating an isolated, secure, optimal environment for the applications our organizations need to run:
- Choose CIDR blocks for each of our environments.
- Segment within the VPC for isolation by availability zone, workload, task type, and other needs.
- Deploy firewalls, security groups, network access control lists and related security measures to protect our data.
- Implement peered VPCs or private clouds for inter-network communication.
These are tasks that need some human decision-making capabilities. While we might use tools to help us generate these network artifacts, it would be very unwise to trust these out of the box. Any SRE with experience knows they have to validate, test and modify generated configuration that will run in a production environment.
Why do people think network engineering is dying?
Creating functional computer networks is easier than it has ever been. Additionally, large amounts of this work can be automated and with recent advances in AI, more and more of it is being automated every day. Even without AI, we frequently do network design and implementation with open source Terraform or OpenTofu templates and increasingly less custom configuration. With all of these advances and all the existing code out there that allows us to abstract our systems jobs down to running a few commands, of course people will come to the conclusion that network engineering is dying.
And they’re right. Sort of.
With automation and AI, humans are increasingly becoming unnecessary to determine how and where to do all this. People are, however, still quite necessary to figure out what to build and why.
The future of network engineering
The business logic behind the networks, rules and connections to create and why they should communicate with each other is still very much in our hands. These are just some of the questions network architects must answer before anything is actually built:
- Should we create multiple accounts, multiple private networks (VPCs) or both?
- Which network segments should safely communicate with each other through peering and endpoints?
- How do we isolate critical data while still allowing access to production resources that need it?
- What kind of capacity do we currently need and what do we expect it to change in the future? Should we plan for growth and how much? Or should we be extremely cost conscious because of expected volatility with our product?
Answers to these questions will be determined by many considerations. Larger and more complex organizations may have many more decisions like these to make. The following are just some that have to be taken into account when deciding on network architecture and access:
- How many customers do we have now, and what are their usage needs? How do we expect to grow in the future based on the efforts of the marketing, sales, and product teams? How will new investment dollars or budgets affect what we are able to implement?
- How does our current software development process work? Teams can work together in virtually unlimited ways and may need access that either enforces isolation or encourages collaboration.
- How does our deployment (CI/CD) pipeline work? Feature releases can be done in many ways through multiple environments. Microservice architectures have their own unique compatibility and deployment needs.
- What is the size of our development team and are they cross-functional? Several methodologies can be used to test new features and demo to stakeholders.
- Do partners, other departments, third-party vendors or outsourced teams need access to environments? If so, access decisions can only be made by those with authority.
- Is our data subject to privacy regulations like GDPR or HIPAA? Industry compliance requirements will dictate important network engineering choices.
It should be clear that many, if not all, of the above questions and considerations are business issues that can only be decided by real people with knowledge and discretion that an AI or automated process can’t possibly have.
Modern networking involves product and business teams
By now it should be much clearer that network engineering is not solely a technical exercise. A complete understanding of current and future technology needs is necessary. Beyond that, strong integration with business plans, goals, and risks is also needed. In order to build systems that work well now, but are also adaptable to uncertainty in financial and product domains, human guidance and discretion will be essential to an optimally engineered network.
The person or team leading the architecture should have a higher level view of the organization. They also should have experience incorporating business goals and constraints into their designs. Configuring the network is perhaps easier than it has ever been, but the stakes are also higher. Ensure you empower your lead with the context they need to succeed, or bring someone in with experience to make sure your network is well-positioned for security and future growth.
