Implied in that question is the conclusion that you should.
For decades now we have been deploying the application services that comprise much of the production pipeline on shared platforms. Application services like load balancing, application performance services, WAF, and federated identity are provided by NetOps on shared infrastructure often in the form of an Application Delivery Controller (ADC).
But time and demand – along with emerging application architectures like microservices – are forcing changes in that pipeline. These changes are good, both for NetOps and DevOps alike, because they are moving to a model that aligns more closely with deployment schedules and operational practices like infrastructure as code.
There are some application services that remain firmly entrenched on shared infrastructure. DNS. Defense against volumetric DDoS attacks. Network firewalls. These services are by nature corporate services. That is, they are designed to protect, defend, and serve the business. If these services fail? No productivity or profit across the business.
But other application services are highly application affine; their configurations, APIs, and services are often configured specifically to support a single application. Not a single architecture, but a single application.
Responsibility for these services are increasingly shifting left toward application operations (DevOps) and engaging the developers that deliver applications. And while a shared model can (and often does) still work to provide the delivery and security application services necessary, a per-app model for many of them is desirable for several reasons.
First, a per-app model neatly resolves deployment schedule conflicts. Enterprise organizations are often constrained by shared infrastructure conflicts with respect to configuration and deployment of the application services it supports. Shared infrastructure means shared resources, which invariably raises the potential for a clash of configurations. By eliminating that possibility, resistance to more frequent or off-schedule deployments can be mitigated. After all, if an application services is dedicated to my application, and running on its own platform with its own resources, the conflict is neatly resolved. My app, my risk.
Second, a per-app model supports emerging automation efforts that include putting into practice methodologies like infrastructure as code. By dedicating resources and platform to a single application, the configuration includes only that application. Immutability can be enforced, and the risk of entropy avoided. In fact, I’d argue (and recently did) that you can’t properly do immutable infrastructure without a per-app architecture. This approach enables inclusion in a continuous deployment pipeline that extends beyond application infrastructure and into “the network.” Providing this capability means shifting the responsibility of configuration and ongoing management from NetOps to DevOps. The good news is that with that greater responsibility comes greater control, as DevOps becomes the “owner” of the application service and is empowered to upgrade, patch, and re-deploy on its own terms and schedules.
Lastly, a per-app model is immediately more portable. Without being tethered to a shared platform and relying almost exclusively on deployment artifacts (configurations and templates), the bulk of the production pipeline becomes able to migrate from cloud to cloud, on-premises to off, with far less friction and effort. That freedom offers organizations the ability to choose the best cloud and location for the application in question without being constrained by costs associated with migration.
DevOps can benefit greatly from encouraging the adoption of a per-app architecture for application services, both on-premises and in the public cloud. With NetOps under pressure to provide greater control and visibility to other operational domains, now would be a good time to grab some pizza and beer and have a conversation with your NetOps counterparts about moving to support a next-generation, application-centric per-app architecture.
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...