Network experts (CCIEs, JNCIEs, people with IETF tattoos) are incredible interpreters. Whether they know it or not, they speak many different languages and can instantly translate very complex concepts in their heads. Now, I don’t mean that they can all speak French, Mandarin, Urdu or Esperanto. I took 5 years of Latin and 5 years of Spanish and all I can remember is how to say ice and meatballs in Spanish. Not very useful. But in my former life as a VLAN wrangler, I could definitely talk some 802.1q.
Here’s an example. A CCIE attends a meeting with an application developer who says “my new application contains very sensitive information and needs to be isolated from the rest of the network, and the app will communicate with a third party partner”. The CCIE hears this and immediately knows the following:
- A new subnet needs to be built with 2 dedicated switches for the server connectivity, because our business requires L2 redundancy as per corporate policy.
- The current server platform used by this developer requires 25Gb NICs, so the top of rack switches will likely be a 32 or 48 port variety.
- The application requires SAML/SSO tokens and SSL certificates distributed by our central Key Management Service (KMS).
- The developers sit in a different building from where the app servers reside, and they will need to SSH to the servers to manage the application. The 3rd party is connected to our network via IP, and the firewall only allows IPSEC, so the firewall or ACL that segments this new network from the rest of the environment will also need IPSEC to be permitted.
- Obviously the app servers will need IP addresses and DNS so the ACL should permit these protocols as well.
- The app developer never mentioned needing internet access, but it goes without saying that they need to download some packages and clone some repos.
- And this thought process goes on and on inside the mind of the network architect.
You may be saying “hey those aren’t languages, they’re requirements. Well sure, but everyone who has ever worked in a large siloed organization knows that each department (app, server, storage, network, data center, security, etc) has their own lingo, jargon and inside jokes. The network is the connective piece between them all, so if you’re a network person you need to understand how these people talk.
What’s the problem? This skill set makes the CCIEs very valuable to the business, and keeps a lot of network people employed. This is literally why network expertise is such a hot commodity. But from a business perspective it’s TERRIBLY INEFFICIENT. Applications now define all of their compute and storage requirements, so why is the network (and security) still mostly ad hoc? In a nutshell, network vendors never really agreed on a common logical representation of system design. In fact, the only things they agree on are good faith efforts to adhere to IETF standards (and they don’t always do a good job at that). So virtually every piece of hardware is proprietary, software is specific to each hardware platform, hell even the features are implemented in radically different ways with little commonality. Don’t believe me? Bro do you even EVPN?
A lot of work has been done recently to try and address these problems at a high level. We now have open source telemetry standards (some thoughts on this here), open source data streaming, network and security policy (ex. Open Policy Agent), patterns for describing application requirements (Kubernetes Helm charts, “open” k8s CRDs) and more. These aren’t exactly household names, nor are they standards, but they’re a lot better than what we had previously in the engineer’s neural mush.
All of these things lead in one direction, an enterprise Single Source of Truth (SSoT) that contains all of the network design decisions, corporate policy, and tribal knowledge that is necessary to automatically perform the sacred rite of “translation” that we talked about before. This is a HUGE lift from where we are now. Most SSoTs combine IPAM, device inventory, basic trust/key management, config repositories, and perhaps some simple verification of network state. But what they lack is the actual reasoning behind all of those bits of data, the WHY. For example:
- How do we plan for oversubscription for each business unit?
- What are the minimum requirements for each new environment we build?
- Where do we use particular technologies?
- What is the root of all trust and how is it extended to new systems?
Most CCIEs would agree that there aren’t really many tools that capture that level of information in code. It’s typically contained in white papers, design documentation, and the aforementioned engineer’s mind. Basically, these are business policies that translate to some sort of design pattern.
We’ve defined a rather interesting problem that likely needs a solution. So what has been done to describe and store these types of design decisions? Next time we’ll dive into some solutions.
Until. next time…
“Route Once, Switch Many” – Sun Tzu
0 Comments