Networking Is Not as Special as We Think It Is
I was listening to the Packet Pushers show #203 – an interesting high-level discussion of policies (if you happen to be interested in those things) – and unavoidably someone had to mention how the networking is all broken because different devices implement the same functionality in different ways and use different CLI/API syntax.
Guess what: the rest of IT is no different (nor are some other technology areas).
The only difference between network-focused yammering and the rest of the IT is that everyone else learned to live with the reality instead of claiming that their domain is so broken that they’d have to reinvent all wheels ever invented (although on a second though I’m positive you can find apocalyptic claims in every IT domain).
The examples I usually use are the databases. Ignoring for the moment the existence of a whole universe of noSQL databases, even the relational databases use different variants of supposedly-standardized SQL language, making it impossible to migrate your application from database A to database B without some heavy forethought or major rewrite effort.
The database drivers (equivalent to APIs everyone loves to talk about) aren’t exactly standardized either (apart from ODBC, which allows you to send text commands to the database – I fail to see how that differs from they way we configure network devices), resulting in (for example) MySQL functions for PHP, Oracle functions for PHP, PostgreSQL functions for PHP – you get the idea.
By this point you should start wondering how anything at all gets done in IT. The magic word is abstractions: PHP Data Objects or PERL Database Interface. These modules are usually a unifying layer on top of proprietary APIs, but don’t deal with the differences in product-specific SQL syntax. Smart applications (example: MediaWiki) implement their own abstraction layer on top of that to cater to those differences.
There must be a fundamental difference between database world and networking world – after all, they both use product-specific text-based human-readable command syntax and proprietary APIs. It might be that in one of those worlds people decided to solve the problem, and in the other one they listen to startups selling them snake oil instead of solving the problem.
Finally, no one in his right mind would propose to scrap all database products because they’re so badly broken, and replace them with a central database controller using distributed file system read/write calls (a rough equivalent of OpenFlow forwarding rules). Networking must really be a very special planet.
most of the nowadays web frameworks have their own ORMs which allow them to communicate with a few of the most popular databases. RoR has ActiveRecord, Sails has Waterline. These kind of abstractions allow you to migrate from NoSQL to SQL and back without modifying your code. However, as you'd expect, they provide their own API to the application.
I think this dynamic adaption is the difference between networking and the rest of IT. In the rest of IT when things fail they fail hard, its easy to spot. When networking fails, it could fail hard or it could be hidden by these dynamic algorithms.
Not sure if this non-determinism is good or bad, but from the perspective of other IT groups it looks like we are not in full control of our networks.
Other than that I feel a lot more confident and less stressed having to enter commands into a DB CLI than a router CLI even in a lab environment.
In comparison, network changes impact only ephemeral data in flight, and rollback is easy.
Networking just isn't that complicated compared with the hugely complex and varied application and data sectors of the industry. Which is why everyone gets pissed that netwoks are so slow to adapt, and so very fragile. I blame lack of competition and the cult of Cisco.
Cult of Cisco I do agree but that was 1998-2013, future looks more interesting and diverse for networking now, hopefully.
Maybe the problem is in the process, when a database change is made there is a project, consensus and everyone at the table, DBAs, system admins, systems analysts, developers, ETL specialists etc ...
But in networking it seems people are left to their own devices, no one wants to get involved because networking seems like some black magic because although end to end connectivity seems like something so obviously simple they don't understand why its so complicated in practice. In my experience most technical people above the network layer and PMs gloss over networking and give it short consideration.
A. Quite a few people understand it (correctly; for some of them servers are part of the network).
B. Quite a few people see its importance/value.
For databases, the value is quite clear : it holds data that makes the business work. Network (pretty much like electricity) is considered as "just existing" (and annoying). Did you never met people saying "it's a network problem" (when it's not) or "isn't there some network issue ?", just because they are out of any other idea ? Or spending days to prove other people that it's NOT a network issue ?
This is the same thing one layer above, with hosting providers "vs" developers. Always the fault of the provider unless you prove otherwise.
Abstraction is indeed a magic word. Unfortunately, it's usually associated with the adjective "leaky". In the case of SQL datavases abstraction: stored procedures, triggers, views, some types of indexes, transactions and data types aren't fully abstracted.
In many cases, SQL abstraction leads to increased complexity, performance overhead, security risks, debugging issues, lack of control, learning curve, and maintenance issues.
However, I don't know of a better solution
You can have ONOS or ODL to hide the details of OpenFlow or anything else. ONOS is now getting some attraction in telco space. ONOS can hide all the pipeline details from the application. You have to write your application only once towards the ONOS Northbound API. Then you could have various integrations to the network: CLI, NETCONG, gNMI, BGP, OpenFlow, PBR, whatever plugin you could get. Since ONOS is open source, you can get some level of long-term control. However, some people want to push the complexity somewhere else. Then comes P4 and microONOS. Now ONOS itself is simpler, but the complexity moved into the P4 implementation. You can chose which approach to follow based on your specific tradeoffs. Or you can stick with classical routing... We prefer a hybrid approach. Using classical routing for the majority of generic traffic and using ONOS based SDN for special safety critical traffic requiring dynamic policy overrides or steering by situtation awareness that cannot be handled by standard routing.