Standardization at the application platform layer enables specialization of infrastructure resulting in greater economy of scale

In all versions of Dungeons and Dragons there is a nifty arcane spell for wizards called “Mirror Image.” What this nifty spell does is duplicates an image of the wizard. This is useful because it’s really hard for all those nasty orcs, goblins, and bugbears to tell which image is the real one. Every image does exactly what the “real” wizard does. The wizard is not impacted by the dismissal of one of the images; neither are the other images impacted by the dismissal of  other images. Each one is exactly the same and yet each one is viewed by its opponents as individuals entities. An illusion, of course, but an effective one.

In the past an “application” has been a lot like that wizard. It’s a single entity, albeit one that might be comprised of several tiers of functionality. cloud computing – specifically its ability to enable scale in an elastic manner - changes that dramatically, making an “application” more like a wizard plus all his mirror images than a single entity. This is the epitome of standardization at the platform layers and what ultimately allows infrastructure to specialize and achieve greater economies of scale.

Some of the benefits of cloud computing will only be achieved through standardization. Not the kind of standardization that comes from RFCs and vendor-driven specifications but the standardization that happens within the organization, across IT. It’s the standardization of the application deployment environment, for example, that drives economy of scale into the realm of manageable. If every JavaEE application is deployed on the same, standardized “image”, then automation becomes a simple, repeatable process of rolling out new images (provisioning) and hooking up the server in the right places to its supporting infrastructure. It makes deployment and ultimately scalability an efficient process that can be easily automated and thus reduce the operational costs associated with such IT tasks. This also results in a better economy of scale, i.e. the process doesn’t exponentially increase costs and time as applications scale.

But just because the application infrastructure may be standardized does not mean the applications deployed on those platforms are standardized. They’re still unique and may require different configuration tweaking to achieve optimal performance…which defeats the purpose of standardization and reverses the operational gains achieved. You’re right back where you started.

Unless you apply a bit of “application delivery magic.”

Many of the “tweaks” applied to specific application servers can be achieved through an application delivery platform. That’s your modern Load balancer, by the way, and it’s capable of a whole lot more than just load balancing. It’s the gatekeeper through which application messages must flow to communicate with the application instances and when it’s placed in front of those images it becomes, for communications purposes, the application. That means it is the endpoint to which clients connect, and it, in turn, communicates with the application instances.

This gives the application delivery platform the strategic position necessary to provide application and network optimizations (tweaks) for all applications. Furthermore, it can apply application specific – not application platform specific, but application specific – optimizations and tweaks. That means you can standardize your application deployment platform across all applications because you can leverage a centralized, dynamic application delivery platform to customize and further optimize the application’s performance in a non-disruptive, transparent way.

It sounds counter-intuitive, but standardization at the application platform layer allows for specialization at the application delivery layer. 

(Parenthetical aside: This is part of the nature of a dynamic infrastructure – the ability to determine on-demand what policies are applicable based on network, application, and client status and conditions)

The reason this is true is that some applications will need more security (and different kinds of security). Others need compression regardless of client-access conditions while others only need it under certain network conditions. Other applications can be much improved by the application of caching at the perimeter of the network, while others will only see small gains in performance that aren’t really worth the cost to provide the caching service. Some applications need to be integrated with corporate identity resources and others are stand-alone. Different applications need different application delivery services. Pushing application-specific delivery policy enablement and enforcement into the application delivery tier allows the applications to remain on standardized platforms while allowing only the application delivery services needed by the application – and the client – to be invoked.

That’s dynamic infrastructure; it’s pay for what you need (not pay for what you use or use what you need but a more efficient, flexible combination of the two models) and thus operationally and financially more efficient, resulting in benefits to all applications and clients.

What we want as a result of casting our “mirror image” spell on the data center, a.k.a. platform standardization, is to enable the rapid provisioning of application platforms and ultimately applications such that network automation can occur. But we don’t want to adversely impact performance, security, or delivery of those applications. By standardizing in the application platform layer we can then apply the principles of a dynamic infrastructure to ensure we can scale, secure, and keep available all instances of an application while maintaining the illusion that each one is a customized, specialized individual entity through specialization with dynamic application delivery policies.