In the last couple of months I have done quite a bit of business travel – spent few weeks in Russia and Japan (travel photos). One of the subjects that came up often in discussions with customers was the problem of consolidating multiple Java workloads and reducing the server sprawl. However there is this complication – in most cases these workloads (applications) belong to different lines of businesses and those who are responsible for running the business are not willing to share the platform with others. Why not? Just think what happens with the hardware and software in production when there is an unexpected (or expected) increase in workload in an all-shared non-isolated environment (i.e. when you deploy all of your Java apps into the same domain or OS instances are shared)? Network, disk and CPU utilization goes up, response time goes down. In some cases you might have a complete saturation and even crashes of the platform. Nobody wants that kind of risk and this is why workload isolation was “invented”. There are many ways to isolate workloads from each other, ranging from various kinds of hardware and software virtualization up to having dedicated hardware and software stack.
Extreme case of isolating workloads into separate hardware servers in most cases is not economically viable (over-provisioning for peak – anyone?). To fix that, there is this “thing” called workload consolidation, which is designed to reduce hardware and software footprint for diverse workloads. However there are complications. Suppose we have many Java EE applications. Do we deploy them into the same App Server cluster? Same domain? Same OS but different domains? Lets consider the technical issues of the Java workload consolidation for private data center environment:
- First – different applications have their own peaks and valleys of requests at different times and must obey certain level of SLA from the client perspective (for example, average response time must be under 2 seconds).
- Second – different applications must not interfere with each other and 10x increase in workload for one application must not cause SLA violation for other applications sharing the cluster or OS.
- Third – traditional approach of isolating applications by running many independent stack instances (hw-OS-JVM-AppServer-Application) results in expensive resource overhead. Virtual images are not quite as expensive as physical, but still expensive as it requires additional CPU, memory, disks, etc. to run the stack.
- Fourth – server sprawl (virtual and physical) means a lot of additional administrative complexity, additional license cost, room for security breaches, etc.
Looking at these issues from a business perspective we have the following considerations:
- First – running on the isolated hw/sw stack is way too expensive (capital and operating costs).
- Second – running on the combined stack means risk of potential SLA violation and can result in revenue loss, etc. (it is said that every 1 second of delay in app response time leads to 7% customer dropout rate).
Q: The billion dollar question is – can you have your cake and eat it too? In other words, can you consolidate your applications, but not have to suffer SLA violations and administrative costs?
A: Yes with WebSphere Application Server Network Deployment. If you run on WebLogic, Tomcat, JBoss or other platform you have no way of separating Java workloads and no way to preserve a predefined level of SLA for multiple applications sharing your platform, unless you create redundant layers for each workload and pay capital and operating costs to maintain these layers.
Q: Is this going to cost me extra in license for some fancy IBM software?
A: Nope. This is built into the WAS ND 8.5.5.x at no extra charge since 2013. It used to be expensive add-on called WebSphere Virtual Enterprise, but no more.
Q: It must be real hard to set it up and require a bunch of $$$ in IBM consulting fees or a PhD from MIT?
A: Wrong again. The setup is pretty simple. I will record a demo and post as a separate article on this blog – starting from blank OS up to a running dynamic cluster with defined SLAs and several running apps in about an 1 hour (I will record and post a demo next week).
Here is the demo of the WebSphere Application Server Network Deployment in action – dynamic clustering is being used to handle several different applications with different SLAs defined and sudden spikes in request volumes. Note that this approach provides centralized and easy management approach as well as minimizes resource overhead by on-the-fly reallocation of server resources to the workload that needs it most:
Now that you have seen WAS dynamic clustering in action, the logical question is – how does it compare to WebLogic and JBoss or Tomcat environment? Short answer is that with these products you will likely have to setup individual domains of servers in their own OS instances with the need to manage each domain separately, increase disk, memory and CPU footprint and likely increase license cost since you will need more cores and memory to run the same workload – in many cases you will have to provision for the peak workload and that will result in a low utilization of resources. You pay for 100% of your hardware and software, but will end up using only 20% on average. Not very effective.
You might be interested in these related posts:
- WebSphere Liberty auto scaling
- Dynamic clustering (auto scaling) in WebSphere, WebLogic, JBoss and Tomcat