Application Portability - Going beyond IaaS and PaaS - Part 1
The other day, I was studying economies of scale for virtual machine (VMs) deployments for a client and tried to benchmark these with standard cloud deployment models - on and off premise. The VMs provide a dedicated run-time environment for a specific application based on the supported stack. In today's world, while the VM densities are increasing based on the processing and compute innovations at the hardware layer, application densities are not increasing due to the inability to support multiple stacks/ runtimes at a single OS level.
I tried to analyze this scenario with use cases that we have tried to address with client virtualization solutions - Citrix XenApp, App-v etc. Application virtualization essentially achieves this kind of isolation, where applications are packaged and streamed to client OS irrespective of the local OS preference. This results in multiple versions of the same application and applications certified on multiple stacks to be virtually run from the same client OS.
How can this process be replicated within an enterprise? As I pondered on this issue, I happened to meet with an old friend and a Linux geek in the subway. Our discussions led to deeper insights into the next wave of virtualization that we believe will redefine the way applications will be delivered in future. This will be a model that will enable cost effective PaaS model that provide massive scale, security and portability for applications. This prompted the following questions:
- How can we enable standard VMs to support multiple apps- each having its own run-time dependencies?
- Today's application teams need a plethora of development frameworks and tools. Can these be supported in one "box"?
- How are PaaS providers delivering the environments today? How do they achieve the economies of scale while supporting these needs - or do they?
- How complicated is it to use sandboxes to isolate application runtimes?
- Can the Dev team get a library that is not in the standard "build" that the technology team offers today? Do we need to update technology stacks such that this library can be supported?
To put it simply - Do we give application teams, a fully layered OS image, complete with libraries in a VM - OR would a "light-weight" container for the application to be packaged with its dependencies (libraries and run-time needs) isolated from the underlying OS and H/W suffice?
Welcome to the world of Application Containers.Here is how it works:
The infrastructure team creates a container image for the application team to layer with dependencies and later hand it over to infrastructure team for management. Now, the application is packaged as if it is running in its own host, with no conflicts with other applications that may also be running on the same machine.
Instead of having 100 VMs per server, I am now talking about thousands of hardware-isolated applications running on a single physical or virtual host. Such application container technologies can package an application and its dependencies in a virtual container that can run on any virtual or physical server. This helps enable flexibility and portability on where the application can run, be it on-premise public cloud, private cloud or otherwise.
In my next post, I will talk more about the underlying technology, its benefits, strategies around adoption and migrations.