About Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE, as well as Android, Scala and any framework you throw at him. creator of Computoser - an algorithmic music composer. Worked on telecom projects, e-government and large-scale online recruitment and navigation platforms.

You wanna be in the cloud? You have plenty of options. I’ve evaluated or used many of them, so here are a few words about each. (I will include some Java-related comments, as I’m using Java, but most of the things apply to all (supported) languages). But before I go into a bit more details for each service, let me summarize what “the cloud” actually means when it comes to hosting your applications:

auto-scaling – if there is an increased demand, you automatically get more resources (more virtual machines in most cases) to handle the requests. For the regular application this is rarely useful, but it’s nice to have it and be sure that your service never dies because the load is too high

pay what you use – simply put, this is in fact the option to choose small servers when you are small, and bigger servers when you are big. The “cloudy” thing here is that you can do that easily, rather than reconfiguring some remote machines

cloud infrastructure – this is fancy talk for “we deploy these services and take care that they are working”. So instead of installing and configuring a message queue on your machines, you hook up to an already installed and managed message queue. Or database, email service, or cache.

management tools – you get consoles, command-line tools and web UIs for handling your installations. This is both a plus (the tools are higher level than working with native commands), and a minus (there’s a learning curve)

load balancers – all services offer these, and you rarely care what’s the software and hardware of the load balancer

The overall plus is the ease of use – you need way less system administration knowledge, and even if you have it, you need to do much less in order to have a real-world-ready application. It is not necessarily cheaper than regular servers (actually, it might be more expensive). But let’s see what each service does:

General flow: you create an EC2 instance, which is a virtual machines, ssh to it and have full control. You can bring up and kill copies of your instance whenever there’s higher load.

Flexibility: since you have root control over your machine, it is very flexible.

Usability: the AWS console and the Elastic Beanstalk give you very nice UI for managing applications. With Beanstalk you can deploy applications without even opening a console, just drop a war file. In reality you will at least need to provide some configuration though. The best thing is having predefined instance images, so you can have “Tomcat with MySQL” up and running within a minute. There are already nice solutions built ontop of the Amazon API, like RightScale.

Features: in addition to the basic instance functionality, you have a lot of extras – managed database, elastic IPs, DNS, cloud storage, CDN, mail service, message queue, cache (this one is not that good, btw), etc. So instead of installing and managing these services on your instances, you can use the Amazon versions.

Pricing – you are charged for the number of hours your instances are running

Trial: yes, 1 year (a micro instance).

Google App Engine (GAE). This is a PaaS (Platform as a Service), so you don’t get your own virtual machines and are limited in the use of some standard APIs (for example, you can’t spawn threads), and you can’t use a file system (you need the Blobstore API instead)

General flow: you create an application and deploy it (through command line or IDE plugin). You don’t manage servers and you don’t have ssh – you have just the app. The app runs in a sandbox, and you may need to use some proprietary APIs in order to store to a NoSQL store, use MapReduce, etc. You have less control. You can browse the datastore, view log files and performance metrics via the admin UI, as you don’t have regular access to the target “machine”

Flexibility: low – you deploy to a sandbox. You are limited to the configurations the admin UI offers you

Heroku. Platform as a Service – you deploy an app in a sandbox and have a lot of useful add-ons for other services. You have two types of “dyno” – one that services web requests, and one that services background requests.

General flow: you download the heroku toolbelt, run it (the latest version fails on Windows though – it installs ruby 1.9.2 and requires 1.9.3, so you have to edit the bat file) and then use it to create and deploy applications

Flexibility: low, because you run in a sandbox, but each add-on is configurable and there are a lot of add-ons, so it’s better than other PaaS options. The bad news for Java developers is that it only supports deployment by checking out from git, and building with maven. No other version control system or build tool. (there is hg-git adapter, which you can try if using mercurial, but it starts getting hacky)

Usability: there is a need for command-line work, which is not that usable. The web UI is OK.

Trial: yes, you get 750 hours monthly for free – this means you get it for free if you have low usage

Jelastic. Platform as a Service for Java only – you deploy an app in a sandbox. You can configure the architecture and use various 3rd party services. It’s not as popular as the other services, but I got an app running quickly (with some useful input from their support)

General flow: you create an application, choose an architecture via a nice UI (it’s reconfigurable later), and then deploy your war file. You configure the maximum number of servers that you want your application to use. Everything is configured with the web UI

Flexibility: low, because you can’t ssh to the machine. However, you are free to edit some application server configurations and have a limited, but sufficient access to the file system, you also can configure each of the additional services you use (databases, for example)

Usability: the interface is pretty good (I’d say better than the rest)

Features: you can use additional services – MySQL, MongoDB, CouchDB, memcached, building with maven. (The list is way smaller than what Heroku offers)

There are many other options, notable RackSpace, which is a traditional hosting company, and the cloud options are simply virtual machines with some “cloudy” features, like auto-scaling. I listed only the popular options that I’ve actually tried (I’ve used AWS, GAE extensively, and deployed sample applications on the other three). The evaluation above does not aim to be complete, and I’ve certainly missed some points here and there.

There’s no “winner” – use different options for different scenarios. But it’s good to know what limitations are imposed by each service, and what’s the approach and general mindset. Because, especially with platforms like Heroku and GAE, you need to change the way you think about deployment.

Newsletter

Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

Email address:

Join Us

With 1,043,221 monthly unique visitors and over 500 authors we are placed among the top Java related sites around. Constantly being on the lookout for partners; we encourage you to join us. So If you have a blog with unique and interesting content then you should check out our JCG partners program. You can also be a guest writer for Java Code Geeks and hone your writing skills!

Disclaimer

All trademarks and registered trademarks appearing on Examples Java Code Geeks are the property of their respective owners. Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. Examples Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.