It’s not that Java can’t run in the cloud, of course it can, it’s just that it was never really designed that way from the beginning. When Java was first brought to market it was mostly intended as a new way to build ‘run-anywhere’ desktop applications. With its Java Virtual Machine (JVM) it transcended traditional operating systems. It even ran in browsers like Netscape (remember Netscape?).
But for enterprise application developers like me, run-anywhere was a cruel joke. JEE included the concept of ‘standardized’ application servers, but the truth is, they were never that ‘standard’. You couldn’t really run your code ‘anywhere’ at all. JEE applications just weren’t that portable. Thankfully, this mess was sorted out by Spring Boot.
Spring Boot can take your application code, combine it with an embedded JEE Application Server (like Tomcat, which you never even see), and package it all up together into an executable JAR file. This JAR file will run anywhere there’s a compatible JVM.
Great. Does that include the cloud?
Well, yes and no. To run in the cloud, you need to pick and secure an operating system, layer a Java distribution on top of it, add your application code, and then tweak the JVM a little to make it run smoothly. You have to bundle all this stuff into a runnable container image, and you must be prepared to do this repeatedly every time you deliver a new feature, a new bug fix, change a configuration item, or deal with a CVE, etc.
Help is available. Buildpacks are a technology that can automate this process for you. For example, the Java Buildpack can layer OpenJDK over Ubuntu LTS; figure out the right memory settings for your app; construct the correct command line to run it, and bundle all these things into a container image for you.
So I have a container, now what?
Next, you need to run your container in the cloud; and keep it running. That’s where a “scheduler” or “orchestrator” comes in. The most basic schedulers (a.k.a people) will simply take your container image and start it.
Application “Platforms” (like Cloud Foundry) have much more automation and go much further.
Platforms can schedule your application to run in the cloud, and spread it over multiple zones for higher availability. They can scale your application horizontally or vertically by adding extra instances or memory. They can even create URL routes automatically and configure load-balancing over your application’s endpoints. Most will also keep your application running by killing misbehaving instances or restarting instances after a crash. Everything a developer needs.
Platforms have a better “day two” operations story as well. Day two refers to the maintenance features required to maintain and run the platform itself. To do this properly you need to take care of things like application’s OS patching and have the ability to resize your platform easily as demand increases. You also need to ensure that your platform’s various components remain secure, and you need to do all this with zero downtime.
The beauty of a Platform is that it’s not a ‘do it yourself’ solution. IT decision makers always underestimate how much money and effort it takes to build a viable platform. Even though it may be technically very interesting, it does take the most valueable resources (developers) away from other, more valuable things (like adding the “wow-factor” that users really want).
But what about Data, Messaging, Monitoring etc?
Applications need services. 12-factor applications may be designed with stateless access in mind, but their data still needs a database, messages still need queues, config still needs externalizing, and applications still need monitoring. So applications need many services, but creating and running them usually means either tickets or toil or both.
But, not if you have a services marketplace! With a services marketplace, you can personally pick and choose from a curated list of ready to run services. No Ops, no DBAs, no Jira tickets. All backed by high-availability cloud-based infrastructure and ready to run with a few clicks or taps. Marketplaces are even extensible, you can add to them using the Open Service Broker API.
Sounds amazing, what’s the catch?
Usually, the catch is the cost. But you can try all these technologies for free (up to a spend of $87) with Pivotal Web Services. There’s no sign-up fee. You don’t even need a credit card. All you need is a spare few minutes.
You can interact with PWS using a simple command line client called cf-cli which you can download here. With the cf command installed you can push, scale, start and stop your apps at will.
For example, for a Spring Boot application built with maven, the terminal commands would look something like this…
# to get a JAR file... mvn package # to push the app and start it on a random URL... cf push my-application -p target/my.jar --random-route
When the cf push command finishes, you’ll be told the URL that your application was assigned to. You can log in to PWS using your browser (at run.pivotal.io) at any time. There you can visit the Apps Manager UI and see your application’s current status, view logs, etc.
PWS includes a full marketplace of over 20 services, many of which have free plans. You can use create-service and bind-service to attach services such as databases to applications. Doing so takes just a couple of minutes. For example, the commands for creating a free SQL database using ClearDB are…
cf create-service cleardb spark mydb
cf bind-service my-application mydb
cf restage my-application
The potential of this is huge. Imagine how much time you could save if all of this infrastructure, configuration, wiring, patching, maintenance and service provision were taken care of for you?
You should try it. It’s like having cloud super-powers. I doubt you’ll have a more productive 10 minutes this year.
