When it comes to running Play Framework apps on the cloud, there are many great options; one of those options is Cloudify. In this guest post, Uri Cohen shares how developers can deploy their apps on the cloud with GigaSpaces' unique open PaaS Stack. Read on to learn more!


The Challenge

Running multi-tier, complicated apps on the cloud can be very tricky. There are many concerns to cater for in order for such an application to be successfully deployed and managed on the cloud.

Let’s take a relatively simple example, of an application that includes the following stack: Apache as a load balancer / static content server, a few Play instances as the web application tier and a replicated MySql cluster for storing the application’s data (say 1 primary and 2 replicas).

Let’s look and some of the things you have to cater for when managing this stack on a cloud environment:

  • Starting VMs: goes without saying. You will compute resources to run your application.
  • Installing and configuring the started VMs: Every VM needs to be installed and configured properly. For example, for VMs on which Play runs, you need to have JDK 6 and Play itself installed, and open the relevant ports for the Play to be accessible. For the Apache VMs, you will need to have Apache2 installed alongside its dependencies and relevant modules (e.g. mod_proxy).
  • Starting and orchestrating application components: Naturally, your application tiers depend on one another and have to be aware of one another. For example, before starting the Play servers, you will have to make sure the MySql cluster is up and running, and that the Play servers are aware of the host names and ports of the relevant MySql servers.

Repairing: Once everything is up and running, things can and will break. Processes will die for no apparent reason, VMs will come and go, and you need your application to continue to work even when this happens. Monitoring key metrics and scaling your application tiers based on them: Think about a (very positive) scenario where your load spikes due to your application or service being very successful. You need to be able to tell what’s the load on your app across its various tiers and for very specific metrics (e.g. request latency), and take action based on it to make sure your users keep getting a decent service level. For example, add additional replicas to MySql, or increase the number of Play instances. Updating your application code: There’s always the issue of updating your application with new code. You want to do it as fast and painless possible, and as soon as new code is available.

In a cloud environment, which is dynamic and volatile by nature, it’s also extremely important to automate all of these processes, so that you can setup environments easily and consistently, switch between environments, test things before you go live, maximize your utilization and minimize downtimes.

Isn’t PaaS Sufficient?

Using PaaS solutions like CloudBees, CloudFoundry or Heroku can be a very good option, as it relieves you as an application owner from the intricacies of handling most the above concerns, and does most of the work for you. However in many cases, you want to control things on a more fine grained level, e.g. choose the cloud you’re running on, use a middleware component that it not consumable via PaaS, choose the version of components that you’re using, the hardware profile of your VMs, the clustering topology of your data tier, the load balancing mechanism, etc. You also want to be able to upgrade tiers (e.g. move from Play 2.0.3 to Play 2.0.4) at your own pace and not wait for the PaaS provider to do it for you.

Last, in some cases, PaaS is not even an option, e.g. when deploying on premise.

Introducing Cloudify

Cloudify is an open source framework for deploying, managing and scaling your applications on any cloud environment. This includes EC2, RackSpace, HP Cloud Services, Azure, private clouds environments based on OpenStack, Apache CloudStack or VMWare. You can even use it on an arbitrary set of servers, virtualized or non-virtualized. It’s designed to handle the above concerns for you, while still letting you retain a high degree of control and flexibility.

Similarly to Chef and Puppet, Cloudify allows you to use recipes to describe what your application looks like. But it really augments both, by defining things from an application rather than an infrastructure perspective.

In other words, while Chef and Puppet are excellent at configuring individual servers (“given a server, here’s how I want it to look like”), Cloudify focuses on what your application looks like (“here’s what my app looks like, now provision the VMs, assign them with roles and install it on the cloud for me”).

Cloudify recipes are used to define application tiers (web container cluster, database cluster, caching instances, etc.), the number of instances in each tier, how the tiers depend on one another, and how to install, start, verify and monitor each tier. Since Chef and Puppet are great for infrastructure configuration, you can and are encouraged to use them to do the installation and configuration part of a Cloudify recipe (Cloudify is integrated with both tools).

For example, for the Play application that we mentioned above (composed of Play itself, fronted by an Apache load balancer, and backed by a MySql cluster), you’d model it as follows with Cloudify

How It Works

Once you have a Cloudify recipe, the first thing to do is bootstrap a Cloudify controller environment on the cloud of your choice. This is done easily from the Cloudify CLI and will eventually result in a Cloudify controller running on the cloud of your choice. From that point onwards, the CLI will communicate with the controller over REST. Next, you issue an install-application command that will trigger the controller to analyze the installed recipe, provision the right amount of VMs for it, and orchestrate the deployment of all the recipe components. Later, this controller will monitor the deployed components and VMs, scale them if needed and make sure to restart any failed components.

What's in Store for Play Users

As one of our favorite web frameworks, one of the first recipes we created was for Play. We also created a sample app recipe for the Play Computers example, which is a full blown application stack that includes MySql, Play and Apache (as a load balancer). Using the Play recipe, you can easily automate the configuration, deployment, failover and scaling of any Play framework app, on any cloud environment (and btw, that also includes private clouds and even non-virtualized environments). If you’re interested in the all the details of the Play recipe this post will give you a good start.

Play Your Recipe with Play!

Another (very cool, IMHO...) tool that you will find very useful, is the Cloudify Player. This is also an open source project, which is implemented using the Play framework, and uses Cloudify to allow users to easily experience new frameworks and tools over the web. The idea is this: if you have a Cloudify recipe for an application (e.g. Play Computers) or a project (e.g. Cassandra), you can configure a player for it. The result of this is a simple embed code that you can include in any web page, and renders the player. What happens under the hood is that the player communicates with a Play application on the server side. This app manages a pool of VMs deployed on the cloud of your choice (in this case HPCloud) and “bootstrapped” with a running Cloudify manager. The server borrows a VM from the pool, connects to the running manager over REST and issues the recipe installation command. After about 30 seconds, you have a running app or service, available for you to try out for 30 minutes. All courtesy of the Play framework and Cloudify.

Here’s the actual widget for the Play Computers app example recipe. Feel free to click the image below, launch the real widget and see it in action for yourself. The embedded video explains how to access the sample app after launching it using the widget.

So go ahead and give it a try, we’ll be more than happy to hear your feedback!



View All Posts or Filter By Tag


Reactive Summit 2016

Austin (TX) - October 4-5


Reactive Microservices Architecture

by Jonas Bonér


Developing Reactive Microservices

by Markus Eisele


Going Reactive 2016

How Microservices & Fast Data are driving adoption of Reactive systems