First Principles for Successful Serverless Adoption
Developing, deploying, and invoking a Lambda function is easy, as demonstrated in many conference sessions, learning portals, and YouTube videos. Once you have experienced the process once, repeating it to write more Lambda functions is straightforward. Does that mean you can simply declare that serverless is easy and instruct your teams to go forth and go serverless? Many enterprise teams make mistakes here.
While implementing and running a Lambda function may be easy, remember, as you learned in Chapter 1, that FaaS is just one part of the serverless ecosystem. Success of operating a simple function cannot be used as the yardstick to measure your organization’s ability to adopt serverless—building and operating production-ready enterprise-scale serverless applications involves far more than creating a few Lambda functions! Enterprises with multiple teams and many engineers need to develop the endurance for a marathon, not a quick-burst hundred-meter sprint.
Serverless is not a silver bullet
As discussed earlier, developing a serverless mindset is critical for successful ser‐ verless adoption. You need to prepare yourself psychologically. The technical and product teams should have a clear understanding of the reasons why serverless requires a change of scenery. In an organization riddled with years of technical neglect, team misalignment, Stone Age thinking, and stubborn engineering minds that resist change, serverless adoption is a tough act to pull off. There is considerable preparation work required to bring such an organization into a state conducive to serverless adoption and growth.
You’ll hear the term serverless-first a lot in the industry. However, there is much to consider when determining whether serverless is the best-fit technology choice to build and operate business applications to deliver value faster. It requires strategic thinking, not a compulsion to jump in headfirst and build everything serverless.
When enterprises force their way into developing applications using serverless technology and scale quickly without the necessary scaffolding, they often end up creating a tangled web of distributed monolith known as a ball of serverless mud (BoSM), as shown in Figure 2-2, rather than a smaller, self-contained, modular, and extendable architecture. As an engineer, architect, technology advisor, or CTO, your responsibility is to prevent such calamities from unfolding in front of your eyes. Instead of leaping straight to serverless-first thinking, your focus should start with an understanding of a few other first principles.
Figure 2-2. A tangled event-driven ball of serverless mud
First principles thinking is a thought process that can help you get to the fundamentals of a problem. Rather than focusing on the prob‐ lem as a whole, you break it into parts to identify the basic elements and causes. Understanding the basics often makes it simpler to find innovative solutions to the business problems your enterprise is trying to solve. In this space, serverless is just a technology enabler.
The first principles that you will need to understand before adopting a serverless-first mindset include domains, teams, APIs, microservices, and events. Let’s take a look at how you might approach each of these elements to see how they lay the foundation for success in an organization on the verge of adopting serverless. Then we’ll come back to the idea of serverless-first.
