Going Pivotal
Recently we deployed several applications to Pivotal Cloud-Foundry (CF). Deployment was pretty smooth for our Grails and Spring-based applications. Because we had issues deploying JDK-7 applications to heroku as it is using jdk 1.6 as default deployment environment and we found no supported way to change this library and wanted to have a PaaS deployment model we decided to go pivotal.
Deployment to Platform-as-a-Service (PaaS)
Cloud computing providers offer their services according to several fundamental models.
PaaS provisions more than just a virtual box but rather a complete runtime environment. Regarding Cloud-Foundry we saw following pros and cons.
Pros:
- built-in failover support
- monitoring and health check on application level, if application fails to respond, new node will be spawned
- very easy scaling
- no vendor lock-in, we can migrate to different cloud-foundry supported vendor if needed (for example appfog or mopaas, others: http://core.cloudfoundry.org/listings)
Cons:
- no or very little persistent disk storage (so deployed applications mustn’t have file system access)
- maybe they rise the price – like all the others
- according to developers of this solution cloud foundry core it’s still in the beta stage, but there are other cloud foundry providers that claim to have stable and ready solution (like appfog.com)
NEEDED CHANGES FOR CLOUD-DEPLOYMENT
As of the temporary/ephemeral filesystem on PaaS model and only being able to deploy only a ‘war’ file, this means that external configuration has to be stored inside war file also. We can however use environment variables. So we decided that all module configuration properties files are stored inside war file.
Thanks to this solution configuration file of module stay inside module project and can be easily read depending on current runtime environment.
DEPLOYMENT TO CLOUD-FOUNDRY
Deployment to CF can be done via the cf which is Cloud Foundry’s command line interface. It is a ruby-gem so you need to install ruby for it. You can use cf to deploy and manage applications running on most Cloud Foundry based environments, including CloudFoundry.com.
$ cf target https://api.run.pivotal.io Setting target to https://api.run.pivotal.io… OK $ cf login Email> adam@example.com Password> ******* $ cf push
We also used Domain-Mapping in our setup. A Cloud Foundry instance defines a default domain that is available to all internal CF spaces (for example development, staging or production). In the Pivotal-hosted instance of Cloud Foundry, the cfapps.io domain is automatically mapped to all spaces in all organizations. In our setup we needed to map one of our clients registered domains to one of our own spaces in Cloud Foundry.
$ cf map-domain –space development example.com
MONITORING OPTIONS WITH CF
You have access to basic informations about the application instances. It contains information like Instance ID, CPU usage, Memory usage, Disk usage, Uptime, State (ie. Running, Stopped and Flapping (alternating between being “up” and “down”)).
Through the console you have access to:
- standard output log and and standard error output logs for instances
- instance-related events such as ‘out of memory’ or module configuration errors
Through the CloudFoundry services you can provide high end monitoring support, with use of external tools (ie. https://newrelic.com). In order to make it work one would need to introduce some code changes and add a library that would allow to monitor the application health.
Pivotal organization is stabilizing
We had to cope with several organizational issues because the VMWare Pivotal organization was being developed at the time we did the migration. As it normally takes a couple of weeks to get an account we had initial delays and then we were stuck with a trial account with just 2 GB of RAM. Obviously this didn’t allowed us to move all our applications to their cloud. Fortunately they just introduce a new quota limit of 10 GB for testing. Also they plan to have a 20GB quota that hopefully will be available in the near future.
Their pricing of $0.03/GB/hr was confirmed. Right now they are in the process of getting billing rolled out and available to their current users. Until then, all accounts are in a trial period that will continue to be extended until they provide an option to enter billing information. Also they said that they won’t leave trial accounts and apps stranded at the end of the trial date one sees when logged in.
Best for Java based PaaS deployment
Right now we run some highly-available applications that are linked to several high-traffic sites and are pleased with the response time and availability. What we especially like is the transparent scaling in terms of load-balancing and failover of our applications, so we can adjust to the traffic coming to our systems. We can absolutely recommend using Pivotal Cloud Foundry for hosting for a highly available PaaS and Java based environment.
We think that cloud-hosting of adequate applications is low risk and comes with good pricing, failover support. Further we think that changes to the deployment model should be looked at regulary as changes to the billing-model or technical constraints such as the cloud-provider moving to another JDK version can be extremely critical to your strategy.