Back in the early days of software development, we built what the kids nowadays like to call monolithic apps. Well, actually, they aren't kids so much as giant behemoths like Amazon that want you to use more of their services and are playing to a younger, techie-er crowd to get the word out, but I digress.
The point is, those giant old client-server apps cost a lot of money to maintain. One change in one piece of the app can easily break another because there is no dependency management. Software developers are harder to retain because the technology is old and outdated. Extending the applications to add new functionality is often kludgy and causes a nightmare level of defects.
DevOps, CICD, and the rapid pace of change
Welcome to today, where we have not ridden ourselves of all those issues, but we have moved on to what people in the tech biz call DevOps. DevOps is not just a term du jour; it has meat to it. DevOps and the newer term, DevSecOps, represent a new way of integrating agile teams to deliver code faster and, well, with agility. The tools developers use to write, manage, and deploy their code are all automated. One of the most significant benefits of DevOps is you can write code on your computer, push it out for review by your peers, and then have the code automatically deploy to a test configuration and finally to production. The entire release pipeline is automated.
Everything I am mentioning is not the future. The reason even big, multi-billion-dollar companies can release new versions of their apps is because they embraced the software development technologies that allow them to speed code through a pipeline. The term a lot of companies use for this is CICD, or Continuous Improvement and Continuous Deployment (or some variant of those words).
Embracing the change
When I first heard about Git, I remember being confused and thought that managing code seemed a lot more confusing than the basic check-in, check-out code repositories of old. Then, I wrote an app that helps technical writers create advanced eBooks. I jumped in with both feet to the DevOps 'way of thinking', using Git as my repository, and began appreciating how easy it was to manage my codebase. Next, when I learned about CI/CD, I decided to take that for a whirl.
With Git and CI/CD, I was able to write code on my computer and then literally with a click of a mouse, the code would push up to the production environment. My customers would be hanging out in my app, and then the next time the went to a page, a brand new feature would be there (my app is tiny with a small customer base, so 'testing' was usually me just making sure it worked first).
The great thing about DevOps and CI/CD is that software developers can move quickly and release software frequently. If there is a problem with the code, then rolling it back is [usually] fast and easy. So the developers have it great, right? Well, not so fast. Developers also have to deal with folks in the security and network management world. Their shiny new version of the app may require changes to their networking equipment to open ports, add rules, or update job priorities (to name a few).
Is the NOS holding us back?
The pace of change in software development is mind-boggling. In a relatively short period, we went from developing apps to run on a single computer, to client-server apps, to virtualized apps, to cloud-centric container apps and micro-services. Unfortunately, the NOS (network operating system) has changed very little. You require specialized resources that require intimate knowledge of the networking hardware and software. There are few APIs, and when you do use them, the APIs might be different depending on the vendor or version of the hardware.
In today's podcast, I interview Glenn Sullivan. Glenn's company, SnapRoute, wants to rethink the network operating system from the ground up, and he wants the NOS to be a first-party participant in the world of DevOps, DevSecOps, and the CICD pipeline.
I'll be honest, it was hard for me to take in where Glenn was going with his concept, but by the end of the interview, I could not wait to hear more, and I think you will feel the same way too.