The Future Of App Delivery: The Next Five Years

June 2, 2022
8 min read time
The Future Of App Delivery: The Next Five Years

TLDR;

Application delivery is moving fast and has recently seen significant advances in centralized control, containerization, integration, and intelligence. If we follow these threads, and broader industry trends, what more might we see in the next five years?

Yes, I’m dipping my toe into the most dangerous waters for any writer: prognosticating on the future, with my predictions available for all to scoff at when they turn out to have missed the mark. Time to throw caution to the wind.

Containers Everywhere

Let’s file this one under “safe bets”. Gartner estimates that 10% of total workloads are already containerized in 2022 and that 90% of businesses will be running at least some production applications in containers by 2026.

Of course, containerized application services like load balancers, ingress controllers, and API gateways already exist and come with the ability to manage containerized apps. I’m not winning any prizes for originality here.

But what will change as containers become the majority instead of the minority? Here are a few things we can expect.

  1. Applications will be more consistently architected for distributed deployment and disaggregated services.
  2. East-west application traffic between containers and microservices will grow exponentially as a result.
  3. Datacenter resources will shift from x86 CPU hardware to ARM or other lightweight instruction sets.
  4. Software-defined networking will dominate as topologies must become more fluid and conceptual than physical.
  5. Platform Ops teams will increasingly demand lightweight, portable, scalable application infrastructure.

This has a few implications for application delivery.

First, big-box application delivery controllers (ADCs) will finally go out of fashion everywhere except in places where migrating apps to cloud-native environments is deemed too expensive – for example, in traditional banking mainframes. This includes monolithic applications running in heavy VMs; a big virtual box is still a big box. The traditional model is likely to be replaced across most of the industry by ephemeral application services in the data plane managed by a centralized control plane, as Snapt Nova and Avi Networks are doing already.

Second, transitional app services that support traditional and cloud-native apps will be less valuable. This opens opportunities for app services to focus entirely on modern app architectures and workflows without being held back by the need for legacy compatibility.

Thirdly, app services will need to achieve vast and rapid scalability, with load balancing, security, and content acceleration functions scaling-out and scaling-in in seconds, in response to bursts of traffic – both north-south and east-west. Traditional performance limits and delays in creating/destroying extra capacity will have to be thrown away.

Orchestration Wars

Back in 2013, when Microsoft was launching the Xbox One, with its focus on “TV, TV, TV”, there was this idea that the most important goal for any media box (including a games console) was to be connected to “input 1” on your TV. In other words, to be the default source – the one place to go for almost everything you need.

A similar goal will take hold among application infrastructure – to be the one orchestration platform to rule them all. Tool sprawl and fragmentation introduce complexity and vulnerability into large distributed systems. A platform that can provide monitoring, control, and automation for most application workflows will win many customers, particularly those who need to keep things simple.

We already have orchestration platforms like Microsoft’s Hyper-V and the open-source Kubernetes, which manage VMs and containers. And we have even broader orchestration platforms like MuleSoft that manage mediation, transport protocols, data transformation, and more between any integrated services.

At the same time, application infrastructure is adding its own orchestration layer, with a decoupled control plane and data plane, enabling centralized controllers to automate any number of app services in the data plane. These platforms are starting to suck up more and more data about the connected backends and applications, giving them the potential to do more than manage app services.

The question for the next few years is: will application infrastructure grow in scope to provide more functions (like provisioning cloud capacity and managing containers directly) or become easier to integrate with other orchestration platforms? Using an application delivery platform to orchestrate scale-up in server capacity, application capacity, and app service capacity with tight integration could improve overall responsiveness, resulting in fewer performance drops and fewer wasted resources from over-provisioning.

Composable Enterprises

From orchestration to composability. I guess we like our musical metaphors. Maybe because timing, structure, and dynamics are as important in business as they are in a good tune. We all recognize that businesses need to be more dynamic and adaptable to changing business needs – Gartner predicts that business capabilities must “evolve from their current state of inflexible, monolithic applications toward a portfolio that is more modular and adaptable to business change”.

Few things are as damaging to adaptability (and therefore to the composable enterprise) than long-term commitments that bind future decision-making. One of the United Kingdom’s constitutional principles is that Parliament may not bind its successor. If only IT departments had such a constitution.

Instead, infrastructure procurement is rife with vendor lock-in and costly investment in products that become obsolete before they’ve even been paid off. While offering attractive pricing, feature bundling discourages businesses from adopting best-of-breed solutions from dedicated suppliers. One-size-fits-all standardization means businesses miss out on solutions designed for their size, industry, location, etc.

Composable enterprises will look for modular app services from best-of-breed vendors designed for their use cases. Traditional vendors might struggle to retain market share as more nimble competitors focus on meeting the needs of every conceivable niche and discard the old-fashioned business processes that are a big turn-off for so many buyers.

Application services such as load balancers and web application firewalls will likely need to pursue one of three paths.

  1. Niche Leader: focus on being the best at one thing and capture that market.
  2. Adaptable Design: focus on removing constraints on portability, scalability, and integration while retaining a hardened core service.
  3. Open Source: be totally customizable and allow customers to modify the product.

Those who try to meet every use case in one static commercial product will be outpaced in agility and outclassed in capability.

Invisible Infrastructure

It’s easy to identify a hacker in a Hollywood movie – it’ll be the person typing fast, filling the screen with reams of nonsense code, while possibly muttering something about IP addresses. TVTropes calls this phenomenon “Rapid-Fire Typing”. We laugh, but there is a kernel of truth: some users really don’t care about the slick web GUI you built for your product. Keyboard shortcuts > mouse.

A nice GUI frontend can work wonders for accessibility, but let’s be real: if you’re a whizz with a CLI or – even better – automation and deploying infrastructure as code, then a GUI with lots of comfortable padding slows you down. For these users, application infrastructure needs to become invisible.

The DevOps crowd can deploy new environments, new apps, and – more granularly – new parts of apps with a few commands or with automation that handles modern deployment strategies like testing in production. Let’s say they need an extra load balancer for a new test environment – should they have to download and install a new software image and purchase and provision a new serial key? The idea is frankly Stone Age.

But we can go further. Should they go to their browser, log in to their ADC’s web portal, input all the config for their new backend, then go to the load balancer section to set up a new instance in that backend? That’s a whole lot of clicks. OK for some users, but not all.

For app services to meet the needs of DevOps teams, they need to become API-first, controllable with short commands or via API-driven automation. App services will need to become smaller and more granular: per backend, per app, per service, per microservice. To enable complete integration with typical DevOps workflows, they must lean heavily into the infrastructure-as-code movement.

Combine this with an openness to orchestration and integration (covered in the previous section). You might have app services that disappear entirely – operating as essential and automated parts of every environment and application. Not created or configured by specific commands, but always there. Invisible and out of mind, but omnipresent and utterly dependable.

Contextual Awareness

I never cease to be amazed by the autocomplete suggestions in Google Docs comments. It’s eerie how accurately Google can predict just how savage my feedback will be and the devastating combination of words that will convey just how little I think of your first draft.

The key to getting this right is that Google is aware of the contextual shortcomings in the text. If I’m staring at an incomplete sentence and I start to write a comment “Inco-“, Google knows I mean to write “Incomplete sentence.” Context matters.

Application services aren’t dumb. Contextual awareness improves the UX and reduces the time to configure new services. For example, awareness of backends, service discovery, centralized awareness of countless nodes, and anticipation of user intent all streamline everyday processes. So what’s next?

App services might become more aware of the function of the underlying applications – their purposes, and what’s most important to fulfilling those purposes. With this awareness, the app services could self-optimize to meet those needs.

They might become more aware of application users and website visitors – their histories and likely intent. With this awareness, the app services could self-optimize to meet the needs of individual users.

They might become more aware of whole network topologies and the global trends and anomalies in traffic beyond the bounds of the host’s network. With this awareness, they could self-optimize pre-emptively in anticipation of shifts, problems, threats, and scale events, eliminating response times.

Smarter Decision-Making

I suck at making decisions. To be precise, I suck at making some categories of decisions. I like to think I’ve got a handle on the big picture stuff, like “what’s important to me?”, “what are my criteria for success?” or “what setbacks do I want to avoid?”. But there are other decisions that I’m almost certainly managing poorly.

  • Which is the most efficient route to travel to my destination?
  • Is it safe to allow someone into my building just because they claim over the intercom to have a delivery?
  • Is packaged meal A healthier for me than packaged meal B?

To be confident of choosing correctly, I would need access to reliable real-time data in these instances. But there are too many choices to make this approach viable in my life (and yours too, probably).

We rely on application services to handle low-level decisions in our app infrastructure. Load balancing algorithms – do I send traffic here or there? WAF rules – block or allow? Pretty straightforward. But that still leaves many higher-order decisions for users to make themselves, like “Is now the right time to scale out/in?” or “Is this anomaly something I should worry about?”.

These decisions also require a lot of real-time data and analytical capabilities, or (more realistically) a lot of experience and good instincts. But these have limits in even the best human operators. As app deployments get bigger and more complex and the consequences of failure more severe, the value of automated decision-making grows.

This is where fast, hyper-connected application delivery platforms have the potential to change the game. Modern platforms are already ingesting vast quantities of data about backends, applications, users, and threat intelligence. Advanced machine learning enables autonomous decision-making on application security, scaling, and anomaly detection and alerting, with faster and more accurate results than human operators could achieve.

Where do we go next?

What if you could instruct your app delivery platform on the big picture stuff, and it could handle the decision-making functions within those priorities and constraints? For example, you might prioritize performance and security and deprioritize cost.

In this example, the platform would self-optimize apps and app services for real-time health monitoring and very low latency in response to scale events and failures, with multiple redundancies, and for high security, with little or no attempt to save on cloud, bandwidth, and service costs.

The platform could help users understand the trade-offs: prioritizing one thing might inherently compromise another. For example, if you prioritize multi-cloud active redundancy, the platform might limit how far you could simultaneously prioritize low costs.

Rather than translating user priorities into pre-set configurations, a platform armed with machine learning and enough data could build a picture of what a deployment that prioritizes uptime and achieves it consistently looks like. This data-driven picture might look very different from what we would assume.

Self-configuring and optimizing an app deployment to match the pattern for the most highly available networks could drive substantial improvements and lead to best practices being rewritten.

 

Those are my predictions. I’m sure I’ll be wrong somewhere, if not everywhere. But now I’d like to hear from you. Find Snapt on social media and tell us what you think will happen next.

Subscribe via Email

Get daily blog updates straight to your email inbox.

You have successfully been subscribed!