Nontraditional network integrations
Nontraditional network integrations
Join the DZone community and get the full member experience.Join For Free
If you listen to the chatter around the network industry, you are starting to see a lot more discussion about integration. While particularly clueful individuals have been hip to the fact for awhile, it seems the industry at large is just awakening to the idea that the network does not exist in isolation. Put differently, the idea that the network can be oblivious to everything around it (and they to the network) is losing steam as orchestration frameworks like OpenStack take deeper root.
Having glue between the major infrastructure components is critical to having seamless operation across all the resources required to satisfy an application or tenant workload. But there is additional (potentially greater!) advantage to be had by performing some less traditional integrations.
Where do integrations matter?
There are two primary reasons to have integrated infrastructure: to cut down on time and to cut down on mistakes. Integration is almost always in support of automation. Depending on the exact integration, that automation is in support of making things faster and cheaper, or in making things less prone to Layer 8 issues.
The point here is that integration is rarely done just for the sake of integration. Companies need to be explicit about why they want something integrated. Failing a well-articulated objective, it’s difficult to justify the work required to integrate and to keep integrated.
Cutting down on time
For systems that work in concert but that do not communicate directly, integration provides a means of reliably sharing context. That context is typically some bit of information useful in tuning one or the other pieces of infrastructure. In the absence of an integration between the two, context sharing is a manual process that requires human intervention. And of course, any human interaction has some associated effort and cost.
The cost of this transfer of information is highest when the boundary between two systems is also the boundary between two organizations. That is to say that when multiple people are required to share context, the effort is higher. It requires some coordination of individuals. In the simplest of cases, there is some delay as people take time to get to their emails or process workflows. In more complex cases, organizations have to reconcile priorities, which is a whole other beast entirely.
And when that context requires iterations through some frame of reference (the bouncing back and forth as individuals troubleshoot something, for example), the delays are cumulative.
Cutting down on mistakes
The same logic holds largely true for using integration as a means of reducing errors. If the introduction of a human into the process creates opportunity for failure, the introduction of more than one human will increase the chances that something goes wrong. Statistically, the likelihood of a miscue in context transfer will increase linearly with the number of times information passes between systems via human interaction.
But give me an example!
Imagine Becky is a Vice President in the accounting division of a large company. She tries to dial into a conference call from her desktop, but realizes as she picks up the handset that the phone is not functional. Though not a skilled technician, she knows to check Layer 1 first. But alas, the handset is plugged into the phone, and the phone is plugged into the wall. So Becky grabs her cell phone and calls IT.
The help desk person runs through her script and realizes that the issue is nothing that can be solved by rebooting something, so she escalates to the VOIP team. The voice engineer gets on the phone and asks Becky for some information. She is frustrated and retorts with something along the lines of “Well, you’re the IT person. You figure it out.”
Is the problem the phone? Is it the network? Is it the PBX? Each system has a different set of people. What the IT person wants is to query the entire set of end-to-end infrastructure and say “Tell me everything you know about Becky’s phone.” To do that today requires querying each individual piece of equipment.
Integration can help
In this case, integration is more than just having the individual elements talk to each other. The real objective is to have them all talk to an external system from which a health check can be performed. For example, integrating everything with a persistent chat client like HipChat could allow the IT person to use HipChat to query all infrastructure for everything related to the particular MAC address associated with Becky’s phone.
While the individual might be well-versed in only one type of infrastructure, the ability to get a health check across all related systems allows progress to be made without calling someone and waiting for them to perform their own contextual check before reporting back information.
The network and CRM?!
Imagine a cloud service provider that has a team of salespeople actively peddling services. Joe is an all-star sales guy who prides himself on exceeding expectations. He has a customer who has an immediate need to secure additional resources in a hosting facility. Joe gets the order into Salesforce and issues an invoice.
The customer receives the invoice, docusigns, and closes the loop. In most environments, the CRM is completely separate from the underlying infrastructure. The only way to convert the sales order into a service is to manually open a ticket, wait for it to be triaged, and then negotiate with the network team to provision the VLAN.
What if integration between the CRM tool and the network allowed VLANs to be provisioned based on business processes? For people on the networking side, the idea of other systems initiating changes might be a bridge too far. So what if a change on the CRM side could initiate recommended configuration that could be reviewed and deployed?
The bottom line
Integration goes well beyond OpenStack and DevOps. While those are also extremely useful, there are gains to be had by looking at nontraditional integration targets. To sniff out the opportunities, companies need to understand where in their business processes things get stalled or mistakes get introduced. From there, they can make intelligent decisions about what integration might look like. And ultimately the opportunity for streamlined operations ought to inform architectural decisions at every point along the way. Who knows, it might be useful to have your devices posting logs to Twitter (or maybe just a Slack war room) when things go awry.
Published at DZone with permission of Mike Bushong , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.