At Cisco, I work with a number of partners and customers who build apps for IOx, which is capable of running container instances on some Cisco routers and switches. In my experience there are several best practices to ensuring that such an app will run efficiently and effectively for years to come. I presented a few of these at DevNet Day 2020 and thought I’d compile them here along with a few others to assist developers who are building IOx apps.
1. Choose containers over VMs
If you have a choice between containers and virtual machines (VMs), go with containers. VMs are much, much bigger than containers because they include a complete OS. This wastes valuable space and resources. Plus, VMs are only supported on a limited number of IOx platforms – you cannot run VMs on ARM-based platforms, and all the new IoT platforms are ARM-based. If you want to future-proof your app, ensure it will run on any CPU architecture and choose containers when you have the chance.
2. Don’t treat containers as light VMs
Working with partners and customers, I’ve noticed some developers approach containers like VMs, but they’re not the same thing. Unlike VMs, containers are lightweight and in theory do one specific task. A container is lightweight, agile and does include services like a typical VM as it re-uses the host functionality like the process scheduler. Albeit possible, you want to avoid creating “fat containers” because you have limited storage and speed at the network edge compared to a traditional server. There are only so many CPU resources, so you’ll see longer processing times with an oversized container.
3. Use the disk wisely
Most IOx equipment has an embedded flash disk, susceptible to wear and tear like all flash disks. Some Cisco equipment can additionally be equipped with an SSD disk, which is a faster and lot less susceptible to wear and tear. For continuous short-term writes the recommendation is to use primarily the temporary file system that’s stored in RAM memory; it’s ephemeral, but resistant to rewrites. For long-term data, such pertaining to system vibration at high frequency, you should typically store that information on devices equipped with an SSD flash disk.
4. Stay agnostic on CPU architecture
We have Intel-based, ARM-based, and even PowerPC platforms at Cisco, so it’s a good idea to be CPU agnostic to future-proof your application. If you write code in C to run only on Intel, at some point you’ll run into limitations because you won’t be able to use your application across all of Cisco’s portfolio of products. Either use a language that has a compiler for all the different platforms or use an interpreted language (Java with Just-in-Time compiling, Python, Perl, PHP, NodeJS).
5. Consider size
Your app must be as small as possible for a number of reasons. First, if your hardware runs in remote locations it might not be reachable with normal ethernet access. You might, for instance, have Cellular/LTE/4G. As a result, a big application will be slow to process and expensive to deploy. For example, a 300 megabyte container may takes 15 minutes to deploy and activate, compared to a small app like Cisco Edge Intelligence that’s a few megabytes and takes mere seconds to deploy. A smaller app is also faster to restart if the container crashes, minimizing your downtime.
An additional reason why it is wise to keep your app small is that storage space is limited. An IOx app needs three times the app space to install. If you’re not careful, you’ll force users to install an SSD disk, which brings extra costs. It’s OK to have a big container for deployment – to handle different utilities for debugging, troubleshooting, and so on – but when you go into production, remove whatever you no longer need.
IOx Local Manager makes it easier for developers
to quickly upload and run IOx applications on Cisco gateways
Avoid pitfalls – watch this video
With these five tips in hand, you’re ready to learn even more best practices in developing IOx apps. I recently led a 20-minute workshop for Cisco DevNet Day, IOx Application Hosting Advanced, which covers the pitfalls to avoid, especially when developing for various CPU architectures such as x86 and ARM. Check it out and let me know in the comments anything additional you’d add to this list!
Learn more about IOx here — you’ll find sample code and scripts, access to learning labs and the DevNet Sandbox, videos, and more.
Additional resources:
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
Great, Sir I want to learn more about DevNet where from I can start can you help?