The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Hosted ISV tech references

I'm going to repost here - not many responses in the JOS group... 

I've been looking for some good resources and best practices on how to set up and maintain a hosted service provider model (ie. salesforce.com, Flickr, del.icio.us, etc).  I'm looking for a resource that talks about architecute type decisions, designing for scalability, selecting equipment, equipment specs, selecting an ISP, dedicated hosting vs. colo, app server selection and why, database design decisions, physical and logical app design considerations, etc. 

I've come across some good individual examples such as the wikipedia enviornment http://meta.wikimedia.org/wiki/Wikimedia_servers and a set of presentations on the Flickr architecure http://www.niallkennedy.com/blog/archives/2004/10/flickr_architec.html - but I'm looking for something with  broader coverage - a blog or a tech site.  It just seems like all the standard dev/tech sites cover enterprise considerations (which can obviously be applied to an ISV), but there doesn't seem to be good tech resources for the ISV service provider.  Am I wrong? 

Thoughts?
Jim Jones
Tuesday, December 06, 2005
 
 
I worked at a large hosted provider (on the order of a Salesforce.com), and there are some techniques that can translate to a uISV

1. Organize your databases into a system db, and a db for each customer.  Otherwise all your tables are keyed by customerID, and when you run out of space on your shared customer database, you'll end up splitting them up across servers anyway.

2. Reliability & security is everything.  Do not install any software on your production machines unless you're sure it doesn't have memory leaks or other bad behavior.  Do not install any hardware on your production machines unless it's on the WHQL list and has a proven track record of good drivers.

3. Strictly minimize custom features.  Give them some fields like "custom1, custom2", etc. and that's it.  Allowing the customers to dictate features to you will make migrating to new releases extremely difficult.

4. Have a process to develop, test, and promote code to the production servers.  Make sure your customers know when the system will be unavailable due to upgrades/maintenance.  Be transparent.  Don't let them demand five-nines availability -- no one can deliver that.  And certainly don't put anything like that into their SLA.

5. Automate the customer sign-up and departure process so that you're involved as little as possible.  If they're departing, make sure they get their data in a timely fashion -- hopefully in a CSV or XML format.

6. Support Unicode.

So far as hardware selection, you can't afford it at this point, but plan for clustered database servers (meaning you must buy the Enterprise licenses for Windows & database server), redundant switches, routers, and firewalls.  For your RAID or SAN, make sure that you have a hot-spare in each array (voice of experience talking here!)  And just in case the hot-spare doesn't work, have a working backup & restore process going.

Best of luck.
example Send private email
Friday, December 09, 2005
 
 
The company I work for is about to host its application at an ASP. One of the requirements this ASP has it that the application uses one database, designed for multi-tenants. This contradicts example's recommendation to have a database per customer.
Personally I like the database per customer model better, but in this case we cannot use it.
Viking147
Saturday, December 10, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz