A very large part of my professional career in network design was spent working on automation. A journey in automation that began in 1996 when I and a few colleagues engineered Bloomberg’s first global IP WAN, which evolved into the most recognized (and agile) WAN in the financial services industry.
The automation behind that network started off very basic, and over the years evolved into a very lean and flexible model-based library core, with the various programs (provisioning, health-checking, discovery, etc) that were built on top. This small automation library (less than 15K of OO code) drove a high function multi-service network with support for 6+ different NOS' and 100+ different unique packet forwarding FRUs. Including service-layer functions such as VPNs with dynamic context-specific filter, QoS and route policy construction, BGP peering (internal and external), inline VRF NAT, etc and support for a variety of attachment interfaces such as LAG/MC-LAG and channelized Ethernet/SONET/SDH/PDH interfaces (down to fractional DS1s) with Ethernet, PPP, FR and ATM encapsulations. And, yes, even xSTP. It was quite unique in that I have yet to see some of the core concepts that made it so lean and flexible repeated elsewhere. We were among the earliest examples of a DevOps culture in networking.
Many lessons were learned over the years spent evolving and fine tuning that network automation engine. I hope to capture some of those learnings in future blog entries. In this blog entry, I want to share a perspective on the core foundation of any proper network automation — and that is network architecture and design.
All great software systems start with great software architecture and design. A key objective of software architecture and design is to achieve a maximum set of high quality and scalable known and yet-to-be-known outcomes, with the least amount of complexity and resources. Applying paint to the network canvas without tracing an outline of the desired picture doesn’t always get you to the intended outcomes. Design top down, build bottom up, as they say.
In networking, automation is a means to an end, which are the high quality services to be rendered. Once we know what network services we expect to deliver over our network, we can then identify the building-block functions that are required and their key attributes and relationships. From there we identify the right technologies to enable these functions such that they are synergistic, simple, scalable and resource efficient. The former is network architecture and the latter is network design.
It’s only after you arrive at a foundational network architecture that you should start the work on automation. After this, automation should coevolve with your network design. Indeed, the network design must be automatable. In this regard, one might even look at network automation as an aspect of network architecture and design, since it's role is to realize the network design. Obviously this would mean the Bloomberg automation library implements the Bloomberg network design, and not yours (although it might have everything you need).
IMO, great network automation is based on software design that tightly embraces the underlying network design, such that there are corresponding functional equivalents in the automation software for the functions in the network design. This is what I call model-based automation (as opposed to model-blind automation). In this sense again, good network automation software design is inclusive of the network design.
This last assertion is an example of what I spoke of in my previous blog, of how an enhanced mode system (here the network automation system) should be a natural extension of a base mode system (the network system), such that if the base mode system is knowable, then so is the enhanced mode system. Which, when done right, makes possible both an intelligent network as well as the intelligent operator. This assertion is backed by a very successful implementation on a large high function production network.
In conclusion, what I've learned is that network architecture and design is king and, done right, network automation becomes a natural extension of it. Companies that do not have the resources or know-how to properly marry automation design and network design have a few hard lessons ahead of them in their automation journey. For some companies, it might make sense to consider network automation platforms such as Contrail's fabric automation, which incorporates standards-based network design that is built into a model-based open-source automation engine.
No comments:
Post a Comment