This post is part of our Summer Intern Blog Series! Each of our most recent class of interns wrote a blog post on their biggest accomplishments and lessons of the summer. This installment comes from Gary, a senior entering his last semester of undergraduate study as an Applied Math-Computer Science concentrator at Brown University. He enjoys playing basketball, spending time with friends, rooting for the Philadelphia 76ers, and eating quality grub.
Over the course of this summer, I have had the pleasure to work as a Technical Intern on the Development Operations (DevOps) team at AppNexus. While companies across the technology industry define DevOps in various ways, AppNexus created the DevOps team as a group of software engineers responsible for building tools and infrastructure designed to assist other engineers. As opposed to product engineers who may develop applications and tools geared towards AppNexus business clients, the DevOps team’s client-base almost always consists of other AppNexus developers.
So, what exactly is network configuration?
Networks can seem like an abstract idea with functionality we take for granted. However, for a company with network traffic volume on the scale of AppNexus, networks are a vitally important concept to understand and optimize. Every minute, AppNexus receives a ton of traffic to its internally-built applications. Therefore, one application cannot run solely on a single application instance or resource. Rather, to achieve optimal efficiency and stability, AppNexus configures networks to spread traffic across many resources located globally across the company’s many datacenters.
There are many ways that this traffic can and should be routed. For example, someone in San Diego accessing one of AppNexus’ domains should not have his/her traffic routed back and forth between San Diego and servers in our New York datacenter. Rather, this person should communicate with the servers in our Los Angeles datacenter to send and retrieve information. This strategy is called Global Service Load Balancing (GSLB) and helps decide which data center to route traffic to, prioritizing geographical efficiency. Likewise, if thousands of people attempt to access a given application at a specific time, they should not all be serviced by only one resource. Rather, their traffic should be divided among several instances or resources so that no one resource gets overwhelmed. To achieve this goal, networks are often configured with some number of Load Balancing pools under which many instances are configured to receive a certain percentage of the overall application traffic.
My project: Network visualization
Although network configuration is essential for the success of AppNexus, until this summer, the data for these configurations was very difficult to visualize and manage, leaving the company at risk for misconfigurations and slow resolution. My summer project dealt with creating a network configuration visualization tool to help diagnose misconfigurations and manage the networks for each of our applications.
Because DevOps’ clients are primarily other developers, my project focused on what made the most sense to the various engineers interested in using it. There are three different types of engineers that would likely use my application:
- Technical Operations engineers who are well-versed in networks and are the main employees tasked with managing network configurations and resource provisioning.
- DevOps engineers who often have a strong background in networks and are occasionally tasked with managing network misconfigurations. Similarly, this tool will help DevOps projects focused on resource provisioning.
- Product and Platform engineers who want to easily understand how network traffic gets to their applications. They also want to identify potential problems with how traffic reaches their application but may not have a strong background in networks and/or want to devote much time to network configuration issues.
Thus, my project attempted to incorporate features and designs to help all three groups with different specialties and use cases for the application. After consulting with many engineers, I determined that representing the configuration as a tree/graph structure would most help engineers understand network traffic flow. From this idea, I created a visualization for the traffic flow from a domain down to the instance/resource level. Check out the example below:
To further assist engineers, I wanted to warn users of potential issues rather than force them to identify problems themselves. To accomplish this goal, I created a framework for enumerating types of misconfigurations and implemented a few tests to alert users to potential issues, enabling future engineers to quickly identify misconfigurations and fix them before they become a problem.
This tool is a small example of the steps DevOps takes to ensure that engineers can focus on their specialties and maintain an efficient workflow. By assisting engineers, DevOps helps the company release more features while also ensuring the reliability of existing infrastructure.
I came into the summer with a minimal background in systems, networks, and even DevOps. However, over the course of the summer, I worked with many bright and helpful coworkers across a variety of teams who enabled me to pick up the necessary context and information to complete this project. The support, investment, and accessibility of employees is truly special, and I am very thankful for the opportunity to meet so many great people and learn so much this summer.