It is a simple thing to find references to the innovation cycle. Just type "innovation cycle" into your favorite search engine, and you'll be rewarded with millions of references in the blink of an eye. Now, finding references on the complexity cycle, however, is a bit more difficult. That might be because I just made it up, but I do not doubt that it exists and will continue to exist, just like innovation.
Complexity isn’t new. We have multiple generations of programming languages to prove that. The number of folks who understand and can harness the power of assembly language, for example, is dwindling. Stack Overflow’s 2023 survey found (a somewhat impressive) 5.43% of its 90000 respondents who have experience with assembly language. Compared to the 63.61% familiar with JavaScript or even the 49.28% experienced with Python, that number is small.
In fact, looking at the list, you can see the complexity cycle in action. Near the bottom are early languages like assembly. Moving up the stack you’ll encounter C, C#, Python, and JavaScript. It’s like walking through the evolutionary timeline of programming languages.
Each generation of languages is developed to address some complexity inherent in its predecessor. Java tried to eliminate the rampant memory manipulation horrors of pointers inherent in C and C++ by abstracting away memory management and access.
Abstracting away. That's the key takeaway here because it's nearly an axiom that the way technology addresses complexity is to abstract it away.
It’s not being removed; it’s simply being moved. The complexity is still there, hidden away beneath a simpler interface.
You can see evidence of the complexity cycle in the evolution of network and app services automation. From imperative APIs that required hundreds of individual API calls to configure a system to today’s declarative APIs that use only one API call. It’s easier, of course, but only the interface changed. The hundreds of calls mapped to individual configuration settings still need to be made, you just don’t have do it yourself.
The complexity was abstracted away from you and placed firmly on the system and its developers to deal with.
Now, that sounds great, I’m sure, until something goes wrong. And wrong something will go; there’s no avoiding that either. Zero Trust has an “assume breach” principle, and Zero Touch infrastructure (which is where the industry is headed) ought to have a similar principle, “assume failure.”
It’s not that complexity evolves. Complexity comes from too many tools, consoles, vendors, environments, architectures, and APIs.
As an enterprise evolves, it adds more of these things until complexity overwhelms everyone and some type of abstraction is put in place. We see that abstraction in the rise of multicloud networking to address the complex web of multiple clouds and microservices networking, which is trying to unravel the mess inside of microservices architectures.
Abstractions in the form of solutions and services are part of the natural complexity cycle.
But before running out and grabbing the latest abstraction, organizations should take a good hard look at their current estate, especially at the sprawl inside operations. According to our annual research, every one of thirty app services we track across every domain is deployed by 93% of organizations. That’s just a category; we don’t track how many of each app service is deployed.
Each category comes with its own set of APIs, tools, and technologies, and every domain has its own set of practices. And while abstractions will arise to address that complexity, it behooves enterprises to determine how much of that is caused by decades of silos and decentralization.
Just as organizations ought to audit their application portfolios from time to time to reduce duplication and sprawl, they ought to do the same with infrastructure and app services. We already see the beginning of this movement in a shift toward platforms that provide a more comprehensive set of security or app delivery solutions and reduce the number of abstractions necessary.
Call it centralization, call it consolidation, call it complexity reduction. Whatever you call it, eliminating complexity by standardizing with a platform approach is a much better way to put the brakes on the complexity cycle.
You can’t stop the cycle. But you can slow it down so it doesn’t overwhelm you.
Related articles:
With many enterprises new to NaaS, service providers can differentiate themselves from competitors by prioritizing superior customer service and experiences.
Unlocking the full potential of telecom in the SaaS era relies on comprehensive strategies and a constant commitment to evolving security practices.
As NaaS continues to evolve with AI, SDN, and industry-specific solutions, it is poised to shape the future of network services.
