{"course":{"slug":"cloud-and-shipping","title":"Shipping It","url":"https://addaly.com/learn/cloud-and-shipping","level":"intermediate","track":"build"},"lesson":{"slug":"what-a-server-is","title":"What a server actually is","url":"https://addaly.com/learn/cloud-and-shipping/what-a-server-is","position":1,"of":74,"minutes":7,"answer":"A server is just a process holding a port open; the cloud only changes who owns the machine.","keyIdea":"A server is just a process holding a port open; the cloud only changes who owns the machine."},"body":{"format":"markdown","text":"## A server is a process, not a building\n\nRun this on your laptop:\n\n```\n$ node server.js\nListening on http://localhost:3000\n```\n\nYou are now running a server. A program is holding a TCP port open and answering whatever arrives on it. That is the whole definition. Nothing about a rack, a cooled room in Mumbai, or a company with a blue logo is part of it.\n\nWhat your laptop lacks is not server-ness. It lacks three things: a public address (your router gave you a private one like 192.168.1.7), a certificate so browsers trust it, and the willingness to stay awake when you close the lid. Deploying is buying those three things from someone else.\n\n## What you are actually renting\n\nThere is a ladder, and the rungs differ in how much of the machine you are responsible for.\n\n- **Bare metal.** A physical computer in a building. You get all of it, you patch the kernel, you care when a disk dies.\n- **Virtual machine.** A slice of that computer, with its own Linux, its own IP, root access. A DigitalOcean droplet, an EC2 instance, a Hetzner box. Small ones run about $4 to 7 a month.\n- **Container platform.** You hand over an image, the platform runs copies of it and restarts them when they die. Fly, Render, Cloud Run.\n- **Serverless.** You hand over a function. It runs when a request arrives and stops afterwards. Lambda, Cloudflare Workers, Vercel functions.\n\n\"The cloud\" means only this: someone else owns the machine, the building, the power and the network, and bills you by time or by request. It is a rental agreement, not a technology.\n\n## The axis that actually changes your code\n\nForget price for a moment. The question that changes how you write things is: **is a process always running?**\n\nAlways-on, you get a process with memory that persists. You can hold a database connection pool. You can keep an in-memory cache. You can start a timer that fires every ten minutes. You pay the same at 3am with zero visitors.\n\nPer-request, a process starts when a request arrives (50 to 500ms of cold start if none is warm) handles it, and may be gone before the next one. Consequences people discover the hard way:\n\n- A module-level cache is usually empty, because the next request lands on a different instance.\n- `setInterval` for a nightly job never fires. You need the platform's scheduler.\n- Every instance opens its own database connection. Postgres defaults to about 100 connections. Fifty concurrent instances plus a pool of five each is 250, and you get `sorry, too many clients already`. This is why serverless projects put a connection pooler in front of the database.\n\nNeither shape is better. They fail differently, and the failures are only surprising if you did not know which one you picked.\n\n> Figure: Always-on process versus per-request function. Always-on process: Memory persists between requests; A connection pool can be held open; An in-memory cache stays warm; setInterval fires for a nightly job; Costs the same at 3am with no visitors. Per-request function: 50 to 500 ms cold start if nothing is warm; A module-level cache is usually empty; setInterval never fires; use the platform scheduler; Every instance opens its own database connection; Costs nothing when nobody is visiting. Neither shape is better. Each one fails in a way that is only a surprise if you did not know which one you picked.\n\n## The machine is in a place\n\nRegions are not marketing. A round trip from Lagos to a Virginia region is roughly 110 to 180ms. Frankfurt might be 60ms. That is per round trip: if your handler runs ten sequential queries against a database on another continent, you have built a two-second page out of fast code.\n\nThe rule that matters more than any other: **put your application in the same region as your database.** Users are far away once. Your database is far away on every query.\n\n## So what is a deploy\n\nGet the code onto a machine that has a public address, run it, point a name at it, keep it running. Everything else is convenience."},"check":{"question":"Your handler stores computed results in a module-level object so repeat requests are fast. Locally, the second request is instant. Deployed to a per-request platform, the cache almost never hits: nearly every request recomputes. What is happening?","options":[{"text":"Requests are spread across instances that start fresh, so the object is usually empty for whichever one answers","correct":true},{"text":"The platform strips global state from deployed functions as a security measure","correct":false,"tempting":"Assumes the platform sandboxes away a language feature, rather than simply not keeping any one process alive between requests."},{"text":"The cache is working, but network latency is large enough to hide the saved computation","correct":false,"tempting":"Assumes latency dominates everything, so an in-process win could not show up in the timings; yet locally the same code showed a clear difference."},{"text":"The production build removed the cache object because nothing appeared to reference it","correct":false,"tempting":"Assumes a behaviour difference between dev and production must come from the build step, which is often true but not here."}]},"prev":null,"next":{"slug":"the-box-and-the-shell","title":"The first ten minutes on a new machine","url":"https://addaly.com/learn/cloud-and-shipping/the-box-and-the-shell"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'What a server actually is', in Shipping It. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/cloud-and-shipping/what-a-server-is (Accessed: 31 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"What a server actually is","courseTitle":"Shipping It","module":{"index":1,"slug":"how-the-internet-reaches-you","title":"How the internet reaches your process"},"answer":null,"keyIdea":"A server is just a process holding a port open; the cloud only changes who owns the machine.","hero":{"kind":"figure","figure":{"t":"figure","label":"Figure 1.1","figure":{"left":{"title":"Always-on process","items":["Memory persists between requests","A connection pool can be held open","An in-memory cache stays warm","setInterval fires for a nightly job","Costs the same at 3am with no visitors"]},"type":"compare","right":{"title":"Per-request function","items":["50 to 500 ms cold start if nothing is warm","A module-level cache is usually empty","setInterval never fires; use the platform scheduler","Every instance opens its own database connection","Costs nothing when nobody is visiting"]},"title":"Always-on process versus per-request function","caption":"Neither shape is better. Each one fails in a way that is only a surprise if you did not know which one you picked."},"alt":"Figure: Always-on process versus per-request function. Always-on process: Memory persists between requests; A connection pool can be held open; An in-memory cache stays warm; setInterval fires for a nightly job; Costs the same at 3am with no visitors. Per-request function: 50 to 500 ms cold start if nothing is warm; A module-level cache is usually empty; setInterval never fires; use the platform scheduler; Every instance opens its own database connection; Costs nothing when nobody is visiting. Neither shape is better. Each one fails in a way that is only a surprise if you did not know which one you picked."}},"blocks":[{"t":"h2","id":"a-server-is-a-process-not-a-building","runs":[{"text":"A server is a process, not a building"}]},{"t":"p","runs":[{"text":"Run this on your laptop:"}]},{"t":"code","lang":"","label":"Text","text":"$ node server.js\nListening on http://localhost:3000"},{"t":"p","runs":[{"text":"You are now running a server. A program is holding a TCP port open and answering whatever arrives on it. That is the whole definition. Nothing about a rack, a cooled room in Mumbai, or a company with a blue logo is part of it."}]},{"t":"p","runs":[{"text":"What your laptop lacks is not server-ness. It lacks three things: a public address (your router gave you a private one like 192.168.1.7), a certificate so browsers trust it, and the willingness to stay awake when you close the lid. Deploying is buying those three things from someone else."}]},{"t":"h2","id":"what-you-are-actually-renting","runs":[{"text":"What you are actually renting"}]},{"t":"p","runs":[{"text":"There is a ladder, and the rungs differ in how much of the machine you are responsible for."}]},{"t":"ul","items":[[{"text":"Bare metal.","b":true},{"text":" A physical computer in a building. You get all of it, you patch the kernel, you care when a disk dies."}],[{"text":"Virtual machine.","b":true},{"text":" A slice of that computer, with its own Linux, its own IP, root access. A DigitalOcean droplet, an EC2 instance, a Hetzner box. Small ones run about $4 to 7 a month."}],[{"text":"Container platform.","b":true},{"text":" You hand over an image, the platform runs copies of it and restarts them when they die. Fly, Render, Cloud Run."}],[{"text":"Serverless.","b":true},{"text":" You hand over a function. It runs when a request arrives and stops afterwards. Lambda, Cloudflare Workers, Vercel functions."}]]},{"t":"p","runs":[{"text":"“The cloud” means only this: someone else owns the machine, the building, the power and the network, and bills you by time or by request. It is a rental agreement, not a technology."}]},{"t":"h2","id":"the-axis-that-actually-changes-your-code","runs":[{"text":"The axis that actually changes your code"}]},{"t":"p","runs":[{"text":"Forget price for a moment. The question that changes how you write things is: "},{"text":"is a process always running?","b":true}]},{"t":"p","runs":[{"text":"Always-on, you get a process with memory that persists. You can hold a database connection pool. You can keep an in-memory cache. You can start a timer that fires every ten minutes. You pay the same at 3am with zero visitors."}]},{"t":"p","runs":[{"text":"Per-request, a process starts when a request arrives (50 to 500ms of cold start if none is warm) handles it, and may be gone before the next one. Consequences people discover the hard way:"}]},{"t":"ul","items":[[{"text":"A module-level cache is usually empty, because the next request lands on a different instance."}],[{"text":"setInterval","code":true},{"text":" for a nightly job never fires. You need the platform’s scheduler."}],[{"text":"Every instance opens its own database connection. Postgres defaults to about 100 connections. Fifty concurrent instances plus a pool of five each is 250, and you get "},{"text":"sorry, too many clients already","code":true},{"text":". This is why serverless projects put a connection pooler in front of the database."}]]},{"t":"p","runs":[{"text":"Neither shape is better. They fail differently, and the failures are only surprising if you did not know which one you picked."}]},{"t":"h2","id":"the-machine-is-in-a-place","runs":[{"text":"The machine is in a place"}]},{"t":"p","runs":[{"text":"Regions are not marketing. A round trip from Lagos to a Virginia region is roughly 110 to 180ms. Frankfurt might be 60ms. That is per round trip: if your handler runs ten sequential queries against a database on another continent, you have built a two-second page out of fast code."}]},{"t":"p","runs":[{"text":"The rule that matters more than any other: "},{"text":"put your application in the same region as your database.","b":true},{"text":" Users are far away once. Your database is far away on every query."}]},{"t":"h2","id":"so-what-is-a-deploy","runs":[{"text":"So what is a deploy"}]},{"t":"p","runs":[{"text":"Get the code onto a machine that has a public address, run it, point a name at it, keep it running. Everything else is convenience."}]}],"check":{"question":[{"text":"Your handler stores computed results in a module-level object so repeat requests are fast. Locally, the second request is instant. Deployed to a per-request platform, the cache almost never hits: nearly every request recomputes. What is happening?"}],"options":[{"text":[{"text":"Requests are spread across instances that start fresh, so the object is usually empty for whichever one answers"}],"correct":true,"tempting":null},{"text":[{"text":"The platform strips global state from deployed functions as a security measure"}],"correct":false,"tempting":[{"text":"Assumes the platform sandboxes away a language feature, rather than simply not keeping any one process alive between requests."}]},{"text":[{"text":"The cache is working, but network latency is large enough to hide the saved computation"}],"correct":false,"tempting":[{"text":"Assumes latency dominates everything, so an in-process win could not show up in the timings; yet locally the same code showed a clear difference."}]},{"text":[{"text":"The production build removed the cache object because nothing appeared to reference it"}],"correct":false,"tempting":[{"text":"Assumes a behaviour difference between dev and production must come from the build step, which is often true but not here."}]}],"order":[1,3,0,2],"why":null},"prev":null,"next":{"slug":"the-box-and-the-shell","title":"The first ten minutes on a new machine","minutes":9}}}