If you work in technology, the question "What's your tech stack?" is the modern equivalent of "what's your sign?" Once relegated to the realm of developers who argued LAMP versus, well, anything else, the assembly of tech stacks to build systems instead of solutions now permeates every aspect of IT.
This componentization of IT is like the componentization of the applications it is tasked with securing and delivering. Estimates range from 80 to 90 percent of modern applications are composed of third–party components; most of which are open source. The benefits of doing so include speed, responsiveness to change (agility), and a reduction in the cost to create the software. After all, if someone else already wrote the code for a wheel, why reinvent it?
There are no estimates as to just how componentized IT maybe today, but the answer to how componentized will it be in the future is clear – very.
We don't build our own monitoring systems anymore. We adopt one, like Prometheus. We don't develop our own search engines; we integrate with Elastic Search or Lucerne. We don't have to design and develop formation and infrastructure controllers; we have Helm and Terraform. We're no longer asked about integrating with systems, we are asked about our support for various operational pipelines.
We build systems out of a software stack rather than developing each component ourselves.
This system-level thinking is pervasive in development, and it's beginning to have a profound impact on the way all software – commercial and custom – is developed. It is also having a significant impact on the way we architect application delivery.
A few years ago, I noted that microservices were breaking up the network. This remains a break–up in progress, for reasons that are closely tied to the mindset of DevOps. That is, DevOps is more likely to think in terms of componentized systems, particularly when influenced by cloud. As DevOps continues to encroach on traditional NetOps and operations' turf, they bring with them their way of thinking. That means stacks instead of solutions.
This perspective leads naturally to the adoption of individual application services that better fit the mode of operation and thinking in which DevOps operates today. Single-purpose, functionally focused application services are used to compose a data path rather than construct one.
That means load balancing is load balancing. Ingress control is ingress control. And an API gateway is an API gateway. No matter that an Application Delivery Controller (ADC) can perform all these tasks and more. An ADC is a solution and what modern ops want is a stack. A stack comprised of application services.
We can see this in the extraordinary adoption rates of targeted services like API gateway, ingress control, and bot defense we saw in last year's State of Application Services report.
You'll note that bot defense – often a component of a traditional web app firewall – has a different deployment rate. Ingress control and API gateway, too, have varying deployment rates than that of the broader – and often inclusive – load balancing service they are traditionally a component of.
That's because modern data paths are increasingly assembled – not architected – from individual components and from application services.
This shift has not gone unnoticed. Just as digital transformation continues to force business to redefine itself and decompose into services represented by APIs and applications, it dramatically changes the way we design, develop, and deliver application services.
IP–based routing has always been the way data paths are architected. Route this traffic here, and this type of traffic there, and if there's something in the payload that matches X then route the traffic over there. It's very network-specific and thus tightly couples the data path to the network on which its deployed.
That makes it difficult to replicate in other environments, like a public cloud. While you can likely reuse policies, you won't be able to take advantage of the configuration binding the data path to the network. That makes multi-cloud realities hard to operate, let alone manage.
Both containers and multi-cloud adoption are forcing data paths to move up the stack and be assembled at the application layer from application services. That's much more portable across environments because you're operating on metadata like host names or tags and labels that are not bound to the network.
Modernization of application delivery, then, requires a shift from configuring traffic management to deploying traffic policies that can assemble data paths. This is a shift that moves from solutions to stacks; from app delivery platforms to application services.
And that's what we're seeing. As application services decouple themselves from their traditional platform providers, they will increasingly look like application microservices. They will be assembled and glued together at the application layer much the same way modern applications integrate via APIs.
Welcome to the Age of Assembly.
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.
Eliminating complexity by standardizing with a platform approach is the way to put the brakes on the complexity cycle.
