Rejoin the conversation by tuning into the business’ true needs. Become part of the narrative of your organization.
This blog was originally posted on the Network World blog: No WANs Land
Making smarter networking decisions
Recently, I learned the average Fortune 500 company has over 1,100 VPCs at AWS. Each one was acquired independently for a single use. Public clouds are often easier, quicker and cheaper than standing up servers in a corporate data center. However, this practice is creating a larger and larger number of private network segments that need to be internetworked. As a networking professional, we need to internetwork many of these VPCs with all of our sites in a secure fashion. Keeping inter-VPC traffic at AWS clearly makes sense, but should one build a classic anywhere-to-anywhere network with ACLs everywhere? Or should be just bridge the networks with tunnels/routes that are necessary? Do we need firewall technology on these routes?
Cisco claims nearly all workloads will be in a public or private cloud within three years. Business logic dictates that each workload has a defined set of allowable users and a defined set of related or supporting workloads. Ideally, one would describe network requirements in the form of a map of connectivity for each workload to its related workloads and users. Understanding users and related workloads is not easy, and traditional network segmentation doesn’t work well. This is because workloads are chained and shared, and users are often authorized to use multiple services.
Focus on requirements
Another frustration is that the networking function provides connectivity, but the security function subsequently limits connectivity by controlling access. Network routes are dynamic and self-healing, whereas access controls are provisioned, physical, and static. The narrative used by service owners is “elastic, dynamic, multi-location, simple” while the networking narrative includes “ISPEC tunnels, IKE servers, BGP, NAT, Dynamic DNS, Load Balancers, Firewalls, ACLs, MPLS, MP-BGP, NAC” plus lots of provisioning. The provisioning is so complicated we now call it orchestration.
The new narrative between service owners and networking professionals needs to focus on services and their requirements. Every service of value requires one or more packets to traverse from client to server through a network. These packets associated with a service constitute a session. Rather than routing packets, networking professionals need to start thinking about sessions of packets. Sessions have one or more service addresses, a direction (client to server), they have bandwidth behaviors (voice, video, HTTP), they have lists of acceptable clients (IP address, netmask, VLAN, equipment type, etc.). Likewise, networks need to provide analytics for services and sessions as a primary feedback loop for automated network adjustments (elasticity).
The networking layer needs to understand services at key network borders. Elastic, dynamic, multi-location, simple networks cannot be orchestrated. For networking engineers to rejoin the narrative, networks must speak the language of services – sessions. When a network engineer provisions services instead of CIDR blocks, then we will become part of the conversation. When network elasticity is responsive to service needs, instead of brute force over provisioning, we will begin to add competitive advantage to our organizations.
We are all speaking the language of the dominant supplier in our space, we are studying for certification by a supplier, and we are no longer valued by our organizations. Rejoin the conversation by tuning into the business’s true needs. Become part of the narrative of your organization.
Patrick MeLampy is the Co-Founder and Chief Operating Officer at 128 Technology.
The original post can be found here.