Whenever you spin up a server, it inevitably leads to the consumption of fossil fuels for its power source—and you will get a bill for it, regardless of whether it's discounted by a hyperscaler or not, writes
IT bloat results in financial expenses and a surge in electricity usage—and given how few ‘Green’ data centres there are on the power grid, it poses a threat to the environment. As any diligent CIO will always seek to rationalise and optimise their infrastructure, what measures can be taken here?
Fortunately, there is hope for rebalancing in the form of a bit of rethinking by developers and adopting more efficient software architectures in the cloud. By slimming the need for so many servers—and so trimming electricity consumption—we genuinely can make a difference to our power consumption profile. Given that enterprise IT alone accounts for 1.5% of the planet's total energy consumption (even discounting deliberately wasteful fringe IT activity like Bitcoin mining), such savings might soon be very noticeable for both your company’s bottom line and the climate’s long-term health.
Thankfully, there is an opportunity to restore balance through a return to some good computer science basics and an examination of the basic data structures used to attack the problem at hand. An excellent illustration of this is how Adobe eventually discovered a highly-tuned way to deliver a popular online service.
Fewer database nodes, but the size of the dataset had more than doubled
Adobe offers a platform called Behance, launched in 2005, which allows individuals to showcase and discover creative work in a social media-like environment. Behance is a way for millions of artists to quickly upload and share their projects, with over 24 million members as of October 2020.
Behance became part of Adobe in 2012, and work started on replatforming. This commenced with a shift to NoSQL document-oriented database MongoDB for introducing the activity feed.
Initially, the configuration for Behance consisted of 125 nodes in a dataset of 20 terabytes. The Adobe IT team tasked to look after Behance recognised the need for optimisation and conducted a second port. They decided to stick with the NoSQL approach, but this time opted for Cassandra, a wide-column store NoSQL database management system.
Over time, several improvement projects were conducted to enhance the delivery of the platform. Three years later, the service was successfully running on fewer database nodes, specifically 48. However, the size of the dataset needed to power the platform had more than doubled to 50 terabytes.
The graph alternative
Users liked a lot of the features, but performance was slow. A third migration was initiated, leading to the adoption of a significantly different database approach, that of graph database technology. And this step proved to be highly successful, serving as the current home for the system. It also exemplifies the benefits of some hard thinking about what the optimum foundation for a computationally parsimonious SaaS app might be.
As a result, Behance using graph technology runs perfectly seamlessly for its millions of users using just three database nodes and maintaining a dataset size of 30 to 50 gigabytes—a thousandth of the previous storage requirements. In fact, the system's efficiency goes beyond that, as each node has eight cores, two terabyte SSDs, a mere 118 gigabytes of RAM per instance, a 50-gigabyte page cache allocation, and a 15-gigabyte heap. This all adds up to a much smaller data centre footprint than the two previous iterations.
It’s a fascinating odyssey, I’m sure you’ll agree – filled with choices that presented their own set of advantages and challenges at each stage. With Mongo, for example, despite being a highly flexible option, database reads were slow because connections had to be computed at high cost along the way. However, with the transition to Cassandra, the slow read problem was solved by introducing something called ‘fanouts’, a popular workaround commonly employed in social feed systems.
See also: COBOL code base in production hits 800+ billion lines
Indeed, as the number of users and data size continued to grow, this approach started to become an issue as it put a large overhead on the system’s web infrastructure. After all, a popular Behance poster with 10,000 followers would require 10,000 individual database writes to publish a new project on each follower’s Behance feed.
That functionality is actually central to the user experience: Adobe calls it ‘Activity Feed’, something that enables users to follow their favourite creatives and curate galleries based on preferences. When a user follows a creative, they receive alerts and an updated feed whenever that creative logs an activity within the app.
The move to the Cassandra version did prove to be an improvement compared to the Mongo iteration. However, keeping the Cassandra version going required much attention and management from the Adobe ops team.
But upon deeper consideration of the application's nature, it’s clear that Behance functions as a social network where people follow certain individuals. By adopting a graph database, that inherently focuses on relationships instead of other data structures, the fanout model required by Cassandra became redundant overnight. This was a big contributor to the huge reduction of the dataset size. Losing the fanout model allowed Adobe to deliver the activity feed users wanted to see in under one second, compared to the potential four-second delay previously experienced.
The best way to solve your programming problem
I am not saying that every problem can be rewritten and optimised with graphs.
On the other hand, it's also true that not every IT problem necessitates the utilization of extensive resources like 1,000 servers and Apache Spark.
So let’s get back to basics and think about the most efficient way to solve a problem resource-wise, not just with cloud brute force. Doing so will potentially lead to cost savings and reduced environmental impact.
