Where F5 Fits in a DevOps World
I’m often asked after speaking at conferences just what dog F5 has in the race. Of late, that topic is usually DevOps or related to DevOps in some way.
The reality is that application-affine services like load balancing are being pulled toward toward applications, into the more agile, software-driven, and automated environment that makes up the application network. That’s where compute and application centric systems like caches (think memcached and redis) and databases and containers are being deployed using CI/CD (continuous integration/continuous delivery) methodologies that rely on a whole lot of automation and orchestration.
F5 – and more specifically, BIG-IP – is nearly synonymous with load balancing. We’ve been doing it since before the turn of the century and many core load balancing algorithms and concepts you use today with other load balancers were, in fact, invented here. So to say we know a thing or two about load balancing applications is an understatement. And we do it with software that’s deployed on either custom-built hardware or and even in the cloud.
That software is enabled with an API. It’s called iControl and it’s available in both SOAP and REST flavors, for your programmatic convenience. This API lets anyone (even me) provision, configure, and control the load balancing (and other) services of a BIG-IP for any application.
Now, as I said application-affine services are shifting toward the application every single day. Scalability – load balancing - is one of those services. It is a critical component today for any application and, increasingly, for the microservices that comprise modern applications. As pointed out by Microsoft in a 2015 paper on scaling services:
In the presence of diverse and plentiful machines, the developer is forced to think about partitioning the application workload, as well as the network connectivity needed to support each partitioning scheme. One very important aspect of connectivity exists between external users and the service itself. Except for the smallest of services, some form of load balancing mechanism is needed to distribute the load of incoming connections over the FE boxes. Many megaservices also have sub-services, which are themselves load balanced. [emphasis added]
Load balancing isn’t an afterthought; it’s a natural complement to applications and services today to enable the scale (and reliability) required to keep users happy and the business running. That makes it increasingly true that load balancing is a part of the overall application architecture. And indeed it should be, as the addition of any component to an application architecture can introduce issues or integration problems that need to be overcome. Issues that need to be addressed before the app moves into production, not after. The time required to find and fix problems in production is many times greater than in development or test environments, and thus including load balancing in the application architecture means a smoother (and faster) transition into production and the hands of users.
But that means you need to be able to integrate the load balancer into the processes automated by the DevOps tool chain that increasingly drive integration and delivery in development and test environments. It means offering up a comprehensive set of programmatic tools like APIs and templates that make it possible to treat the infrastructure as code and automate its provisioning and configuration. Which is what iControl (REST or SOAP) does for F5.
A BIG-IP can be integrated into DevOps in the deploy, test, and release phases by taking advantage of its native APIs using pretty much any language you like (here’s Powershell, Python, and Perl) or through frameworks like Chef and Puppet and tools like Ansible and SaltStack. iApps, our templates that describe an application service configuration, can be treated like code: store it in Github, retrieve and deploy it as is or customize it with a script.
Basically, BIG-IP application services like load balancing and many of its application performance and security services should be integrated earlier, in the CI/CD process, to ensure that these critical services work together seamlessly with the application, as expected.
Eventually we’re going to see more and more traditionally “network” devices fit into a DevOps world as the pressure to move applications faster, more frequently, and with less disruption continues to drive business and IT leaders headfirst into the application economy.
For a deeper dive into the DevOps tools you can use with BIG-IP, check out this post on DevCentral "F5 Friday: DevOps Tools and F5"