Yesterday, Cisco announced a new software release for ACI. If you are looking to automate IT, or build out your cloud environment, and want to do so in an open fashion that provides a lot of flexibility – then you’ll probably be interested.
Why? The new ACI release:
- Makes managing and securing your cloud environment easier;
- Provides openness, expanding customer choice; and
- Delivers operational flexibility
OK, so what does this actually mean?
- Makes managing and securing your cloud environment easier
Three of the most popular cloud management tools include Microsoft Azure Pack, OpenStack and VMware vRealize. Earlier this year, we announced Windows Azure Pack ACI integration. With this new ACI release, we integrate ACI with OpenStack and vRealize, as well. (More details are here.) So this means that if you need to, say, provision a virtual workload in vCenter, ACI automagically orchestrates things to match computing resources and networking infrastructure. So, you can enjoy the policy based automation and all the other benefits of ACI regardless of which of these tools you use to manage your cloud environment.
This also means OpenStack users can now create and manage their own virtual networks, extending ACI policy directly into the hypervisor with a hardware-accelerated, fully distributed OpenStack networking solution – the only one available that integrates both physical and virtual environments.
To more easily and completely secure these environments, the new release provides micro-segmentation support for VMware VDS, Microsoft Hyper-V virtual switch, and bare-metal endpoints. Essentially, this means more granular enforcement of security policies. These can be based on numerous different criteria relevant to attributes associated with the network, e.g. IP address, or the virtual machine, e.g. VM identifier, Name, etc. There are additional capabilities that can, for example, disable communication between devices within a policy group (intra EPG, for those more familiar with ACI) – useful in thwarting lateral expansion of attacks.
- Provides openness, expanding customer choice
Piggybacking off some comments above, it’s worth noting that since ACI’s inception, one of its differentiators has been the ability to integrate physical servers as well as virtual machines, and to apply policy consistently across them. Well, now there’s a new kid on the block, as the industry observes an increasingly popular trend to use containers as another way of operating applications. As part of this announcement, we are extending ACI support to include Docker containers, in addition to VM’s and bare metal servers. This is done by using Project Contiv, which is an open source project that has a Docker network plugin allowing, among other things, automatic configuration of Docker hosts to integrate with ACI. Check out details on this video and/or this white paper. Network Computing commented here, that:
“Given all the hubbub in the industry over Docker, ACI’s new Docker container support is noteworthy.”
Another way this new release is driving openness and providing more choice for customers is around L4-7 services. ACI now supports service insertion and chaining for any service device. So, customers can leverage their existing model of deploying and operating their L4-L7 device, while automating the network connectivity. This is in addition to, not instead of, the device package model, which provides for more comprehensive ‘soup to nuts’ automation. Speaking of which, as part of this announcement, several new partners also joined the ACI Ecosystem. This video provides some insight into how some of them automate your applications.
- Delivers operational flexibility
The new release has a number of tools that create more flexible operating environments. A quick rundown includes the multi-site app, which enables policy-driven automation across multiple datacenters, providing enhanced application mobility and disaster recovery. In short, this means you can run ACI in 2 different data centers, and extend the policy across them. Other tools provide the ability to do configuration rollback, as well as NX-OS Style CLI. This is for the CLI junkie that wants to run the entire ACI fabric as a single switch. There are some other cool nuggets in here as well, like a heat map that provides real-time visibility into system health.
Clayton Weise, Director of Cloud Services at KeyInfo, summed it up best when he said:
“ACI is the direction we’re going to go because it gives us the best flexibility.” (Read the entire Network World story here.)
In summary, this new release adds capabilities that will help you more effectively manage and secure your cloud environment, as well as leverage the benefits of both openness and operational flexibility.
Tags: #CiscoACI, #ciscodatacenter, ACI, API, cloud, Cloud Computing, containers, data center, docker, L4-7 Services, Linux Containers, Open, SDN, security
Last week, I posted about our Project Thor, our effort at creating a royalty-free next-generation video codec. This post generated lots of comments – which is great! But also illustrated that there is a lot of confusion about what it means for something to be open. I’d like to remedy that here and describe the four dimensions of open. Yup, four.
Dimension 1: “Open as in Open Source”
One dimension of open is whether the technology is available in open source form. Typically this means that the source code is available and that there is a license associated with it wherein the owner of the code makes it available for usage, distribution, and modification within other projects without charge. Cisco is typically favors the BSD license. It’s important to note that open source licenses are really about copyright: They tell you whether or not you can include this code in other projects and distribute it. Whether it really costs nothing overall — that’s the next dimension.
Dimension 2: “Open as in Free”
The second dimension of open is whether the technology can be used in a form that does not require payment. Where things get interesting is when a piece of code implements something that is patented. In such a case, it may not actually be free to use the technology, because you need to pay a patent royalty fee to the patent owner. It’s totally possible for code to be open source (Dimension 1) but not free (Dimension 2). A great example of this is x264. This is an open source project – indeed available under the GPL license – but because H.264 utilizes patented technologies, any company that ships a commercial product using it has to pay patent license fees to the patent holders, in this case the MPEG-LA consortium. As a side note, the GPL license attached to x264 would also require a commercial product to open source its own code; but that’s a separate matter. Read More »
Tags: BSD license, Cisco, collaboration, Open, Thor
Only on TechWiseTV
This is the first in a multi-part series where we cover ‘programmability’ for networking. The idea is to fully review the programming options now available inside the Nexus switches, (3000, 9000). This first episode covers new access with Linux tools, NX-API and more. Further shows will be diving into the details around Object Models and orchestration partners.
The primary point for any of these is to understand how Cisco Open NX-OS extensibility exposes greater programmability and automation capabilities. It is fascinating and full of new learning opportunities. It does not come without a few career questions of course…usually, something along the lines of: do network engineers need to become programmers now too?
Two answers: Yes. It depends.
Networking knowledge and skill should not be undersold here. Programming capabilities should be additive. They are useful in just about any tech career and obviously affecting the networking space. I think it’s foolish to ever quit learning but it does depend on your aspirations, your current level of satisfaction and perhaps how narrowly defined your skill set might be.
Full disclosure: I am not a programmer. I have been learning the fundamentals of python and a few others as I work on this series but I am not hire-able for this skill by any means. But the distinct feeling I get, and the feedback I hear from you guys: its not that hard. You are probably well versed in scripting for various CLI operations…take it up a few notches and work on some of these ‘readable’ languages that will have similar syntax. This will give you the ability to judge the appeal of what we are offering with ACI and other solutions much more credibly…and I guarantee you will find ways to get rid of redundant crap and stupid errors you may be fighting with yourself or your team.
JOIN US AT THE WORKSHOP
Live, interactive, never dull.
September 21, 2015
Programmable networks will forever change the way you manage infrastructure enabling you to dramatically accelerate configuration and deployment of your network, automate time consuming manual tasks, and allocate IT resources far more efficiently. Are you ready for the revolution?
Discover how to create a programmable network as we discuss and demonstrate the NX-API and NX-API REST (Object Model) in detail. Understand how Cisco Open NX-OS extensibility exposes greater programmability and automation capabilities that eliminate costly manual errors.
– You can sign up at the workshop tab when the date gets a bit closer, http://www.techwisetv.com
Nicolas Delecroix in the TechWiseTV Lab
Two great experts on this episode.
Six Key Points: What OPEN means for NX-OS
Shane Corban shares Six Key Points: What OPEN means for NX-OS
Changes made across the software stack to address Extensibility, Openness, Programmability.
- Auto Deployment (Bootstrap and Provisioning)
- Added support for PXE server, operationalize NX-OS software to match an existing server environment
- Extensibility – how we package software
- We did not use to expose much beyond a bash shell
- Now you can install native RPM’s, and third party applications running processes as they would on a Linux server
- Open Interfaces
- We are now adding support to leverage Linux like tools for debugging, configuration and troubleshooting…manipulate those front panel ports as native Linux interfaces within our switch software stack.
- Application Integration (Adaptable SDK)
- Published an SDK, a build environment that you can install on any Linux server, download the build agent, and put your source into that directory structure and build into an RPM for installation and run it natively.
- Build your own custom automation apps, monitoring agents, and have them run natively on our platform
- Programmability Tool Choice
- We have a native Python shell today that has a Native Cisco Library that you can utilize for automation
- NX-API – the ability to embed CLI commands and structured data (JSON, XML) for execution on the switch via HTTP/HTTPS Interface to get back structured data back on show commands.
- Management Tools
- Support for Chef and Puppet
- Agents will be publicly available on the enterprise sites
- Support for Open Stack, Neutron
NX-OS is now more modular, more open, more capable of third party integration providing a wide variety of programmability choices ideal for Dev-Ops environments.
Five case study examples
Nicolas provides five case study examples.
- Checking Software Version
- Using Python script with NXAPI and JSON to pull version numbers
- Python script to query multiple switches to check compliance against a specific version
- VLAN Provisioning
- Checking for proper VLAN provisioning
Special thanks behind the scenes to Rami Rammaha and Mark Jackson
Cisco Nexus 9000 Programmability Guide
Matt Oswalt is a great writer. You should follow his blog: Keeping it Classless. I enjoy his angles on things. Read up on his blog entry: Evolution of Network Programmability, Nexus 9000 NX-API,NX-API Update.
Some Learning Basics:
What do you think still needs to be covered? I would love any thoughts on how the rest of this series should be shaped. Leave your comments below and just to make sure…tag me on twitter. We are diving into Object Models (taping next week) and then some angle with the Orchestration Partners. Case in point: Puppet Labs is making available today a native Puppet NX-OS agent and Cisco Puppet Module.
Let me know!
Tags: ACI, Awesome, Insieme, JSON, Linux, nexus, NX-OS, Open, Programmable, python, RPC, TechWiseTV, XML
Over the past several years, I’ve been lucky enough to be a part of two important trends in the networking industry – the evolution of open standards and open APIs, and the definition of policy as the key interface to the network.
Open is an extremely important word to the future of networking. The simple dictionary definition for open means not closed or locked, allowing access to inside, and freely accessible.
The ultimate networking environment will allow a user the freedom to connect anything together in the cloud and to an existing environment. In order for this vision to happen, companies must work together to create a common language.
OpenStack has garnered a lot of interest in the development community and among our customers. We at Cisco have been actively helping to shape the discussion around policy. Working collaboratively with our partners and competitors, we helped create Group-Based Policy (GBP), an intent-driven policy API for OpenStack.
The Group-Based Policy initiative represents a significant innovation in how users conceive, manage, deploy, and scale their applications in OpenStack clouds. And its now available as a 100% open source solution available to any vendor. When coupled with Cisco Application Centric Infrastructure, we are able to offer our customers a completely policy-driven network.
Read More »
Tags: ACI, API, APIs, application centric infrastructure, Cisco, Cisco Application Centric Infrastructure, cloud, data center, group-based policy, network, networking, Open, open APIs, open source, open standards
Enterprises have taken on many cloud computing opportunities but for the most part the adoption of applications on the cloud is very early and mostly for new applications and for development and test use cases. Many enterprise applications have not been considered for cloud due to their legacy deployment models or application architecture.
Many companies have made the mistake of thinking that legacy enterprise virtualization technology, enterprise software methodology, enterprise provisioning systems, and enterprise management systems will survive their company’s business transformation. Unfortunately time and time again these systems are not able to scale, adapt quickly enough for the business, and frequently cost up to 10 times more than open source based solutions.
The reason for this lies in the power of community and the scalability of software propose-built for scale and adaptability. OpenStack definitely fits this requirement and has finally matured enough to be a force in the transformation of your enterprise business. Cisco announced the largest global Intercloud, which is based on OpenStack and other open source software to deliver a cloud that can scale to 100s of thousands of virtual instances and 100s of instances provisioned in minutes.
As important as that is for cloud scale, interoperability, and adaptability, the message in this announcement is much bigger. Cisco is committed to OpenStack and open source projects and is taking the lead in developing and driving software defined network, network function virtualization, application policy control, cloud optimized computing, security, orchestration, and service assurance innovations back to the open source community . Cisco’s contribution focus is operationalizing Openstack for the enterprise scale, reliability, networking, and compute scheduling needs. In Havana, Cisco contributions included the Neutron Cisco plugin framework, feature additions to the Nexus plugin for physical Cisco Nexus switches, introduction of the new Cisco Nexus 1000v virtual switch plugin, and actively leading and participating in the design of the Neutron Modular Layer 2 plugin framework. Cisco’s contribution in these and other areas, such as Layer 3, Firewall and VPN network services including yesterday’s announcement highlighting additional IETF contributions Cisco introduced with the OpFlex protocol for application centric infrastructure (ACI) .
Join us as we transform the cloud from legacy virtualization technology and custom code that does not scale to an agile cloud platform that scales and adapts at the speed your business requires. All supported by an international community of architects, engineers, and developers with your enterprise business interest in mind. Lastly, designed from the bottom up to interoperate with the most popular clouds on the market today while future-proofed via the abstractions in our software innovations. Cisco is committed to this approach because we believe that a world of many clouds requires openness and interoperability to allow you maximize your business benefit. Let’s see what we can accomplish together.
You may want also read a previous blog
What makes Cisco Cloud Services Application centric ?
You can also follow me on Twitter @kenowens12
Tags: ACI, cloud, cloud services, global intercloud, Hybrid Cloud, interoperability, Open, open source, OpenStack, OpFlex