Friday, June 03, 2011

hypervisor (vm) and jvm (java) and SLA and costs

I've been testing several approaches to optimize the platform that the applications run on. This blog post is just a brain dump without any clear direction other than current thoughts.

Most of the applications I work it would fall under the equivalent of the JavaEE6 web-profile (jpa/web or jpa/ejb/web) with a couple that have messaging that, in reality, could be modified to work with other async-style approaches (while messaging also supports distributed work efforts, most of the applications aren't reaching a critical mass where then need to distribute that work).

So, what are we talking about platform wise?

*jboss or tomcat (or, more appropriately, the new TomEE as an option)

*jvm

*OS to run it on (preferably with iSCSI and similar large-disk-space mounting support).

*hypervisor to run multiple guest OS/vm/appcontainers.

Some of the general goals are reduce diskspace/memory, maximize the number of applications that can run on a piece of hardware, while still protecting or segregating applications from each-other so if in our haste to 'time to market' an application will only hurt itself and not any others. Failover/disaster-recovery is also a consideration, with a minor emphasis on time-to-increase-capacity-and-associated-downtime but that is not as critical.

App Container

Jboss has been doing some wonderful things with the new jboss7 AS stack. I haven't finished my memory review, but I hope they got the 'memory bloat' under control. Jboss 4.0.x series with one application can run in under 128MB in most cases, while Jboss 5.x and 6.x series for the SAME app need to double-to-triple to 256MB/364MB.

-jboss deployment bonus: The ability to deploy an application's 'configuration' beside it as a SAR in the same deployment directory as the application WITHOUT needing to modify the server itself is HUGE. I do not understand why people do not take more advantage of the SAR benefits. You create your application binary once, then vet/test with one SAR configuration, take the SAME binary to your staging/pre-deploy/uat/stress-testing/etc environments with different SAR configurations, then again move the SAME binary to production with a different SAR configuration. What you tested is what went live.

-And, once you setup the SAR configuration for the environment...leave it there and update the application binary with changes (assuming no additional configurations). The least variables to mess around with the better!

TomEE is a new player and haven't reviewed it yet.

Jonas unfortunately has never gave reason to peak my interest.

Geronimo & Glassfish are additional options, but also do not provide any significant reason to change from Jboss (which I have the most experience/skill in).

Tomcat/Jetty are decent web-only platforms, but would not be considered as part of the strategy related to inability to support the full necessary stacks.

Conclusion: Jboss still in the win, but if Memory is a constraint be wary of jboss5/6 versus the older jboss 4.0.x series. The new Jboss7AS is a significant rewrite and will hopefully address this, as well as additional scenarios.



jvm/os

This is where it gets interesting....

*jboss again comes out with the Boxgrinder project so that you can have predictable/repeatable platforms. This is kind of an outsider as it doesn't directly relate to any of the above areas, but is a way towards combining and using them in a cool (or more predictable...less variables) fashion.

*Azul has their new Zing JVM/OS combo-solution that will run on hypervisors (and is optimized). But, at a price of $5k-$6k per 'server', but I haven't touched/tested/or discussed if a server represents a single JVM that can run multiple appcontainers or not.

*Oracle has a not-very-discussed JVM/OS combo-solution that will also run on hypervisors called Maxine Virtual Edition: http://labs.oracle.com/projects/guestvm/
-GPL licensed/forever open sourced.
-takes queues from openJDK, so will continue to keep updated with recent JDK updates.
-not 'production' ready...if this can get some more steam, this is definately a good place to go.

Away from the cool stuff, and back to reality --

Just Enough Operating System (JEOS) continues to be a buzzword but with no real meat or applied solutions. The Boxgrinder project above does try to help with some pre-defined approaches to a JEOS for the different linux OS distributions. CentOS is still a popular choice for low-cost options, and the guys there are trying there best to get CentOS 6 out the door even while RHEL 6.1 gets released -- if you want the faster turn around, pay for it and get the benefit of testing and security announcements, otherwise free CentOS is free but help them out.


hypervisor (virtualization)

Hypervisor battle is pretty hot right now, with no real clear winner yet.

With Xen and KVM as the current front-runners on the open-source server hypervisor segment (with others close behind), it's not really black and white which one to pick although Xen has a little bit of an edge with Citrix backing and Paravirtualization support.

VMWare, hyper-v (which announced CentOS support?!), and other commercials also offering some competitive advantages over the open source alternatives (for a price).