Options range from web site generators such as Wix, to Paas providers such as GAE, all the way to the traditional LAMP setup hosted on IaaS that gives you the maximum control and customization power.
Quoting Spider-man, “with great power comes with great responsibility”.
In our case, if you choose to LAMP or its variants on IaaS, you have the responsibility to ensure proper service level that in many cases require high availability configuration to minimize downtime as well as ability to scale the service as user traffic increases.
Such service level requirement typically translates to putting your front-end web servers behind a load-balancer and allowing the application to scale out to multiple web servers.
In case your web service is state-full, additional considerations typically results in ability to distribute the session context management and in some cases instruct the load-balancer to enforce sticky session load balancing algorithms.
Cloudify, a DevOps automation tool which is basically equivalent of Amazon OpsWorks on Openstack, lets you get all this “great responsibility” with significantly less effort and help you abstract you architecture from the actual IaaS you will choose to work with to keep the flexibility to change vendor in the future or create a service that utilize more than one IaaS vendor.
In this post, I will show you how to easily deploy web service based on tomcat web servers, XAP distribute session management and Apache that serves as a load-balancer as a service to the front end the tomcat servers.
The Apache load balancing allows us to keep a VIP the internet know about and hide behind it arbitrary number of web servers.
How do I actually use it?
1. Download Cloudify from www.cloudifysource.org
2. Download the HttpSession sample recipe from https://github.com/yoramw/cloudify-recipes/tree/master/apps/HttpSession and its services from https://github.com/yoramw/cloudify-recipes/tree/master/services (both apps and services folders should be in the same folder hierarchy as it appears in the recipes folder)
3. Start the Cloudify CLI (bin/cloudify.sh (or bat for windows)
4. Run > bootstrap-cloud
5. Start the WebUI from the URL that the CLI printed once the bootstrapping was done.
6. Install your recipe app > install-application -timeout 30 /apps/HttpSession
7. Wait for Cloudify to deploy the servies (it should take 5 – 20 minutes depending on the cloud provider speed).
8. You can bring additional tomcats or shut them down using > set-instances tomcat <# of desired instances>
9. You may run some load on your new web service and see how it behaves using: > invoke apacheLB load 35000 100 (3500 requests by 100 concurrent requesters)
As you can see, the deployment is very simple. Cloudify configures everything for you and connect the services together.
You can use the same recipe to deploy your testing/staging environment as well as the production environment.
Changing the deployment to a different provider just means bootstrapping a different cloud and installing the application recipe there exactly the same way.
Behind the scenes:
Using XAP as the distributed session store requires Apache Shiro.
The tomcat recipe takes care of connecting Shiro to XAP.
If you want to dive into the details and adjust configurations, I recommend reading the Gigaspaces paper on global Http session sharing at http://wiki.gigaspaces.com/wiki/display/SBP/Global+Http+Session+Sharing.
In order to enable Shiro in your own application, use the HttpSession example as a starting point. Place the shiro.ini from the HttpSession example in your app WEB-INF, add the shiro filter to the app web.xml and add the jars to the lib folder as shown in the example recipe.
In the recipe, the ApacheLB recipe bring up an Apache that servers as the load balancer. It configures the service to either respect sticky sessions or not by setting the “useStickysession” property in the apacheLB properties file to true or false.
When a tomcat service instance complete its installations, it will register itself with the ApacheLB which will automatically add it to its pool ready web server.
When a tomcat service it orderly brought down, the first step it does is to remove itself from the ApacheLB pool or ready servers.
The ApacheLB recipe also let you generate load to test your setup by utilizing the Apache ab command line utility.
To sum things up, Cloudify takes the hassle, time and effort from deploying your highly available and scalable web app while letting you hold on to gains of having the most flexibility in designing and building your application the LAMP way…