Code Wizards’ Blog

This is a problem that unfortunately we so often see.

Architects are employed to ensure that software projects have a reasonable base; solutions are well thought out, robust, and follow industry best practices; and provide a more detailed but higher-level view of application spread (and inter-operation) than a senior developer, project or programme manager could affect.

However, there’s a gap, the architects produce plans and ideas and don’t communicate them effectively to the developers, so new problems arise. Often it then gets worse because the architects blame the developers (and especially the lead developers) for not following the plan, while the developers blame the architects for poorly thought out plans and non-committal/non-understandable language. Out of frustration, I thought we could cover one of those major communication problems today: Scale-Up vs. Scale-Out.

Any developer who’s been in the industry has heard these terms a few times (probably by some people who have used them inter-changeably), however they mean very different things and have different design decisions and costs associated with them.

a. Scale-Up -> To add additional hardware (processing power, memory, faster/bigger disk) to a solution to enable it to scale further

b. Scale-Out -> To use additional hardware nodes (web servers/database servers/application servers) to an existing solution to enable scaling by spreading the workload further. (Note: this also includes strategies where duplicated hardware is put in place and the solution is segmented down functional/data lines so that each set of hardware runs independently of the other). Grid computing is an example of Scale-Out pushed to the maximum.
Scale-Up is usually the first port of call for badly performing applications, but there’s always a high point of what can be done. Even if you started on a single CPU Windows 2003 server and then ported up to a SUN Fire E25K you’ve still hit a ceiling. However, for most projects this makes sense as the user/work loading will never be exponentially larger than it started. So long as there’s sufficient upgrade path (and the application can handle it) then Scale-Up will often be the best in cost-benefit analysis, primarily because one only upgrades (or moves on to new hardware) if it’s strictly necessary.
True Scale-Out requires designing from the start as it’s hard to push a Scale-Out strategy on to existing solutions. If the service is known to be massive from day one then segment your workload like Google/Ebay and co and have multiple servers that all do a minor part of the workload, and other servers that collate that and have responses back to the user. In that way you can always add more hardware to do individual tasks without a major problem. However, for smaller projects this isn’t worth the cost or the stress.

Some architects like to say they’ve got the ultimate scaling strategy: a mix of Scale-Out and Scale-Up, and to an extent some do. However, having your webserver, app server and database server on a single machine, then scaling out to three machines, before beefing up each of those machines further isn’t true Scale-Out (it’s just a modification of the Scale-Up strategy really). For those solutions you have to be extremely careful about issues like marshalling (inefficient data passing between tiers won’t really hurt when you’re on the same machine, however if you have to pass that data across a network, serializing and de-serializing as you go, then that can cause major issues.

Hope that helps explain Scale-Up (aka ScaleUp) and Scale-Out (aka ScaleOut). As ever i’m happy to hear from you with questions etc.