For many SDN and DevOps enthusiasts, the natural outcome of this wave of technological change is a highly-automated network that is well-orchestrated with surrounding systems and applications. One of the prevailing thoughts is that this level of automation is a well-formed abstraction layer. With the abstractions in place, the army of network engineers will be unencumbered by device configuration, and automation will ensue.

Or will it?

First off, let me say that abstraction is absolutely necessary. There is no doubt that networking will only advance if we can both remove unnecessary elements and simplify those that remain. We have to accomplish this in a way that is vendor (and ideally technology) agnostic. Abstraction is clearly the path forward.

But will abstraction necessarily lead to automation?

For the vast majority of network engineers who are designing and actively managing networks today, automation means writing shell or Perl scripts. The scripts themselves qualify as automation insofar as they remove keystrokes, but they basically execute the same serial logic that has dominated networking devices for decades.

When you want to make a switch or a router do something, you specify some configuration. Then you specify some other configuration. And again and again until you get through the litany of parameters that collectively make the device work. This workflow is so ingrained in our collective psyche that we inherently serialize the tasks required to make the network work.

There have actually been companies that have done a decent job of breaking the habit of serialized configuration. Juniper’s flagship operating system Junos moved to a more code-like representation of configuration, making no assumptions about the ordering of specific tasks. But our training runs deep, and even the Juniper guys will tell you that the biggest barrier to entry is familiarity with the UI.

We are addicted to our serialized behavior.

One of the side effects of highly-serialized configuration is that we tend to think extremely linearly and transactionally. There are a lot of network engineers for whom any kind of object-oriented approach is almost too foreign to really embrace. So when they try to automate tasks, they fall back into a sequencing of steps, repeated as many times as necessary. Automation without reuse is painfully difficult to propagate beyond only the most repetitive tasks.

And so we end up in a scenario where automation is basically synonymous with scripting, and where the value is largely applied only to the most frequently-executed tasks.

Where could automation take us?

If we think through where automation could take us, we ideally aim a little higher. Automation could mean the automated exchange of data between collaborative systems in support of some task. For instance, you might want your servers to communicate to your network so that when a new application is spun up (or a VM moves), you get corresponding policy changes, firewall or load balancer changes, and potentially network capacity allocation.

For most network engineers, the idea that infrastructure communicates and dynamically provides a service is science fiction. Our serialized mode of operation simply doesn’t support this kind of multilateral communication. Even if the abstractions remove some of the configuration complexity, the mental block is around sequencing.

If the current networking model has taught us anything, it should be that our network engineers are quite capable of managing tons of inputs and outputs. Now, whether that ought to be a requirement for the job is another question entirely. But as a group, network engineers are certainly capable of handling a lot of variables. That abstraction reduces these variables to the most meaningful is very interesting, but it wouldn’t seem that input management is the biggest bottleneck to automation.

The barrier to automation

Rather, the biggest barrier to automation is that workflow is so structured. First, it was the devices themselves that forced the structure. Then it was the processes (ITIL anyone?) that forced it. The end result is that we have built a discipline so dependent on structure that it actually impedes our own progress.

If we want to get to automation, we need to find a way to work around—or perhaps work within—this structure.

What we are really talking about is changing how we think about provisioning and managing a network. Why do you think there is so much angst when people talk about network engineers needing to learn to code? It’s because moving from a serialized set of steps to an object-oriented way of thinking about the problem is extremely difficult.

People aren’t pushing back because learning a new language is hard. Or at least they shouldn’t be. Look at any networking device configuration and tell me that you aren’t already a master coder. The biggest difference is that you you are using an interpreted language called Cisco CLI (or Junos CLI or whatever CLI).

What next?

What we need to do is bite off small (dare I say tiny) workflow elements, automate those, and then string them together into larger workflows. This implies a couple of things. First, we need to think less about discrete capabilities and more about how they exist within some broader workflow context. Second, we need to understand how these building blocks fit together. It’s the connecting of individual workflows that forms the basis for automation, and those connections highlight the pieces of information that flow across workflow boundaries.

More bluntly, the data that stitches together workflows ends up being the stuff that needs to be in an abstraction. It very well could be that getting the automation parts right will help us get to better abstractions.

Obviously we have to work the process from both ends – abstraction down, and workflow up. I don’t think it’s as simple as one or the other, which is why abstraction and automation might be a networking incarnation of the age-old chicken-and-egg question.

[Today’s fun fact: A parrot’s vocabulary is generally no more than twenty words. Who knew parrot’s and politicians had so much in common?]
Showing 9 comments
  • Peter Carstairs
    Reply

    Abstraction won’t necessarily lead to automation because it’s human nature to take the path of least resistance. That said, it could ultimately lead us towards a world where networks are installed clicking next prompts. What I’d prefer to see is a market where I can install any OS on my customised hardware or select an off the shelf option. This is the choice I want without being held back by legacy networks.

    • mike.bushong
      Reply

      I understand the first point. The second point is a bit of a leap for me, not because I think it’s the wrong thing for networking but rather I view hardware/software selection as a separate topic from things like policy abstraction. Did you intentionally connect them? Curious to learn more about how you are thinking.

      • Peter Carstairs
        Reply

        Yep, intentionally connected the two because I don’t see abstraction as being related to automation. To me they’re in separate camps with one being a goal while the other is a process of thinking to achieve the goal. Without that goal no amount of process or abstract thinking is going to help achieve something which hasn’t been envisioned. Maybe I’ve simplified things too much?

        goal + determination + process + amazing beard = amazing outcome

        • mike.bushong
          Reply

          That makes sense. I think the challenge for me was I had “policy abstraction” on the brain, so hardware was a separate thing in my thought process. I had unnecessarily narrowed my field of vision. Your points are absolutely valid.

          I do find it interesting how hardware/software decoupling intersects things like controller-based architectures and policy abstraction. I suspect people will have to do all of them, as I don’t believe the only problem with the network is the price of the hardware. If we build fundamentally the same network, just at a lower cost, we will have failed IMO.

          -Mike

  • Kirk Byers
    Reply

    Mike, I disagree with you on parts of this. Switching to object-oriented does not change things from being serialized. It changes how the data is structured, but it would generally still be serialized. Calling methods or assigning object attributes is not really all that different from calling functions and assigning variables. It also potentially changes the re-usability of your code, but this still not doesn’t change serialization. Did you have a different meaning of object-oriented or were you focusing on how things could be grouped together (with the underlying serialization being hidden)?

    If you start talking about doing things asynchronously, then that would change whether it was serialized, but then this is complicated and can have difficult bugs (race conditions). Sometimes it makes sense to do this, but I would only do this if necessary (i.e. the application requirements mandated it).

    At the end of your article, I did not understand your conclusion about automating workflow elements–do you have an example?

    • mike.bushong
      Reply

      On serialization, I didn’t mean to suggest that nothing needs to be ordered. I think of order within a particular task, and then applying that task elsewhere. It might make sense for instance to define policy (ACLs, QOS, filters, whatever) and then apply those policy elements separately. The act of definition and the act of assignment are separate. And in fact, once created, you can assign something multiple times (a la object re-use). The analogy was loose.

      I was really just trying to say that people who think abstraction will necessarily cause automation might be disappointed. You can automate without abstracting. And in doing the automation, you actually get some useful info about what ought to be abstracted. The act of automating, in some cases, is conducive to identifying the lowest common denominator of inputs required.

      But not all the posts can be hits 🙂 Looks like I missed a bit with this one.

      -Mike

  • Kirk Byers
    Reply

    Similar to what you stated in your reply…I probably view it as an interactive cycle of automation and abstraction (I need to think about it more). Individuals automate some things and then our abstractions improve. We then automate some more things and this cycle continues.

  • Kirk Byers
    Reply

    I like what you stated in your above reply (with respect to ‘You can automate without abstracting’ and learning about the abstractions to use from the automation process).

    I agree that is wrong to have the idea that ‘someday’ we will get these ‘abstractions all straightened out’ and then we can start automating (as everyone continues doing the same thing they did before without much automation).

    IMO we need to dive-in and do the best automation we can, given what we have available. We then need to then build on this (including better abstractions and better tools). And get in this cycle of automate -> create better tools | create better abstractions -> automate.

    Regards, Kirk

pingbacks / trackbacks
  • […] Is it the easiest thing to accomplish? Not necessarily, but its possible. Mike Bushong from Plexxi writes about the linearity in thinking behind today’s Network Engineers, which definitely exists, […]

Leave a Comment