Customers frequently comment that IT simply isn’t keeping pace with their needs. Provisioning new data center resources can take weeks. To be fair, IT professionals are doing the best they can but manual processes and organizational silos can make the process equivalent to trying to play a symphony without a conductor.
Cisco UCS Director’s advanced automation acts as the orchestra conductor for your data center. Your data center is the power source of your business — if it is slow, your business is slow. Cisco UCS Director’s advanced automation is exactly what you need to deliver speed and efficiency allowing IT to move in concert with your business. Read More »
Cisco has a broad spectrum of customers across a wide range of markets and geographies. These customers have a diverse set of requirements, operational models and use cases, meaning that a one size fits all SDN strategy does not fit all our customers. As a result, we made a series of announcements earlier this summer (at Cisco Live San Diego) that continued to showcase how our SDN strategy provides customers with a high degree of choice and flexibility. This blog will review key elements of the strategy, as well as provide a bit of background and context around them.
Cisco’s SDN strategy for the Data Center is built on 3 key pillars:
Application Centric Infrastructure (ACI)
This approach enables our customers to choose the implementation option that best meets their IT and business goals by extending the benefits of programmability and automation across the entire Nexus switching portfolio. Let’s consider each of these pillars.
A lot has been said and written about ACI already, so I’ll keep this section on ACI brief. ACI is Cisco’s flagship SDN offering. It offers the most comprehensive SDN solution in the industry. Based on an application centric policy model, ACI provides automated, integrated provisioning of both underlay and overlay networks, L4-7 services provisioning across a broad set of ecosystem partners, and extensive telemetry for application level health monitoring. These comprehensive capabilities deliver a solution that is agile, open, and secure, offering customers benefits no other SDN solution can.
I know the paragraph above was a bit of a mouthful. For a quick snapshot of what that all translates to in terms of actually helping a customer, check out this report from IDC. If you want to learn more about ACI, go here.
This pillar is all about providing scale and simplicity to VXLAN Overlays. Beyond that, it provides a clear path forward for the overall Nexus portfolio to participate in and derive the benefits of SDN.
VXLAN has gained huge momentum across the industry for a wide variety of reasons that, in many cases, involve improvements over traditional technologies such as VLANs and Spanning Tree. These involve attributes such as more efficient bandwidth use via Equal Cost Multi Pathing (ECMP), higher theoretical scalability with 16 million segments, and more flexibility through use of an overlay model upon which multi tenant cloud networks can be built. As momentum for VXLAN networks grows, so does the demand for 2 key things:
A standards based approach to scale out VXLANs, and
Simplified provisioning and management of them.
Regarding a standards based approach to scale out VXLANs, Cisco is now supporting “Multipoint BGP EVPN Control Plane” on Nexus switches. Why does this matter? Well, the original VXLAN spec (RFC 7348) relied on a multicast based flood-and-learn mechanism without a control plane for certain key functions (e.g. VTEP peer discovery and remote end host reachability). This is a suboptimal approach. To overcome the limitations inherent with this approach, the IETF developed MP BGP EVPN Control Plane as a standards-based control plane for VXLAN overlays. This reduces traffic flooding on the overlay network, yielding a more efficient and more scalable approach.
As far as the second item, simplified provisioning and management, Cisco announced an overlay management and provisioning system. This new solution, called Virtual Topology System (VTS), automates provisioning of the overlay network, so as to enhance the deployment of cloud based services. Through an automated overlay provisioning model and tight integration with 3rd party orchestration tools such as OpenStack and VMWare VCenter, VTS simplifies overlay provisioning and management for both physical and virtual workloads by eliminating manually intensive network configuration tasks. These whiteboard sessions provide an overview and also a bit more technical detail, if you’re interested.
Infrastructure programmability is a big deal because it drives automation, which drives speed, which is an obvious prerequisite for the success of just about any business dealing with digital disruption. As programmability evolves, Cisco continues to roll out more and more capabilities across the Nexus portfolio. We have a broad range of features in this space including things such as Programmable Open APIs, integration with 3rd party DevOps and Automation tools, Custom App Development, and Bash shell commands. This set of capabilities within NX-OS facilitates the concept of the Programmable Network pillar. Let’s consider how this may be useful for you.
A while ago, a small number of customers with very large networks started shifting the way they operated. Their networks were growing very large because (not too surprisingly) the number of users, thus servers, was growing very large. As the number of servers grew larger and faster, they realized they had a choice:
Hire a zillion new sys admins, or
Brutally overwork their existing sys admins, or
Deploy and manage servers in new and different ways.
The last option won out (in many cases, anyhow), and the revelation was automation. That is, tools that automated server deployment and management helped these sys admins and their employer’s scale the business. In the process, they paid close attention to metrics like the number of servers a given admin was managing. These “device to admin” ratios went up a lot…like in some cases orders of magnitude. With automation tools and other changes (to culture, process, etc.), some companies saw admins managing not 10’s or 100’s of servers, but 1000’s of servers. They also started experimenting with and employing DevOps – a term that at this point has a multitude of meanings, but is defined here in simple English.
As these elements have converged, people across different silos have started to collaborate a bit more, and as a result, tips, tricks and tools have started to spill across the silos. So, for example, as sys admins saw efficiency gains from using tools like Puppet and Chef to automate tasks on their servers, there was a desire to use the same tools on networks. In other cases, someone who was comfortable with Linux and wanted to work from a Bash shell wanted to use those commands for configuration and troubleshooting on the network as well as servers. Others wanted APIs that would allow extraction of all sorts of arcane box info to be massaged and acted upon by scripts and other tools.
Essentially, there was a need for more elements of the box to be more accessible and programmable in a wide variety of ways. It’s worth noting that although these trends started with a small subset of customers, many of the elements are working their way out to a much broader, more diverse cross section of customers. As this evolution has occurred, Cisco has been adding more programmability to the Nexus switches. This paper provides a more detailed view of various use cases and the functionality Nexus provides.
In summary, these 3 pillars of ACI, Programmable Fabric and Programmable Network provide a wide range of capabilities to help our customers across the broad spectrum of challenges they have. In the coming weeks and months, we’ll provide more information – here, as well as other venues – to help you better understand the strategy and its components. If this blog was too geeky and you’re looking for upleveled info, we’ll have that. If this was too fluffy, and you want more technical depth, we’ll have that as well. To punctuate this point, I’ll be hosting a webinar on September 15 that will cover the above in more detail. You can register here.
Making the Right Connections Opens New Doors to Digital Business Success
The digital transformation of business isn’t just about the connection of things, though those connections are certainly important. Industrial or IT automation can take many forms, whether it’s connections between people, the connections between people and things or, perhaps most importantly, the processes that that enable connections of all kinds to happen quickly and intelligently. Without order, digital business transformation runs the risk of becoming digital chaos. What’s most essential in every case is creating the desired business outcome.
Hyper-Distribution: Billions of Connections Shouldn’t Mean Billions of Headaches
But connecting all these things isn’t easy. 50 billion things are projected to be connected to the Internet by 2020. Along with this hyper-distribution of things also comes the hyper-distribution of data. No longer is data only found in large centralized warehouses – it is being dynamically captured and acted upon at the edge of the network to respond to events in real time.
Organizations are struggling with the management of business processes in this expanding, hyperconnected world. Value chains are increasingly global, yet the decisions that need to be made are becoming increasingly local — and they need to be made in real-time. Hyper-distribution is fragmenting traditional business processes. Dealing with this growing complexity was identified as the number one IoT management challenge in a 2014 business study.
Not surprisingly, companies are being forced to re-imagine their processes and many are turning to software to turn what is being imagined into business reality. And they are calling upon new forms of automation and analytics to do it. Real business transformation will only occur when things connect with both people and process to turn information into actionable intelligence. Automation facilitates the new connections. Analysis gives the connections new meaning. Da Vinci instructs us, “Simplicity is the ultimate sophistication.” Finding ways to make the increasingly complex world of hyperconnectivity both simple to understand and simple to implement is the ultimate challenge for the networking industry.
What do I mean by hyper-distributed business process? Let’s take a look Read More »
Companies are embracing software defined networking (SDN) and DevOps practices to deploy network changes repeatedly and consistently. Customers who run mega scale data centers like Web2.0/OTT and fortune 100 are looking to do more with less, increase “device:admin” ratio and agility, and respond faster to business needs in a world where continuous application update grows by the hour without breaking infrastructure operation.
Using Puppet Enterprise, you can not only realize those SDN benefits, but you also extend DevOps practices to network administration across mega scale data centers, commercial and large enterprises by defining your desired network configuration with infrastructure as code. Using infrastructure as code enables cross-team change collaboration, automated infrastructure testing, and automated application deployments that span compute, storage, and network.
Let’s face it. Danger lurks inside every enterprise network, and when it hits, addressing the crisis with manual processes that are inefficient and error-prone can take days – or even weeks – to resolve. If you’ve ever been in a situation like this, minutes can seem like hours. You’re aware that not only is fast problem resolution critical, but that the displaced effort and incremental time incurred by you or your staff in resolving the issue is detrimental as well. Crisis preparation can help. But fire drills often don’t compare to the real thing. To avoid constantly reacting to problems, many enterprises are harnessing automation to gain greater visibility into their network infrastructure to proactively manage and defeat danger before it occurs.