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:
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.