Microservices

Individual serverless components have the capability to scale infinitely (up to the capacity of your cloud provider, which is infinite when infinity is considered relative to an average company's compute power). This sounds, and indeed is, amazing and very useful, but these components tend to expose issues with application architectures that you previously couldn't see. This issue is called serverless backpressure. The following backend components can be impacted by this backpressure:

• Third-party APIs: It is incredibly common to depend on third-party APIs such as Stripe, Twitter, and Paypal these days. Whether these are to provide payment services (like Stripe or the Bitcoin network) or to provide data (like Bloomberg or Reuters), most applications have an integration of some kind. Serverless applications can cause unexpected problems with these relationships by flooding them with requests far beyond what they can handle. These services often have a rate limit in their SLA too, and it can be very easy to violate them with a serverless service.
• Transactional databases: These can be a source of issues too, as they are both unlikely to be able to scale reactively and they purposely stop new transactions to enforce the atomicity of the current transaction being processed. If you are using a serverless function to insert records into a transactional database such as Azure SQL, you can easily overload the database and leave your functions hanging until they time out.
• Monolithic applications: These suffer heavily as they cannot react and scale individual parts of their functionality. So, when a serverless function starts scaling with users (compared to a conventional application that would slow down as it reaches its limit, thereby reducing the load on the monolith) it puts an ever-increasing load on the monolith, which often causes the rest of the functionality offered by that service to become unusable.

There are strategies to deal with this, and they aren't just "Move everything to serverless." Transactional databases will always have a place, and by their very nature will struggle to scale in a truly serverless way. External services are vital, and you cannot expect the providers to switch their entire application architecture for you. Monoliths exist, usually perform vital functions, and cannot simply be made into serverless apps.

That being said, serverless lends itself to one architectural pattern in particular: microservices. The microservices architecture advocates the splitting of the functionality of an application into the smallest possible pieces that can manage their own state. These microservices are then written, tested, and deployed independently. This architectural approach has several benefits:

• Many teams can work in parallel on the same application by focusing on a few microservices each.
• Continuous integration and deployment become much quicker and easier as the microservice has a drastically reduced number of features and acceptance criteria. New features can be added to the application without rebuilding and redeploying the whole application.
• Applications can become polyglot, with the most optimal language and framework used for each microservice rather than one language being used for the whole application.
• Each microservice can scale independently without affecting the functionality of other parts of the application.

We will be using the microservices approach in this book, but it is not the focus of this book. Rather, we will be focusing on the serverless architecture and its unique quirks, while using microservices as an underlying guide.