Archive for August 2007
In software development as in life, it’s good to have principles. Design principles are essential to discuss and document in the early days of a software development project. Principles support and protect the vision of the architecture; that which will allow it to be stable, flexible and/or scaleable. Without them (and this is particularly true in larger teams, new teams and teams with high turnover), it is easy to make day to day decisions that will weaken the application, introduce bugs or won’t scale. Design principles are guardian angels for software. Discuss them, review them often and go back to them when alternate implementations are being discussed.
The ubiquitous use of Ajax on Web 2.0 sites such as Google, Yahoo and Facebook has propelled Ajax into the spotlight. And for good reasons; used wisely, AJAX often improves the user experience by making it easier to find relevant and contextual information without leaving the page. The problem is that as of today, implementing AJAX is a mixed bag. Some features are trivial to implement (eg: auto-complete), others more complex and time consuming. It helps having a good AJAX library (or two) as a starting point. Just like designers and developers often use higher level tools to speed up development, AJAX libraries are a speedy alternative to coding AJAX by hand. The choice of a library hinges on a number of factors such as the template technology used (JSP, velocity templates, etc…), the type and number of AJAX functions and the degree of customization required. So unfortunately one size does not fit all. Also note that this is a relatively new market still. As the market mature so will the tools.
Today, one of the most useful AJAX tags library I have found for JSP development is Ajax Tags which is available as a Source Forge project.
Building scalable systems is a deliberate, purposeful and complex undertaking. Architected correctly, following certain design principles, a system will scale (handle a high level of concurrency and throughput), albeit with some effort. On the other hand, systems which were not designed to scale often end up being expensive and unreliable when stressed. So unless you are building a small departmental application, it’s often best to sow the seed of scalability right into the core technologies, the base architecture of your application.
So how do you scale?
1. Identify a few design principles and guidelines before you start architecting. Google made the assumption that no single piece of the application could be deemed 100% reliable. What you think is bullet-proof will eventually fail. Knowing this forces the architect to handle failures gracefully and build fall-back systems. This principles applies to software, hardware and network components.
2. Avoid single points of failures. Application serves are load-balanced. Load balancers and switches are paired. Databases are setup using replication/pooling and/or partioning. Should any given machine fail, the traffic is automatically rerouted to other components.
3. Build your system as a set of discreet components. Each components hides its complexity (and error handling!) to the rest of the system. A component can run on all or some machines. For example, background jobs can be handled by a thread pool server(s) instead of bogging down an application server used to serve user requests. Please note that using property and descriptor files, a single application can be instantiated in a number of ways declaratively so the developer does not have to build several applications.
4. Automate your unit and load testing.
5. Build introspection capabilities into your production system. The worst thing about a bug is not being able to understand it. Threshold based introspection capabilities must be built into systems so a developer can understand what is happening, who is using the system, what resources are being used, etc…