Heroku the Great

Deployment Tears Be Gone...
It is true that using Heroku made my pains go away. My "I am doing this side project - this ultra lean startup and I don't have time for this" pains went away. It is simple. However, before walking in the door at Heroku you still need to assess your intentions.

How Are You Being Served?
This question is more about your use of Heroku as your customers see it. Ask yourself - how is this application being reached? Is it a stand alone? Is it one of those Facebook apps hosted here with data per user? Is it for a company? Is it SAS for many companies? Is it a hybrid?

My interest lies in a corporation using our application to add some capability to their web site for their own users. It is in effect SAS but serving the UI not just SOA services.

Serving many groupings of end users from one application means doing one of two things per Heroku Support (I asked after exhausting the docs and my patience searching at large):

1. Create a separate deployment for each company - so you in effect are managing, paying for and billing for the cost of multiple applications on Heroku. There are no tools yet to automate that.
   
2. Partition your data by corporation using it.

So we landed on using a database key to partition our data by company - in concept - we have to settle on the domain design which in our usage of Rails will be pretty much equal to the schema design. We ain't fancy folks and we save our tears and toil for the UI and core application. As for UI struggles maybe I'll post some thoughts on this later on. Oddly, the villain in this isn't just poor old IE 6...