Theory vs. Practice
Diagnosis is not the end, but the beginning of practice.
› What is "2D Scalability"?
If you provide a successful service, then you have to make your application(s) scale. There are two dimensions which can then be involved for scaling:
- horizontally using several machines, each of them running your application(s)
- vertically using several workers running your application(s) on each machine.
The second way of doing things, scaling vertically, was introduced in the early 2000's on commodity hardware (a decade ago). Despite multicore being now ubiquitous, from cellphones to Data Centers, network switches, TVs, planes, trains, boats, automobiles, laptops and desktops, there is still a wide gap as far as software development tools are concerned.
The question is not whether or not you will have to use parallelism (adding a dimension to the equation grants you access to exponential gains), the question is about how to do it to reduce costs. After all, you have paid for this hardware so not using its capabilities is quite a pity.
Scaling from 1D to 2D
Today's software scales horizontally. But scaling vertically is harder because parallel programming is a challenging technical field, requiring applications to be redesigned from scratch by parallelism experts.
Internet / Intranet
Clients
This is not a problem for dedicated hardware which can only focus on one single specialized task. In contrast, software, including App. servers are by definition more generic and therefore present more difficulties to scale vertically.
↓ ↓ ↓
Server Farm
Load-balancers
↓ ↓ ↓
App. servers
↓ ↓ ↓
Switches
↓ ↓ ↓
Storage
As a result, it is not surprising that App. servers are the bottleneck* in Data Centers. This is what triggers the common conclusion that software is making progress slower than hardware.
The only remaining question is what has to be done to fill that gap – at the lowest possible cost.
The answer is obvious: do not change your codebase – keep using the same libraries in the same programming language so you can avoid hiring experts to redesign everything.
All what is needed for this to be done is a multi-language App. server which makes legacy code scale vertically.
And G-WAN does it better than the servers dedicated to any specific programming language.
Not filling this gap is pointlessly increasing costs in servers, network equipment and electricity, the recurring costs.
Removing the last Bottleneck*
Given the fortunes spent at dedicated hardware to make Data Centers more efficient, it sounds like a shameful waste of resources to ignore software App. servers – the largest bottleneck by several orders of magnitude.
G-WAN's mission is to remove this last negative coefficient from the equation in order to have a coherent processing chain.
And if you are not (yet) using a Data Center, using one single server machine instead of a few ones will also generate recurring savings, simplify your operations and greatly please users with a much lower latency, delivering more responsive services.
[*]: We have received so many remarks stating that the real bottleneck is rather the database that we have written this this addenda to just point people to a relevant resource. I maintain, with rock-solid ground, that databases are the bottleneck only if you are misusing those tools. When used properly, databases are not the bottleneck.