BLOG

Control versus Execution in the Data Path

Lori MacVittie Thumbnail
Lori MacVittie
Published April 27, 2020
  • Share to Facebook
  • Share to Twitter
  • Share to Linkedin
  • Share via AddThis

In days gone by, the app services delivering apps formed a straight and narrow data path. All apps basically traversed the same set of services over the same network. This architectural simplicity made it easy to combine a single point of control with a single point of execution. That, in turn, led to the rise of the application delivery controller (ADC). Through it, app traffic could be shaped, steered, scaled, and secured—all in one place. Control and execution combined to provide ops with a strategic point in the data path at which all manner of policies could be enforced and executed.

The rise of cloud and continued adoption of containers has disrupted that data path. We now have multiple and sometimes dynamic data paths through which apps are delivered. A single, strategic point of control and execution is often no longer operationally—or architecturally—feasible.

But that does not mean that a unified point of control is no longer possible even when execution is delegated to a disparate set of app services.

It is important to have as few points of control through which app services in the data path can be operated (deployed, configured, and managed). Encouraging the use of multiple control points inevitably results in conflicting policies that cause problems for app consumers. Troubleshooting issues becomes more complex and time consuming, which raises the ire and angst of users. Unfortunately, tool sprawl is a common complaint amongst those managing the addition of cloud-native architectures to an already diverse app portfolio.

We know from our 2020 State of App Services research that ops is primarily responsible for the operation of app services, but they aren't alone. DevOps, NetOps, and SecOps are all invested in the operation of app services both on-premises and in the public cloud. 

app services role responsibility

What often separates them is the specific functions of app services for which they are responsible.

DevOps are largely responsible for reliability, for performance, and for app-specific policies. NetOps, on the other hand, are, apropos of their moniker, more focused on network attributes. It is NetOps that often maintains app services from an infrastructure perspective. SecOps, of course, is concerned with security as it relates to the infrastructure and the app.

But just because there may be a division of duties does not mean there should be separate tools with which they practice their arts. Today, there is ample evidence that the CI/CD and continuous deployment pipelines are built on disparate toolsets. Jenkins and git repos dominate the CI/CD pipeline while Ansible and Python are the tools of choice on the continuous deployment side. Much of the decision lies in matching toolset to ways of working for the various constituents that must interact with the tools on a daily basis.

Thus, should a single tool emerge to improve policy consistency, speed troubleshooting, and eliminate the complexity and cost of tool sprawl, it must have the right interfaces to ensure that all major constituents of the app services in the data path are able to leverage the toolset to perform their respective duties.

That's important to the overall security and reliability of the app services themselves. By maintaining a unified point of control, organizations can be confident that changes are tracked and understood. While it's not an immutable implementation, it takes several steps toward that practice by centralizing control in a single tool. 

An example of such a tool is NGINX Controller.  

NGINX Controller

You'll note that, as envisioned, a variety of app services (analytics, API management, security, and service mesh) can all be controlled centrally, even though operation and execution are distributed.

In any environment, it's important to reduce the number of tools allowed to interact with data path components (app services) to mitigate potential problems with misconfiguration or conflicting configurations. In a modern, multi-cloud environment it's even more critical to centralize control because of the complexity incurred by the often exponential growth of app services comprising the data path. 

More compelling to those who own the budgets is the reduction of operational expense associated with eliminating repetitive, manual activities with automation.

Unifying control in a single tool is one way to do that. 

Connect with F5

F5 Labs

The latest in application threat intelligence.

DevCentral

The F5 community for discussion forums and expert articles.

F5 Newsroom

News, F5 blogs, and more.