Similarities and differences between Fast-CGI, CGI, and Amazon AWS Lambdas
I’m not sure what triggered the thought, but it might have been my reflection on the “old days” of web development and its evolution. This led me to consider the similarities between CGI, FastCGI and AWS Lambda. Agreed, they represent different paradigms for handling dynamic web requests, and AWS has a core need to monetise the functionality, but the technologies share many fundamental concepts:
Similarities between Lambda’s and Fast-CGI/CGI
- Process Isolation: Both create isolated environments- FastCGI uses separate processes; Lambda uses containerised contexts.
- Stateless Design: Both rely on stateless request processing, with each request independent.
- Request-Response Model: Both follow receiving a request, processing, and returning a response.
- Short-lived Processes: Processes end after a call or timeout, freeing memory and CPU.
Key Differences between Lambda’s and Fast-CGI/CGI
- Execution Model: FastCGI uses persistent processes for requests (CGI does not); Lambda creates temporary environments that may be reused.
- Scaling: FastCGI/CGI requires manual setup; Lambda auto-scales.
- Infrastructure: FastCGI needs server management; Lambda is fully managed.
- Pricing: Lambda charges per invocation, Fast-CGI and CGI don’t consider monetisation.
- Cold Start: FastCGI processes stay warm; Lambda and CGI has cold start latency.
- State Management: FastCGI can retain in-memory state; Lambda containers are ephemeral, needing external storage.
- Protocol: FastCGI uses binary protocol; Lambda uses HTTP/event APIs.
Argument for AWS Lambda as an Evolution of FastCGI
Lambda adopted FastCGI’s architecture and improved it with cloud-native orchestration. Its evolutionary approach often yields the best technologies. This can be summarised:
-
Dynamic Scaling: Where FastCGI required manual process pool setup (spawn 10 workers, max 50), Lambda makes this elastic and automatic. Traffic spike? Spin up hundreds. Traffic decreases? Scale to zero.
-
Resource Optimisation: FastCGI processes consume resources when idle (CGI does not), while Lambda’s “scale-to-zero” feature charges only during execution, improving efficiency.
-
Failure Isolation: FastCGI process crashes can affect the pool. Lambda’s ephemeral model provides a fresh execution environment for each invocation, preventing bugs from process state corruption.
-
Geographic Distribution: Lambda expanded the model globally, now offering process pools across multiple data centres instead of just one server.
Conclusion
From an architecture perspective, FastCGI/CGI and AWS Lambda are different paradigms for managing dynamic web requests but share many core concepts. Lambdas were an evolutionary step, not a radical change.