Tuesday Apr 28, 2009

Which Application Server to use with MySQL?

At the MySQL User Conference last week I had a number of attendees come up to me to ask which application server they should be using with MySQL. They were looking for something that was fast, lightweight and compatible. To me the choice was obvious -- GlassFish

So why GlassFish?

Project GlassFish, was launched when Sun open-sourced its application server and the Java EE Reference Implementation, was Sun's first step toward open-sourcing the entire Java platform. Less than a year after the initial launch, the GlassFish community delivered the first release of the GlassFish Application Server, a production-quality, Java EE-compliant application server, followed by a second release in 2007. Today, GlassFish is the leading open-source and open community platform for building and deploying next-generation applications and services. The GlassFish application server has been downloaded more than 18 million times since 2006.

Another choice might be Red Hat's JBoss application server that was released in 2006. Although JBoss has had some success in the past, I would caution that there are some issues around  backward compatibility and features that are not supported in the commercial release of the product. In addition it seems to be pretty far behind as far as latest features around JavaEE are concerned.

In contrast, the GlassFish application server is backward-compatible; features released today will be supported in future freely available versions as well as future Sun-supported commercial versions of GlassFish Enterprise Server. Additionally, the freely available GlassFish application server is ready for production right out of the box. For these reasons, I recommend GlassFish application server over JBoss!

Tomcat application server is extremely popular with Java developers who only want to only use servlets, but it doesn't support the full Java EE stack. So why use only a bit of Java when you can use the full reference implementation?

Wednesday Oct 24, 2007

Google's Developer Pledge Needs Updating

Having just read ZDNet's piece on the Google's developer pledge of allegiance:


I can't help but think that this could be improved:

"I pledge allegence to the web" Why just the web? I love the web just as much as anyone else, but surely this is too limiting? With devices such as mobile phones, Blu-Ray devices, set-top boxes, and the like, I think that pledging allegiance to the Internet makes way more sense.

"One platform" great aspirational goal but is there really only one platform? Each web browser is its own platform, in fact each version of each browser seems to have its own nuances and could almost be considered a platform. As a developer I am also concerned about writing applications that work on way more than one platform.

"DOM" and "AJAX"  Although both these technologies are core to things like HTML/XML rendering and client technologies like Google Maps. These are way to limiting... What about PHP, MySQL, Apache, etc. As a developer I use all of these and, oh yes there is that other little technology out there called Java! How little is Java?

From Java.com: Java powers more than 4.5 billion devices:

  • over 800 million PCs
  • over 1.5 billion mobile phones and other handheld devices (source: Ovum)
  • 2.2 billion smart cards
  • plus set-top boxes, printers, web cams, games, car navigation systems, lottery terminals, medical devices, parking payment stations, etc.

Please don't limit me by having me pledge allegiance to only DOM and AJAX!

IMHO, perhaps they should have used this as their pledge of allegiance?

I pledge allegiance to the Internet,
and to the innovation and ubiquity for which it stands,
one common vision
of creating liberty and opportunity
for all.


Tuesday Oct 16, 2007

Garbage Utility Computing?

The more I talk to the world about utility computing the more I am amazed that the average person wants one definition of "utility computing" The world really isn't that simple. Lets consider your typical utilities that you pay for in the average home -- electric and garbage. Both are undoubtedly utilities, but both have a very different payment model.

My electric utility provider only charges me for electricity I consume. This model is very consistent with the model we use at Network.com where we charge $1/CPU/hour for compute utility. Like my electric company, unless you use the utility you pay nothing. (As a side -- wouldn't it be great if could create the same set of energy consuming hogs like TVs in standby mode, cell phone chargers that aren't charging anything,etc. We could made millions off the useless use of compute, and like the electric utility charge you for this no-value. Alas just a dream, we only charge for what you actually use doing real work, maybe the electrical utilities should do the same?) 

Now some utilities like my garbage utility charge me irrespective of whether I put the garbage out or not. They actually charge me the same if I have no garbage or a can full of garbage. This too is a utility and is very similar to the electric utility, just the business model is different. Phone service is another utility where there is more of a hybrid model of pay-per-use over a certain threshold. Hosting services seem to use this utility pricing model.

So which one is the true utility -- sorry to have to shatter some ideals here.. but BOTH! Utility isn't about how you pay, nor it is rental -- I don't rent electricity, it isn't leasing -- I don't have a lease for any hydro-electrical plants! What is it? It really is about getting someone with expertise in an area to provide a service to you that is more beneficial for you to pay to have run on your behalf than run it yourself.

Grid today did a great write-up on the origin of Utility Computing and to reiterate the theme there -- I believe that we are in the early days of Utility computing, the "killer application" has not been found yet, but this will be the dominant compute model of the future. I am excited to be at the forefront of this evolutionary charge and part of the team moving Network.com forward.


Musings from Mark Herring at Sun...


« July 2016