Aaron Worsham

For anyone who has run multiple instances of Rails on the same server, as is common within the frugal budgets of corporate IT departments, then you will have run into a limitation of resource allocation, typically memory.  The Ruby community likes to defend their language’s performance tradeoffs by reminding us all that hardware is cheap, or at least cheaper than your developer’s time.  While I agree that hardware is cheap, cheaper still is not buying more hardware than necessary and instead find new ways to use your limited resources efficiently.  The folks at Phusion have similar concerns, which is why they have developed the Ruby Enterprise Edition.

Ruby Enterprise Edition is a forked version of the Ruby on Rails web framework.  For those not familiar with the software practice, forking is taking existing source code, usually open source, and branching off your own version in your own direction.  Programming communities discourage excessive forking because it waters down the developers focused on the original project.  However, when a group has different goals than the original, it can be the quickest and least painful way to accomplish that goal.

The goal of the Phusion group who created Ruby Enterprise Edition was to directly address the memory sharing practice of multiple instances on the same hardware.  Technical details can be found here For those business users who have issued one server to be their company’s ‘Rails Application Server’, this fork may become a standard deploy.  It purports to save 33% of the memory typically allocated with the parent version of Rails. As the fork is compliant with 1.8.6, you can run all of your recently created web applications unless they were developed against edge rails for the very recent release of 2.0 or 2.1  Forks typically lag behind parent source code in feature support, but there is no reason to doubt Enterprise Edition will not support 2.0 soon

Phusion has not rested on this solution for improved corporate rails hosting.  They have already also developed a module for Apache called Passenger (also called mod_rails).  Apache Modules like this have made languages like PHP a brain-dead easy solution for developers and programmers to get web apps up and running.  As I have said earlier, Rails suffered from a complex set of options for hosting.  Mod_Rails really takes that issue out of the equation.  Couple Passenger with Enterprise Edition and you have a well thought out corporate solution for your growing number of Rails applications

Personally, we are looking to use the Enterprise Edition / Passenger combination on an web application we developed internally.  It is exactly what we need to expand deployments of unique instances without overcompensating with more hardware investments.

Technorati Tags: ruby on rails, ROR, ruby, ruby enterprise edition, Phusion, Passenger

If three of the four words in that title apply to you (and one of them isn’t ‘for’) then you may want to check out eRubyCon

The guys over at EdgeCase are very talented Ruby consultants.  I have had the pleasure of working with them on a few projects and I can tell you their hearts are wholly into the Enterprise Ruby space. That kind of passion for their craft should translate into an engaging conference.  Certainly, the speakers they have lined up are first rate

My personal opinion is that if you are not using the best tool for a job, you are using a second rate tool. You can be in a .Net shop or a Java shop and still not have the right solution for every problem an Enterprise can throw at you.  If you have been at all impressed by what Ruby can do for you in the Web Framework arena with Rails and Merb, you should really check out the other places it can make a difference in your company.

Technorati Tags: ruby on rails, ROR, ruby, eRubyCon, EdgeCase

Without knowing it, my father has skillfully summed up a crisis we are facing online. ‘I have too many $#@%ing passwords’ he told me the other day ‘Just email them to me’. We had just uploaded our latest series of pictures starring his granddaughter. ‘Dad, its real easy. All you need to do is get a Flickr account. Tell me the account name and I’ll share my pictures with the account. Then you can login and look at them online’ I said as if I had just solved all of his problems. But, as I mentioned earlier, he has too many passwords. Too many accounts to remember. Too many places that want the same pieces of personal information over and over again. When he visits he brings his own camera.

The issue is one of those big, nasty problems that would have been solved already had their been an obvious solution. In the internet’s infancy the World Wide Web was just that, a web of interconnected, hypertexted documents. Plain old text-heavy Web Pages which were free to any browser who could connect and request them. Back then, who you were was a very uninteresting question to ask. Web sites didn’t care much what your username was or what street you live on or what your phone number is or who’s in your address book. It is back in this era that the Authentication and State models were developed for the simplest of cases where a sensitive document may have a basic password protecting it. This is years before online Shopping Carts, Home Banking, Corporate Intranets, Web Applications and Social Networks. We are today banging our heads against the limitations of past decisions.

Over time sites started implementing “login” methods as a way to validate users. They all asked the same personal information because no independent website talked with any other. Programmers typically call this a ‘Share Nothing’ approach. As more and more and more and more websites became important in our lives, this share nothing attitude was cause for a growing concern. Your information was being used as currency upon which you were granted services online, grossly inflating the chances of that information becoming misused or abused. Online user accounts were completely disjointed from your actual identity, to where on different sites you may be referred to as “aaronworsham” or “worshama” or “aaronw” or “IndyMusicFan56” or “MgoBlue1997” depending solely on what name was free and available at the time. Worse yet, many sites are using your email address for a username, forcing most of us to setup dummy accounts that we must now maintain for password reset requests.

So what is to be done about this? Scary as it may sound, we need to pull away from our “Share Nothing” architecture and start interconnecting these web services. What if my Father had an account at Google for his mail. If Yahoo trusted Google, it could ask Google to “log in” my father so that he could get into the Yahoo owned Flickr site and see his granddaughters pictures. His personal information, including his password, would be housed on Google only. The identity he uses to login could be his Google account or can be related back to his personal blog account or his personal domain name. His identity would remain static. This is the basic idea behind OpenID

The OpenID initiative was started by Brad Fitzpatrick of LiveJournal as a way to start distributing trust relationships for sites like his. In theory it works when one company agrees to be a provider and many companies trust that provider for their authentication. To date many more companies are agreeing to be providers of OpenID than sites willing to trust them. This is still early on, so I feel that this will change over time as more sites start out with the decision that their users do not want yet another place to store their personal information.

Authentication usually has a “on or off” connotation. You are either allowed in or you are not. That need not be the case. Taking the idea of trust relationships further, we imagine using the OpenId model to ask for permission to use services on another site. Take, for example, My father logged into Flickr through his Google OpenID. Now Flickr wants to email out a picture to each of his friends on his email address book. My dad could put all those email addresses into Flickr, but he wouldn’t like it. What if Flickr could use the OpenID trust relationship to ask Google to share dad’s address book. As long as Dad was prompted to provide his password, Flickr itself could be granted limited authorization into google to use dad’s Gmail address book. This is the idea behind OAuth.

The OAuth was a group project between the main engineer at Twitter and some engineers in the OpenID community. The official OAuth site has a good analogy to help get the concepts behind limited system authentication straight

Many luxury cars today come with a valet key. It is a special key you give the parking attendant and unlike your regular key, will not allow the car to drive more than a mile or two. Some valet keys will not open the trunk, while others will block access to your onboard cell phone address book. Regardless of what restrictions the valet key imposes, the idea is very clever. You give someone limited access to your car with a special key, while using your regular key to unlock everything.

These concepts of OpenID and OAuth are even easier to apply to closely controlled interconnected systems like within a company. Sure, most companies have standardized on an LDAP solution by now, but as more applications become web-enabled, it becomes advantageous to consider supporting the standards that the web is using on the outside. Once you try interconnecting your internal applications with outside, 3rd party systems that do not have access to your LDAP repository, you will want that trust relationship model OpenID and OAuth brings.

Technorati Tags: OpenID, OAuth, authentication