What Is Rejected
Why It Is Attractive
Why It Is Still Wrong
Rejected Approach
The adoption of serverless computing (function-as-a-service platforms) as the primary architectural pattern for application development.
Why It Is Attractive
Serverless computing presents several compelling advantages:
- Operational Simplicity: Eliminates the need for server provisioning, patching, and monitoring
- Automatic Scaling: Handles traffic spikes without manual intervention
- Cost Efficiency: Pay-only-for-usage model appears more economical than reserved infrastructure
- Rapid Development: Allows focus on business logic rather than infrastructure concerns
Why It Is Still Wrong
Despite these attractions, serverless computing fails as a universal default pattern:
- Cost Unpredictability: While pay-per-use seems efficient, complex applications with interdependent functions can generate unexpectedly high costs through cross-function communication and cold start penalties
- Performance Inconsistency: Cold starts and execution time limits create unpredictable latency, unacceptable for user-facing applications requiring consistent response times
- Vendor Lock-In: Deep integration with cloud provider services makes migration difficult and expensive
- Debugging Complexity: Distributed execution across ephemeral functions makes tracing issues and understanding system behavior nearly impossible
- State Management Challenges: Stateless nature conflicts with applications requiring complex state transitions or long-running operations
No Alternatives Proposed
This rejection closes the door on serverless as default without proposing alternatives. Each system must evaluate its specific requirements for consistency, performance, and operational control before selecting an appropriate architecture, as further explored in event-driven architecture considerations.