Why A Per-App Approach to Application Services Matters

I can’t read minds (my kids would disagree but that’s neither here nor there) but I can read the responses to our State of Application Delivery survey. And when I read them through the lens of self-identified app developers I see a very interesting picture emerge.

Developers care about speed. And security. And scale. Not necessarily in that order, but they care about all three. Not only do they care, but they recognize the value of application services to help them achieve all three.

To wit, developers not only want vague ‘acceleration’ application services, they want specific services that provide TCP optimizations and caching. They want a web application firewall, and some load balancing, to boot.

The problem is that most of these application services are delivered in a shared infrastructure model. Each application gets its own “virtual representation” but it physically resides on a shared piece of software or hardware.

This can cause real problems – and is in part a source of the friction that remains between IT and app dev. It’s this shared nature of systems that brought us change windows and review boards and Saturday night deploys (with pizza, to keep us placated) – the processes that slow down development and make deployment a frustrating experience for all involved. 

We’re no longer deploying monolithic monster apps. Even if we haven’t gone manic microservices and decomposed apps into hundreds of little services, we still have more apps that are on more frequent deployment schedules. Apps that are developed in week-long sprints rather than year-long projects, and need to push updates faster and more frequently.

That, ultimately, is more of the reason (public) cloud has been so successful. Because it’s my app and my infrastructure and I don’t have to wait for Bob or Alice or John before I push an update. Because it’s all mine, and it’s all on me if it goes wrong.

That same approach is possible (and preferable, I should think) on-premises, as well. What’s necessary is for all the pieces and parts that make up the delivery chain for an application to support the same kind of per-app approach that cloud has made desirable.

Basically, a per-app approach to delivering the network and application services needed is akin to dedicating a subnet to the application; an app delivery VLAN, if you will. It’s all about that one app, with dedicated services.

That kind of isolation is not only good for deployment schedules, but it’s good for everyone else, too. Failure happens, and when it does you want to restrict the blast radius as much as possible. Per-app architectures means a tightly constrained failure impact, which makes all those people on-call “just in case” happy because they didn’t get that call. I can release and deploy every week without running afoul of the apps that release and deploy once a month. My app, my services, my deployment schedule.

A per-app architecture also makes it easy to troubleshoot issues that crop up in production. And they often do. In fact, 50% of developers reported issues in production after code release in a 2017 Atlassian survey. There’s no chance someone else made a change that might impact the application. You can get straight to the systems involved rather than spending valuable time figuring out which systems might be involved.

A per-app architecture naturally fits better with cloud – whether public or private – because that’s the assumption made by the model. Each app has a dedicated set of application services to scale, speed up, and secure it.

The reality is that a per-app architecture was inevitable. This isn’t the first time I’ve said that. The gravity of applications is too strong to ignore, and the increasingly application-specific security needed to keep an application safe meant a per-app approach was going to come about sooner or later.

And it’s a good thing, because those application services developers want are, more often than not, application-specific. What works for one isn’t necessarily going to work for the other – and may in fact be a negative. By embracing a per-app architectural approach to application delivery you can ensure that developers are not only getting what they want and need to scale, secure, and speed up apps, but you can better support the self-service model they expect from cloud whether on-premises or off.