Why Railo kicks butt for ColdFusion based SaaS

There is a lot of debate around the relative merits of Railo v Adobe ColdFusion and each to his own with that debate. There is however one area where Railo is a clear winner at the moment ( not to say that Adobe won't catch up in the future), and that is in the area of having a CF engine to create a Software as a Service platform.

We found we had 4 major considerations for the CF application engine when creating a Software as  Service platform

1. Scalability

We needed an archiecture that allowed us to deploy as many CF instances on a single server as possible to ensure our business model worked to allow lost cost and high performance, our SaaS service is based on the Amazon elastic cloud and we wanted to minimize the number of servers to make this work. Our ideal archiecture was to use Jboss and to create each web instance as a jboss WAR and to then to be able to monitor each WAR and to have unique admins for each web app. In the past we have used CF Sandboxing to manage individual CF applications but this is still one CF instance on one App Server instance, we couldn't give each client their own CF admin login and this ultimately lead to the type of restricted and locked down to the point of useless hosting arrangements many developers have expereienced with CF hosting. Railo has the ability to given each WAR / Client their own Railo Admin (eqivilent to CF Administrator), but to also have a centralised server admin for overall control. The great thing about the way you can do it in Railo is that you can use centralised application libraries meaning that each new web app has only a small memory / resource footprint, our expereince with CF had been that you couldn't run more than 5 or 6 CF instances on a single server before it started to create load issues, with Railo we have tested up to 1000 and still found the server coping well. Obviously this is based on a lot of smaller load sites but what we care about is how busy all the sites are on the server and the total load, using the WAR archiecture we can monitor each web app separately and instantly see if any apps are using heavy load and scale elastically as required. Another winner for Railo in the scalability test was the ability to easily cluster, with close integration with Jboss clustering and an integrated cluster scope, clustering is easier to setup and manager.

2. Security

If you are going to allow developers access to build applications in a shared hosting environment then security is a big concern, and one of the reasons so many ColdFusion developers have found it frustrating when looking at CF hosting as hosting companies have been forced to lock a lot of things down. As mentioned above Railo allows individual webs with their own administrators which are mapped to an app server WAR, this means you can easily lock down a war and the Railo security manager makes it easy to lock down file access to the WAR. You can also add exceptions to the security model to allow access to shared folders on the server, this was a feature we commissioned Railo to write for us and works really well. All up the security model in Railo with individual webs and administrators is considerably more flexible than the CF Sandboxing model with everything running on one instance. It also allows clients to control their own application level settings without having to involve us. Whilst you could have done this via an API with CF I think Adobe could learn a lot from the way Railo have done this.

3. Cost

If you look at the really successful SaaS based appliations available very few are built on commerial application servers, the biggest are built on PHP or Java such  as facebook. Having had to put together business models on building SaaS application platforms then I know that using an open source platform has a lot of appeal as it reduces the licensing risks more than the cost. For example if you are on an underlying commerical platform and the vendor changes their pricing model then your whole business plan could fail, as much as Adobe have been good business partner of ours over the years they have been known to completely change their charging and product offering every couple of years and whilst this is manageable it is still risk. If you are going to deploy  300 servers then the underlying cost starts to add up, we currently run around 20 Amazon servers with the majority now running Railo and there is no denying that cost plays a part, especially given the benefits Railo offers in running the type of setup we are using. Whilst I like using open source products I still believe that there has to be a strong underlying business model for the product vendor, and that relying on services to pay the bills is a hard game to play. Unless Railo starts to expand their business model I am sure they will start to fall behind Adobe as they wont have the cash to reinvest back into product development. We're in that game and know exaclty how hard it can be but I'm sure Gert and his team are working on this. If Adobe CF had the scalability and security features of Railo I am sure that would overcome my Cost argument as these are critical requirements.

4. Updates

Working in the dynamic environment that is the web today, getting frequent updates to your underlying platform can be vital to keeping on top of the game. Again this is where Railo really has nailed it, whilst Adobe is without doubt better tested and tighter the easy updater from Railo is a game changer. As mentioned above we needed an update to the security features in Railo (we'll blog later on this) and commisioned the Railo team to build it. Once finished they gave us an update URL and we simply just updated our servers. With Adobe you're looking at updates of major functionaliy every couple of years and this can be a very long time for a SaaS platform.

 

In summary I'm not trying to compare Adobe CF to Railo from a coding side of things but from how they compare directly when used to build a Software as a Service platform. I know Adobe have announced they will support CF on Amazon Ec2 but this is just moving the single server CF model into a rentable cloud model, it doesn't solve the issues around building a SaaS platform. Our Railo port wasnt' a cake walk by any means, given the size of our application (smaller apps are certainly a cake walk to port), and going forward we still need to support both Adobe CF and Railo so have increased our release workload. If you are looking to build an SaaS platform and know CF (or PHP or Java or Ruby for that matter) , then you should seriously look at Railo.

 

 

---

Comments

Add a comment

---

---

---

---

---

---

Add Comment