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.


  1. Hi Ivan,
    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.
    1. Migrating from NoSQL to SQL and back means living with the least common denominator: fixed-column tables without server-side joins and transactions. Like using ACLs as the least common packet filtering denominator.
  2. I'm not very familiar with databases so this question might come across as dumb. But how often does the underlying syntax of databases change compared to that of Network vendors? Or is that a non-problem?
    1. New release, new feature, new syntax ;)
  3. I'm probably not going to be coherent but the difference that I see with a database versus a router is that when you make a change to a database (add table, delete table, insert row, etc ...) the change is confined to to the database system (except if there were reports or API's depending on those tables). When you make a change on the router it affects other peers and in fact the "network" or the algorithms that manage this distributed network are adapting or adjusting themselves in near real-time to the changes you are making.

    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.
    1. Database changes are rarely confined to the database in any non-trivial IT infrastructure. They typically impact and require changes to ETL processes, data warehouses, integrations, web service APUs, etc. And these changes affect *persistent* valuable business data.

      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.
    2. I stand corrected, in my previous post I fell for the Grass is always greener over the fence fallacy.

      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.
  4. Networking IS quite special (not necessarily in the good way), mostly because:
    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 ?
    1. > 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.

  5. 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

  6. 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.

Add comment