As spring turns to summer, just 6 months from when Cisco announced its vision of Application Centric Infrastructure, the momentum has started to pick up on all fronts – solution availability, technology integration with partners, channel awareness and most importantly strong customer traction. It is worthwhile to look at the trajectory thus far –
Nexus 9000 shipping with strong customer traction, awards and records
70+ active ACI trials with customers and channel partners
ACI ecosystem – 33 ecosystem partners leveraging the open approach and the policy model
1000+ customers in pipeline
175+ customers across major SPs, Enterprise and Commercial with several production deployments
With the APIC ready to ship this summer and become generally available, it is very exciting to see the positive feedback coming in especially from customers and partners that are deploying the Nexus 9000 as also those participating in the ACI trials with the Application Policy Infrastructure Controller (APIC).
Hear directly from our major partners in this short video montage
Today we continued the momentum with new “ACI-ready” Nexus 9300 Top of Rack switches (9336PQ and 9396TX) both of which can ease into traditional 3-Tier deployments or ACI deployments moving forward. A new line card was also made available for the Nexus 9500 to function as an ACI ready spine. In addition, there were several other innovations across the Nexus portfolio, including a new Nexus 6004X switch, VXLAN support made available across the entire portfolio as well as enhanced programmability and SDN/automation capabilities on the Nexus 7000 series switches.
Cisco IT is early in the journey to deploying an application centric infrastructure (ACI). This journey requires us to look at the IT organization differently. When we started evaluating what it would take to align applications to the network, we quickly realized that our organizational structure wasn’t favorable to extracting the most value from ACI. We needed an architecture team that represents all seven layers of the OSI stack, and works in sync to create tenets and policies and classify applications that conform with how we ultimately want to build out the fabric. ACI requires a completely different view of the relationship (along with a common syntax and language) between IT infrastructure and applications.
There has been a lot of recent online discussion about automation of the datacenter network, how we all may (or may not) need to learn programming, the value of a CCIE, and similar topics. This blog tries to look beyond all that. Assume network configuration has been automated. How does that affect network design?
This week has been the semi-annual OpenStack Summit in Atlanta, GA. In a rare occurrence I’ve been able to be here as an attendee, which has given me wide insight into a world of Open Source development I rarely get to see outside of some interpersonal conversations with DevOps people. (If you’re not sure what OpenStack is, or what the difference is between it and OpenFlow, OpenDaylight, etc., you may want to read an earlier blog I wrote that explains it in plain English).
On the first day of the conference there was an “Ask the Experts” session based upon storage. Since i’ve been trying to work my way into this world of Programmability via my experience with storage and storage networking, I figured it would be an excellent place to start. Also, it was the first session of the conference.
During the course of the Q&A, John Griffith, the Program Technical Lead (PTL) of the Cinder project (Cinder is the name of the core project within OpenStack that deals with block storage) happened to mention that he believed that Cinder represented software-defined storage as a practical application of the concept.
I’m afraid I have to respectfully disagree. At least, I would hesitate to give it that kind of association yet. Read More »
The programming of network resources is not just a trend, but also a way to future-proof IT and business needs. This blog series examines how infrastructure programmability is providing a faster time to competitive advantage and highlights the differences between programmable infrastructure and traditional infrastructure, and what programmability means for your entire IT infrastructure.
To read the first post in this series that defines infrastructure programmability, click here.
To read the second post in this series that discusses benefits of network programmability, click here.
According to a recent Network Computing article, changes in network virtualization (overlaying virtual networks over a physical infrastructure) and network programmability (provisioning and controlling its behavior) are causing some to wonder what’s in store for the networking profession.
These changes mean that our skill sets will evolve and our jobs will get more interesting. As the need to build more agility into IT systems becomes more urgent, we are looking for ways to reduce complexity, drive simplification and reduce costs to invest in new initiatives that are critical to the business. We must free up resources so that IT can build new capabilities and provide faster time to new business competitiveness. How can we do this? A new model for IT – one that is simple, smart and secure.
The programming of network resources is not just a trend, but also a way to future-proof IT and business needs. View Executive Perspectives.