What if every time you wanted to roll out an app, you didn’t need to figure out what new computer/server you were going to put it on? What if I told you that there were compute resources built into your network? And, what if I told you they even had access to serial ports for IoT devices? Shall we talk?
On June 20th, Cisco announced “The New Network. Intuitive.” The announcement included new programmability capabilities inside of Cisco switches and routers, providing a strong “YES” to the questions above – Yes, compute resources are in the network; Yes, they have access to the serial ports. So yes … let’s talk about how you might move some of your software closer to the devices at the edge of your network.
When we have devices at the edge of the network, we are starting to delve into the world of IoT. And, in IoT, we almost always have four things:
- A thing
- Some data
- A network
- An algorithm (that’s where your software comes in)
By using the capabilities in the New Network, I’m going to show you how to better manage number 2: Data. There’s more. But this is a key benefit to doing this the new way instead of the old way.
If you want to see some other related blogs, you may want to warm up with a blog by Jeff McLaughlin, that describes some of the new things you can do with the new network. In another blog, Hank Preston discusses what may be the easiest way for a network engineer to get started using programmability features in the network.
Why host apps on a router?
Use Case #1
Imagine you want to run a small program at a branch office. What have you done in the past? I think what most folks have done is to install some sort of compute appliance. That network diagram would look something like this.
Figure 1 – Compute Devices at Branch Offices
The problem with this methodology is that you now have a compute appliance installed, which needs to be maintained. It consumes space and electricity. What if you could eliminate the device completely and get that same functionality out of the network router, which you need anyway?
Use Case #2
Another example of old school is this IoT implementation. In the past, it was common to use a terminal server to connect multiple serial devices to the network, and then push that traffic back to a centralized compute resource. Below is a picture of what that would look like.
Figure 2 – Old School Terminal Server for IoT Connectivity
The problem with this method is that if the network is down, then the IoT Devices are not supported by compute. Also, this method transmits every byte, that goes into and out of the IoT devices, across the network. And finally, this terminal needs to be maintained.
What if you could eliminate the device completely and get that same functionality out of the network router, which you need anyway?
The New World Solution – Solves both use cases!
In the below diagram, you will notice that we have eliminated a fair bit of hardware and headache from the diagram! Let’s talk about just a couple of the advantages of this method.
Figure 3 – Edge Compute in a Router
First, you have entirely eliminated a device at the edge of the network, reducing time and effort of management at the edge. Second, you can run the code at the edge instead of the middle of the network. What if the application was super simple, like a heat sensor on some machinery?
Here’s some pseudocode to make the point:
If read(IoT Device 1) > “180” then
set(IoT Device 2) := “OFF”
msg(“IoT Device 2 status [off],[heat]”, “central alarm app”)
So, what’s nice about this? How about the fact that the only time traffic goes over the network is when it actually needs do? How about the reliability is dramatically increased because the compute resource is directly connected to the IoT Devices?
But wait, there’s more. What if you wanted to increase the reliability? For the price and effort we had before, we can add another router and increase the reliability of the whole setup at the edge as shown in the diagram below. And for the record, this is almost exactly what one of our customers is doing to improve public safety.
Figure 4 – Edge Compute and Network Redundancy
Generally speaking, this new methodology increases reliability and decreases maintenance. Cisco has routers for both branch office applications, which have a ton of different “port type” capabilities. And, they also have ruggedized routers with wireless capabilities built in to handle the redundancy.
What does app hosting on a router look like?
Cisco has several different methods for putting an app on a router. For today, I’m going to talk about how it looks when you do it on IOS XE, since we just announced some new functionality in that area. This operating system makes it possible to run both virtual machines (KVM) and Linux Containers (LXC) in order to host applications right on the routers.
If you would like to learn about the details of what is working today and how this all works, you can visit the Cisco DevNet IOS XE page. We have a fair bit of information for you to get started. Another great place to learn about this from slightly different perspective is our IOX page. In the meantime, I’ll provide a little bit more detail on the router configuration part – just to show you what it looks like from a Cisco IOS perspective. But, I highly recommend hitting one of the links above to really get the best description and details.
How does this really work?
On a Cisco IOS XE router, there are 5 major steps to get an application running on the router using a KVM. Below, is some sample code just to give you an idea of what it might look like.
NOTE: I am intentionally leaving out details to make this readable in a blog. You need to go here in order to get the details and exact commands.
In this blog, I wanted to provide a short introduction to running an application on a Cisco device running IOS XE. I hope that the “Why” section was compelling. Having seen what some of our customer are doing with IoT and this functionality, I hope you will explore it. The “What” section was strictly designed to cement the picture, “You can run containers right on the box!”. And finally, in the “How” section, I showed you a sampling of the commands it would take to put a KVM package onto a router and get it running. Clearly, the “How” section is incomplete. But, hopefully, you get an idea that it’s not really all that hard. And, I did leave out how to create the package. That would be too much detail for a blog. But, you can get all the details you want if you simply go to Cisco DevNet’s IOS XE, or IOX, page to learn more.
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Visit the new Developer Video Channel