On the DevOps Journey: How Network Engineers Can Begin to Think Like Developers Using F5
NetOps embracing development best practices is a key piece in the DevOps puzzle. Three shifts in mindset and technology use cases can help.
Despite advances in technology and a burgeoning transformation of an industry, many NetOps teams struggle to adopt infrastructure automation tools at scale and embrace core DevOps practices across their teams.
Adoption of container platforms like Kubernetes, Red Hat OpenShift and Pivotal Container Service (PKS) are redefining how many developers deploy and manage their application workloads. Infrastructure automation tools such as Ansible, Chef and Puppet are also transforming how NetOps engineers are provisioning, deploying and managing the foundational infrastructure configurations for these container platforms.
To embrace DevOps practices, network engineers must begin to think like developers. Luckily, development best practices have been in place for years, and F5 serves as the perfect catalyst to begin to incorporate DevOps practices into infrastructure configurations.
By following these shifts in mindset and adopting the development best practices below, NetOps can begin to reap operational rewards.
Rigor and discipline are non-negotiable when it comes to GIT
Infrastructure as Code is one of the first steps to NetOps gaining the operational improvements of a DevOps approach. With this comes the need for rigor and discipline with managing infrastructure configurations within a version control system (VCS) like Git. A tool like Git provides traceability of changes, rollback capabilities, cross-functional visibility and can automatically trigger automated testing.
Git can be intimidating but it becomes more palpable when you can find a way to use it to get repetitive, mind-numbing tasks out of your workflow. Take for instance configuring an F5 Virtual IP or VIP.
If you’re an F5 administrator, you already know the many dependencies and processes in creating an F5 VIP when deploying an application. You need to get an available IP, configure the profiles, consult your development on the proper health monitor and what nodes you’re load balancing against.
Not only is this process tedious but it inherently introduces risks and extended lead times to the overall configuration process.
Code configurations for success
An easy means of systematically getting control of these dependencies and beginning to treat device configurations as a form of code is with F5 AS3.
F5 AS3 enables NetOps engineers to wrap all the F5 dependencies associated with an application into a single concise JSON payload. These declarations describe common F5 configurations such as virtual IPs, pools, health monitors and profiles in a standardized readable language that can provide the same predictable set of configurations after every execution of the payload.
Example of AS3 payload from "F5 Friday: Configuration as Code with F5 AS3."
When paired with a version control system such as Git, network engineers can use F5 AS3 to easily version, collaborate and promote configurations throughout their environments and to their F5 devices.
So, if you’re looking to get started with a tool like Git, try AS3. You’ll get a DevOps methodology under your belt, as well as create operational improvements and agility for your organization.
Test drive everything
Developers test, test and test again, and it’s time NetOps started doing the same. But it’s hard for NetOps to get into a test-driven mindset. That’s because when network engineers get a ticket with a long list of requirements, immediately, the race to implementation is on. Rarely do they get to step back and see the big picture. By contrast, developers know the end goal of the application they’re building.
It’s important NetOps also knows the end goal of the requests they receive. Put in the time to gather an entire list of requirements so you can understand what you’re designing toward. The more often network engineers can ask themselves, “What are we trying to accomplish?” the better.
With all the requirements in hand, the next step is to design tests while building out implementation steps, just as developers use test-driven development (TDD) to code tests while building out applications.
Until test plans are coded, NetOps will continue to struggle with an unpredictable testing process, likely documented in Word documents or ServiceNow, with a slew of manual steps. Chances are that in many cases testing won’t even take place.
Development teams are forced into the test-driven mindset as it’s part of a larger Continuous Integration and Delivery (CI/CD) process that ensures quality code. Using Selenium, for instance, a developer can create a test process in conjunction with the development of an application to not only code the underlying mechanics of an application but also the testing process.
When NetOps implements infrastructure as code, they can begin to practice CI/CD and build a high level of quality into deployments. No more just checking a box. Tests are forced to run every single time a change is made within a Git repository.
Not only will NetOps be surprised by how much less feedback they get from developers about broken configurations, but they’ll be amazed by the level of trust that forms across teams.
If you build CI/CD, trust will come
For many organizations, there is often a one-to-one relationship between an F5 virtual IP and an application it supports, but very rarely do developers or individuals directly supporting the application outside of NetOps see these configurations.
Because no team has a complete picture of what’s configured across the full application stack, often conflict and distrust arise between teams when an issue comes to the surface.
Adoption of infrastructure as code through the use of F5 AS3 and Git forces transparency across teams. Developers know exactly what’s configured on the F5 devices supporting their applications and NetOps engineers can see the code developers are running behind their F5 infrastructure.
By incorporating testing in the CI/CD process, NetOps engineers can further ensure the F5 configuration being made works successfully in conjunction with the application it services. Outside of the technical win, teams will benefit from a higher level of trust and collaboration.
Automate waste away!
By nature, developers don’t like doing anything manually. If a developer sees something that happens once a week, they’ll write code around it and automate it away as quickly as possible. Whether the code is efficient or not, they’ll engineer something to fix the problem at hand.
While it’s not necessary to take such an accelerated approach to eliminating repetitive tasks, NetOps does need to get into the mindset that part of their job is to automate manual tasks away and provide self-service capabilities to development teams.
One way to start is by holding monthly infrastructure meetings where you look for patterns in ticket requests to identify repetitive tasks. When a pattern is identified, and the assumed time savings justified, put it in a backlog of items to automate.
Of course, random ad hoc work will always come in and serve as a distraction from self-service, automated improvements. But by not taking the time to at least identify patterns in toil, NetOps will never begin to eat away at it. Worst of all, not only will network engineers be stuck with the mundane and tedious, but operations will lose out on their intellectual capital.
Conquering the toil
Creating an F5 VIP often can sometimes take weeks depending on the size and complexity of internal processes within an organization. Further compounding this issue of toil is the fact that F5 configurations are common given how often new applications are onboarded into organizations. For every new application, configuration changes need to be made to its associated F5 device.
By the end of this year, 72 percent of organizations will have adopted some DevOps methodologies, according to findings from a 2018 survey conducted by F5 and Ansible. As DevOps becomes more pervasive and encouraged by leadership, NetOps must be prepared to embrace DevOps methodologies.
Focusing on areas where NetOps can get into a developer mindset by executing some simple F5 use cases is one of the best things NetOps can do to be DevOps-ready.
NetOps will see the operational benefits of practices like infrastructure as code, test-driven infrastructure and automation. Along the way, they’ll gain confidence by bringing both speed and stability to the application deployment process.
It’s a win-win. And at the end of the day, the DevOps journey only pushes forward when NetOps and development win together.
Learn more about the benefits of Ansible and automation by checking out this lab.