Using Grails for SaaS Deployment

First, a little history…

About 6 months ago we began using Grails for our new and ever growing set of REST apis.  Overall our experience has been great.  Grails has really allowed us to accelerate development and focus on the things that are important to us.  Naturally, when we started talking about Sierra and knew that we’d need to build a user dashboard, admin console, etc… we turned to Grails.

Grails is implemented using Groovy, which is a scripting language that runs in the Java JVM.  Seeing as the rest of the Saffron stack uses Java this was another strong selling point for us, but it also means that in order to stand up Sierra we’d have to jump through all of the same hoops that come along with running a Java stack.

In the past all of our software and applications were installed and run in LAN environments.  This allowed us to ignore some of the issues that come along with deploying a Java application on the Internet.  Not so with Sierra, which is SaaS.  I hope to cover some of those challenges here which may, or may not be of some use to others.

1. Hosting – We needed some place to run the web front-end for Sierra.  While our new office does have sweet server closet we didn’t want to host it here.  We needed a place with more reliable power, bandwidth, etc…  We also needed an environment that would be relatively easy for us to manage.  We chose Slicehost.  With Slicehost we were able to get a server slice up and running in minutes.  It really is a great service.
2. Port 80 – Whenever you use a web browser to hit a web server your traffic typically travels over port 80 (unless your using https).  The port number is usually assumed and you don’t even see it in your URL.  Unfortunately Java web containers (Tomcat, Jetty, etc…) don’t easily run on port 80.  They typically run on port 8080.  The reason for this is one of security.  Most Unix OS’s don’t allow a non-root user to start a process that listens on a port below 1024.  You don’t want to run as root because that could be bad.  So, your left trying to figure out how to let people hit “http://saffronsierra.com” and not “http://saffronsierra.com:8080″.  There are number of potential solutions to this problem.  Using iptables seems to be the most commonly used/recommended approach and is the one we chose.
3. Too Many Redirects – Some Grails plugins give you to ability to state what URL endpoints needs to travel over http vs https.  This gives you the flexibility of not having the explicitly state http vs https in your markup.  They do this by issuing http redirects.  This works great in a development environment, but can cause problems in production.  As we moved over to our slice we kept getting the browser error  ”Too many redirects”.  Browsers have a threshold as to the number of times a particular request can be redirected.  I’m guessing, but I think the solution to the port 80 problem threw us over the redirect limit.  In order to get around this we had to explicitly define “http://” or “https://” in our markup.  While this doesn’t give us the flexibility of being able to separately define things on the fly in configuration, not markup, it will work for now.
4. Spam – Sierra needs to send out emails to user for certain events (registration, service start, etc…).  We setup Postfix to send mail on localhost.  However, I noticed that whenever I would send a test email to my Gmail account it would get flagged as spam.  After reading and tinkering a bit I figured out that by simply modifying some of the defaults in the “main.cf” configuration file for Postfix Gmail no longer thinks Sierra email is spam.  The steps I followed to edit main.cf are nicely listed in this Slicehost article.

I’m sure there were other challenges, but those are the “big” ones that come to mind.

Tags: development, grails, Groovy, Java, REST, Saas, SaffronSierra, Slicehost

This entry was posted on Friday, September 4th, 2009 at 4:22 pm and is filed under SaffronSierra. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.