With Interop less than three weeks away, we are excited to learn that Cisco APIC, the SDN controller for our Application Centric Infrastructure (ACI) fabric, has been selected as Best of Interop 2015 Finalists in Software Defined Networking (SDN) category. As you may recall, when we announced ACI back in Nov 2013, we mentioned that APIC would be the software controller for the application-centric policy model, and would be available in Q3, CY 2014. In a short span of less than a year, APIC has gained broad industry adoption with more than 300 Customers either deploying or in production already.
Interop Vegas, is a great venue to unveil more aspects of the ACI fabric, the policy model, and key APIC features. If you aren’t going to be in Las Vegas the last week of April, now may be the time to start making plans as we gear up for some exciting ACI news and events, and hopefully bringing home this Best of Interop award.
But wait, there’s more…
If you are not familiar with ACI or APIC yet, let me take the opportunity to tell you about APIC and why I think it is a finalist for the Best of Interop.
The Cisco APIC is the unified point of automation and management for the ACI fabric and health monitoring. The Cisco APIC is built with open APIs and an open application-centric policy model designed to simplify the provisioning, monitoring, and management of applications across the data center. Cisco’s Application Centric Infrastructure (ACI) is a fabric architecture with centralized automation and policy-driven application profiles designed to make the infrastructure highly responsive to the needs of applications, while significantly simplifying the data center and cloud operational model.
The Cisco APIC is built on the SDN principles of an extensible/programmable centralized controller, standardized north-bound API’s, a protocol for communicating with and orchestrating data center devices and network nodes, and features and agents within the network infrastructure to support the controller’s policy model and respond appropriately.
The Cisco APIC uses an application-centric policy model rather than network-centric SDN policies that do not adequately reflect business requirements. Cisco ACI is an open ecosystem of management, services, and security partners that incorporate best-of-breed solutions across physical and virtual infrastructures. Customers have a choice of flexible workflow automation and orchestration solutions on top of APIC and the ACI fabric, including OpenStack, VMware cloud automation solutions, Microsoft System Center, Cisco UCS Director, and more, rather than being locked into a specific automation model.
The APIC software is delivered on turn-key UCS C-Series server appliances, so the user out-of-box experience is simple.
Apparently these stellar traits weren’t lost on the Best of Interop judges as it made it to Finalist status. We sincerely hope this bad boy brings home the prize too – stay tuned for more excitement to come.
Tags: Best of Interop 2015, Cisco ACI, Cisco APIC, policy, SDN, SDN controller
Earlier this month, I attended the first ever summit on OpenDaylight (ODL) project in Santa Clara, CA. This near sold out event was largely successful by many standards. It brought together a large number of great minds to the table to solve some of the toughest challenges the networking industry is facing around Software-defined Networking (SDN) and Network Function Virtualization (NFV). The group announced a first major step forward with the first open source software release called Hydrogen. The bulk of the credit goes to 154 contributors from Cisco, IBM, Ericsson, Red Hat, Citrix and others who wrote over a million lines of code in past ten months to make this happen.
The two-day summit was packed with a variety of sessions that were geared towards a diverse set of audience. The sessions varied from general topics to specific topics such as relevance of Open source software, NFV, LISP, standards, discussions on North and South bound APIs, developer tutorials for building applications & tool chain, using OpenStack with ODL, analytics, test automation, and a true story of SDN in production environment.
Of all these topics, here are the three important themes that stood out to me –
1. The importance of an Open Source, community initiative for SDN
The concept of Open Source software has been around since decades. It is fast catching up in the non-traditional realms of computer networking. For some, the concept of open source equates to free software. While this is partially true, I strongly believe that open=free is a misnomer. I have started to realize that open source and further, the collaborative initiatives like ODL is far beyond the notion of freeness. In my view, the most important thing that such an initiative does is to gather right minds to bring out bright ideas. The collective wisdom that emanates from such a collaborative initiative helps vendors develop a cohesive set of products that speaks a common language, and perhaps share certain fundamental design constructs to aid interoperability. At the same time, I believe that this collaboration helps to compress the infinite ways vendors can built products to a bounded, agreed upon set of behaviors and interfaces. Customers are real beneficiaries of such an open initiative due to this standardization and better product interoperability. As Vijay Pandey from IBM aptly said in one of his presentations, open source initiatives like ODL “promote innovation and raise the value bar.”
Cisco firmly believes in and supports such open source initiatives. Cisco is a platinum member of ODL project, as well as a Gold member of OpenStack Foundation. You can find more information about OpenStack at Cisco , and a rich set of Cisco Services to help you exploit and adopt OpenStack.
2. What and how much to Standardize (North and South bound APIs)
In the summit, there were several interesting debates on what to standardize and how much. With regards to how much, I am with Guru Parulkar’s mantra to “standardize as little as possible.”
One of the core capabilities that SDN brings to the table is the notion around exposing interfaces from control plane to the infrastructure layer (South Bound APIs or SBI) and to the application/business layer (North bound APIs or NBI). We talked about using common approach for design constructs above, and the APIs are central to the constructs. However, if we (are somehow able to) standardize every hook into the system, we are forcing the industry to take a “single” approach to solve the underlying problems. Additionally, I believe that such an approach will not only go against the very notion of openness, but will also hinder innovation and ability to provide unique experiences.
If we talk about SBI, we rightly need some standardized ways to abstract some of the infrastructure complexities. I learnt that ODL will include support for SDN open standards such as OpenFlow, VxLAN, PCEP etc. Similar to SBI, can we standardize the NBI’s as well?
Read More »
Tags: adoption challenges, APIs, Cisco, Cisco Services, consultative led, opendaylight, OpenStack, SDN, SDN controller
The London Eye
Last week I started my SDN reflections on the London Gartner Data Center Conference, and I found I had quite a lot to discuss.
Last week I covered:
- Do we need SDN?
- SDN and the Gartner Hype Cycle
- SDN Deployment Models
So here is the concluding part. This week I’ll cover:
- Overlay-Based SDN — and the questionable assumptions being made by others in this area (good for Gartner for calling these out!)
- The SDN Vendor Explosion Challenge,
- The “Unspoken Costs” of SDN Deployment, and
- The “How” of SDN is still missing.
I hope you find this useful and informative and as always, feel free to debate with me around my observations!
Read More »
Tags: architectural approach, Cisco ONE, Cisco onePK, Cisco Services, SDN controller, software defined network
In my first SDN blog, I asserted that “Services” – that is technical support, professional and consultancy services – are the missing “S” in the SDN debate. I’d now like to apply our Cisco Domain TenSM framework “in anger” to examine in more detail the impacts that SDN may have on your IT services and operations. While come of our competitors will only talk about the network switches and new device protocols, l’ll show how it’s not just the network switches that you should be concerned with: your SDN and Cisco ONE journey could involve impacts across multiple “domains”.
As I bogged about Cisco Domain Ten this past year, I’ve positioned it as a mechanism to help you on your data center journey. Let me now extend that use – SDN after all is more than just a data center technology play. My experience with Cisco Domain Ten over the past year has helped me realize that it is, in fact, an excellent framework for considering impacts to more general IT services, and not just to the data center . I’ll also illustrate my case with both service provider and enterprise/business/public sector examples.
The following diagram summarizes the areas impacted – let’s discuss each one.
SDN Impacts – via Cisco Domain Ten
Read More »
Tags: architecture, Cisco Domain Ten, Cisco ONE, Cisco onePK, cisco_services, data center, SDN, SDN controller, software defined network
In my previous 3-part blog series I discussed the challenges in the Enterprise WAN and relevancy of SDN in overcoming these challenges and how Cisco ONE Enterprise Networks Architecture addresses these WAN challenges. In this blog post I will discuss how Cisco ONE (Open Network Environment) and ONE Enterprise Networks Architecture fit together. In a following blog, I will discuss how Cisco ONE Enterprise Networks Architecture provides six significant benefits to enterprises through programmability. ONE + ONE = 6 is the new math for Enterprise programmability!
Cisco ONE (Open Network Environment)
Cisco ONE is a comprehensive, Cisco wide solution (not just data center) approach to making networks more open, programmable, and application-aware. There are numerous blogs, and videos about Cisco ONE that can be found here. As a brief summary, Cisco ONE comprises of 3 pillars that provide a programmable approach to both physical and virtual infrastructure: Read More »
Tags: architecture, Cisco ONE, Cisco ONE Enterprise Networks Architecture, enterprise networks, open APIs, Open Networking, programmability, SDN, SDN controller