Chapter 4. Limitations of Serverless
So far we’ve talked about what Serverless is and how we got here, shown you what Serverless applications look like, and told you the many wonderful ways that Serverless will make your life better. So far it’s been all smiles, but now we need to tell you some hard truths.
Serverless is a different way of building and operating systems, and just like with most alternatives, there are limitations as well as advantages. Add to that the fact that Serverless is still new—AWS Lambda is the most mature FaaS platform, and its first, very limited version was only launched in late 2014.
All of this innovation and novelty means some big caveats—not everything works brilliantly well, and even those parts that do we haven’t yet figured out the best ways of using. Furthermore, there are some implicit tradeoffs of using such an approach, which we discuss first.
Inherent Limitations
Some of the limitations of Serverless just come with the territory—we’re never going to completely get around them. These are inherent limitations. Over time we’ll learn better how to work around these, or in some cases even to embrace them.
State
It may seem obvious, but in a Serverless application, the management of state can be somewhat tricky. Aside from the components that are explicitly designed to be data stores, most Serverless components are effectively stateless. While this chapter is specifically about limitations, it’s worth mentioning that one benefit of that statelessness ...