AWS re:Invent in late November 2016 was the year when serverless computing crossed from interesting curiosity into recognised category. AWS Lambda, which had launched in 2014 and had reached general availability in 2015, had accumulated enough production usage and surrounding services that it could no longer be dismissed as a niche capability. The keynotes and sessions reflected this maturation. New Lambda features were announced. Step Functions arrived as a coordination layer. Application architectures built around Lambda were demonstrated as production patterns rather than experiments.
The basic idea of serverless was that developers could write functions that would run in response to events without managing the underlying servers. The pricing was per execution rather than per instance per hour. The scaling was automatic. The operational overhead, which had been a significant fraction of running production systems, was largely eliminated for workloads that fit the model.
What was less obvious from the marketing material was where the model fit and where it did not. Serverless worked well for event-driven workloads with variable traffic. It worked less well for sustained high-throughput workloads where the per-execution cost added up. It worked well for applications where the team had limited operational capacity. It worked less well for applications with significant state or complex inter-service coordination, at least without significant additional engineering.
The architectural changes that serverless enabled were genuinely significant. APIs that processed thousands of requests per second could be built without provisioning any servers. Background processing of files uploaded to storage could happen automatically with minimal infrastructure. Webhook handlers, scheduled jobs, and many integration tasks fit the serverless model naturally. Teams that adopted these patterns reported substantial reductions in infrastructure work.
The category that emerged through 2016 and continued growing in subsequent years included not just Lambda but the entire ecosystem of related services. API Gateway. DynamoDB. SQS. SNS. EventBridge as it eventually was renamed. The serverless approach was less about a single service and more about a way of building applications using managed services that handled the operational concerns the application team did not want to handle themselves.
The serverless model would not replace traditional infrastructure entirely, and the discussion about when to use it productively continued for years. What 2016 settled was that serverless was here, was being used in production at significant scale, and was a legitimate option in the architectural decision space alongside containers and traditional servers.