The Self Provisioning Runtime

The Self-Provisioning Runtime: Where Cloud and Languages Collide

Shawn Wang has some big ideas about where the industry is heading, arguing that two separate tracks—programming languages and cloud infrastructure—are converging.

Advancements in two fields — programming languages and cloud infrastructure — will converge in a single paradigm: where all resources required by a program will be automatically provisioned, and optimized, by the environment that runs it.

That sentiment aligns with what we're seeing in front-end development, which has expanded dramatically as JavaScript became ubiquitous. In response, a wave of services has emerged targeting developers who can "write a little JavaScript"—offering complete databases with GraphQL endpoints and cloud functions, all without deep infrastructure knowledge. The tradeoff is trust: you rely on these platforms to protect you from your own blind spots.

Extrapolate that trend and the future looks increasingly hands-off, where code might declare its infrastructure needs inline:

/*
  - Be a cloud function
  - Run at the edge
  - Get data from my data store I named "locations", require JWT auth
  - Return no slower than 250ms
  - I'm willing to pay $8/month for this, alert me if we're on target to exceed that
*/

exports.hello = (message) => {
  const name = message.data
  const location = locations.get("location").where(message.id);

  return `Hello, ${name} from ${location}`;
};

That's illustrative pseudo-code, but you get the picture: describe what you need alongside your logic and the runtime handles the rest. The cloudcompiler.run demo essentially worked this way, and even Netlify's conventions—like dropping .js files into a functions folder and getting working endpoints with relative URLs—point straight at this model. The eventual reality will likely be even more automatic, with the platform proactively inferring and spinning up what your application requires.