Make Open Source Project "runs best" on OpenSolaris

Often people ask me what I do for a living and my short answer is "We make applications run best on Solaris". However it is generally not clear to many people what "run best" on Solaris or now OpenSolaris really means. Majority of the people think it is all about performance since it can be a measured quantity for an action "runs" in terms of "how fast". Well that is just one part of the job. Runs best actually means multiple thing. Lets take an example to see how it means multiple thing.

Consider a Business problem that can be solved by using a solution based on IT. Well the first thing most people will do is find the right piece of software that solves the business problem. Lets call it the BusinessApp. Now BusinessApp is what now drives the foodchain for the Techical Architect to see how that BusinessApp can be deployed to acheive the goal. Let's assume a simple scenario that the BusinessApp requires a DatabaseApp and both of them running on some OperatingSystem running on SomeHardware.

Let's recap the components

1. BusinessApp (for example: Openbravo ERP)


2. DatabaseApp (for example: PostgreSQL)


3. OperatingSystem (for example: OpenSolaris)


4. SomeHardware (for example: Intel Xeon Quad Core based system)

So the question is what really features are more appealing to the Technical Architect:

1. It should work - No brainer


2. It should be easy to integrate the components and deploy it
   


3. It should be easy to maintain
   


4. It should perform meeting a minimum user expectations on how long to wait
   


5. It should scale with the increase in the number of users

So "run bests" means all of the above in tandem. The priorities may differ slightly depending on the Technical Architect but most of them will agree the initial thing is to meet the first three steps before you go for a pilot to test the performance out.

 So how do we achieve "runs best" on OpenSolaris

1. First of all we identify that the individual components (say PostgreSQL, Openbravo, etc) works on OpenSolaris which is what most people mean when they say "Oh! it works", "Oh! Its supported" in ascending order of deep support of components in the stack.
   


2. The "Easy to integrate/deploy" is often missed out however it is quite important for the "First User Experience of a deployer" who often makes recommendations on what's easy to do. For example to use Openbravo on OpenSolaris you need PostgreSQL, Tomcat, Ant, JDK and integrate them together before you can deploy the Openbravo ERP application on OpenSolaris. Most of the time you need a tight integration to "Ease" the pains which generally to many are more critical than the performance problems itself. This is mainly resolved by having documentation and/or  good scripts which makes sure that the dependent and other components are preinstalled and a great installer to integrate all of them together. Remember pkg(5) doesn't do all we want, it installs the components we still need to have good scripts to integrate all the components together to act as a single integrated application. That's an effort which has the biggest return on investment since many people find this step as make or break to continue with the effort of seeing the feasability of whether deployment is possible or not.
   


3. Yet another thing which is important but often sidelined is  "Easy to Maintain". For example starting Openbravo requires that PostgreSQL server is running and then also Tomcat is running. Instead of making a user run different scripts, a well written SMF Manifest makes it easy to start and stop the service on OpenSolaris which can be made practically hands free and start and stop along with the database. Otherthing which really helps "Easy to Maintain" are the new ZFS snapshot features which in the next release of OpenSolaris (2008.11) will include Time Slider which can be tweaked to make sure that the app and all its related components have consistent snapshots which means you always have a good and working version to revert back in case a bad thing happens.
   


4. This one is the most popular of all "It Performs Great!". Of course it doesnt perform all by itself. Every Technical Architect knows that its best to do their own performance test if their name is going to be tied to solution. DTrace on OpenSolaris is exactly an aid in those scenarios to help resolve the problems many times before it occurs in Production. And fortunately even when the problem does make it to the production system also.


5. Of course no solution is complete if the scaling process is not thought out before. These are the what-if scenarios. What if instead of 50 regular users, I get 30,000 users because an email from HR was fired to input all the vacation days in the system before the end of the day. Such scenarios are unfortunately more common than not.
   

Again all this is part of the job to make an OpenSource project for that matter any project run best on OpenSolaris