ArcReady is a quarterly Microsoft architecture meeting that travels through the Midwest.  This quarter Larry Clarkin himself is presenting on "Architecting for Scalable and Usable Web Applications".  Larry is the Architect Evangelist for the MidWest region and well known in Indianapolis. This session is about how to prevent scalability problems in web applications and how to handle them before they happen.  This is not a quick fix session about how to fix applications that already have an issue.

The room here in Indianapolis was packed.  There was a mix up in the rooms, and the ArcReady event got the smaller room.  There ended up being over 50 attendees with quite a few standing in the pack.  I was pleased that I left early and got a seat.

Performance vs Scalability

Performance is how your application behaves when there is just one user. Scalability is how your application behaves when there are many users.

Scaling Later: Don’t worry about how to handle your 1 millionth customer when you don’t have your first yet.  It’s good to start thinking about scalability early, but don’t spend a lot of time on it until the system is being used.  Getting revenue means that you have money to work on scalability in the future.

Patterns for Scalability

1. Block and Tackle: Diagram your network layout and all of its resources so you can identify potential bottlenecks early.  Caching can really help elevate the load.  For instance, cache the list of States in the country since this list isn’t going to change between page requests.
2. Scale Up: Taking existing architecture and improving pieces of it.  Many times this means work on the database server.  Web servers are easy to scale out, but databases can’t be farmed like web servers.
3. Scale Out: Adding more servers and potentially changing your architecture.  This often means adding more web servers in the web farm and moving the session to the database.
4. Specialize: For each server you add, give it a dedicated role such as a web application server, web service server, and a resource server.
5. Split the application: Put different parts of an application on a different server.  For example, at Amazon.com each tab for its’ store is on a different machine.  Microsoft has parts of its’ site on separate machines such as microsoft.com, msdn.microsoft.com, and technet.microsoft.com.  Microsoft ties its’ sites together with Live Passport and search indexing.
6. Split the database 1: Split the database based on data.  Perhaps have a Reference (read) and Transaction (write) databases.
7. Split the database 2: Reads happen a lot more than writes.  So have a lazy replication from writable database to a read database.  This could be done with replication.
8. Split the database 3: Sharding - Split data on some key such as area code or A-L & M-Z, etc.
9. Geo Distribution: You need to keep multiple copies of the data in multiple locations to avoid things such as power outages and natural disasters.  You could even use these sites to help route the traffic to its closest server center.  This does take a lot of replication work, but can really help with failover and scalability.
10. Offload the Work: Content distribution networks can help help funnel the work.  You could even push your entire web server farm to a company that specializes in this.

Anti-Patterns for Scalability

1. Spending all your time looking at code: Chances are the problem may be a setting or a hardware related issue
2. Caching everything: Scalability can be destroyed because of everything stored in memory.
3. Services calling services (especially across the network): This is a mess and causes performance issues.

Scalability Tips

• Make sure you set debug=false in your web.config file before deploying.  Partially because the timeout becomes timeout and the resources held by that request are kept with that infinite timeout.  You can put a string in the machine.config to prevent debug=true settings on any website on a machine.  It’s best to turn this on for every production webserver.
• Load balancing SSL is specific to the session and the service.  So if you just do true load balancing, performance and scalability will drop with SSL because of how the SSL negotiation works.  For each server a request gets routed to the SSL tokens need to be renegotiated.  To help prevent this, you can use server affinity so that every request for a client stays on the same server.  You could also have a single SSL negotiator that is in front of the web farm.
• Many times images and resources take up the majority of the data in a web request. So you can move these files to a separate server to help distribute the load.  This can include images, javascript files, css files, etc.

Usability

Application Archetypes

1. Information/Reference: Wikipedia, blogs, etc
2. E-Commerce: Amazon, e-bay, etc
3. Utility: Windows Update, etc
4. Data Viewer/Editor: Reporting sites, etc
5. Document Viewer/Editor: Office, etc
6. Entertainment: Gaming, Movies, etc

Web UX Continuum

1. Ubiquity: Web
2. Richness: Supplemented Web such as Silverlight
3. Next Generation: Platform Optimized such XBAP

Overall there are 35 different UI platforms that Microsoft gives developers.  You can run UXIQ (download) to give you the best option for your needs.

Usability Best Practices

1. Form follows Function: Think about functionality first
2. Create a set of design tenets: 5-6 pillars of design principles that the application must have such as "I don’t want the user to have to click more than 3 times to get anywhere".
3. Use the appropriate level of fidelity: How rich is the application?  Or have a different level of fidelity depending on the user.
   •  ProtoXAML is a template that allows you to take WPF mockups and skin them with "napkin" or "whiteboard" like look to the took.  People like the whiteboard metaphor and respond well to UIs that look this way when giving feedback.  This is an example of using very low fidelity to get a point across
4. Build with the customer and user’s input: Get customer input early and often.  However think about all potential users of the application.
5. Build for ease of use, but don’t forget the power users: (70-20-10 rule)  Make your application easy to use, but make sure you have options for the power users.  Tripit.com is a good example of this in use.
6. Plan for concurrency: You will always have more than one user in an application.  Think about locks and other data sharing
7. Balance computing load: This can make things faster and more scalable (see scalability topics)
8. Balance security with usability: Make sure you security mechanisms are also easy to use. Some password reminders can be confusing because the answer could be expressed in many ways.   For instance, you may be able to shorten the answer in some way or what about casing of the words.
9. Build for supportability & maintenance: Marketing always wants to update a website.  Make sure your site is easy to maintain and make changes to in the future.
10. Compliance: (Section 508 and Accessibility) One such issue is screen readers.  These are programs that read a website out loud for the visually impaired.  The readers have to be able to read your site in such a way that user’s can make sense of the data.

Anti-Patterns for Usability

1. Golden Hammer: The same solution doesn’t work for all applications
2. Breaking UI Conventions
   • An example of this could be using a hyperlink to represent a submit button.  Hyperlinks usually open pages or change navigation.  Submission is usually handled via a button.
3. Overuse of Animations or other types of bling
4. Not considering multiple "heads" for complimentary online vs. offline scenarios

Overall, it was a very good event (although seating was cramped).  It was Probably one of the best ArcReady events I have attended in quite a while.  Lately, I have thought the sessions have been a bit boring and not very useful.  I am glad to see the event is picking back up again. Larry is an excellent speaker (and mentor of mine).  He did a great job of engaging the audience and getting them involved.  This can often be a very difficult thing to do.  He wasn’t afraid of silence and to solicit the audience to get a response.

During the break, Larry showed a video of the WorldWide Telescope.  You may have seen this video.  Its of a little kid talking about where he lives and how see sees the sky at night. Larry stated that he couldn’t give us a copy yet because it wasn’t out.  I corrected Larry that it was released today (see last post) and can be downloaded.

The event ended with Larry asking the audience about some of the best practices for UI development.  The audience suggested things such as compressed scripts, no vertical scrolling, keep buttons together, keep consistency in site navigation, etc.

If you missed this event you can try to catch it at one of these locations:

• Columbus - 4/29/2008
• Kansas City - 4/29/2008
• Cleveland - 4/30/2008
• St. Louis - 5/01/2008
• Austin - 5/06/2008
• Southfield - 5/7/2008
• Minneapolis - 5/08/2008
• Indianapolis - 05/13/2008
• Downers Grove - 5/14/2008
• Milwaukee - 05/15/2008
• Houston - 05/15/2008
• Nashville - 05/20/2008
• Dallas - 05/20/2008
• Cincinnati - 05/21/2008
• Chicago - 06/11/2008

You can also download the presentation directly from the ArcReady website.