Serverless is a deployment architecture where servers are not explicitly provisioned by the deployer. Code is instead executed based on developer-defined events that are triggered, for example when an HTTP POST request is sent to an API a new line written to a file.
Think about deploying code as a spectrum, where on one side you build your own server from components, hook it up to the internet with a static IP address, connect the IP address to DNS and start serving requests. The hardware, operating system, web server, WSGI server, etc are all completely controlled by you. On the opposite side of the spectrum are serverless compute platforms that take Python code and execute it without you ever touching hardware or even knowing what operating system it runs on.
In between those extremes are levels that remove the need to worry about hardware (virtual private servers), up through removing concerns about web servers (platforms-as-a-service). Where you fall on the spectrum for your deployment will depend on your own situation. Serverless is simply the newest and most extreme of these deployment models so it is up to you as to how much complexity you want to take on with the deployment versus your control over each aspect of the hardware and software.
Each major cloud vendor has a serverless compute implementation. These implementations are under significant active developer and not all of them have Python support.
Azure Functions has second-class citizen support for Python. It's supposed to be possible but kind of hacky at the moment. Polyglot support should be quickly coming to Azure to better compete with AWS Lambda.
IBM Bluemix OpenWhisk is based on the Apache OpenWhisk open source project.
Serverless libraries and frameworks aim to provide reusable code that handles common or tedious tasks, similar to how web frameworks deal with common web development tasks. Some of these frameworks are built for a single service like AWS Lambda, while others attempt to make cross-serverless operations more palatable.
Frameworks for building Python-based applications on serverless services include:
Serverless concepts and implementations are still in their early iterations so there are many ideas and good practices yet to be discovered. These resources are the first attempts at figuring out how to structure and operate serverless applications.
Lessons Learned — A Year Of Going “Fully Serverless” In Production is a retrospective from a small development team that combines a static site with serverless backend code to easily scale their site without an operations staff. They discuss the good and the bad of working in this fashion while generally coming away with a positive experience.
From bare metal to Serverless gives some historical detail and background context for how various execution architectures have evolved, from the invention of the web to software-as-a-service, infrastructure-as-a-service to today's newer serverless platforms.
Have you shipped anything serious with a “serverless” architecture? provides some great answers by Hacker News developers who are using serverless for large production applications and how they deal with the limitations of the platforms.
Serverless cold start war compares startup times of serverless function instances across Google Cloud, AWS and Azure. This is only one way to measure the results the author did a great job presenting the data and elaborating on potential reasons why the results appeared as shown.
Serverless architectures provides a fantastic overview of the subject with a balanced approach that includes the drawbacks seen in current serverless platforms.
Why the fuss about serverless? is a wide-ranging post about the history of application development and infrastructure. The timeline is a bit hard to follow but otherwise it's a unique look at why software deployments are moving to serverless-based architectures and the advantages that can provide.
Serverless architectures in short lays out some of the initial thoughts behind what the advantages and disadvantages of serverless may be. However, it's early days for serverless so these strengths and weaknesses may change as the architectures and good practices evolve.
Serverless architectures, five design patterns goes over the four main principles of serverless infrastructure and the five major usage patterns the AWS Lambda team is seeing from initial serverless deployments.
Serverless Cost Calculator estimates the amount each serverless platform would charge based on executions, average execution time and memory needed per execution. AWS Lambda, Google Cloud Functions, Azure Functions and IBM OpenWhisk are all included in the results.
The "big 3" serverless platforms, AWS Lambda, Azure Functions and Google Cloud Functions have varying degrees of support for Python. AWS Lambda has production-ready support for Python 2 and 3.7, while Azure and Google Cloud have "beta" support with unclear production-worthiness. The following resources are some comparison articles to help you in your decision-making process for which platform to learn.
Serverless at scale compares the "Big 3" AWS, Azure and Google Cloud in serverless performance. The author provides some nice data around average response times and outliers.
Microsoft Azure Functions vs. Google Cloud Functions vs. AWS Lambda presents an overview of Azure Functions and how they compare to Google Cloud Functions and AWS Lambda.
There is some concern by organizations and developers about vendor lock-in on serverless platforms. It is unclear if portability is worse for serverless than other infrastructure-as-a-service pieces, but still worth thinking about ahead of time. These resources provide additional perspectives on lock-in and using multiple cloud providers.
On Serverless, Multi-Cloud, and Vendor Lock In is an opinion piece that for most cases the additional work of going multi-cloud is not worth the tradeoffs, therefore at this time it's better to go for a single vendor such as AWS or Azure and optimize on that platform.
Why vendor lock-in with serverless isn’t what you think it is recommends using a single vendor for now and stop worrying about hedging your bets because it typically makes your infrastructure significantly more complex.
Fix errors in your Python code before your users see them by monitoring with Rollbar.