You know what has been bothering the fuck out of me lately? We use a lot of terms in the tech industry so loosely that they have virtually no meaning. It’s no wonder people outside of tech some times think we are full of shit. We are full of shit. I know this to be true, because I’ve attended those bullshit meetings where people parrot these terms like… well… parrots. The meetings are bullshit precisely because nobody is really on the same page about what anything means.
Workflow, Automation, Integration. What do these words even mean? From the operator’s perspective, these are all closely related and in a lot of cases they are identical. Operators want to automate their workflows and there is an immutable, absolute requirement for integration to accomplish this. Read that sentence over and over. Some might argue that much of the excitement about SDN on the customer side was predicated on the idea that vendors would finally realize this. But why hasn’t this really happened yet?
1. The general openness of networking hasn’t improved much since SDNs inception. Sure, Broadcom has “open sourced” their SDK but quotes are required around that term. Intel has actually open sourced DPDK as far as I can tell. Those are good starts. Other projects (which shall not be named) are open source, but they are intentionally crippled versions of a commercial product. All in all, this is stifling innovation because it leaves the hard work up to people who are not particularly motivated to do something different with respect to networking.
2. Vendors don’t understand what customers actually do. I’ll take shit for this statement, but I’m absolutely convinced of it at this point. Customers don’t actually understand what they do, either. They’ve learned how to do it, but that’s not the same thing. Reciting RFCs, design principles, and troubleshooting patterns is missing the point. What we actually do, behaviorally (with respect to our knowledge domain and the systems within), is another thing altogether. It should be the subject of a study in some social sciences field, I imagine. Engineering, in any field really, is all about how humans navigate complex problem spaces cognitively. This is very hard to understand in fields with enormous technical width and depth. It’s easy to jump from the human side of it to weird rationalizations based on specific elements and constructs of an engineer’s chosen specialty.
*Side note: I will eat the next person who tells me they understand what the customer wants because the sales team told them so. I will also eat the next person who tells me they did a survey, so they “have all the answers already.”
3. Nobody wants to be responsible for taking the lead on solving this problem. Imagine a circle. Along the entire circumference there are dots. Those dots represent APIs to the various systems you deploy or use in your environment. Who is responsible integrating between any two dots? Company “A,” company “B,” or the user? What if the integration is three or four systems? What if something changes for one of those companies? On the vendor side, everyone wants everyone else to integrate with them. “They’ll download our SDKs. We’ll create a developer community. PROBLEM SOLVED.” Because there isn’t a graveyard littered with initiatives predicated on such nonsense. Workflows and automation are highly fluid things. This is a hard problem to solve, and it really kind of falls outside of the knowledge domain of traditional network companies. So there is resistance to putting the time and resources into solving it.