Channels ▼


The Role of the Developer in the New Network

Lori MacVittie is Technical Marketing Manager for F5 Networks.

Cloud and virtualization are imposing a heavy burden on the infrastructure supporting applications. The "new network" necessary to support the dynamic environment in which applications are rapidly provisioned requires that network components -- from switches to firewalls to load balancers -- be not only dynamic, but able to collaborate with the broader management ecosystem. We all know what the word "collaborate" means to applications and it's no different for network components -- integration.

Network components will need to integrate with applications to improve scaling decisions, with each other to react to changes to applications (launch, decommission, scaling), and with the orchestration systems that will automate many of the tasks typically accomplished manually by network and systems' administrators.

The means to achieve such integration exists for most components, but it is as a developer would expect: programmatic. APIs exist to allow remote management and control of network devices (virtual and physical) and it is almost certainly the case that someone will need to leverage those APIs to achieve a dynamic infrastructure.

A potentially new role within IT is emerging, one that focuses on network and infrastructure components rather than applications: infrastructure developer.

The Need for the New Network

The reason an infrastructure developer will be needed is related directly to the need for a new network. Virtualization and cloud computing ultimately require new kinds of interoperability to reduce the burdens imposed by these technologies. What's really problematic is that this can occur many times over a short period of time, and in a large-scale environment can be occurring for myriad applications at the same time. Massive amounts of information about policies, locations, and infrastructure must be shared over the same network, at the same time. Components must be updated, configurations changed, policies applied, and it has to happen in the right order. The scalability of such a dynamic environment is inherently limited to a single bottleneck: manual configuration and management.

The new network needs to enable the means by which a dynamic infrastructure supporting multi-component/tier applications can be automatically discovered, rapidly provisioned, scaled, secured, managed, modified, and migrated across disparate locations. Without automation these operational processes take far too long to be called "rapid" and are inherently error-prone as people miss steps or mistype a command.

It's not just about starting up and shutting down applications. A dynamic infrastructure must be able to react on-demand to events and changes in the environment. As policies governing the delivery of applications change, as the applications change themselves, when attacks threaten availability and security, the underlying infrastructure must be capable of adapting and responding with as little manual intervention as possible.

Why Is This So Complex?

Consider the series of events that occurs when an application is first deployed anywhere. As a developer or architect, once the application is deployed into the production environment and verified to be working, it's time to shift the burden to the network team. This is often referred to by networking folks as "throwing the application over the wall" because the line of demarcation between networking and application development is long and wide and, like a castle wall, not meant to be breached.

Figure 1: Abstracted diagram of integration of cloud framework with infrastructure component APIs.

The network team has to concern itself with firewall policies, routing, switching, load balancing, network-hosted security such as IDS, IPS, and web application firewalls, as well as any unique application related solutions such as application-specific acceleration, optimization, or resource obfuscation. Each policy is a potential point at which an error might be introduced, or a step missed, leaving applications and corporate resources vulnerable to exploitation. When a second or third instance of the application is launched to support capacity on-demand, the load balancer must be updated and any application-specific policies might also require modification. Again, this is generally a manual process. Most of these processes are transparent to the developer today. In a dynamic, cloud computing-style architecture, however, these processes become automated and are driven by a framework: and that framework requires integration and control over the comprised infrastructure components.

It will become the responsibility of infrastructure developers to enable this automation through integration of networking components into the automation frameworks necessary to scale such dynamic architecture effectively.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

