We are currently doing a day 2 proof of concept with Juniper Apstra. It’s all about abstractions. Juniper Apstra is a network management solution that helps with the configuration and management of VXLAN/eVPN based networks. If you aren’t familiar with VXLAN/eVPN, it’s the solution for scaling networks to the size of public cloud operations. The project highlights the challenges we face with abstraction in modern enterprise IT.
There’s no better representation of the software-defined data center than the public cloud. With a few clicks of a button, I can implement a highly redundant application infrastructure that includes multi-region replication, highly redundant storage, and 10’s of Gbps geographically load-balanced networking. It’s the beauty of abstraction. It’s the envy of all enterprise IT infrastructure services design.
However, the public cloud isn’t for all applications. Customers are in pursuit of building the base abstractions that the public cloud offers but without the scale. To provide these types of capabilities, enterprises customers are looking to the Juniper Apstras of the world to manage the abstractions.
What makes abstractions hard? I will ignore the multi-tenancy part of the challenge and focus on the intersection of abstraction to the physical underlay. VXLAN/eVPN is an easy one to pick on. The network is already abstracted via virtual switches. Troubleshooting the virtual switch inside a hypervisor and the physical network proves challenging. What happens when you virtualize the physical switches using VXLAN/eVPN?
Well, first the benefits. You can stretch your IP addressing across multiple physical sites with a click of a few buttons. You offer cloud-like capabilities. However, you break the relationship between the IP address and the physical location of the underlay. For example, 192.1.3.x has always been the physical switches in the CTO Advisor Chicago data center, and the 192.1.4.x IP is the New York City data center.
Where are the physical underlay components if you are experiencing application performance issues with containers pods with 192.1.3.x IP addresses? These are all problems the public cloud providers have to worry about. As consumers, we trust the underlay is performing as required. In the private DC, it’s our responsibility.
What are your abstraction stories/nightmares? Where have you seen abstraction on top of abstraction break operations?