In my role as a Principal Consulting vArchitect at VCE, I function as an evangelist for solutions on the Vblock. These solutions focus not only on Infrastructure-as-a-Service, but Platform-as-a-Service as well. In particular, I have been looking at technologies such as Cisco Intelligent Automation Cloud and VMware’s vFabric Suite.
Lately, I’ve been learning more about vFabric Elastic Memory for Java (EM4J) and how it solves a well-known problem that has plagued Java programmers for years. However, as IT continues to move to a service-oriented model and DevOps continue to gain traction in the Enterprise, infrastructure administrators need to understand the impact of technologies such EM4J to them and the developer community they support.
A Solution To a Long Standing Problem
One of the challenges when running a Java application is memory management. Since Java memory heaps are static entities, often too much or too little memory are assigned to Java Virtual Machines (JVMs). Assigning too much memory can be a waste of resources and can sometimes lead to poor performance through long garbage collection pauses. Conversely, if a JVM (not to be confused with a vSphere VM) does not have enough memory, the application may encounter an out-of-memory exception error and simply crash. Not only does this negatively impact developers, but also impacts the server or vSphere admin who is challenged with either having to over-allocate and potentially wast precious server resources or dealing with the consequences of potential under-allocation of resources; in the latter situation, to prevent or to resolve application crashes, the infrastructure admin may have to go through the fire drill that comes with having to assign resources needed to created additional JVMs on the fly.
One way to resolve this conundrum would be to provide a way to pool RAM resources across a group of JVMs being hosted on the same 
ESXi host, with the ability to reclaim unused memory from any JVM and reallocate it, on the fly, to another JVM that is under memory pressure. Any vSphere admin will quickly recognize this as being analogous to the Memory Balloon Driver, used by vSphere to reclaim and to reallocate memory resources across vSphere Virtual Machines (VMs).
EM4J is an extension of this technology up to the Java layer to allow RAM resources to be pooled across JVMs. EM4J is essentially an agent that runs directly inside a JVM and manages memory inside the Java heap using a “memory balloon.” When Java doesn’t occupy the entirety of a JVM, the agent allocates new or unused objects to the Java heap, inflating the memory balloon and using up available RAM. The memory associated with these objects is then reclaimed by the ESXi server, which can then reallocate this memory to other VMs, running JVMs under memory pressure.
The benefits of this technology should be readily apparent to anyone involved in Java development or to anyone who supports Java developers. It allows higher consolidation of JVMs, better utilization of resources, and true elasticity in a PaaS environment. It is imperative that vSphere admins step out of their comfort zone in the infrastructure space and begin to understand and to seek to bring more value to their developer communities.
To learn more about EM4J, I suggest exploring the vFabric webpage and watching the video below. To learn more about the vFabric Suite, I highly recommend listening to Al Sargent, Group Product Marketing Manager at VMware, talk about the launch of vFabric 5.1, on the VMware Community Podcast.
The Future of PaaS Elasticity?
While EM4J is an important and valuable resource management technology for application development environments, it does not help when physical resources are exhausted on the ESXi host where the JVMs resides and resources are not available on other hosts in the DRS cluster to allow for workload re-balancing. In that situation, either additional physical RAM have to be added to a host or a new ESXi server has to be spun up and JVMs rebalanced across the cluster; the task is even more complicated if additional physical resources have to be added to host additional VMs.
What if the concept behind a resource management technology, such as EM4J, could be extended “below” the hypervisor, to allow for automated provisioning and elasticity of the physical infrastructure as well, i.e. compute, networking, and storage? For example, using software in the vFabric Suite, when Application Performance Manager (APM) detects an out of resource condition, it would make an API call to Application Director to add resources to the application server or database server VMs running within the vFabric framework. If physical resources are exhausted, App Director could than use a workflow engine, like vCenter Orchestrator, to automatically provision additional physical resources, deploy new ESXi hosts, and to create new VMs. Once those resources are no longer needed, a policy engine would initiate the workflow to decommission physical and virtual resources and release them back to their resource pools.
I do not know of any products that can currently provide this type of automation and elasticity; but my expectation is that someone will deliver on such a such a feature in the near future and will have a leg up on building the next generation of PaaS Clouds. What do you think? Is this the type of automation and elasticity something that would be of value to the developers you support?
Cloud Architect Musings 