How Cloud and Containers are Driving Application Services to Disaggregate

• Applications drive decisions on everything from location to form-factor of supporting delivery infrastructure. 55% of organizations choose a cloud based on application needs and requirements. 40% want to be able to choose the right form-factor for the app. (State of Application Delivery 2018)
• As cloud and microservices architectures break up and distribute apps, shared infrastructure becomes a burden instead of a benefit, driving up capital and operational costs 
• Cost, configuration, and upgrades are key drivers of supporting per-app architectures with per-app application services.
• A per-app approach for application services is necessary to support modern apps and architectures

In the past few years we’ve seen a concerted effort from cloud providers – Amazon, Microsoft, Google, et al. – to answer the very enterprise need for application services.

You can find a number (and it’s growing) of application services in cloud marketplaces today that address security (like web application firewalls) as well as performance (caching) and even identity management. This is no surprise. Enterprises depend on an average of 16 different application services to make their apps go faster and safer. Every year that number grows larger. Enterprises aren’t going to sacrifice them for the speed of cloud.

In that respect, application services are influencing both customers and cloud providers. But it’s not a one way street. Cloud – and increasingly containers – is also having a significant impact on application services and how they are delivered.  

As enterprise organizations continue to invest in private (on-premises) cloud and experiment with containers, they are finding that the traditional model of delivering application services isn’t always a good fit.

Like most of the network, application services have long been delivered via a platform (often called an Application Delivery Controller or ADC for short) supported by scalable, reliable hardware. These devices were designed for high availability and scalability, able to support hundreds of applications simultaneously. Shared infrastructure – whether network or application –has long had advantages in terms of costs. Spreading the capital and operational expense across multiple applications made sense.

Until apps and architectures emerged where it didn’t.

There are a growing number of apps and architectures that require a more application-affine approach. The modern menagerie of microservices, for example, demands a fast, scalable, and affordable platform on which to deploy application services for a single application.

Shared service platforms can’t meet that demand the way a purposefully architected per-app platform can. There are three good reasons for that:

1. Cost. You don’t go out and buy a twelve-passenger van if you’re the only person who will ever use it. All that extra space costs extra money up front and to run. In the right situations (and for the right applications) shared infrastructure lowers the cost per application and makes great financial and operational sense. But if you’re trying to support only a single application, it only adds up expenses without adding value.
2. Configs. Modern apps and architectures are being developed and deployed with frequent updates in mind. If you’re sharing a platform with eight other apps – that aren’t on the same schedule – they might be a bit miffed if something goes wrong and impacts their applications. Not to mention that the more configurations – and the larger they get – the more time it takes to read and verify those configs every time they need to be reloaded or changed.
3. Upgrades. When Bob wants to upgrade that shared platform and you don’t, who wins? If Bob wins - and it breaks an application - no one wins, that’s who.  Upgrades of shared infrastructure can be a scary proposition. They can also lead to additional time spent updating or upgrading (or even migrating) configurations to the newest versions, which takes us right back to issue number one and the costs that can add up.

There is a need (and a demand) for an application service platform designed purposefully to support only a single application. By reducing the responsibility to a single application reduces the size (and complexity) of the configuration, limits the blast radius of a failed upgrade to a single app, and lowers the cost of both acquisition and operation.

Because of cloud, and containers, and microservices. Because of DevOps and the digital economy that drives organizations to deliver faster and more frequently.

Applications and architectures are changing. Environments are changing. That means application services – and their delivery mechanisms – must change as well.