Network Operations and Application Development: Different Worlds No More
Today’s corporate network has evolved from a convenient means to connect a few important systems to critical infrastructure on which the lifeblood of an organization runs. Companies today are dependent on their networks to enable their core applications and business processes, and any network disruption has a profound impact on the financial health of the organization. Yet, despite the important role that networks serve, the realms of application development and network operations have traditionally been separate, disconnected domains. Developers usually build applications that run on servers, and network administrators maintain and configure the network that connects them, but rarely vice-versa. As a result, these two sets of professionals rarely have the opportunity to work together directly.
One of the surprising side effects of the movement to Service-Oriented Architecture (SOA), however, is that this natural separation between application development and network operations is breaking down. The reason for this unexpected trend is the rise of a new class of content-aware network devices frequently referred to as XML appliances. The story of how the rise of XML on the network leads to this new class of hardware, and how the presence of such devices leads to a change in how network operations and application development must work together is an interesting subplot in the larger story of SOA.
The Emergence of the Content and Application Aware Network Appliance
People that follow the network appliance markets realize that technology problems that might once have been the domain of software-only solutions rapidly moved to specialized hardware appliances when it became clear that users required high performance, low total cost of ownership, and ease of installation and maintenance in a single, low-cost product. Only specialized hardware form factors meet these simultaneous qualifications, and for good reason: the hardware form factor limits the amount of customization and “tinkering” that administrators can perform and allows for the inclusion of specialized chipsets and software optimizations for improved performance, while their packaging is readily adaptable by resellers and third-party channels that can reduce the cost to implementers.
However, traditional packet-based network appliances are ill-suited for handling the requirements of XML in general, and Web Services in particular. Most of today’s network equipment focuses on the lower layers of the Open System Interconnection (OSI) network stack. In these layers, network appliances focus on the source and destination of packets as they travel on the network, making routing, security, and performance optimization decisions solely on packet header information and the ports they are sent to on the network.
However, the packet and port model is too simplistic for dealing with XML-based content in general, and Web Services traffic in particular. Since most Web Services run over standard network protocols such as HTTP and HTTPS, looking at packets and ports is not sufficient to handle the needs of Web Services. Network appliances must be able to understand the message content itself that is traveling across the network. Instead of being simply network and IP-aware, these solutions must be content-aware. More specifically, they must be application-aware. They must inspect and parse XML-based traffic as it flows across the network and then perform some sort of activity on the traffic, as policies and application logic dictates. As such, the current incarnation of network appliance must offer a hybrid of the capabilities of traditional network infrastructure and policy-based, content-aware software applications.
The Changing Role of the Network Administrator
The changing role of the network appliance necessarily changes the role of the network administrator. Rather than simply maintaining the data center and being responsive to threats or performance issues as they crop up, the network administrator must now deal with application and Web Service management issues, including security and other policy considerations that apply to the Services that XML appliances interact with. This new level of responsibility for such operations personnel also means that they will become a key part of the enterprise architecture team in the Service-oriented environment, because such network appliances are an extension of the runtime application infrastructure.
As a part of the enterprise architecture team, the network administrator will be responsible for helping guide the development and implementation of applications with the same goals as other members of the team: increasing business agility and asset reuse in the face of IT heterogeneity. The only difference between the network administrator and software developers is that they provide solutions in the form of network appliance and topology enhancements and Service descriptions, rather than software-based solutions alone.
The Relationship between XML Appliances and SOA
The emergence of Web Services and SOAs that abstract the underlying implementation from consuming systems and provide location independence have increasingly spurred companies to realize that their network assets can and should be considered to be extensions of their previously software-only applications. Furthermore, existing software infrastructure, such as application servers, databases, and messaging middleware, are becoming increasingly burdened with security, reliability, and integration tasks that bog down the systems to the point that they spend precious little time on the business logic that the application developer created.
XML appliances are now addressing this burden, performing tasks that were formerly considered to be part of the software application universe. These new appliances are giving application developers programmatic control of the performance and operation of their network that they have never had before, as well as providing network administrators control over the most detailed parts of an application. As a result, as companies build SOAs, they are increasingly finding the need to incorporate the functionality of XML appliances into their application architecture, rather than just their network architecture.
One of the side effects of the movement to SOA is that the implementation of the Service is abstracted from the consumer of that Service. That means that a Service consumer, or a user for that matter, wouldn’t know whether their Service requests are being fulfilled by an application server, database, mainframe, human, or network appliance. As such, the formerly separate worlds of network administration and application development are increasingly becoming intertwined. Why should we restrict the ability of application developers to control software-only assets when hardware devices can easily expose their functionality as Services? Why should we restrict network administrators’ ability to secure and control hardware-only assets when they can likewise maintain software exposed as Services?
The ZapThink Take
By giving developers more power over network performance, and by giving network administrators more control over the applications that run on their networks, companies can expect to see significant impact on the efficiency and performance of their business. Rather than building overcapacity into their application server-based infrastructure simply to enable it to scale, companies will increasingly look to network appliances to offer some of the capabilities that they had previously relegated to software-only applications. In particular, companies will call upon such appliances to provide security, reliability, messaging, and some forms of integration that intermingle the notions of business logic with transport and message delivery.
Finally, the relationship between network administrators and application developers will no longer be separate. In a world where Services abstract the network as well as the application, network and software engineers must work together in the new corporate IT infrastructure that considers networks and applications within the context of SOA. Fundamentally, the technology shift is the easy part; changing how people work is the greater challenge facing IT organizations today, as they move to SOA.