Expandable Hardware

Expandable Hardware

Hindsight is an exact science. Looking back, we can always see what the better decision would have been now that we know how things have panned out. How many people wish that they had bought high tech stocks back in the early 1990s? And how many other people wish that they had sold those same high tech stocks before 2000? The history of an experienced system architect will be littered with such learning experiences. One of the primary things that can be learned is that there is never enough money at the start of the project to build the system you really need by the end of it. In terms of software, you often have scope to continually refactor until it meets your needs. In terms of hardware, if your first estimate was too low, you usually hit hard and painful limits as the use of the system grows.

How do we ensure the hardware doesn't impose restrictive limits on the system?

Given an Internet technology system based around an APPLICATION SERVER ARCHITECTURE you will be able to identify multiple system elements that could potentially become a bottleneck as system load grows. Some of these bottlenecks will arise due to the capacity of the hardware rather than the software, so you must decide how this will be tackled from the outset.

As noted in the introduction to this pattern, we can never be sure about the forecasts for growth in traffic for a public Internet technology application. With the help of the business people, we can estimate our anticipated number of users and their usage profile. However, users may appear more rapidly or more slowly than we anticipate. In almost all applications, there is some restriction on the amount of money initially available. It may be that the system represents a first ‘toe in the water’ by a company into an area such as online banking. If so, they will not pay for an initial system that can support all of their existing customers. Rather, they will want to pay for, say, a system that can support 10% of their customer base but that can expand to meet increased demand.

As part of the creation of the system architecture, you will need to estimate how much hardware you need to deliver the sort of performance required. Take the case of the database server described in the ‘Costing the GlobalTech system’ section of Chapter 7. Our estimate for the initial peak load of 3000 consumer and 700 retail users is a server with four processors and 6 GB memory costing $30 000. We're pretty confident that this will easily handle the initial peak load but we also know that, if the system is a success, we will need to handle nearly three times this amount.

So we have a dilemma: do we specify just the basic server we know we need; one a bit more powerful to cope with some increase in load; or a server that, at the outset is capable of coping with the maximum load it is ever going to have to face? This is not a pleasant set of options. If we spend just $30 000 for the ‘base’ specification, we will have to replace the server as soon as the system starts to be really successful. If we specify a server that is a bit more powerful, we have to spend more money than we strictly need and we will still have to replace it if the system is successful. In fact, only luck will make this the best choice – we will need to be a bit successful, but not as successful as we hope.

The last option is a bit scary. If we want to be sure we don't have to replace the database server (unless we far exceed all expectations) we have to spend $85 000 rather than $30 000. If we're using DATA REPLICATION, we're looking at $170 000 against $60 000. If we don't succeed to the degree we hope, we may have wasted $110 000, more than the total cost of the rest of the system. Even if we do reach the expected level of use, it may take a year or so to get to this level, so why spend the money now? We need a way to be able to gradually increase the capacity of the hardware without adding additional servers – something we can't do with a COMMON PERSISTENT STORE.

Use hardware that can be expanded to add new processors (or higher-speed processors), memory, disks and network connectivity. Ideally, size the hardware so that it can cope with the maximum predicted load when it is configured to about half its maximum capacity in these four areas.

Populating a server with half its processors, memory, disk capacity and network connectivity is not a hard and fast rule. If your initial requirements are reasonably low, but success for your system may mean you need to quadruple the capacity, you can buy a four-processor machine and populate it with just one processor and 25% of its memory and disk space. This is a very expensive way to get the capacity you initially need but gives you a lot of room for expansion. On the other hand, if you think you might just need a little ‘room for manoeuvre’, an initial population of 75% of capacity provides that without costing too much more than fully-loaded hardware of the same power. In our experience, however, populating a machine to half its capacity gives a good balance between initial cost and expansion potential.

Let's look at buying EXPANDABLE HARDWARE for the GlobalTech database server. A fully-laden server with four processors and 6 GB memory costs $30 000. If we bought a higher-capacity server with the same specification, but with the potential to add a further four processors and 10 GB, we would need to spend $45 000 – we're basically spending $15 000 to get the potential to upgrade later on. Populating it with the remaining four processors and 10 GB costs an additional $60 000, giving a total cost of $105 000. This is $20 000 more than buying the eight-processor, 16 GB server straight away but $10 000 less than buying the four-processor server and then replacing it with the eight-processor one (although you don't have a ‘spare’ four-processor server at the end).

You may do the sums shown above and consider that the extra initial cost is unwarranted at the start of the project and it is better to pay more later as the traffic grows. If it were simply down to cost then this is an easy decision to make. However, EXPANDABLE HARDWARE also gives you the ability to gradually increase the capacity of the database server in line with increase in use (you don't have to choose whether to have either the ‘small’ server or the ‘big’ one). Perhaps after a few months we add two more processors and an additional 6 GB memory, with the last two processors and remaining memory following several months after that. And we have may have the option to do this in an unplanned way. If we experience a sudden surge in demand, we will be able to obtain additional CPU and memory much faster than we would an entire server. Is this worth an additional $20 000?

So, by starting with a more expandable server, we have reduced both the cost and the risk of upgrading. This gives the optimal upgrade path based on a higher initial cost. We could also apply this pattern to other hardware resources on servers, such as hard disk capacity, and to other hardware components such as routers, switches and network-attached storage units.

So, in addition to the expandable database server outlined above, we decide to use EXPANDABLE HARDWARE for the application servers as well, despite the use of LOAD-BALANCED ELEMENTS. This increases our initial cost somewhat but gives us two separate ways in which we can increase capacity, either by introducing a new hardware server to cope with large increases in use, or by adding some memory and possibly an additional CPU to cope with smaller increases in use. We also apply the pattern to the routers and load balancers, specifying them with spare slots for additional blades to cope with the anticipated increase in load.

Impact of the Pattern on Non-functional Characteristics

Availability	There may be a negative impact on availability if there is a decision to employ a single, expandable element rather than multiple functionally-identical elements.
Performance	Unaffected by this pattern.
Scalability	Scalability is improved due to the ability to add extra capability to the existing infrastructure.
Security	Security is slightly improved as there will be fewer elements to secure than there would be with the alternative strategy of employing more functionally-identical elements.
Manageability	Manageability is improved as there will be fewer elements to administer than there would be with the alternative strategy of employing more functionally-identical elements.
Maintainability	Unaffected by this pattern.
Flexibility	Flexibility is improved as it is possible to add more functions to the system without changing the underlying hardware, by simply upgrading what you have.
Portability	Unaffected by this pattern.
Cost	The initial cost of the system is increased. However, the cost of increases in capacity are reduced. One important caveat is that the potential saving will decrease over time. The development of hardware still roughly conforms to Moore's law and in two years' time, we are likely to be able to buy a hardware server four or five times more powerful than the one we purchase today for the same price. If we have bought EXPANDABLE HARDWARE with the intention of not upgrading for a year or more we have to be aware that it might be just as cheap to buy what we need now and then completely replace it when we run out of capacity.

Moving On

The evolution patterns so far have dealt with ways to evolve a system once it is deployed. There are also ways of building the ability to evolve into an application as it and its environment is developed.