As a member of the Tail-f Engineering team at Cisco, I have been fortunate enough to spend the last couple of years together with customers that have taken on using our NSO product as a fundamental part of their automation and service orchestration efforts.
As much as I enjoy the deep technical challenges this has exposed us to, it has also been very interesting to see how these organizations have taken on the formidable task of transforming their ways of working in alignment with the shifts in technology stacks.
It is no secret that the NSO architecture team members are big fans of the promise of the model-driven automation and orchestration stack. And at the core of this belief lies our conviction that a flexible and robust model-based system will support the emergence of new and better abstractions for networking. Abstractions that are defined by the teams in charge of the system, and not hardcoded in shrink-wrapped applications, nor defined by weak abstractions like workflows.
When you combine the efforts of customers teams looking for ways to change and a technology platform like NSO, you also start seeing experience-based opinions within these teams. Opinions that are formed by trying, and at times failing, and not from industry hype or fashion alone.
We do our best to track these hard-found experiences knowing that it is almost literally is the currency running the automation part of the industry. Technology is all well and good, and some vendors do a decent job, but gaining experience as a team such that you can drive your own path is expensive. Our customers are always looking for ways to come together and both share and learn from each other.
What we haven’t seen much enough of, is customers sharing these kinds of insights more widely outside of narrow interest groups and meetings. So it’s always a good sign to see large networks coming out with experience-based opinions that partially goes counter to the mainstream discourse.
I happened to stumble across a piece called “BT’s McRae says NFV is ‘unimpressive’ but service models and automation are ‘transformational'” over at FierceTelecom. What made me excited about it, even though it doesn’t directly mention NSO, is that the comments made by Neil McRae, chief architect at BT so completely mirrors our own experience in the domain.
I’d like to go out on a limb here and suggest that the comments made by Mr McRae are all related to the concept of efficient network service abstractions. He goes on to say this in several ways, but three of them stand out to me:
I strongly believe that the ability to leverage the insight encapsulated by the three points above will prove to be essential for any successful undertaking towards automation and service orchestration. I also happen to think it holds true for all kinds of networks, not limited to the type of service provider network represented by Mr McRae. Networks are always tasked to eventually do something on demand for someone (if we allow the “someone” to also be an application). Understanding what that something is and how to effectively express it using abstractions is the key to success.
It’s an interesting article, you should read it and treat yourself to some hard earned and free experience.
Carl has spent many years trying to solve network management with special focus on automation and orchestration. He is a Technology Director leading the engineering product management team for the Network Service Orchestrator (NSO) product.
Published with permission from blogs.cisco.com
