Discussions

Blogs: Bob Griswold on Scaling up and out

  1. Bob Griswold on Scaling up and out (4 messages)

    Bob Griswold of Terracotta has written a blog called "Conflicting Galactic Forces in Java" that characterizes some of the differences between scaling up and scaling out. Even though this blog is a lead-in to a plug for his clustering product, he touches on a number of interesting weaknesses in the current JVM technology. In his assessment, these weakness make scaling out a much more difficult problem then he believes that it should be.

    Scaling out reflected by the move towards using many smaller machines instead of few larger ones has been a trend in computing for years. Although having many smaller machines offers both cost and scaling advantages these advantages do not come without a price. This price is doubly felt when one is using VM technology such as the Java Virtual Machine.

    As Bob points out, the JVM (as well the VM for Ruby and Smalltalk) were designed to abstract away from developers much of the mundane work that is often orthogonal to the problem at hand. However that assumption breaks down once an application extends beyond the boundaries of a single virtual machine. These problems extend to singularity (needed for correctness) and identity (needed to ensure singularity).
    …this works almost perfectly as long as the application runs contained within a single JVM. If the application is intended to be deployed on multiple JVM's, in other words - if it is intended to be clustered or distributed, this promise falls apart.
    If writing applications that scale-out is far too difficult then is it time for the Java community to explore a JVM that extends over machine boundaries or do you see products such as those offered by Terracotta to be the answer to scale-out complexity?

    Threaded Messages (4)

  2. If writing applications that scale-out is far too difficult then is it time for the Java community to explore a JVM that extends over machine boundaries or do you see products such as those offered by Terracotta to be the answer to scale-out complexity?
    I don't think it's too difficult. It's just not something the JVM provides. You have to plan for that up front. A framework that helps with this and makes it somewhat seemless would be helpful but it shouldn't be completely opaque to the developer. There are many cases where a single instance per VM in a mutliple VM cluster is not only OK but is the desired behavior.
  3. You are describing exactly what Terracotta provides. If you want the same application to run in multiple VM's - single instance each, but you want some of the objects to be shared and some of the behaviors to be shared (locks, method invocations, wait(), notify(), etc.) across a cluster, Terracotta allows you to share those transparently among all the nodes in the cluster without writing any code at all. We extend the JRE to do this - consider it a utility provided automatically by the runtime. Try it out and see for yourself - download our product and give it a try.
  4. Not a simple model[ Go to top ]

    Using JSR 133 -- something that developers don't tend to "get right" on a single JVM -- as the basis for distributed programming is very scary. I think that this is the reason why distributed models tend to be built on top of transactional models, which are well-known paradigms for encapsulating a number of changes into a unit that succeeds or fails as a whole.

    Nonetheless, it's an interesting idea to do replication based on synchronizaton boundaries using AOP.

    Peace,

    Cameron Purdy
    Tangosol Coherence: Clustered Shared Memory for Java
  5. Scale out with Akamai[ Go to top ]

    To scale a web application to reach a global audience, you must scale beyond a single server room & backbone. Your app server cluster behind its firewall constitutes one node. My position is that operating a single node does not constitute scale-out.

    For this reason, I am an avid proponent of the Akamai service, a network of 15,000 'edge' servers (over 1,000 networks) in over 70 countries. The Akamai edge claims to serve 10%-20% of the content of the Internet, and is within one hop of 85% of Internet users worldwide.

    Akamai offers two services: one, an http caching proxy on each edge server which, when combined with TTLs and other caching techniques, can effectively bring your content within one hop of your users. The second is so-called EdgeComputing, a local JVM on a subset of edge servers such that your application is hosted by Akamai and scaled beyond your wildest dreams.

    All I can say is that it is very competitively priced. Assuming you are willing to architect your applications around caching and clustering, Akamai just might save your business when scale is required.