The Serverless Square of Balance: The Trade-off Between Delivery and Stability
It is time to introduce the serverless square of balance (Figure 7-2). The square of bal‐ ance illustrates the four key activities that must be undertaken to achieve a resilient, high-quality serverless application: test, deliver, observe, and recover. Crucially, it is not enough to simply conduct these activities; they must be designed and undertaken in the most efficient way possible. In addition, they must all be balanced against one another, without overly relying on one or two techniques. Achieving this balance of focus in your microservices is the key to serverless harmony.
Figure 7-2. The serverless square of balance
The authors of Google’s book Site Reliability Engineering (O’Reilly) assert that soft‐ ware can be too stable, to the point that stability can be detrimental to quality: “maximizing stability limits how fast new features can be developed and how quickly products can be delivered to users, and dramatically increases their cost, which in turn reduces the number of features a team can afford to offer.” They encourage you to take calculated risks when verifying your software before shipping it: “Our goal is to explicitly align the risk taken by a given service with the risk the business is willing to bear. We strive to make a service reliable enough, but no more reliable than it needs to be.”
The risks you take to increase delivery speed by reducing test coverage must always be counteracted with useful alerts, automated recovery from failure, and effective debugging of root causes.
Move fast and make things
Chapter 6 discussed the importance of establishing and maintaining a rapid develop‐ ment and delivery workflow, as well as preparing for everything to fail by making operations tolerant of faults and able to recover automatically.
The quality of a serverless application relies on delivery speed and application stabil‐ ity. In most cases, speed should always be preferred to stability. Stability is a product of speed; without speed there is no stability.
Optimizing for speed is often seen as a decision to sacrifice quality. Take the old Facebook engineering adage: “move fast and break things.” This implies your appli‐ cations must be broken if you are to develop them quickly. Research by DORA found the opposite to be true among high-performing software product teams. First published in the book Accelerate, by Nicole Forsgren, Jez Humble, and Gene Kim (IT Revolution), the Google Cloud team’s research found that high-performing teams delivered code into production (from commit to deployment) 440 times faster than low-performing teams while having a change failure rate 5 times lower.
In serverless applications, maintaining the quickest possible delivery speed underpins your entire strategy for promoting quality and a great user experience. It’s no use budgeting for errors and fine-tuning your alerts to identify bugs as soon as possible if you cannot remove the bugs from your production environment rapidly.