Wow, what a boring title.
Why would anyone read beyond this artistically crafted clickbait?
I’m really selling this well. But, bare with me and my meanderings will become clear.
Why have Enterprises standardized on Network Vendors in their On-Premises networks?
Let me be clearer; if we have 3 data centres, why don’t we install Cisco in one, Arista in the other and Juniper in the third? We could generate a price war between the 3 vendors and get the best possible deal, no?
No.
In more than 15 years of selling networking solutions to enterprises, I have never been able to place one vendor without displacing another. Or more specifically, if the data center network is running Juniper today, it’s impossible to swap out the core switches for Cisco switches without replacing the edge switches also.
Ok, impossible is a big word. With smart engineers, anything is possible. But, there are legitimate reasons why enterprises standardize:
1. Network Interoperability
We expect network devices from the same vendor to behave well together. This is not always the case, but you’re really increasing your availability by having Cisco ToR switches connect into a Cisco EoR switch. Or insert your favourite vendor as you see fit.
I had a specific case in my career where something as basic and standardized as LACP caused intermittent link flapping between Cisco and ALU switches.
We spent weeks going back and forward between the vendors, each blaming the other. The solution? Replace the ALU switches. The customer was very happy, you can imagine.
2. Internal Skillsets
Over time you invest in people, processes, and tools all of which are heavily aligned to the vendor of choice. If the business factors are strong enough, you may have a budget to throw these skills out the window and retrain everyone for a new vendor, but it’s not ideal and does not create satisfaction in your team.
In my experience, engineers have strong vendor affinity. When they trust a vendor and have deep enough knowledge, a vendor change may be enough to cause them to look for work elsewhere.
3. Roadmap Planning
Following individual product roadmaps from one vendor is already challenging. But, doubling or tripling this work is not a useful investment of your time or energy.
Imagine managing 2-3 vendors for the same architectural block. Maybe you get invited to 2-3 more dinners than before, but let’s face it, building that kind of trust takes time and energy and you don’t want to spend all your time doing only that.
4. Bug Tracking
Another fun task made a million times more complex by following multiple vendor release notes and upgrade paths. Change control windows are few and far between, and who is to say that an upgrade on one vendor will not impact the other vendor.
5. Troubleshooting and Visibility tools
Diagnostic commands, vendor-specific management tools, troubleshooting procedures, all have to be documented and learned each time a vendor change is made. This all represents time, money and risk.
Integrating Cloud-Native constructs into your visibility tools is either suboptimal or impossible.
Why is this important when we move to the Cloud?
To be clear, I am not saying that we should standardize on 1 CSP.
Ultimately, the application owner decides where the application will run best, or which CSP has the AI/ML service they need. We infrastructure folks simply need to provide secure, enterprise-grade network connectivity, operational excellence and end-to-end visibility. Easy, no?
Easier said than done. Moving to that new CSP now entails understanding the networking and security constructs, designing and integrating with them, integrating these constructs into your Standard Operating Procedures, understanding how you can operate at scale, and working out how to gain visibility into someone else’s black box.
Conclusion
So, you already knew this? We all do.
But, why is it when we move to the Cloud and each CSP offers us a different network construct, we accept this as the status quo?
And let’s face it, networking is not the core focus of these CSPs, so you don’t get the advanced knobs and whistles you get on-prem.
CSP networking is “good enough”. But, did we go from searching for architectural excellence on-premises to accepting “good enough” in the Cloud?
I don’t think so. I guess we just didn’t question it.
But there is a solution.
Aviatrix Multi-Cloud Network Architecture
In order to address the points above, and more, Aviatrix has built the Multi-Cloud Network Architecture.
We provide a repeatable secure cloud networking infrastructure across all CSPs with centralized controller and visibility.
The advantages:
- Common behavior and architecture across clouds
- Single technical skill set to maintain
- One roadmap to follow for secure cloud networking
- One place to track bugs and releases
- Centralized visibility and troubleshooting
- Advanced and consistent security features available across all Clouds
- Complete alignment to Infrastructure as Code
- Future-proof operational simplicity through our abstraction of the underlying Cloud-Native complexity, offering new feature adoption without the operational headache
Reach out to me if you want more information.
