Serverless
Serverless
What is serverless?
- Upload code, skip server management
- Runs only when triggered, and you pay only for that
- Less ops burden ↓
Adopting serverless removes a few items from your team's to-do list entirely. Deciding how many servers to run, applying security patches, and adding instances when traffic spikes in the middle of the night all move over to the cloud provider. In exchange, the unit developers deploy changes from 'one server' to 'one function'. Because each feature is split into its own function, you don't have to redeploy everything to fix one, and in practice teams notice even more that failures stay isolated to a single feature. The server cost that used to be a monthly fixed cost also becomes a variable cost that moves with call volume and execution time.
Serverless falls into two broad types. FaaS (AWS Lambda, cloud functions) lets you upload code as individual functions, while BaaS (Firebase, Supabase) lets you rent the whole back end, such as authentication, a database, and file storage. What separates it from containers or PaaS is whether resources also shrink to zero when requests drop to zero. If one instance is kept running around the clock, it is cloud in name only, not serverless. The limits are clear too. A single function run has a time cap (Lambda allows up to 15 minutes), and functions don’t retain state, so sessions and uploaded files must be kept in separate external storage. Heavy, long-running jobs such as encoding a long video are a poor fit from the start.
The most common misconception is that it is 'always cheaper.' It has a huge advantage when requests are sparse, but once traffic stays above a steady level, the cost flips. For a service that gets dozens of requests per second around the clock, a single small always-on server is often cheaper. More dangerous is an accidental infinite loop. If a function calls itself, or retries on failure never stop, the bill can reach millions of won overnight, and most teams only find out when the invoice arrives. The right order is to set budget alerts and retry limits before deployment. You also need to factor in cold starts, where the first response is slow after a long idle period, and lock-in, where your code gets tied to one cloud's syntax.
Seolyeong ParkGenerative AI and AX training expert with 17 years of hands-on experience and 200+ lectures, who gets non-specialists using AI right away
John KimJohn Kim, CEO of Nanum Consulting and author of “B2B Marketing Design”It went mainstream in 2014 when Amazon launched AWS Lambda. Uploading code as individual functions and 'paying only when they run' is the classic form of serverless.
Consider a hypothetical case. Company A sells online job-training content, with 11 employees and annual revenue of about KRW 1.8 billion (≈ US$1,346,700). Its website inquiry form receives 30–50 submissions a day, and to send just the notification email, it kept a KRW 220,000 (≈ US$165)-per-month server running 24 hours a day. With only one developer, every security patch stopped other work.
- When Manager Kim of the development team pulled a month of logs, the server running around the clock had actually worked for just over 3 minutes a day.
- When the CEO asked, 'Can't we pay for just those 3 minutes?', Manager Kim split the inquiry-saving and email-sending code into a single function and uploaded it to Lambda.
- Testing exposed a cold start, with the first request taking 2.4 seconds. They raised memory to 512MB and added a scheduled call every 5 minutes to keep it warm, cutting the time to 0.6 seconds.
- To prevent billing surprises, they capped retries at 2 and set a budget alert that texts the CEO and Manager Kim when monthly calls exceed 50,000.
- Two months later, the server bill had dropped from KRW 220,000 (≈ US$165) a month to KRW 18,000 (≈ US$13), the 4 hours a month spent on patching were gone, and no outages had caused missed inquiries.