Posted on Jul 28 • Originally published at sethorell.substack.com

Serverless Is Not A Primary

I love serverless. With it, I help teams deliver value quickly, without the need to spend time maintaining servers and back-end infrastructure. But serverless is not enough.

You cannot lead an engineering team to success with serverless if they don't test the code they write, deploy the apps they build, or integrate changes quickly. Each of these areas must be addressed first. These are the fundamentals upon which serverless can shine.

As DORA has consistently demonstrated, year after year, continuous integration and continuous delivery substantially increase code maintainability, job satisfaction, and software quality. The goal is team Agility, Autonomy, and Ownership. Serverless can play a role, but it is not sufficient for success.

Building the fundamentals

A hierarchy is at play here. Processes build on previous processes. You cannot deploy continuously until you can deliver continuously. You cannot deliver continuously until you integrate continuously. You cannot integrate continuously until you solve self-testing, fast (now even faster!) code reviews, and robust build pipelines, among other things. Where does serverless fit in?

"You build it, you run it."
-Werner Vogels

Serverless is a type of software architecture. The term says, "Sure, there are servers somewhere, but you don't have to worry about them; we'll handle that part. You go build." Serverless allows you and your team to run what you build easily.

However, running software is the final stage of the journey. What happens during the "you build it" phase is crucially more critical than your "you run it" phase. If you haven't nailed down your fundamentals, serverless solves very little.

What are these fundamentals? Continuous integration, continuous delivery, and continuous deployment. Each of these fundamentals is itself a bundle of primaries. For example, to achieve continuous integration (merging changes into master at least once per day), you must address the following challenges: version control, self-testing, fast code reviews, and build pipelines. Each of these takes thought and hard work to achieve. If you are interested in how I approach the thorny issue of code reviews, read my first article on the subject.

I have worked with organizations that had the fundamentals but were not utilizing serverless, as well as organizations that lacked the fundamentals but were fully committed to serverless. The developer experience is night and day different between the two, where the team with the fundamentals delivers better software faster with fewer bugs. The team without the fundamentals missed release dates, had ongoing quality issues, and required separate teams to test, deploy, and run their app.

The DORA metrics are a good measure of how well your team has mastered these fundamentals. As I explained in my 2023 article, "The Other Side of DORA Metrics - The Virtuous Cycle", good DORA numbers reflect excellence at the fundamentals. You can't achieve high DORA scores unless you've tackled the basics.

Serverless for ownership

Werner Vogels, Amazon's CTO, famously declared that, at Amazon, "You build it, you run it." He contrasted this approach with the typical "hand-it-off-to-operations" approach most other companies at the time were using. He found that getting engineering involved in the entire software lifecycle enhanced quality and connected the developers with what their customers experience. That's ownership.

When I refer to "ownership," I mean the team's ability to take full responsibility for the applications they code, encompassing testing, deployment, and monitoring. No additional teams (Operations, QA, SRE, DevOps) are required to run and improve the app. For this, serverless shines.

Serverless architectures make running systems easier. No load-balancers, VPCs, or Availability Zones need to be configured. Just build your application and go.

This doesn't mean that serverless is easy. It's not. It takes practice and guidance. With serverless, your engineering team can run everything. Without it, you will have a hard time and will likely need a supporting team (likely some form of Operations) to co-manage the application.

Fundamentals for culture

Serverless is about architecture, but the fundamentals — continuous integration, self-testing, continuous code reviews, and continuous delivery — are about culture. To implement the fundamentals, you will affect how your engineering teams design, verify, build, and release applications. This could be a significant change!

Culture is opt-in. That is, each individual must decide for herself whether she supports the culture or not. Leadership can define the culture, but it will be adopted only if each engineer and manager in the organization truly believes in it. This is where you can lean on others for persuasion.

If you have access to someone with experience, use him. For example, I have helped transform many teams and organizations from a traditional, vertical-silo, throw-it-over-the-wall deployment to a self-tested, continuous deployment. Someone like me can answer questions, give advice, and map a path forward.

In addition, understand what DORA has illustrated. Teams that adopt these fundamentals are happier, more productive, have higher quality code, and ship faster. DORA also demonstrates a strong correlation between the impact of these software delivery practices and business goals, including revenue growth, market competitiveness, and customer satisfaction. Take that to your C-suite.

Engineering biomes: forest & desert

However, depending on your company's current culture, your message may not be well received. Beth Andres-Beck quoted some user pushback in her clarifying article Forest & Desert, "This architecture you've described sounds like a lush forest, but we are living in the desert. I don't see how this will work here." How do these environments impact culture?

As Martin Fowler summarizes it, "The Forest and the Desert is a metaphor for thinking about software development processes, developed by Beth Andres-Beck and her father Kent Beck. It posits that two communities of software developers have great difficulty communicating with each other because they live in very different contexts, so advice that applies to one sounds like nonsense to the other."

I have been mainly speaking to the forest dwellers so far. Now, I want to direct a message to anyone stuck in the desert: lead your team to the forest or get out. The desert will suck out your soul. If nobody in your desert-dwelling company is interested in what you have to say on this, quit.

There are too many companies that are either squarely in the forest or want to move there. They would love to have an engineer like you who is interested in that kind of culture. Don't believe the people who say, "This is just the way it is," or "This is just the way enterprise builds software." They are wrong. Strive for something better.

If you are new to CI/CD, check out Dave Farley's YouTube channel, "Modern Software Engineering," for bite-sized lessons. Read through the treasure trove that is Martin Fowler's blog, including his seminal article on continuous integration (updated in 2024). Hear Jez Humble address claims of "Continuous Delivery: Sounds Great But It Won't Work Here" in devastating fashion.

Now, place serverless on top of all this. You will be unstoppable.

Happy building!