asim.dev

JavaScript Saves The World

dotJS 2019 · Paris, France

by Asim Hussain · 1 December 2019

talk tech green
JavaScript Saves The World
▶ Watch on YouTube ↗

This was my talk at dotJS 2019 in Paris, and it starts with a confession: I’d argue all day about shaving 2% off SEO, but I’d never once put my hand up in a meeting and asked, “what’s the greener option here?” It’s the talk where I work out that as technologists we have an outsized lever on climate — and that the simplest place to start is to stop wasting electricity.

AI-generated summary of my talk

Jump into the talk

  1. 0:00 Intro: I care, but…
  2. 1:02 Cloth nappies and a lot of poo
  3. 3:02 The epiphany, and a climate-change primer
  4. 6:04 Why technologists have an outsized impact
  5. 8:06 How wasteful servers really are
  6. 10:07 So what is serverless, anyway?
  7. 12:09 Serverless Node with NestJS
  8. 14:11 Deploying with Hexa, and where to go next

The nappy epiphany

When my son Micah was born I got handed the nappy duty — and then my wife told me we’d be using cloth nappies, not disposables. So I got very, very used to dealing with poo. Eight times a day, for months. And one day it hit me: I was willing to deal with that much poo for the environment, yet I’d never once, in a single scrum, a single architecture discussion, put my hand up and asked, “well, what’s the greener solution here?” I’d happily argue for hours about improving SEO by 2% or knocking out 4% of bugs. Never the greener option. That gap is the whole talk — what does it actually mean to build a green application?

A quick, depressing primer on the climate

To make the case I have to set the scene. Carbon dioxide is a greenhouse gas — it acts like a blanket, trapping heat. It’s the most common one, but not the only one: methane has about 25 times the heating potential, so we normalise everything into “carbon dioxide equivalent” and just talk in terms of carbon. In 2016, right here in Paris, 187 states agreed to try to keep warming to 2°C, ideally 1.5°C — and we’ve already used up a full degree since pre-industrial times, so there isn’t much headroom. The reason 2°C matters is that the damage isn’t linear: at 1.5°C the share of species losing half their climatic range is single digits, at 2°C it’s double digits, and it climbs sharply from there. Animals and plants can’t take a jumper off when it gets hot. The grim part is we’re not on track — we haven’t even hit peak pollution yet.

Why you, specifically, can do something

Here’s the turn. Most people who care about this can only really change their own lives — recycle, fly less, all the things my family does. But you’re a technologist, so the things you build can touch ten, a hundred, a million users. That’s an outsized impact, and the easiest place to start is electricity, because making electricity is responsible for around 30% of carbon emissions — and roughly 80% of the world’s electricity is still made by burning fossil fuels like coal and gas. So the one thing I want to ask is simple: don’t waste electricity. We destroyed a little bit of the planet to make it. Don’t waste that gift. For bonus points, use clean energy — renewables, or at least carbon-neutral regions. If you’re on AWS, only a handful of regions were carbon-neutral at the time, so push your work towards those.

Idle servers are the silent waste

Picture a typical load on your app over time, and the servers you’ve provisioned to handle it. Some run flat out, some sit idle, most are somewhere in between. So what does a server actually cost in carbon? A typical 2019 server runs to roughly 600kg of carbon a year at full tilt — but here’s the kicker: an idle server still draws between 25% and 50% of its power, so even one doing nothing is still emitting carbon. And the machine itself had a carbon cost just to be manufactured, amortised over its lifespan. Add it up and an idle server is sitting there quietly emitting close to half a tonne of carbon a year — for nothing. You destroyed a bit of the earth to make and power it, and got no user value back.

Serverless, and building it in Node

This is why serverless is interesting to me. Instead of provisioning servers, you hand the provider a small, atomic bit of code — say, the handler for one URL — and they run it. It auto-scales, it’s pay-as-you-go, and if you use zero you pay zero. You stop thinking in servers at all; you’re billed on memory used and how long your function ran. The green angle is the whole point: because your code and my code run on the same shared pool of machines, the provider can keep them near 100% utilisation. No idle waste, no carbon spent for nothing.

The catch with raw cloud functions — Azure Functions, AWS Lambda, Google Cloud Functions — is that you get a bare handler and have to build the rest yourself. I don’t want to invent my own opinions; I’d rather borrow good ones, which means a framework. I really like NestJS — at the time the fastest-growing Node framework by GitHub stars. You scaffold a normal Nest app with its CLI, run it locally, and then to make it serverless you just run nest add on a package. Under the hood that’s an npm install plus something more interesting: schematics, the same code-modification engine behind the Angular CLI. It analyses your code and makes the changes for you — adding files, editing files, adding imports — rewriting about ten files to convert your project into a serverless app you can still run and debug locally. When you’re ready to ship, I recommend the Hexa CLI (made by Wassim, on our team in Paris) — an opinionated tool that sits on top of the cloud CLIs so hexa init then deploy pushes you up to Azure, AWS or Google. We bundled the Azure path into docs we called Nitro.

So: servers emit carbon, serverless just wastes less of it, so don’t waste the opportunity. Use clean energy where you can, ideally renewables. And if I’ve nudged you to do more in this space, come and join Climate Action Tech — I’m one of the organisers, and I genuinely want to talk to anyone who cares about this.