FEATURE : CLOUD
flourished because rather than thinking about data at the granularity of databases or tables or even rows , they made a direct connection between code and data at a simple level .
A SUPERCLOUD HAS TWO INTERESTING EFFECTS ON THE COST OF RUNNING A PROGRAM .
You can think of NoSQL as a drive towards granularity . And it worked . NoSQL stores , KVs , object stores ( like R2 ) abound . The rise of MapReduce for processing data is also about granularity ; by breaking data processing into easily scaled pieces ( the map and the reduce ) it was possible to handle huge amounts of data efficiently and scale up and down as needed .
The same thing is happening for cloud code . Just as programmers didn ’ t always want to think in databasesized chunks , they shouldn ’ t have to think about VM- or container-sized chunks . It ’ s inefficient and has nothing to do with the actual job of writing code to create a service . It ’ s unnecessary work that distracts from the real value of programming something into existence .
John Graham-Cumming , CTO , Cloudflare
In distributed programming theory , granularity has been around for a long time . The CSP model is of tiny processes performing tasks and passing data ( it helped inspire the Go language ); the Actor model has messages passed between multitudes of actors changing internal state ; even the lambda calculus is about discrete functions acting on data .
Object-oriented programming has developers reasoning about objects ( not virtual machines or disks ). And in CORBA , and similar systems , there ’ s the concept of an object request broker allowing objects to run and be accessed remotely in a distributed system without knowing details of where or how the object executes .
The theory of computing points away from dedicated machines ( virtual or real ) and to code and data that run on the Supercloud handling the details of code execution and data locality automatically and efficiently .
42 INTELLIGENTCIO LATAM www . intelligentcio . com