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.
About the Author

Related Blog Posts

F5 accelerates and secures AI inference at scale with NVIDIA Cloud Partner reference architecture
F5’s inclusion within the NVIDIA Cloud Partner (NCP) reference architecture enables secure, high-performance AI infrastructure that scales efficiently to support advanced AI workloads.
F5 Silverline Mitigates Record-Breaking DDoS Attacks
Malicious attacks are increasing in scale and complexity, threatening to overwhelm and breach the internal resources of businesses globally. Often, these attacks combine high-volume traffic with stealthy, low-and-slow, application-targeted attack techniques, powered by either automated botnets or human-driven tools.
F5 Silverline: Our Data Centers are your Data Centers
Customers count on F5 Silverline Managed Security Services to secure their digital assets, and in order for us to deliver a highly dependable service at global scale we host our infrastructure in the most reliable and well-connected locations in the world. And when F5 needs reliable and well-connected locations, we turn to Equinix, a leading provider of digital infrastructure.
Volterra and the Power of the Distributed Cloud (Video)
How can organizations fully harness the power of multi-cloud and edge computing? VPs Mark Weiner and James Feger join the DevCentral team for a video discussion on how F5 and Volterra can help.
Phishing Attacks Soar 220% During COVID-19 Peak as Cybercriminal Opportunism Intensifies
David Warburton, author of the F5 Labs 2020 Phishing and Fraud Report, describes how fraudsters are adapting to the pandemic and maps out the trends ahead in this video, with summary comments.
The Internet of (Increasingly Scary) Things
There is a lot of FUD (Fear, Uncertainty, and Doubt) that gets attached to any emerging technology trend, particularly when it involves vast legions of consumers eager to participate. And while it’s easy enough to shrug off the paranoia that bots...
