A popular infrastructure for web applications is the ‘shared nothing’ architecture (sometimes also referred to as ‘share nothing’). Interestingly enough, even though shared nothing architecture is widely used for web development, the idea was thought of way back in 1986. According to this Wikipedia article, Michael Stonebraker at the University of California, Berkeley used the term in a 1986 database paper.
While the idea has indeed been around for some time, it wasn’t until recently that it became a more popular means of deploying systems.
A shared nothing architecture is one in which you have a number of separate nodes that do not share particular resources, most notably disk space and memory, though this can be expanded to include other resources such as databases that also should not be shared.
Comparison of several architectures: share everything, share disks, and share nothing. Source: SlideShare
Operating under numerous self-sufficient nodes rather than having a single source of particular resources offers several advantages: easier scaling, non-disruptive upgrades, elimination of a single point of failure, and self-healing capabilities.
Scaling becomes simpler when things such as disks are not shared. For example, scaling up a single shared disk to get more storage space can lead to enormous problems if things do not go well, as all of the other resources require that disk to be able to do their work.
On the other hand, if you are using several nodes that do not share the space, scaling up the disk space on any or all of the resources becomes quite a bit easier with less potential problems. If the scaling should fail on one of the resources, the others will still continue to do their work normally. According to Gerardnico, “This architecture is followed by essentially all high-performance, scalable, DBMSs, including Teradata, Netezza, Greenplum, as well as several Morpheus integrations. It is also used by most of the high-end e-commerce platforms, including Amazon, Akamai, Yahoo, Google, and Facebook.”
Similar to the scaling advantages, you can use shared nothing architecture to perform non-disruptive upgrades to your services. Instead of having a certain amount of downtime while you are upgrading an infrastructure with shared resources, you can upgrade a node at a time, and the redundancy in the other nodes will continue to run so that you do not need to shut everything down for the amount of time it takes to perform the upgrade.
For example, if you need to upgrade an app, you can do so on each node while the others are running. Since these nodes don’t share disk space or memory and instead redundant copies of the app are on separate disks, you can simply update each one in turn without taking everything down. If one of the upgrades fails along the way, it will only take down the single node rather than the entire service. This can make upgrading much less stressful.
With shared systems, a single point of failure can take down your site or app entirely. As noted, the ability to have separate systems on separate nodes with redundancy can make things much easier while avoiding the disaster of a single failure causing unexpected downtime.
For instance, the failure of a shared disk could prove quite disastrous to your system. Since it is a single point of failure, none of your other services can run properly until the failed disk is restored. If there is no recent backup, then you may also incur a data loss, which could be small or very large in scope.
The next step, in this scenario, is to stand up a new disk with the latest backup you have (or in really bad cases this could be only the basic data you need to run the system from scratch). This will likely take some time and your services will be down or non-functional until the recovery work is complete.
It is indeed much better to have some redundancy in separate nodes as well as knowing the other nodes won’t fail due to a disk failure on a single node.
Along with all of the other advantages, “shared nothing” architecture allows for some amount of self-healing that can be another line of defense against unexpected downtime. For example, when you have redundant copies of data or databases on different disks, a disk that loses data may be able to recover it when the redundancies are synced.
Had it instead been a single, shared disk, the data would be lost and downtime would inevitably ensue. As you can see, shared nothing architecture can be very helpful to your organization, and perhaps save you from any number of outages that might otherwise occur when certain resources are shared. Even though the initial idea was introduced more than three decades ago, today’s technology makes shared nothing architecture a much more viable option.
