Why indeed one may ask start a blog on network automation. But the better question actually is; why start a network automation company? Because that’s what got me started in the first place. To answer this, I have to take you back to the year 2000, when I started to work on several networking projects for Rabobank. At the time Rabobank was one of my biggest accounts. I had a team of network (management) consultants working on several projects when Rabobank decided to revolutionize the way they run their networks. They decided to become proactive through standardization and centralize.
The first project was the migration of 1600 local bank offices from 3Com to Cisco (4500 devices) and start managing them centrally. I was asked to put together a team to select and implement all of their monitoring tools for the new NOC. Although a great project, this was not too special. We implemented HPOV and Cisco Works for monitoring, Micromuse for event management, Concord for performance management and several other integration things. Things became more interesting when we were asked to develop a solution to be able to generate all 4500 unique configurations with Rabobank’s LAN and WAN services and provision all locations in just a matter of weeks, as they were under time pressure. This is how the first release of netYCE was developed (the name was actually derived from its original functionality i.e. Your Configuration Engine for networks).
At first, we only focused on the provisioning part and used smart (sub)templates with easy to substitute parameters such as IP and VLAN numbers and we developed what we called ‘models’ to generate configs for their different types of architecture & designs on the fly and without errors. Second step was to activate the configs on all devices by developing a Cisco vendor module and having an integrated TFTP server in the platform so engineers in the field could just log in, fill in the bank id and the system would generate and provide the complete config. As a next step, Rabobank decided that all network changes should be done and controlled centrally. Engineers and operators were to be given central access to the platform and should be able to do everything that they normally could on the command line (CLI). This was a major step in the development of the platform. All operational tools and vendor modules were developed to support multiple vendors. Also the concept of network abstraction was introduced to manage all parameters and relationships in a vendor- and technology-agnostic way from one place.
The results of the first project were amazing. Rabobank went from 30 fte to 6. Networks became extremely stable and fully standardized, while at the same time offering all the flexibility to quickly and easy deploy new services and support desired ‘specials’. I didn’t realize at the time, but we given the opportunity to contribute to what is now called ‘Design Driven Networking’. Over a period of 6 years, Rabobank migrated nearly all their networks under control of the netYCE platform. Next to all their local banks these were the office-, server backbone-, data center-, surveillance- and ATM machine networks.
Rabobank invested ongoing in the development of the platform. (i)OS upgrade support was added and integrations were build with other NMS systems to automate more and more manual processes. Also the northbound interface was added so external (orchestration) systems could provision the network without involvement of engineers or operations. By 2010, Rabobank was so mature that all their networks were fully managed by only 9 engineers with automated processes extended to their help desk to support their self-service requirements. During those 10 years, Rabobank asked several external analysts to assess if there were commercial solutions available as they realized they needed ongoing support on the platform. It turned out that none of the major players (IBM-Intelliden, HP-Opsware, Infoblox-NetMRI, EMC-Voyance) offered the same type of functionality. These were all focused on backing up configurations that were manually deployed and changed in production networks.
The things that were most important for them were not included. These were the ability to standardize networks, control all lifecycle change processes and enforce architecture and design principles while keeping track of all engineering knowledge in one place. As we were still Rabobank’s trusted advisor and partner to maintain the platform, we sat together and jointly decided to bring the solution to market. That’s how in 2011, the company NetYCE was set up. Since then, I have been in a privileged position to speak to over 100 large enterprise and service provider companies around the world and gained a wealth of insights on how other companies try to optimize and automate their networks.
In my upcoming blogs, I will share these insights and go in more depth as how the market has evolved in the last few years, what are still the challenges to address and how the netYCE platform got further developed to support other markets and customer requirements. I have come to realize that there is a huge demand for an open, vendor-agnostic discussion on this topic that doesn’t only address network challenges by adding new technologies to the equation, such as virtualization, SDN, OpenFlow, and Network Function Virtualization. But by looking at the basics how to optimize and automate networks. In the end this is best (only?) be done by controlling change processes, focusing on standardization and by enforcing architecture and design principles.
I invite you to participate in this discussion. Please join the LinkedIn group on Design Driven Networking or by commenting on my blogs.
Ceo and founder NetYCE