Network Infrastructure as Database
A while ago I wrote about the idea of treating network infrastructure (and all other infrastructure) as code, and using the same processes application developers are using to write, test and deploy code to design and implement networks.
That approach clearly works well if you can virtualize (and clone ad infinitum) everything. We can virtualize appliances or even routers, but installed equipment and high-speed physical infrastructure remain somewhat resistant to that idea. We need a different paradigm, and the best analogy I could come up with is a database.
Imagine an organization that needs a large transactional database to run its business, and requires the frontline operators to modify data in that database with SQL statements (INSERT, UPDATE, DELETE). I haven’t heard of anyone being even remotely that stupid – and yet that’s how most of us run our networks. Time to take another lesson from application development world.
It’s obvious that one should interact with a production database only through well-defined and thoroughly tested transactions (whether you call them transactions, application programs or web scripts is irrelevant). Direct CLI (SQL) access to the database should be either prohibited or limited to the absolute minimum.
Likewise, we should make changes to our network devices with well-defined transactions (example: CREATE VLAN or REMOVE VLAN). These transactions (call them scripts, playbooks or recipes if you wish) should be treated like any application code, and tested in a lab environment before being allowed to touch the production network.
And now for the usual set of objections:
But I don’t trust scripts. Fantastic. Now tell me: is it better to rely on something that is tested and repeatable, or doing configuration changes on the fly hoping for the best?
How do I know it will work? Welcome to the world of software development. Write code, include unit and integration tests, test everything, deploy in a pilot environment, and finally in production. Lather, rinse, repeat.
But it might mess up my configurations. And you think nobody ever messed up their database? We have backups for a good reason – and most networking gear has some configuration versioning and rollback mechanisms.
But it might crash my switch. It might. Database systems have their own bugs, and I’m positive you were able to crash some databases with invalid data or weird requests a few decades ago… but guess what: unless we start screaming at the vendors, and vote with our wallets, nothing will change.
What about maintenance windows? We have to use maintenance windows in current networks because we can’t trust the manual configuration process. When was the last time you could do your e-banking transaction only at 2AM on a Sunday morning? Once everyone starts trusting the network configuration transactions, you’ll be able to use them at any time.
Have you encountered any other objections? Write a comment!
Finally, you might decide that your network isn’t big enough to warrant a network automation solution (or that you don’t have the manpower to work on it). The next best thing you might do is decoupling: move the dynamic parts of your network infrastructure into the virtual world where you can treat is as code, and keep the physical part of your network infrastructure as static as possible.
We talked about network infrastructure-as-code in the Network Automation Concepts webinar.
The goal of "SDN" isn't to make life easier or "empower the network engineer" to do other things than to create vlans. While that is part of it, the goal is to make the skill set obsolete so you don't have to spend money on those people anymore. The only question is if it'll work to the extent that some people think.
To "hate" someone for having these concerns only tells me that you completely lack empathy.
Funnily enough my very first blog post was about this very subject: http://packetpushers.net/the-man-in-the-white-suit/
A new VM could drive a host over the edge resource wise, a new LUN could be placed in the wrong place overloading a SAN and causing performance issues for a critical application.
And agrede with Amanda,,, I feel that exciting challenges and opportunities are coming, and if we think that all we can contribute as NW engineers is configure ports and VLANs, then we have a real problem... I would expect that we can provide much more value than simply memorise a set of commands and then blindly repeat them.. We understand how complex computer systems communicate and the challenges they present... And is up to us to keep learning and evolving,,, that is the fun part, isn't it?
I don't know... but I think that to reduce the SDN wave to a debate around NW engineers versus programmer profiles (or OMG! I'm going to be replaced by a script!) is a bit simplistic and underestimate ourselves.
The above would make a commit/rollback mechanism more important in the network (just as in a database).
You could also probably still leverage virtual environments for some of your testing i.e. test changes in a part virtual/part physical environment.
Also we need standardization of some of these programming interfaces so that we can write code that can work relatively easily across multiple vendors (maybe OVSDB?...need to look into this more).