Virtualizing services within the network
When we launched the new ISR 4451-X at Cisco Live a few months back, one of the Big New Things we talked about was the Service Container architecture. Unless you were paying close attention to the 4451-X, you might have missed that whole thing. So what the heck is a Service Container?
To put it simply, a Service Container is a virtual machine running within the network itself. Instead of your typical server virtual machine, these VMs can be used to enhance the capabilities of the underlying network itself. Service Containers can add additional services, such as WAN Optimization, to the network. They can also enhance the capabilities of network devices by adding things like new programmable interfaces to the network. In some cases they can even be used to add impressive capabilities to the network from trusted third party developers.
Write Once. Run Anywhere
The motivation for creating Service Containers is the ability to write an application or service once and run it anywhere. Traditionally, a service or feature has been implemented in a network platform within the operating system, generally Cisco IOS on Cisco routers and switches. That meant that the service was tightly coupled to the host operating system and would need to be largely or completely re-written on other platforms.
With Service Containers, you can take advantage of the portability offered by a virtualization layer. Take Cisco WAAS as an example. The same software can be written once and then run in a variety of locations depending on performance and scale needs. WAAS running on an appliance is the same software as vWAAS running in a datacenter or blade virtual machine which is the same software as ISR-WAAS running in a Service Container on the ISR 4451-X. That means the end-user gets the same experience and features across the board and that fewer Cisco engineers are needed to support WAAS in all of these locations. With Service Containers you get much of the benefit of a services blade, like a UCS E-Series module, without the complexity or additional hardware.
Earlier I referred to Service Containers as a type of virtual machine (VM). While that is completely true these might not be the type of VMs you’re familiar with. Most people are familiar with VMs running in hypervisors from companies like VMWare, Citrix or Microsoft. These hypervisors abstract the underlying host hardware or operating system creating a standard environment for VMs. The virtualization for Service Containers works exactly the same way using a couple of open source, lightweight virtualization technologies.
The two VM types used by Service Containers are called Kernel Virtual Machines (KVM) and Linux Virtual Containers (LxC). The two differ mainly in how tight they are coupled to the Linux kernel used in most network operating systems such as IOS XE and Nexus OS. LxC containers use many of the kernel resources of the host while KVM containers have their own independent kernel. This means that a KVM can be slightly more portable than an LxC container while an LxC might have a slight performance edge over a KVM. To the end-user, however, the container type is completely invisible since all of this is determined by the Service Container developer. That makes this great information for your next Cisco Trivial Pursuit night, but not something you ever need to worry about unless you plan to start developing your own Service Containers.
You might also hear folks at Cisco Trivial Pursuit night referring to Service Containers as onePK containers and that’s not a bad way to look at these VMs either. That’s because all of the networking platforms that support Service Containers are also supporting the one Platform Kit software development kit (SDK). onePK is revolutionizing the way applications interact with the network. Instead of requiring an application developer to write a complex function to parse the command line or SNMP interface to a router, onePK allows them to make a simple procedure call to quickly and consistently return exactly the piece of information needed by the application. Because of the ease of writing applications that use onePK to interact with network platforms, the majority of services you find running in a Service Container are using onePK rather than older, less reliable mechanisms such as CLI, SNMP or even XML when communicating with Cisco hardware.
Where the rubber meets the road.
Now that you’re all excited about Service Containers you’d probably like to know where you can see them in action. As you can imagine, a technology like this is going to start showing up on newer platforms first. In fact, Service Containers have already been hiding right under your nose for several years. This technology has been used for several years on the Catalyst 4500 Sup 7E, 8E and newer supervisors to deliver embedded Wireshark so that network administrators can remotely capture and debug application traffic.
The Cisco Cloud Services Router CSR1000v is using a Service Container to implement a web API; something critical for virtual data center management. Service Containers are also used across the Nexus Family of products to deliver advanced network modeling applications as well as to provide an open container allowing you to build and run your own custom applications. Most other platforms require a securely signed application than can only come from Cisco for anything running in a Service Container.
Last but certainly not least the new ISR 4451-X is providing an environment for Cisco Service Containers that enhance the functionality of the host platform. The first of these containers is Cisco ISR-WAAS for WAN optimization running natively inside the branch router with the same features as WAAS running on a blade or an appliance.
This is just a small taste of some of the applications and services Service Containers are capable of delivering. You’re sure to see new features and new capabilities rolled out in Service Containers on the Catalyst 4k, ISR 4451-X, CSR1000v, Nexus products and other new platforms. For the latest information, and for even more geeky Service Container information, check out the links below.
The TechwiseTV guys do a much better job of explaining Service Containers than I just did.
We also just recorded a webinar on Service Containers that goes into much more detail than what I have here.