While cost and pricing models are definitely something to consider when you evaluate serverless platforms, such as Amazon Lambda, Azure Functions and Google Cloud Functions, there are other features to keep in mind.
The biggest issue to keep in mind is that serverless might mean something different to each cloud provider, and their serverless platforms might support different kinds of applications.
Stateless application types
Serverless computing was originally framed as a way to run a transient application in response to an event. These applications were stateless, meaning they didn't recognize the context of a series of connected events. This allowed developers to load, run or duplicate these apps as needed.
There are two different types of stateless applications that can run on serverless platforms. The first type is known as functional or Lambda computing, and in this model, the output of an application is a simple function of the input. No matter how often or where you run the application, you'll always get the same response.
The second type is back-end state controlled. With this kind of application, a database stores the context of multistep processes, so when a new event occurs that represents a new step for the application to take, it can start where it left off.
The functional model is problematic because most applications involve stateful behavior, like writing to a database or supporting multistep transaction processes. If a serverless provider demands this behavior on its platform, you'll have to break up your application to create stateless pieces. If your application is third-party software or if you lack the staff or time, you won't be able to use serverless computing for all your target applications.
The issue that the back-end option centers around is how it's implemented. Where is the database that stores the state, and how much delay is introduced to obtain and restore it? The delay can be significant -- up to a second in some cases, according to users -- which can kill the performance of the application. If you host serverless apps in a variety of geographies, the location could impact the delay.
Serverless performance and portability
Serverless platforms differ in terms of the time it takes to recognize an event that a serverless application needs to process, spin up that application and get data to that application. Every millisecond it takes is a delay in response time.
Another significant issue that affects serverless performance is where you host your functions. If you host your application far from the source of events that it processes, network delays can cause problems. On the other hand, if all hosting locations end up in the same data center, then additional reliability might be lost. Finally, if your secondary hosting points are a long way from the primary point, the delay associated with reaching the new hosting spot can be excessive, and any back-end state synchronization delays will be longer.
Lambda lock-in risks
Amazon Lambda is the oldest serverless offering, and compared to other serverless providers, Amazon provides the largest number of integrated tools and services. You can easily link between serverless apps and mobile or internet of things (IoT) front-end tools, and Amazon also provides a service to handle state control. This richness in tools often makes Lambda the default choice for new serverless users, but since other serverless providers don't offer the same level of web service support, you'll probably face the biggest portability challenge with Lambda if you decide to change providers.
How developers should write an application for optimal performance also varies by serverless platform. This means the serverless apps you design for one provider will most likely require changes to run on a different provider's cloud. That's particularly true given that serverless computing is usually a part of a broader IoT or event-processing ecosystem that a cloud provider's web services support. The more of these services you use, the less likely it is that you can easily move your serverless apps to another provider.
Another portability issue lies in the fact that serverless providers don't support all programming languages or middleware, which means that, unless you're flexible in your selection of programming tools, there is no guarantee that your serverless apps are portable at all. The tools that cloud providers support change quickly, so evaluate your options carefully before you start a serverless project. If you want the most portability based on current tool support, look at Node.js to build apps.