Business managers might not need to keep up on the nuts and bolts of technologies, but they should stay aware of the different technologies available to their IT teams. One decision to be made during development is which software frameworks and languages are best for creating software that runs in the cloud. The Java Virtual Machine (JVM) is a popular platform for developing software that can be scaled to the cloud. But using the JVM does not restrict you to the Java language. There are several different languages that target VM, with numerous platforms branching from there.

Here’s How It Works

The JVM is a software runtime that executes code that has been compiled to a low-level instruction set called bytecode. The JVM was first built by Sun as part of the Java tools, and the Java language was the only language that was compiled to bytecode. But since Java’s introduction some 20 years ago, dozens of languages have been created that target the Java Virtual Machine. Some of these languages are simply JVM-targeted versions of other languages (such as Jython, which is a form of Python that targets the JVM, and JRuby, which is Ruby for the JVM). Other languages are new and were created specifically to target the JVM. Scala is one such language, and is popular for cloud programming, as is Groovy. From the JVM the next step up is the platform. By itself, the JVM runs the bytecode—but to run web software in the cloud, you’ll need a web platform. There are many options here, and which one you choose depends on the language; at this point, we’re at the “Platform as a Service” (PaaS) level of the cloud, wherein cloud vendors offer platforms on which you can build your software. If you’re going to stick with the Java language itself, you have plenty of options, such as the Spring framework. Although it’s ten years old, the newer versions of this one include support for a web-based MVC (Model View Controller) approach. If you prefer to work in Groovy, you can use Grails, which is also a MVC web framework. And if you use Scala, one option for frameworks is called Lift. For what it’s worth, if your programmers are careful, they can even intermix these frameworks and languages, because ultimately the code all gets compiled down to the JVM.

The Nuts and Bolts

These platforms can make web programming easier, but they don’t handle the nuts and bolts of listening and responding to web requests. Another tool is required for that: the actual web server. One of the most common JVM-based web servers is called Apache Tomcat. Another common one is Jetty, which is part of the Eclipse Foundation. Some companies have such platforms readily available. One is VMWare’s CloudFoundry; others include CloudBees, VMWare’s Spring Source, RedHat’s OpenShift, and more. Most of these offer several options for platforms (such as Spring and Grails) and languages (such as Java, Scala, and Groovy). The usual web server is Tomcat. The general idea is that you can develop your application, and upload it to their servers without having to fuss around with installing and configuring the runtime (JVM), the web server (e.g. Tomcat), and the framework (e.g. Spring). Many of these companies also go beyond the JVM and support other runtimes and web servers as well, such as Node.js.

So Which Do You Choose?

Many times in my life as a developer, I’ve heard project managers insist: “We will not pick the technology until we know the project requirements.” That does make sense, but only to a point. For example, if you’re developing a scalable web-based application set to run in a cloud-based system, you’re going to find that you can develop the application successfully whether you choose Java/JVM, PHP, Node.js, and so on. It’s not as if one has better support for accounting software, while another has better support for contact management systems. On the other hand, you do have technological choices in terms of whether you select a relational database such as Oracle or MySQL versus a so-called NoSQL database—but for this article, we’re looking at languages and platforms. My usual advice is for a software team to embrace the expertise of the team. If the team members are predominantly Java and Spring experts, then by all means don’t switch them over to Groovy and Grails under some delusion that Groovy is “better suited to the requirements.” Or if the team already has several Groovy and Grails experts, go with that. Choosing a technology isn’t always easy, but if you work with what you have while understanding the differences and similarities, you’ll prove more successful in the end.   Image: Lightspring/