Code Reuse and Cloud Computing

In preparing for my Web 2.0 Expo presentation “Forecast: Partly Cloudy,” I have been looking at how existing code can be reused in the cloud. There are several big challenges to reusing existing code in the cloud:

Many cloud platforms support only one specific language (e.g. Python for Google App Engine, Ruby for EngineYard). That excludes a lot of code written in PHP, Perl, Java and other languages.
Almost all cloud platforms have a non-SQL data access model. This matters for code that has explicit SQL statements in it, which is unlikely to ever be meaningfully available anywhere (SQL after all is one of the issues with the existing stack).
A lot of code uses libraries written in C or C++. Support for these libraries will be take time to implement on many cloud platforms as they cannot sandbox the existing code. In fact, some of the libraries will never be supportable because they permit low level access that cannot / should not be reproduced in a sandbox.
Letting code in different languages talk to each other is a non-trivial problem. Google internally uses something call Google Protocol Buffers which they have opensourced. Facebook has a similar solution called Thrift (also open sourced). Both of these are IDL-based code generators, which require effort in defining interfaces, generating stubs and connecting them up to existing code.

Our portfolio company

More from Continuations

Continuations

Feb 4

Philosophy Mondays: Human-AI Collaboration

Today's Philosophy Monday is an important interlude. I want to reveal that I have not been writing the posts in this series entirely by myself. Instead I have been working with Claude, not just for the graphic illustrations, but also for the text. My method has been to write a rough draft and then ask Claude for improvement suggestions. I will expand this collaboration to other intelligences going forward, including open source models such as Llama and DeepSeek. I will also explore other moda...

Cover image for Intent-based Collaboration Environments

Continuations

Dec 30

Intent-based Collaboration Environments

AI Native IDEs for Code, Engineering, Science

Continuations

Dec 29

Web3/Crypto: Why Bother?

One thing that keeps surprising me is how quite a few people see absolutely nothing redeeming in web3 (née crypto). Maybe this is their genuine belief. Maybe it is a reaction to the extreme boosterism of some proponents who present web3 as bringing about a libertarian nirvana. From early on I have tried to provide a more rounded perspective, pointing to both the good and the bad that can come from it as in my talks at the Blockstack Summits. Today, however, I want to attempt to provide a coge...

Many cloud platforms support only one specific language (e.g. Python for Google App Engine, Ruby for EngineYard). That excludes a lot of code written in PHP, Perl, Java and other languages.
Almost all cloud platforms have a non-SQL data access model. This matters for code that has explicit SQL statements in it, which is unlikely to ever be meaningfully available anywhere (SQL after all is one of the issues with the existing stack).
A lot of code uses libraries written in C or C++. Support for these libraries will be take time to implement on many cloud platforms as they cannot sandbox the existing code. In fact, some of the libraries will never be supportable because they permit low level access that cannot / should not be reproduced in a sandbox.
Letting code in different languages talk to each other is a non-trivial problem. Google internally uses something call Google Protocol Buffers which they have opensourced. Facebook has a similar solution called Thrift (also open sourced). Both of these are IDL-based code generators, which require effort in defining interfaces, generating stubs and connecting them up to existing code.

Our portfolio company

Code Reuse and Cloud Computing

Many cloud platforms support only one specific language (e.g. Python for Google App Engine, Ruby for EngineYard). That excludes a lot of code written in PHP, Perl, Java and other languages.
Almost all cloud platforms have a non-SQL data access model. This matters for code that has explicit SQL statements in it, which is unlikely to ever be meaningfully available anywhere (SQL after all is one of the issues with the existing stack).
A lot of code uses libraries written in C or C++. Support for these libraries will be take time to implement on many cloud platforms as they cannot sandbox the existing code. In fact, some of the libraries will never be supportable because they permit low level access that cannot / should not be reproduced in a sandbox.
Letting code in different languages talk to each other is a non-trivial problem. Google internally uses something call Google Protocol Buffers which they have opensourced. Facebook has a similar solution called Thrift (also open sourced). Both of these are IDL-based code generators, which require effort in defining interfaces, generating stubs and connecting them up to existing code.