I'm interested in understanding the basics of serverless architectures. For example, who manages the server management in this approach? Apart from cost advantages, in which scenarios should it be preferred? What should be considered at the application level? Can a detailed explanation be provided?
What is serverless and how does it work?
👁️ 9 views💬 2 replies❤️ 0 likes
2 Replies
Serverless is a model where you can run applications without managing servers—the cloud provider (like AWS Lambda or Azure Functions) handles everything in the background. Beyond cost savings, it’s ideal for apps with sudden traffic spikes (like an event site). What are you trying to build with serverless?
Serverless is actually a bit of a misleading name — because there are servers, you just don’t see them or manage them. The infrastructure is handled by the cloud provider (AWS, Azure, GCP, etc.). All the computing, scaling, and patching required to run your functions are their responsibility. So, the answer to "who’s managing it?" is: your cloud provider. You just write the code, set up the trigger (HTTP request, queue message, timer, etc.), and let it run.
Beyond cost savings, I think serverless’s biggest strength is its automatic scaling and ease of transitioning to an event-driven architecture. Especially for applications exposed to spike traffic (like during a marketing campaign), functions scale automatically instead of you having to manually scale VMs or containers. But be careful: it’s not suitable for continuously running, low-latency applications — local setups or long-running containers might be more efficient.
At the application level, the most critical thing to watch out for is state management. Functions are stateless — they start from scratch with each invocation. That’s why you need to store data in a database and use external caching (like Redis). Also, there’s the cold start problem — the first time a function is called, startup time can range from 100ms to 2s. If you have critical paths, you might need to set up provisioned concurrency.
Alternatives? Yes, especially for long-running processes, GPU-intensive tasks, or when you need custom networking (like on-premise integrations), serverless might fall short. But if you're building a simple, episodic system with heterogeneous scaling demands, serverless can be a game-changer. I even migrated microservices to serverless in my own startup — operational overhead dropped by about 70%. But during migration, we faced new issues like losing root-level access, vendor lock-in risks, and debugging complexities. So, it’s not just about the advantages — you’ve got to weigh the trade-offs too.