Enterprise Application Integration (EAI). This little three-letter acronym is a four letter word in app dev, with good reason. For countless years, app integration has entailed bulky middleware, a variety of complex protocols such as simple object access protocol (SOAP), common object request broker architecture (CORBA), and Java database connectivity API (JDBC), and required legions of experts whose hands shake as much from the gallons of coffee they consume to make it through a single project and from the desire to strangle the enterprise architects behind the requirements.

Whether we call it software-defined or cloud, the reality is that modern network architectures endeavoring to provide a more “self-service” model require not only system automation, but workflow automation (orchestration). And orchestration ultimately requires integration, because workflows involve provisioning and configuration of multiple systems.

Those who embrace the concept and embark on a journey to automate network systems, quickly discover the truth that has been written on the weary faces of app integration experts for decades: integration is hard. Not just to implement, but to maintain and to operate without disruption on a daily basis.

This is because integration is basically tying together a rope, a chain, and a shoelace so you can shimmy across a chasm. Each system has its own unique data model, its own API, and in the world of network infrastructure, may be using SOAP, representation state transfer (REST), or nothing at all. Even the simplest of network orchestration efforts often require engineers (network engineers, not software engineers, mind you) to be able to piece together a system that connects and interacts with all these technologies, and applications to boot. See, ticketing systems (think Remedy) are often included as part of the overall orchestration. Because, it’s a process, and the process of requesting a service begins with a ticket. A request is entered into an application, which creates a ticket that subsequently kicks off a series of actions that automatically carries out the request.

The benefits of embarking on such projects are measurable; they are tangible. A customer recently related just how measurable when he justified the month-long project to automate just a few services, noting that their team was seeing 100 access requests a week. Each request required 1-2 hours to complete, for a grand total of 100-200 hours a week. Simply approving such trivial changes placed significant burden on their change control board and held up other important work. With no budget to hire additional engineers, they turned to automation. What used to take hours now takes minutes, or less. That freed up the engineers for other tasks, which made other things go faster. In effect, automating even a few, small tasks had a ripple effect in improving the overall responsiveness of IT. Because DevOps in the network is more about scaling operations than it is changing configurations fifteen times a day.

In the process, these network engineers have discovered what app dev has always known: integration is hard, testing is critical, and being a polyglot is a requirement. They’re using Eclipse, and Git. They’re discovering JIRA. They can tell you the difference between REST and SOAP, and that logging is more important than you think. They’re critically analyzing and cursing the APIs of providers and turning to communities for tips, tricks, and assistance.

They are integrating infrastructure, and they’re acutely aware of just how fragile the resulting systems are. Because networks weren’t built from the ground up with the intention of being integrated and automated. Cloud providers have a significant advantage in this because they knew they were going to abstract and automate the heck out of their systems. Knowing that, they could invest in hardware and systems with an eye toward how it would support integration. Heterogeneity is highly undesirable for such systems, and yet that is exactly what the enterprise has to deal with when they move to automate their systems. One system uses REST, the other SOAP, one JavaScript object notation (JSON), one extensible markup language (XML). One is so old it doesn’t have an API, but it’s critical, so screen scraping and parsing is the order of the day.

This is why “DevOps” and its view of “infrastructure as code” is becoming an increasingly important part of automating the data center. Because it’s not just about being faster, it’s about developing the discipline needed to maintain, not only individual components (automation), but the overall integration required to make it all flow seamlessly (orchestration). It requires code reviews, testing, logging, and version control. It requires attention to ‘release’ schedules of the increasingly critical systems that automate and orchestrate network tasks. Because breaking one now means requests are going to pile up and cause a traffic jam.

Network automation requires as much attention to the discipline of application development as it does to understanding the network.

Software is eating IT, or at least beginning to. And that means “the network”, too. DevOps is as much a philosophy that produces consistent, predictable, and repeatable processes as it can be velocity of deployment. If you’re going to rely on code (software) to execute critical processes related to the deployment of network services, you can’t ignore the perhaps less glamorous aspects of code – testing, maintenance, and review of the code you’re creating to integrate infrastructure, and ultimately automate the data center.