Repositories and Standardization Can Help Address Network Automation Integration Challenges
Integration has always been a four-letter word in the sense that it evokes gnashing of teeth and lamentations of those languishing on projects dedicated to its implementation. In fact, 59% of IT decision makers characterized “integration as the 'Achilles heel' for their organization." (The Connected Business Integration 2018 Report)
On the surface, integration begins with a simple premise: how do we share data across applications? Because no application - even a monolith - is an island. I haven't met an application yet that didn't share at least one piece of data with another application.
We (as in the industry) have gone through several eras of integration. From hub and spoke models to the enterprise (service) bus to message queues, integration is always an integral component of an enterprise application strategy.
We don't call it Enterprise Application Integration (EAI) anymore - mostly because I think that scares the youngsters and sends us old-timers into apoplectic fits - but we do still use the word "integration". And we use it increasingly outside the world of application development. CI, after all, stands for continuous integration. We see integration as significant to the deployment (production) side of the world, too. And we see just as much frustration as our app dev counterparts, as noted by those who are frustrated by a lack of integrated tools when faced with automating the network.
Operations needs integration. Without it, we can't automate processes (which is what orchestration is) because processes necessarily span multiple systems, services, and devices - each of which likely has its own operational domain and toolset. Without integration, you can't build a pipeline and without a pipeline, operations will be overwhelmed by the growing requirement for frequent deployment-on-demand.
This is where infrastructure as code and repositories can provide relief. Repositories are more than a place where you can store just about any kind of artifact from configuration file to Python program to scripts and templates. They can be an active participant in your (integrated) deployment pipeline.
Repositories are more than Storage Chests
Repositories are not just a place to store artifacts. I mean, yes, that's their primary purpose but they have evolved into much more than just a storage locker. Today, repositories like GitLab and GitHub can be a key component of the automated pipeline. Using triggers and events, repositories act not only as a place to store artifacts but as tools in a larger toolchain. Commit kicks off a job that, when finished, invokes a webhook that triggers the next step in the pipeline.
What is a Webhook?
Sometimes called a 'reverse API', a webhook allows one application - like a repository - to send data in real-time to another application via a URL/API. For example, upon commit of a new config for your load balancer, the repository triggers a webhook that, in turn, sends the config or URI for the config to an app (or the load balancer directly) that in turn loads the new config.
Basically, we're using repositories in much the same way we used to use an enterprise service bus to share data and initiate action in different applications and services in order to complete a "process". In the business world, that process might be completing a customer order and involve the customer information system (CIS), an order fulfillment system, billing, and elements of the supply-chain.
In the operations world, that process spans infrastructure, network, and security services involved in fulfilling the deployment of an application or policy.
Even more exciting for those who cited "skills" as their top challenge, repositories can be controlled almost exclusively from the command line. Yes, using the same skills already possessed by most NetOps. A little bash and some PERL*, an API via curl and voila!
Now, that doesn't address the deeper need for integration at the device layer, which is expressed in the frustration of a lack of vendor solutions. Because ultimately, the configuration or changes to the configuration that are stored in the repository and triggered by a Webhook still have to be translated to device speak.
And that's where standardization and solutions come into play.
Standardization Reduces Operational Integration Burden
Automation is something that many of us at F5 are focused on right now. One of the solutions we've come up with is our F5 Automation Toolchain. It comprises the F5 Application Services 3 Extension (AS3), F5 Declarative Onboarding (DO), F5 Telemetry Streaming, and the F5 API Services Gateway. Together with a repository, they can enable organizations to build out the pipeline they need to deploy the application services an application (and the business) needs to keep apps fast, secure, and available.
But Lori, you're thinking, that doesn't help me with all the other devices and services I need to automate and integrate.
True. This is one of the ways in which standardization on a common application services platform can help. Because the platform (BIG-IP) is the same for a broad set of application services, you can use the automation toolchain to deploy a WAF and a load balancer and access control as well as DDoS protection, amongst others. Standardizing on as few platforms as possible adds value by reducing the integration burden on all operations - network, infrastructure, and security.
This is true within the confines of the data center and in a multi-cloud scenario. Standardizing on a single platform across application services and cloud environments means faster time to value when deploying apps anywhere.
You can find the (totally free for the taking) F5 Automation Toolchain in a number of locations:
So remember, repositories aren't just a place to store things. They are a valuable tool in your automation tool chest that can be brought to bear to help automate all the disparate pieces of your pipeline. Standardizing on a repository along with an application services platform can go a long way toward reducing the operational burden imposed by that four-letter word: integration.
*interpret "PERL" as Python or some scripting language that's actually usable. PERL is just the only one that rhymes with curl and I've not found anything good to rhyme with wget.