Advantages and Disadvantages of Serverless: A Technical Perspective

This is a concise list of serverless pros and cons. For a detailed analysis please refer to Serverless Technology Outlook: A Critical Analysis.

For an introduction to Serverless, please refer to What is Serverless? A Definition.

Advantages:

• With a serverless platform, a programmer can write code and directly run it in the cloud without worrying about hardware, operating systems, or servers. They can write the business logic as code, and then run the code without needing to be aware of the deployment complexities.
• Applications get high availability and auto-scalability without additional effort from the developer. This can significantly reduce development time and consequently costs.
• Serverless platforms make citizen programming possible (low code) by removing the need for server management, scaling, HA, configurations, builds, and other details. Hence, serverless platforms significantly reduce the barrier to entry for programming complex backend systems.
• Polyglot architectures -Serverless platforms enable polyglot architectures where multiple programming languages are used together.
  Zimine, Jonas, Roberts, and others have also pointed out several disadvantages of serverless.

For a discussion on the business impact and other impacts of the aforementioned advantages, please refer to “Impact” section of Serverless Technology Outlook: A Critical Analysis.

Disadvantages:

• When the number of functions in the application grows, serverless adds friction. Firstly, different functions are often developed separately. Secondly, they can be hard to debug. Thirdly, integration logic may be pushed into DevOps scripts, which can obscure the overall architecture.
• Serverless applications are often modeled as a collection of functions that are wired by an event-driven architecture (EDA). While designing serverless based solutions that go beyond simple use cases, architects have to think differently. EDA-based programming is not intuitive to traditional developers and is generally harder to debug. The resulting architecture is more complex and logical flow is harder to reason. Jonas[2] also argues that such friction has a significant impact. This also applies to microservices architectures that often use EDA as well.
• Serverless need tools and Integrated Development Environments (IDEs) to simplify the experience for complex serverless applications. Such an IDE should enable users to create functions in one view, compose them, test the fully composed application in the IDE itself, debug, make sure everything works, and then a push a button to deploy it to a serverless platform. These IDEs don’t yet exist. In addition, the IDE should have a debugging experience that helps pinpoint problems. This requires local testing within developer machines. There is progress towards this: for example, Azure Functions already supports local debugging triggered by cloud events. We believe that IDEs that support the aforementioned capabilities will hasten the serverless adoption.
• Serverless, by design, is an opinionated solution. It is agile as long as the programmer is willing to conform to its model but becomes clumsy if the programmer resists the model. This is a disadvantage. It is true that the same can be said about programming languages as well, but training in programming language takes significant time and it is rare that people switch programming languages. This lack of flexibility may limit serverless adoption in some use cases.
• A concern with serverless is how to handle state using stateless functions. The current architecture best practices are to store the state in platform services such as databases, shared file systems or messaging systems. Serverless faces two kinds of latency challenges: cold-starts and high tail latencies. First, when the first user request arrives, the serverless platform needs to load the function, which is one of the causes of high tail-latencies (this can be in the order of seconds). Cold-starts are avoided by keeping one copy running, by forecasting when the first call happens, or by improving the startup time of the code.
• The lack of standards and concerns about vendor lock-in pose a significant risk to serverless adoption. The real concern is not serverless functions, but the platform services required by those functions. It is hard to abstract away those services effectively.
• The vendor lock-in also can make it hard to switch from one serverless platform to another. This platform specific approach reduces the size of the developer pool available for hire, a few developers will know all the available systems.

For a detailed analysis of the above pros and cons and a future assessment please refer to Serverless Technology Outlook: A Critical Analysis.

To receive updates our emerging technology analysis, please subscribe to our Global Technology Outlook Updates Newsletter.