This blog series discusses scalability from three distinct perspectives: people, processes and technology. If you haven't read the first and the second part of this series yet, we recommend you read them first before continuing with this post.

While scalability is an art more than a science, over time several sound architectural principles have emerged. Examples include designing for rollback or to be disabled, redundancy of all the components, embedded monitoring, asynchronous communication, stateless systems, etc. There isn't a perfect recipe that works for every project, but always keeping these concepts in mind and finding the right balance dramatically increases the chances of success.

This blog series discusses scalability from three distinct perspectives: people, processes and technology. If you haven't read the first part yet, we recommend you read it first before continuing with this post.

Processes are critical to scale. They cover and assist all the different stages of software development, from the early phases (planning, design), to implementation, to putting the software into production and maintaining it. Any activity is ultimately risky, and being able to understand the potential risks and gains is essential when growing your business.

When the user load is growing and adding more resources to the existing system is no longer enough, the first step usually consists of redesigning the system. As in every journey, it's good to know both the start and the destination first. So before starting any architecture or software redesign, you need to understand what the current state is. Calculating the headroom of your current system is a process that involves determining the current usage and the free capacity of each component, and measuring it against the expected growth. This will give you a better idea of the time remaining before service degradation or outages, as well as help identify the real bottlenecks of the current architecture.

In order to manage the success and popularity of a web site, it needs to be designed to cope with a growing number of users. A site designed to support 50 concurrent users can't serve thousands of simultaneous visitors without collapsing. Thus, the very success of a web site could also be the cause of its failure, if it is not able to sustain the sudden and exponential growth in number of users or requests.

A recent study by Computing & Double Take revealed that 83% of UK organisations admit downtime of several hours or more. Even if you manage to avoid a complete collapse, users will not stick around on a slow-loading site. The ability to grow (and shrink!) depending on need or availability thus becomes critical, directly affecting your revenue stream. A system that's able to cope with this changing demand is called scalable.

A couple of months ago I started working on a Typo3 project for a client, and at about the same time I was asked by the folks at Packt Publishing to review a book, so the choice fell naturally on "Typo3 Extension Development" by Dmitry Dulepov.

The book, published in September 2008, covers the entire extension development life cycle, from planning to uploading it to the Typo3 Extension Repository (TER).

Following last month's article by Ian, here's some thoughts on how to test a Zend Framework application.

One of the unit testing best practices suggests to break dependencies, so you can test each component separately.

The first problem that arises when you want to test controllers might be having a tighter control over the HTTP Request and Response objects. Fortunately, ZF already has something that really makes your life easier, i.e. the Zend_Test_PHPUnit_ControllerTestCase class, which has stubs for the Request and Response
objects, and you can easily check headers, return codes, routes, redirects, and even the view itself.