This may be a crazy stupid idea, but I was having a conversation today about the kinds of things that make sense to be "as a service". Amazon EC2 and S3 are essentially compute as a service and storage as a service.
Since I'm a Java guy, I wonder:
Does it make sense to have a JVM as a service?
Why? Because while running Java workloads on Amazon may be cool for scale out scenarios, it does nothing to help with scale up scenarios for Java workloads. The classic JVM is a limiting factor in scale up scenarios because the more memory it has to deal with the more garbage collection time becomes a real performance issue.
Azul Systems offers a JVM compute appliance that illustrates the logical model of what I have in mind. Basically the Azul appliance centralizes JVM processing onto a machine designed to provide low response times, pauseless garbage collection, and efficient huge memory management. Basically each server has a JVM proxy that hands off processing to the compute appliance.
So, what if we mashup Azul with Amazon?
That is, what if we take the Azul JVM appliance concept and make it a cloud service? That could enable any EC2 instance running a Java workload to leverage a model where a JVM proxy on a given EC2 instance hands off its processing to a JVM as a Service. That JVM as a Service could then centrally handle dynamic scale up/scale down of JVM resources as well as eliminate the nasty garbage collection performance issues once and for all.
Now all we need is the JVM gurus at Azul or Oracle/BEA JRockit to get to work on it. I want my JVM as a Service guys, and I want it now!!! :-)
If you are a JVM guru, feel free to chime in as to why this idea is stupid and could never possibly work. Or if you have an equally outrageous "as a service" idea, please share.
Subscribe to:
Post Comments (Atom)
10 comments:
My understanding is that JSR 284 is supposed to enable stuff like this but it's unclear to me how or if 284 will be included in Java SE or EE.
This mash up is a very good idea. Azul is probably unique in this space with 'unlimited' heap and 'pauseless' GC for vertical scalability. Unfortunately, this has been thought about and proposed but has not getten traction yet. I have the tech-idea, plan, but no $$ or biz skill to pursue :-( It is very viable in my opinion if Amazon like outfits pay some attention.
btw, I was part of a similar mash up project (representing Azul part) at one of the customers to implement something similar to Unified Computing System recently announced by Cisco. It, termed Data Center In a Rack, is an Enterprise Cloud meant only for Java workload and expandable like UCS as needed. i.e., semi-elastic cloud for java. I can go over the details if there's any interest.
Hope this 'clouds on Azul' (pun intended) takes up shape some time soon. Anyone interested in pursuing this, you have a body available for immediate use!
Great entry Shaun. As a [self proclaimed] JVM guru I can tell you that this notion of yours is neither stupid nor crazy, and that it actually does work.
"JVM as a service" (or "Java as a service") is exactly what we built Azul to deliver. And it looks like the time has come. People are often amazed at how easily this JVM as a service concept works in an enterprise environment, and extending it's availability to work within Cloud providers will certainly allow hosted applications to blow past the classic scale limitations of the JVM.
To make sense, a "JVM as a service" needs to provide two things:
1. JVM virtualization: The JVM needs to transparently appear to run as a normal JVM within a host machine image, but would in practice consume it's resources outside of the image and would not be limited the technical limitations of the host image's software stack.
2. Enhanced JVM capabilities [e.g. GC elimination, Significant scale benefits, detailed visibility in production, etc.]: The virtualized JVM needs to provide a compelling behavior advantage, in at least some metrics, compared to the non-virtualized JVM instance that would otherwise be run within the constraints of the regular machine image. Without these advantages, Virtualization would be nothing but a neat hat trick.
Looking forward to bringing JVM as as service capability to a cloud near you....
Thanks for the comments Gil, Alex, and Raven.
While it will likely take a while for cloud computing models a la Amazon AWS to become pervasive, I love how it forces a disruptive way of thinking about the problem domain. Azul's appliance is very much an inside the enterprise perspective, but mashing it up with AWS...and hmmm...we could just have a disruptive approach to powering Java apps in the cloud.
Offloading the JVM computing helps make the resource requirements more predictable (ex. much smaller memory reqt's since proxy JVM does not use much EC2 server memory).
I've been thinking along the same lines for a while -- What if the OpenJDK was ported to run on a VM like VMWare, VirtualBox, or Xen??? You would need some kernel-level code tossed in to manage threading, network, filesystem, and the console (maybe use Groovy Console or IRB??) but probably not much else.
Thoughts?
Cheers,
Jim
Hi Jim,
I actually think it's more complicated than that. Yes getting it closer and more intimate with the Hypervisor is key but also optimized to handle the memory management, garbage collection requirements that "real time" JVMs target is an area of difference. Not sure how optimizations like that differ from what OpenJDK has. Ex. I do know that Sun and IBM have their own "real time" JVM efforts that are completely different than the standard JVM a la OpenJDK.
Heard about Google Native Client ?
Your idea can be mixed with it, Guess in what way ?
Instead of sending bytecode the server can send parts of Native code as required by target client (OS or CPU specific).
I wonder if with a the large cache and ample cores available certain applications can be written in simpler ways and thus reduce developer time as well. I am thinking that one can delay writing code to support scale-out, sharding, etc and just lease more capacity if business is up.
David,
Auto-magic (adaptive) scale out is nontrivial when applied to every layer / resource in the app infrastructure, but I do believe that's where things are headed in the not so distant future.
I was thinking about doing this in 2005, but at that time, the Java license terms prohibited this type of thing. You can run "your programs" with Java, but you can't run someone else's programs in a commercial service without violating the terms. I doubt that Oracle has opened this up, as they probably want to be the "JVM as a service" provider to the exclusion of others.
Post a Comment