Chapter 8. Too Much of a Good Thing Is Not a Good Thing

Starting in Chapter 1, I’ve been explaining the reasons and benefits for adopting serverless as a runtime architecture and design philosophy. Well-architected microservices managed through a serverless framework can definitely make application development and the long-term costs of ownership seem almost magical and fun compared with serverful architectures. Even infrastructure platforms like Kubernetes, which can delegate patching host vulnerabilities and network provisioning to platform teams behind an API, have substantially more overhead and day-to-day costs than platforms that can automatically scale and monitor applications based simply on the runtime contract those applications fulfill.

As you’ve probably gathered from the title of this chapter, even a serverless bed of roses can have painful thorns if taken too far. In this chapter, I’ll highlight several patterns that provide early warning that serverless runtimes are not a good fit for certain corners of your application architecture. Before you flip forward to find your favorite pattern, recall that Chapters 5 and 7 include architectural tools for connecting serverless components with other architectures.

This list of patterns comes primarily from my personal experience with customers who outgrew the early Google App Engine product. As Google’s first cloud infrastructure offering, many customers who saw the serverless potential of App Engine ended up trying to ...

Get Building Serverless Applications on Knative now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.