Serverless vs Containers: Why I Picked Cloud Functions

Serverless vs Containers: Why I Picked Cloud Functions

In the modern cloud world, nobody buys physical servers anymore. I rent computing power. But how I rent it is the subject of a massive architectural debate: Containers (like Docker managed via Kubernetes) versus Serverless (like AWS Lambda or Firebase Functions).

For g-makris.com, and for most agile FinTech startups I consult for, I choose Serverless. Here is deeper look at why.

The Container (The Virtual Server / The Rental Car)

Imagine renting a car. You have the car 24/7.

• Availability: It is always there in the driveway, ready to go.
• Cost: You pay the daily rate whether you drive it 500 miles or 0 miles.
• Maintenance: You have to put gas in it. You have to check the tires. If the engine light comes on, you have to deal with it.

In tech, this is a Container. You wrap your application and all its settings in a box (Docker). You deploy it to a server. You have total control over the Operating System (OS). But you also pay for that server every second it is running, even at 3 AM when zero users are online. And you are responsible for "patching" the OS when security vulnerabilities are found.

Pros: Total control, consistent environment, no startup delay. Cons: You pay for idle time. You carry the burden of maintenance (DevOps).

Serverless (The Function / The Taxi)

Now, imagine calling an Uber.

• Availability: You summon it only when you need to move.
• Cost: You pay only for the minutes you were moving. If you stay home, you pay $0.
• Maintenance: You don't care about the gas, the tires, or the engine light. That is the driver's problem.

In tech, this is Serverless. I write a single function—e.g., processPayment(). I upload just that code to Google Cloud. Google puts it to sleep.

When a user clicks "Pay," Google wakes up the function, runs it (for 200 milliseconds), and shuts it down again. I am billed for exactly 200 milliseconds of computing time.

Pros: Zero maintenance (No OS updates). Cost scales to zero (perfect for startups). Infinite scaling (if 10,000 people click pay, Google spawns 10,000 functions instantly). Cons: "Cold Starts". Just like waiting for a taxi, sometimes it takes 1-2 seconds for the cloud provider to "wake up" your code if it hasn't been used in a while.

The Business Case

For a high-traffic FinTech app processing millions of transactions per second, Containers might make sense because the "Cold Start" delay is unacceptable. But for a modular platform like mine, Serverless is superior.

It allows me to deploy single functions independently. If I introduce a bug in the "Send Email" function, it crashes only that function. The "Process Payment" function keeps working perfectly because they are isolated. It reduces the "Blast Radius" of errors and drastically lowers the monthly cloud bill.

I don't want to manage servers. I want to ship features.

Best,

Gerasimos Makris Founder of g-makris.com AI Web Developer | Double Master's in MBA & FinTech and Blockchain

Tech Glossary & Concepts

• Serverless: A cloud-native development model that allows developers to build and run applications without having to manage servers.
• Container: A standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.
• Cold Start: The delay that occurs when a serverless function is invoked for the first time (or after a period of inactivity) because the cloud provider has to boot up the environment.
• Kubernetes: An open-source system for automating deployment, scaling, and management of containerized applications. It is complex and often overkill for small teams.