#SDAS #Cloud #API #devops #LineRate It has an impact. A big one, in fact. Get ready for a change...
Application development trends significantly impact the design of data center networks. Today there are two trends driving a variety of transformation in the network: API dominance and micro-architectures. Combined with a tendency for network operations to protect its critical infrastructure from potentially disruptive change, these trends are driving toward an emerging "app network" tier in the data center that is software-defined.
This "app network" can be realized in one of two ways: through the deployment of application proxies, or via an application service fabric. The choice comes down to how integrated devops and network teams really are, and whether or not you have a service fabric available. If you do, it's a good solution as it affords the same flexibility as application proxies while removing platform-level management from devops shoulders. Only services need be configured, managed and deployed. An application proxy, too, is a good option and gives devops and developers complete control over the platform and the network-hosted domain services.
Today we're going to dive into the application proxy-based architecture.
APPLICATION PROXY ARCHITECTURE
Application proxies are highly programmable, scalable and perform with the alacrity expected of a "network" element.
Application proxies provide devops and developers with the mean to rapidly provision domain services specific to a micro-service or API. By decomposing traditional ADC-hosted services into domain specific, application proxy-hosted services, each service can be containerized and their deployment subsequently automated to ensure CPR (consistent, predictable and repeatable) results. Successful continuous delivery is the end goal. As noted earlier, this can be achieved via an application services fabric as well as dedicated application proxies.
This architectural model is more efficient in terms of resource consumption. Decomposing services ensures they scale independently. When services are code-level integrated into applications, the overall application footprint is much larger and requires more storage and more compute to scale. Decomposition reduces demand for storage and compute overall by only requiring expansion of a subset of services at any given time.
When the application proxy is highly programmable, devops and developers receive added benefits in the form of being able to codify services and treat as part of the code base rather than as separation configuration files. For example, specifying simple URI rewrite rules in some proxies requires changes to a configuration file. Using a programmable application proxy, such rules are coded and treated like artifacts; they can leverage existing build systems like Jenkins. They became part of the overall application rather than separate configuration files that must be merged, replaced, or otherwise managed. Using programmatic means to implement domain specific services affords devops more opportunity to seamlessly integrate with existing application deployment processes and increase its success rates.
The transformation of application architectures is driving data center networks toward a need for programmable domain services. These services must match service velocity and change the economy of scale as the number of applications needing services increases with each new application and application version. Not doing so means organizations will respond with discrete services that introduce operational risk and inability to consistently deploy new applications.
Both application proxies and application service fabrics meet these requirements, and both models are equally capable in offering a more seamless, less disconnected continuous delivery experience.