When you run a software platform, you constantly have to think about how long your software is going to run. Sometimes you get something that’s practically eternal like FORTRAN or COBOL-based applications. Other times you find your app already out-of-date less than a year after you built it because of a platform change or a shift in the way people consume your data. How can you plan ahead for this? And what are the biggest barriers to keeping things moving along smoothly.
Other People’s Code
From my perspective, one of the hardest things to maintain in software development today is someone else’s code. It’s hard enough to figure out what you wrote yourself just a few months ago. Even with copious commenting. Imagine the difficulty of figuring out what someone else was working on?
This is a very common problem in enterprise software development. When you have teams working on applications and platforms you have a lot of minds working on the problem together. The solutions they come up with are often novel and innovative. But novel and innovative are also codewords for “complicated” and “obscure”.
How many times have you heard (or said), “We’re not exactly sure how this works so we’re going to have to rewrite the entire code base from scratch.” It’s a pretty common issue to not understand how former developers worked on something. It’s even more common when that platform isn’t native to your company. Say, for example, if it came via an acquisition.
Acquisitions in tech are as sure as death and taxes. Small companies get purchased. Big companies get split apart and sold off. Other companies are always on the lookout for the next big thing they need to compete. But acquisitions also mean having a new team support the new software. The old team may not want to stick around to help. And even the old team will have to retire or get promoted at some point. What happens then?
Bridge To The Future
This issue is very much at the forefront of the platforms that Cisco has for their customers. A large portion of their software platforms have come via acquisition. Even for something that is inherently linked to Cisco, such as the Catalyst switching line, came from an acquisition. The former Catalyst Operating System (CatOS) was one of the most visible examples of this trend. Switches ran CatOS and routers ran Cisco’s Internetwork Operating System (IOS). Never the ‘twain shall meet.
Until, that is, Cisco ported the CatOS feature set to IOS. It was a bit bumpy for a while. Until the features were integrated together there were weird things like VLAN database modes and such. Eventually Cisco worked out all the kinks and got the entire CatOS feature library running in IOS and was able to retire the platform. That was a huge boon for Cisco’s development process. Now, all the features came to IOS first and the developers worked on IOS full time instead of splitting their attention between two radically different platforms.
Flash forward to the 2000s and Cisco found themselves in a similar situation. Their wireless access point (AP) line had finally migrated to running IOS. But those APs were autonomous, meaning they needed to be configured one at a time. The industry was moving toward a centralized management model. Cisco needed to get up to speed on this market, so they did the natural thing and purchased a company. Airespace was snapped up by Cisco and their AireOS controller became the de facto wireless offering from Cisco.
Now, some years later, Cisco is still maintaining the AireOS code. There was an attempt a few years ago to migrate the codebase to something more like IOS, but it wasn’t successful. That’s because they attempted to port everything as one big monolith. As with all platforms, the feature parity wasn’t 100% when the old IOS WLC code was introduced. This caused a huge backlash in the industry. Why would I run feature-incomplete code that’s untested when I can keep running the old stable code. And that’s exactly what happened. Enough wireless professionals opted out of the new code base that Cisco went back to developing on it and dropped the idea of IOS-based WLC code.
That is, until last November. Cisco announced during Networking Field Day 19 that they are introducing a new IOS-based WLC codebase. What separates this codebase from the existing attempt is something simple in design and complicated in execution – modularity. By remaking the code into a series of modules that create functionality inside the base platform, Cisco has essentially solved the monolith issue.
When code is monolithic, major changes require everything to be tested and retested. Release schedules slip. Features get missed because it’s too risky or too time consuming to build them. On the other hand, building your features into a module greatly reduces the amount of time that it takes to ship. Now, instead of worrying about how the code is going to interact with the entire system you only need to figure out how to make it work with the module subsystems. Instead of waiting for a major update to the OS to ship you can ship the module independently.
More importantly, modularity increases reliability. If you don’t need a feature in a module, you don’t’ need to update that module. Likewise, if you need to update one module to fix a problem or enable a new feature, you don’t need to upgrade to a new code base and risk introducing new bugs into already-working features. The modularity ensures that one failure in a unit won’t crash the entire system. It also builds on an architecture change in the future. When features are written as modules you can easily break up the modules and have them run on nodes across a cluster. Now, instead of forcing devices to share a portion of the load to balance everything you can instead have specific modules being executed on devices spread across a grouping and provide redundancy for those processes everywhere.
Bringing It All Together
I’m a huge fan of what Cisco is doing with their new modular IOS WLC code base. They’re speeding time to introduce new features. They’re increasing reliability. And they’re ensuring the future of a codebase that has run its course. Now, instead of having developers split across two different setups and forcing them to get trained on something over a decade old, they can usher in the future and have a more unified development model. Make way for the future of IOS.
