Moving Code to Data
... rather than the other way around.
The two building blocks of computing are code and data. These are often in different places, so one has to be moved to the other.
For example, if you have a PDF on your computer that you want to convert to PNG, you can download a program to do that to your computer. This approach keeps the data on your computer. Alternatively, you can upload the PDF to an online converter, keeping the code where it is, and instead moving the data to it.
Of these two approaches, I think moving code to data has a lot of potential:
First, if you have any online service that has to work offline, like Google Docs, you have to download the code to the user’s device, anyway.
Second, with edge computing, I want my data to be stored in or close to my city, rather than thousands of kilometers away. Imagine an app like Google Docs that stores each user’s data in their city1, rather than in a central datacenter, so that everyone gets lower latency. Copying the Google Docs code to hundreds of cities is better than uploading everyone’s documents to a few central datacenters. Code is easy to duplicate: you can just make copies of it. Not so with data — when you copy data, you’re opening the pandora’s box of data consistency problems like stale copies and conflicting edits.
Third, large-scale cloud services use distributed databases, which shard users’ data into multiple machines. But, in that case, why not co-locate the code that processes that data on the same machine, rather than having separate app servers that receive a HTTP request from the user and then make an RPC to the database? Such separation introduces a whole bunch of problems:
Latency.
Errors.
Retries, which are often the solution to errors, but have their own problems: if you retry thrice at three layers, you’re retrying 27 times, which is enough to bring down your lowest layer, like the database, and prevent it from starting back up.
If you have M app servers and N app servers, you have MxN connections, which can impose significant load.
Discovery — how does the app server know which backend instance(s) to connect to?
The overhead of networking, on both sides of the connection. Especially if you code synchronously, with one thread per connection.
All these problems go away with co-locating the backend code on the database servers. This technique may not have been feasible in the past with multi-gigabyte servers. But we now have serverless environments like Google App Engine and Cloud Run that have low overhead. And FaaS in the form of AWS Lambda or Google Cloud Functions, where each function can take as little as 128MB. Other technology is pushing the boundary: a Cloudflare worker starts up in 5 ms and takes only 3MB memory. Such technologies open the door to more ways in which the code can be moved to where the data is.
With the exception of shared documents — if an Indian shares a document with an American, the document can’t be located in both India and the US.