Guru’s Guide to Excel-ing as a Network Engineer

While it’s tempting to make fun of it, the reality is that Excel is a pretty good tool to consolidate the data from your network in one place, analyze it, generate reports, and much more. Unfortunately, importing data from network appliances into Excel is a laborious, manual process and keeping the data up-to-date is almost impossible.

What’s New?

Three trends have come together to make Excel, a trusted workhorse, even more useful in network operations:

1. Single API endpoint (centralized management): Next generation networking solutions, like Avi’s platform, have a distributed architecture with as-a-Service semantics. This means I no longer have to go to hundreds of load balancers or web app firewalls to collect data manually. I can simply go to a controller and collect data from hundreds of end points. This makes it remarkably easy to gather data.
2. REST APIs that are available for 100% of the features (not just some small subset)
3. Excel has improved too. It now has native data gathering capabilities and can download data automatically from external sources. This enables it to speak to end points with a Web API and download JSON data for instance.

The “Aha” Moment! A Real World Example…

So what does this look like in practice? Here’s an awesome example one of our customers shared with us. Matt, the load balancer (LB) admin, has two Avi controller clusters, each with about 50 Service Engines (technical name for our software load balancers). Each cluster has a total of about 400–500 applications (about ~1000 apps total across the two clusters).

With his legacy load balancers, Matt had an Excel spreadsheet that had a record of all 1000 applications, capturing which application was on which of his 100 load balancers (across 2 sites). He also had a bunch of Python scripts that would scrape each load balancer for basic information about his applications-essentially answering whether an app is up or down. To get any detailed information on application health, performance, security, LB health, LB licensing etc., he would look up which LB to log into and then go to that LB to get detailed information. Overall, a fairly laborious and manual process.

During the PoC phase, Matt took advantage of the fact that with Avi several dozen LBs were essentially one elastic LB that he could ‘speak’ to with a REST API.

Instead of manually capturing information on load balancers, applications, application health etc., he simply fired up spreadsheet and pointed it to his Avi Controller and with a few clicks downloaded all application and health data. When he fired up another cluster, he simply added data from that cluster with a few more clicks.

With this one time setup, he had all the data he needed in a single spreadsheet that automatically updated the data from all controllers in his environment. This meant he had real-time data from hundreds of applications across several dozen load balancers across two Avi clusters was available to him in Excel-where he could easily analyze it and generate reports as needed.

Over the last few months, here are some of the use cases he’s using Excel for:

• Collect and analyze detailed health score data for hundreds of applications
• Dynamic up-to-date IPAM for all application (VS) IPs (no more manual IP address management)
• Consolidate and analyze all licensing usage (e.g. which tenant is using the most licenses, how much capacity will we have worldwide at the end of the year, do I need to add capacity)
• Globally, which applications are seeing the most connections per second (/TPS), what about max throughput, or concurrent connections? Once in Excel, he can run sophisticated what-if analysis, or forecast growth, identify patterns and so on.

You could even connect a Microsoft Power BI, for instance, to your controllers so you can use the power of a sophisticated business intelligence platform on the real-time data from your LB infrastructure. This is just one of the several advantages of moving to a software-defined platform!

What Matt showed me really brought home the power of a well thought out architecture that’s built for automation. The two things that really made this possible:

• 100% of functions available over a REST API
• An “as-a-service” architecture that presents the entire infrastructure as a single elastic fabric so that automation has to be done only against a few end points and not hundreds of load balancers.

The short video below recreates what Matt did, Feel free to reach out to us if you have any questions on this or if you’d like to try this out for yourself. Let’s Excel together! :)

Originally published at https://blog.avinetworks.com.