As a Cisco team member, I’m convinced that the value of professional organizations cannot be understated. It’s understood that employees across various industries have a lot on their plate these days. Data centers, SDN’s or large solutions that help a manufacturing plant to become more “connected” are more than enough projects to keep us busy. However, employees often forget the value of professional organizations that are relevant within each industry. Whether an employee belongs to a professional organization or not, employees must realize the value that these organizations have: professional credibility, influence messaging on a ground level and increasing visibility for Cisco are some of the most important aspects that being involved with professional organizations can bring about.
Professional organizations are a place where I can network, learn and help deliver Cisco messaging as well as educate, engage and contact customers through community involvement. When I first joined Cisco 15 years ago, I regularly attended and presented at monthly users group meetings, but over the years, Cisco’s participation at these meetings has waned and appears to be trending down. Often, I think we take for granted the value of professional organizations, but they provide a standard for professional credibility and give Cisco a broader visibility. As a member of an industry professional organization, specifically the Institute of Electrical and Electronic Engineers (IEEE), I get tremendous value through education and networking. I know my colleague Rick Geiger, who is on the Gridwise Alliance Board of Directors, would agree. At the local and state level, large impacts are possible as professional association members are able to drive professional credibility, influence agendas and position topics to society members who work or interact with our customer base.
For example, several months ago I received a monthly newsletter promoting a seminar on Software Defined Networking (SDN). One line stated “Software Defined Networking has got Cisco shaking in their boots because it just might completely transform what types of equipment are needed to build a network. Do I have your attention now?” Needless to say, I registered and attended -- member discount to boot.
Education of members was the primary purpose of the seminar, meaning attendees expected the delivery of neutral, fair and technically accurate presentation on the future of software defined networks. As I saw it, the presentation on SDN was focused on a Google approach to SDN architecture for data centers, and included a good amount of Cisco bashing. Nonetheless, the seminar provided an opportunity to influence the messaging at ground level and the topics discussed seemed to be informative and beneficial for all those in attendance.
Influence Messaging and Topics at Ground Level
Understanding the messaging and positioning of the local technical mavens presents a golden opportunity to counter and influence at street level. The bottom line, secure all forums to get Cisco’s messaging to our end users. The IEEE meeting provided a good opportunity to secure a date and timeslot to present Cisco’s SDN and Application-Centric Infrastructure strategies as well as an opportunity to counter any negative perception the audience picked. As Mike Robinson, Practice Architect states:
“As a member of UTC’s Smart Network Council, I get to collaborate with leading utilities in the United States who are dealing with the industry’s pressing issues. This is hugely valuable. It offers a direct path to decision makers, a seat at the table as they develop their strategies, and it builds trust as a colleague (as opposed to coming across just as a vendor). Also, through UTC I get the opportunity to speak at conventions, periodic forums, and regional meetings.”
Broader Visibility for Cisco
Cisco will also have an opportunity to drive thought leadership to influencers -- Mavens and Sales specialists who will attend the upcoming session I secured. Account managers, engineers and other members of the sales team should make it a priority to get engaged with professional organizations, user groups and other community influencers.
Read More »
Tags: ACI, Manufacturing, SDN, software defined network
We are living in the age of the “supertasker.” At Cisco Live Cancun last week, I polled our audience and asked, “How many devices are you connected to at this moment?” The majority of the audience held three or four. However, some still had their hands up at five and six devices. Supertaskers are emerging as the next-generation workforce, integrating several new devices to increase their productivity—and they will not be the minority for long.
As the Internet of Everything (IoE) continues to evolve, we see increased momentum towards connecting the unconnected. The Fitbit, for example, reminds us that we need to achieve our daily step goal while maintaining our work-life balance. As more organizations digitize their business, we expect 50 billion objects to be connected to the Internet by 2020—and more and more of these devices will integrate into our ever-changing work lives. Read More »
Tags: CCWTR, cisco live, cloud, Fast IT, Internet of Everything, Joseph Bradley, software defined network
As the IETF (Internet Engineering Task Force) meets in Hawaii (IETF 91), the unavoidable question for both participants and observers is whether a Standards Development Organization (SDO) like the IETF is relevant in a rapidly expanding environment of Open Source Software (OSS) projects.
For those new to the conversation, the open question is NOT whether SDOs should exist. They are a political reality inexorably tied to trade policies and international relationships. The fundamental reason behind their existence is to avoid a communications Tower of Babel (with the resulting economic consequences) and establish governance over the use of global commercial and information infrastructure (not just acceptable behavior, but the management of resources like addressing as well). Rather, the question is about their role going forward in enabling innovation.
SDOs (like the IETF) have to evolve their processes Read More »
Tags: API, carrier ethernet, ietf, network function virtualization, Open Loop, open source, Open Stack, open standards, OSS, SDN NFV, SDO, service providers, software defined network, yang
Tighter Planning Cycles for Greater Efficiency with the Evolved Services Platform
In the global geography of telecom, wide-area networks (WAN) are oceans of uncertainty. Resource-constrained and multivendor, WANs produce delays and outages in far-flung and sometimes remote areas, posing a special set of issues that are distinct from those we see in data centers and access networks.
WAN bandwidth is the most expensive bandwidth in the network and failure impacts are large. WANs bear the brunt of traffic growth with a very tricky calculus: underbuild your WAN and jeopardize your brand, but overbuild it and spend your way into oblivion.
Greater Predictability through Ever-Shortening Planning Cycles
To keep pace with these conundrums, you need sophisticated modeling and planning tools, which naturally evolved—in the case of the WAN Automation Engine (WAE)—into an ever-tightening loop of planning, building, and measuring, eventually encompassing SDN.
Longer planning cycles inevitably means over-engineering, over-building and over-hiring. With the Evolved Services Platform’s (ESP) Orchestration Engine, Cisco is shrinking these cycles, and thus reducing the uncertainties that lead to inefficiencies.
Last week I discussed the Orchestration Engine of the ESP in terms of how different components fit in individual domains. Let’s see how to use this framework to plan, engineer, and ultimately automate the WAN to make it cloud-ready.
As the Process Becomes More Automated, a Shrinking Planning Cycle Brings Huge Efficiencies.
The cycle progressively shortens, from years to months, and eventually (with automated, programmable networking) to continuous changes. As this process moves from manual to automated, the network becomes more predictable.
But Why is this Happening Now? Read More »
Tags: esp, evolved services platform, SDN, Service Provider, software defined network, WAN, wide-area networks
Software-based techniques are transforming networking. Commercial off-the-shelf hardware is finding a place in several networking use cases. However, high-performance hardware is also an important part of a successful software-defined networking (SDN). As you optimize your networks using SDN tools and complementary technologies such as network function virtualization (NFV), an important step is to strategically assess your hardware needs based on the functions and performance requirements. These need to be aligned with your intended business outcome for individual applications and services.
Two Categories of High Performance Hardware
- Network hardware that utilizes purpose-built designs. These often involve specialized Application-Specific Integrated Circuit (ASIC)s to achieve significantly higher performance than what is possible or economically feasible using commercial off-the-shelf servers that are based on state of the art, x86-based, general purpose processors.
- Network hardware that uses standard x86 servers that is enhanced to provide high performance and predictable operation for example, via special software techniques that bypass hypervisors, virtualization environments, and operating systems.
Where to Deploy Network Functions
Can virtualized network functions be deployed like cloud-based applications? No. There is a big difference between deploying network functions as software modules on x86 general purpose servers and using a common cloud computing model to implement network virtualization. Simply migrating existing network functions to general purpose servers without due regard to all the network requirements leads to dramatically uneven and unpredictable performance. This unpredictability is mainly due to data plane workloads being often I/O bound and/or memory bound and software layers containing important configuration details that may impact performance.
These issues are not specifically about hardware but how the software handles the whole environment. Operating systems, hypervisors, and other infrastructure that is not integrated into best practices for data plane applications will continue to contribute to unpredictable performance.
Bandwidth and CPU Needs
A good way to begin to assess hardware requirements is to examine network functions in two dimensions: I/O bandwidth or throughput needs, and computational power needs. In considering which network function to virtualize and where to virtualize it, CPU load required and bandwidth load required throughout different layers of the network can help determine that some but not all network functions are suitable for virtualization.
Applications with lower I/O bandwidth and low-to-high CPU requirements may be most appropriate for virtualized deployment on optimized x86 servers. Applications with higher I/O bandwidth and low-to-high CPU requirements may be best deployed on specialized high-performance hardware with specialized silicon. Many other factors may play a role in determining what hardware to use for which applications, including cost, user experience, latency, networking performance, network predictability, and architectural preferences.
Service-Network Abstraction is Key
Additionally, you might not need high performance hardware for certain functions initially. But as such a particular function scales, it might require a high performance platform to meet its performance specifications, or it might be more economical on a purpose-built platform. So you might start out with commercial off-the-shelf hardware and then transfer the workload to the high performance hardware later. If you have focused on establishing a clean abstraction of the services from the underlying hardware infrastructure using SDN principles, the network deployment can be more easily changed or evolved independently of the upper services and applications. This is the true promise of SDN.
Read more about how to assess hardware performance requirements in your SDN in the Cisco® white paper “High-Performance Hardware: Enhance Its Use in Software-Defined Networking.” You can find it here: “Do You Know your Hardware Needs?” along with other useful information.
Do you have questions or comments? Tweet us at @CiscoSP360
Tags: abstraction, ASIC, cpu, High Performance Hardware, network function virtualization, Networking Performance, SDN, software defined network, VNF