Serverless for applications: architecture in everyday life

The love story with serverless usually ends with the first unexpected cost report or the first incident that no one can diagnose. It is on a day-to-day basis, with the system running in production and real people depending on it, that the approach reveals its true character.

Launching serverless is easy. Operating serverless is where the difficulty lies that no one mentions in the tutorials. The same attributes that make the technology attractive, ephemeral execution, automatic scalability, charging per use, become concrete challenges when you need to understand, monitor and pay for what is running.

This text is about that phase. Not about concept or implementation, but about what happens after everything is up in the air and the responsibility to keep the boat afloat is yours. Observability, costs and operation: the themes that separate those who play serverless from those who truly operate serverless.

The production shock

In development, everything seems under control. You test a function, it responds, you follow. In production, with real traffic, behaviors you've never seen before start to appear.

Functions take longer than expected at certain times. Errors arise at unforeseen points. The monthly cost is different from the estimate. And when you try to understand why, you discover that you don't have enough visibility to answer.

This is the shock of serverlessproduction. A system distributed across dozens of ephemeral executions is, by nature, difficult to see. And what you don't see, you don't control.

The thesis: serverless transfers the work to the operation

My position is that serverless does not eliminate operational effort, it transforms it and, in some ways, intensifies it.

You stopped taking care of servers, it's true. But it gained the responsibility of operating a more widespread, more dynamic and more difficult to observe system. The work didn't disappear. It changed its nature.

Anyone who adopts serverless thinking that the operation will be trivial is setting themselves up for disappointment. The operation is different, and mastering it requires investing in three fronts that are often neglected: observability, cost control and continuous monitoring discipline.

Observability: seeing the invisible

In a traditional application, you can log into the server and investigate. On serverless, there is no server to join. Functions are born and die. When something goes wrong, the failure environment no longer exists.

Therefore, observability is not a luxury in serverless, it is the only way to understand the system. This means three things need to be in place from the beginning.

Structured logs, which record what each function did in a searchable way. Metrics, which show execution patterns, duration, errors and usage over time. And distributed tracking, which allows you to follow a request as it crosses multiple functions and services.

Without these three layers, debugging a problem in production becomes guesswork. With them, you can answer the most important question in the operation: what is happening right now inside my system?

Costs: the silent villain

The pay-per-use model is sold as an advantage, and it often is. But in everyday life he hides a trap. When the cost is proportional to usage, a mistake can cost real money, in real time.

A function in an improper loop, an event that triggers a cascade, a spike in malicious traffic, all of this becomes an invoice. And because serverless scales automatically, it scales the problem as efficiently as it would scale success.

Operating serverless responsibly requires monitoring costs closely. Set alerts for anomalous spending. Understand which functions consume the most. Set limits where it makes sense. The end of the month cannot be the moment when you discover that something has gotten out of control.

For a public organization, this is even more sensitive: predictable budgeting matters, and a cloud bill that goes up without warning is a management problem, not just a technical one. Cost needs to be monitored like any other system health metric.

Daily operations: what changes in the routine

Updates and versions

Updating dozens of independent functions requires process. Without automation and versioning, you lose control of what is running where. A healthy operational routine treats each change as something traceable and reversible.

Handle partial failures

In a widespread system, failures rarely bring everything down. Instead, parts fail while others follow. Operating well means designing for partial failures: automatic retries, queues that hold what could not be processed, and clarity about what to do when a part falls.

Provider limits

Every serverless] platform has limits on simultaneous execution, duration and size. In everyday life, these limits can surprise you at a peak. Knowing them and monitoring how close you are to them is part of operating maturely.

An example of daily operational life

Think of a serverless system that processes citizen requests for a municipal service. Everything works fine until, on a deadline day, the volume skyrockets.

Without observability, the team would only see complaints of slowness without knowing the cause. With observability, it would see that a specific function is coming up against a competitive limit and that costs have risen along with traffic.

A mature operation would act with information: adjust limits, identify bottlenecks, and the next day review the peak costs to understand whether it was worth it. Without this visibility, it would be difficult to put out fires in the dark. It is this difference that defines operational maturity.

Trading is where the truth comes out

Serverless rewards those who operate it seriously and punishes those who ignore it after launch. The technology delivers flexibility and savings, but requires continuous attention to observability and costs.

The lesson I carry is simple. Launch is the beginning, not the end. Systems live in everyday life, and it is there that we discover whether the architecture was a good decision or an unfulfilled promise.

Serverless shines for those who understand that the bill, technical and financial, arrives every day, not just at launch.

If you operate serverless in production and feel you lack visibility or cost control, it's worth talking to. I have other articles on the blog about the concept of serverless, use cases and implementation that complete this journey from beginning to day to day.