Serverless architecture has quickly emerged as the up-and-coming way to develop cloud-based applications. The benefits of serverless computing are just too good ignore: zero server maintenance, out-of-the-box scalability and ground-up support for asynchronous workflows. It’s a developer’s dream. But serverless architecture comes with a catch. These significant operational benefits cost developers a hefty price: laborious configuration, immature frameworks, lack of tooling and a dearth of established design patterns. Until very recently, going serverless basically meant throwing out decades of established tools and practices, and starting over. In a nutshell, making serverless apps can be painful.
The pain, however, is slowly going away. It began with Amazon Web Services (AWS) releasing the Serverless Application Model (SAM). SAM is essentially a simplified template syntax for CloudFormation (AWS’s infrastructure-as-code framework) that reduced the jaw-dropping amount of code previously required to automate the deployment of serverless apps. SAM made configuration a little better for some use-cases, but it was only a small incremental improvement. The fundamental problem still remained: developing applications as Lambda functions required starting over with new design patterns and Lambda-compatible libraries. For the Python crowd, this meant kissing goodbye time-saving application frameworks like Django and Flask.