In September 2015, IBM introduced beta support for autoscale clusters using Docker and now this capability is fully supported. However setting it all up from scratch takes some time and is not a trivial exercise. What if you need to set up dozens of different environments in QA, performance test, production, etc.?
I don’t know about you, but I like when my installation and deployments are repeatable and consistent. Hence I try to automate anything that I have to do more than once. You can find many admin scripts in the Download section of this site. Scripts are great because they can be used directly by humans or built into an overall DevOps automation pipeline.
Autoscaled clusters are great because they allow you to optimally use computational resources by scaling the size of the cluster up or down according to the workload on the system. Most applications have very ‘peaky’ workloads. Some of these peaks are easy to predict, such as special promotions, holiday shopping, tax season, etc. Other peaks are unexpected and could be driven by natural disasters, viral videos, stock market fluctuations, etc. Regardless of the nature of the peak or valley in your workload, it is a good idea not only to¬† maintain appropriate response time, but also do it with a minimum amount of system resources.
The traditional approach in enterprise IT has been to provision for the peak plus 30% extra capacity on top of that. The problem with this approach is that your company has to spend a large amount of funds to procure and set up hardware, software, networking, etc., yet the average utilization rate for the computing resource is around 10% on average per year. This means you have spent 100% of your IT budget, but you’re only using 10% of it.
The alternative approach is to not provision a permanent environment for the peak but to watch the workload and manually adjust the capacity. Obviously this involves human factors and is expensive and could be error-prone. Not to mention that traditional application servers do not allow for easy expansion or contraction of cluster size.
WebSphere Application Server ND and WebSphere Liberty ND both support autoscale clusters. WebSphere Liberty ND also supports cluster elasticity where you can not only dynamically stop and start pre-defined cluster instances, but also add entirely new instances without having to install and define them ahead of time. Liberty cluster elasticity and autoscale with Docker is perhaps the easiest and most efficient way to do this.
I decided to write a script to automate installation and configuration of WebSphere Liberty autoscaled clusters with Docker with just a ‘single click’. Detailed instructions and comparison of this capability with Oracle WebLogic, Red Hat JBoss, and Apache Tomcat can be found in this post on IBMadvantage.com blog: WebSphere Liberty autoscale clustering with Docker.
Here is a quick demo of the script in action:
The script is available on GitHub. Please feel free to reuse and contribute.