Last month in my blog Journey to “Self-Healing” Enterprise Networks, we discussed reasons why IT process automation solutions for network domain has not fulfilled its promise. Today we will first reason of the two – “Need for out-of-the-box workflow templates for rapid development of network operation process automation for quick-wins”.
In today’s high performance distributed environment, network is vital to maintaining an efficient business. Efficient, scalable and stable network environment requires time and resources from the organization. Information Technology (IT) environments encompass multiple advanced network technologies that include security and wireless for borderless networks, video systems for unified communications, and storage and virtualization management for flexible deployments.
Within IT & Network Process Operations community, automation started with the big hype and promise for “self-healing” solutions for systems, network, and process automation. Remember the promise of “Robotics”!? Wouldn’t it be great to have our servers, systems, and networks solve their own problems? Leading to more stable systems and networks in which system administrators and network administrators would be free to work on higher priority activities and be more productive, improving the quality of Enterprise solutions. Though it is a noble goal, IT and network process automation did not deliver its full promise but instead started us in the journey towards the goal.
There are many reasons why IT process automation solutions for network domain has not fulfilled its promise. Many people have done in-depth analysis, which can be summarized as two big inhibitors for wide-spread adoption of automation in network operations:
Need for out-of-the-box workflow templates for rapid development of network operation process automation for quick-wins
In-depth understanding of complex network implementations with domain knowledge of the Enterprise processes and industry best-practices for support
In my blog last week I introduced a series of conversations in which Mike Spanbauer, Industry analyst at Current Analysis, Cisco Executives, Jim McHugh and Brian Schwarz discussed several topics. One of the topics they discussed was the adoption of Cloud technologies by Enterprises.
If you are interested in another analyst perspective, tune in to a webcast on December 6, at 9:00 am PST , to hear from James Staten of Forrester Research on their findings and analysis of the Cloud computing frontier.
Recognizing that Cloud computing is an important trend, I wanted to see how Cisco and Cisco UCS in particular facilitate a customer’s Journey to the Cloud. First, I noticed that InformationWeek recognized Cisco CTO Lew Tucker as a pioneer in Cloud computing. Second, I found a document by Cisco partner GTSI on the Cloud Maturity model which looks like a roadmap. The Journey included Consolidation, Virtualization and Automation – three things the Cisco UCS excels at.
Consolidation -- The converged server and network access architecture of the UCS promotes consolidation of resources. The notion of server pools and network port channels allows furthers consolidation and better utilization of the resources. The ability to run a large number of virtual machines on the same server as a result of superior performance enables consolidation of workloads on the same physical infrastructure. Read More »
No software is immune to security vulnerabilities. The time between the discovery and disclosure of security vulnerabilities and the availability of an exploit is getting shorter. This imposes pressures on network security professionals and information technology (IT) managers to quickly respond to security vulnerabilities or apply mitigation in their network. Many organizations are struggling to keep up-to-date with the constant release of new vulnerabilities and software fixes. At the same time, they are under pressure to provide near 100% availability of key business services and systems.
As an example, every time Cisco discloses a security vulnerability for Cisco IOS Software (or any given product), network security administrators have to identify affected devices and (in numerous cases) upgrade such devices. These activities can take hours, days, or even weeks depending on the size of the organization. For instance large enterprises and organizations may have thousands of routers and switches that need to be assessed for the impact of any given vulnerability.
If I have said it once, I have said it at least a thousand times. No figure of speech here, completely one hundred percent literal. What have I said? “If you can do it in UCS Manager GUI, you can do it in UCS Manager API!” Whatever “it” is.
When do I say this? Whenever I talk about the UCS Manager to customers or coworkers, there is almost always the question, “Can this be done via the API?” To which I always reply “If you can do it in the GUI you can do it in the API.” Not sure if that is grammatically correct, but my point is made. That is the power and the ease of the UCS XML API.
The UCS Manager graphical interface is built on the XML API. When developing a script and you’re not sure how to do the action, what the call is, what the correct parameters are, etc… Just look at how the UCS Manager does it and you’re good. How do you look at how UCS Manager does it? Use Wireshark or some other packet capture tool and see what’s going on, what is getting passed from the UCS Manager client to UCS Manager. Done, no secrets, no convolution, no obfuscation.