The Server-Side Pad

by Fabien Tiburce, Best practices and personal experiences with enterprise software

Archive for August 2007

It’s Good to Have Principles!

with one comment

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.

While I have long relied on design principles for application and database development, the rise of Ajax and Javascript libraries places a bigger emphasis on design principles for the front-end. Conflicts in Javascript libraries and styles are more frequent with Javascript and scriplet-friendly Web 2 applications. And with Ajax bridging the gap between front-end and back-end technologies (and in the process bridging the gap between front-end and back-end developers), establishing design principles for the front-end is a worthwhile exercise for a development team as a whole.

Advertisements

Written by Compliantia

August 17, 2007 at 3:34 am

Choosing an AJAX library

leave a comment »

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.

Written by Compliantia

August 8, 2007 at 1:51 pm

Google and YouTube Scalability

leave a comment »

Google’s recent conference on scalability held in Seattle in June 2007 offered an interesting insight into how two of the world’s largest properties have and continue to scale their systems.

Google scalability presentation

YouTube scalability presentation

Written by Compliantia

August 8, 2007 at 1:41 pm

Scalability Principles

leave a comment »

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…

Written by Compliantia

August 8, 2007 at 1:18 pm