Back Down the Chain: The Link between Listening and Usability

As F5 has moved toward a DevOps and Agile style of development on our platform, we have coalesced around the principle that shipping a product is not the bar for success.

Today we’re getting rid of the bar and looking at the whole lifecycle—sending a creation out, listening to constituents (both inside and outside F5), and then feeding those learnings back into development. We prioritize customer feedback over almost anything else, especially when it comes from customers running F5 in production environments.

Our goal is always to build a better product and fill in our gaps. But it’s also to find balance between advanced functionality and ease of use. We want to give advanced functionality to our customers, but we also understand the end user is not necessarily the systems architect we’re working with up front.

To put complex functionality in the hands of a wider audience, we’re going back down the chain and automating configuration through new, richer APIs. And that translates to the F5 Automation Toolchain we have today.

With the Automation Toolchain, we’re pushing the boundaries of what we thought we could do and the functionality we could enable. We found that much of that had to do with the experience of the API, which has led to our push toward a declarative model.

Why does the user experience for an API matter? It matters because the people consuming that today are not those systems architects. They are the developers and engineers two or three steps down the chain.

Our customers want services that are easy to integrate, and that their customers can consume even if they aren’t experts. That means APIs can no longer be an afterthought designed with experts in mind. We are designing our APIs to be very clear and succinct, so it’s easy to infer how the interface should be used just by looking at it.

By making the API declarative or intent-based, we’re shifting the whole approach. Instead of giving users a two-page configuration brief to follow, we’re simply asking them: Tell us what outcome you want.

And we’re enabling this automation to consume complex services, not just simple things. You still have all the power of the F5 platform, but now it’s easy to get that complex functionality to the people who need it.

And then there’s the fact that not every customer is at the same place in the journey to automation. We have customers at all points in the spectrum, so we’ve also built the Automation Toolchain as a set of components that can be broken apart and used independently, then brought together as a unit when the time is right.

Along that lifecycle, there are discrete steps that are each addressed by a component of the Automation Toolchain:

• Bootstrapping. This is the initial step when you just want to get an F5 instance running somewhere. If you’re a customer and you want to bootstrap a BIG-IP instance in a public or private cloud, we’ve got F5 Cloud Templates to help you accomplish that.
• Onboarding. This is where you’re taking that instance to the point where you can deploy a service. You don’t want your developers to have to set up all your IPs, configure the users, the logging and all of that. And they don’t want to do that either. That’s where the F5 Declarative Onboarding Extension comes in. It allows us to present a very simple declarative interface to take care of the initial configuration.
• Deploying application services. This is the day-to-day stuff that happens in every environment. Deploying a new service. Changing or deleting that service. Modifying it or adding new functionality. For this, we have the F5 App Services 3 (AS3) Extension, which presents a declarative outcome-based API interface with the ability to templatize configuration. AS3 is where most of our customers start because it tends to provide the most value right away.
• Monitoring and telemetry. When you’re using the Automation Toolchain, data is now available by default, so it makes sense to use F5 Telemetry Streaming Extension and get that data off the device as fast as possible to some other system. That could be products like our BIG-IQ management platform, a cloud-based analytics solution or other tools that allow you to apply big data principles to what you’re getting from devices.
• Change management. Change happens and will always happen. Going back to DevOps, we’re also moving away from massive changes and monumental releases. Today it’s small units of change over time. You can drip-feed new features to the customer, and they can adopt those as they need to. And none of these changes will break what came before or require heavy modification.

All of these are predicated on a single API call to the platform that describes your desired outcome. F5 processes the call into all the actions that need to take place on a BIG-IP device to reach that state, and responds to say yes, it’s done or no, there’s an issue. It’s all done in a very stable manner based on established patterns and methodologies for automated systems.

The result is that the Automation Toolchain reduces the effort required to integrate with our platform to the point where it’s almost a no brainer.

Our view of how F5 platforms should be integrated in the future is that we want to be the easiest platform for the ecosystem to integrate with. Pound for pound, for every line of code that a customer or partner has to write for our platform, we want to deliver 100 times the cost of that line of code in functionality and usability.

In the end, it’s not about doing simple things. It’s about doing very complex things in a very simple way. This is what the F5 Automation Toolchain delivers.