Getting Multi-cloud Right with Per-app Architectures

Before we tackle the how, it's important to lay out what is meant by "per-app" architectures.

Per-app architectures are a logical construct that may or may not be mirrored in the physical world. That is, having a per-app architecture is about a dedicated data path per application rather than dedicated devices. Per-app architectures are describing the logical topology rather than the physical. Cloud-based application deployments can be described as per-app architectures, even though most of the underlying network services and some application services execute as shared services. That’s because they are defined by policies that are application specific and force traffic to flow based on a logical per-app topology.  

That said, if the goal is to move an application (and its supporting application services) to the cloud, then the most efficient model will be a logical and physical per-app architecture. That means identifying and separating out the application services and infrastructure that require application specificity and implementing them as virtual or software-based components that are dedicating to that application.

Some services – network and application – are tightly bound to the application. Load balancing and web application security, caching, and performance-related functionality are refined based on the application they are supporting. Network and network security in the data center are generally corporate services whose policy is intertwined with its configuration. They support and secure all applications but are beholden to none. Per-site services are shared services, whereas per-app services are dedicated to a single application.

Don’t be fooled; you aren’t moving an application, you’re moving an application architecture. That includes the application middleware and application services you need to secure and scale your app. Yes, you could adopt the cloud provider complements of those application services, but you’ll be adding time, effort, and operational overhead to do so. Each foreign service adopted incurs the same overhead and costs as any new device (and vendor) brought into the data center. Cloud-based application services are as much products as any traditional product. Each has its own API, operational model, consoles, and quirks and flaws. That forces data center operators to learn and manage those services atop all their existing services. It adds to the operational overhead required to deploy and support an application.

Per-app architectures are an answer to avoiding (or at least minimizing) that whilst also providing greater consistency of policies and procedures in a multi-cloud environment. That consistency is critical when considering compliance with both corporate and governmental expectations. Using two different web application firewall services, for example, can provide vastly different levels of protections. Achieving functional parity in the cloud with on-premises can be challenging when using a variety of providers for similar application services. Using the same application services in the cloud(s) as on-premises means leveraging existing investments in skills and certifications and ensures policy parity that cannot be achieved in a heterogeneous deployment. 

Using the same application services in the cloud(s) as on-premises means understanding the architecture that will be deployed. This is where mirroring the logical topology in the physical becomes valuable. While per-app architectures can be implemented using shared physical devices, it is far better in terms of portability and speed to mirror the logical in the physical. Using virtual or software-based components to provide the application services and infrastructure necessary gives you a good foundation for migration to a cloud-based environment.

Identifying the per-app components of an application architecture is achieved by recognizing those services for which policy is tied to the application. In practice, that means you really can’t deploy the service without tweaking it to fit the application. For example, a fully operational web application firewall policy that protects one application is unlikely to protect a different application. This is because many of its protections are application – and API – specific. Protections are often triggered based on a specific URI or even the presence of a given element in an HTTP message. That level of specificity makes the web application firewall a per-app application service.

Configuration, on the other hand, is specific to the site. The network topology in the data center is not the same as in the cloud. Nor should it be. The configuration must necessarily be different based on the environment. This is not true of policy, which is tied to the application layer and thus is not (or should not be) impacted by the configuration.

The reason this is important is because logically separating per-app and per-site elements immediately improves the portability of that application architecture. Configuration is still required, but application services that separate policy from configuration means less time spent porting the policy to the cloud. Service policies intertwined with configuration means you must recreate the entire configuration when moving to the cloud. Recreation means opportunity to introduce error. When service policies are extracted from configuration, they can be reused with minimal effort as there is less environment (per-site) related variables and parameters that must be addressed. With the increasing inclusion of auto-discovery capabilities within application services, the impact of the required per-site network topology is minimized, and operators can focus on per-app policies rather than configuration.

Per-app architectures are also well-suited to answering the DevOps challenge of faster and more frequent deployments. It is an excellent means of separating out shared components with lower tolerance for risk and higher demand for stability from per-app components with high tolerances for risk and lower demand for stability. Such an effort makes it feasible to be more protective of the reliability and stability of core shared components while affording DevOps and Dev more flexibility in deployment and testing of per-app components. These benefits make per-app architectures a boon for those migrating to the cloud as well as those staying on-premises.