The First Principles For A Successful Serverless Adoption!
The discipline you require for an enterprise-scale serverless adoption!
Five years ago, at a conference, I watched someone live-code, deploy, and invoke a Lambda function to show the audience, Hello, Serverless!
The speaker then proclaimed — Serverless is easy! Many continue to believe in that proclamation to this day.
The ‘Hello, Serverless!’ Syndrome
Writing a Lambda function to show Hello, Serverless!
is a breeze. I’m sure many of us started our careers by writing a Hello, World!
program.
Nothing is wrong with this simple and easy start, but when enterprises take this measure of serverless-is-easy as their yardstick and dive deep into it without preparation, they get caught in a gusty whirlwind.
Why?
Building and operating production-ready, enterprise-scale serverless applications requires more effort than experimenting with simple Lambda functions. Serverless technology is an ecosystem, and Lambda functions are just one of many elements in that ecosystem.
The serverless mindset
Serverless requires a new way of:
thinking (stateless, asynchronous)
architecting (event-driven, microservices)
building (incremental, iterative)
operating (observability, metrics) applications
This approach differs from how we built monolith applications with siloed teams. Hence, embedding serverless thinking in engineers, teams, and organizations is essential.
The serverless mindset acts as a psychological entry criterion towards serverless adoption.
The Serverless-First Fallacy
There is a fair amount of misconception about the term serverless-first, especially within organizations that have established a cloud-first strategy and developed serverless thinking.
Often, they feel that serverless-first, as a principle, is urging them to build everything serverless in a hurry.
To succeed, enterprise-scale serverless development requires-
a favorable business environment,
an aligned team structure and
modern development practices.
Ignoring these and jumping head-first into serverless will lead to building a tangled application that will quickly evolve into a ball of serverless mud (BoSM).
Serverless-first is not a silver bullet
For enterprises with years of technical neglect, team misalignment, Stone Age thinking, and stubborn engineering minds, trumpeting serverless-first loud will not be heard by anyone.
To transport such organizations into modern, growth-promoting, flow-enabled, agile, and high-performing teams, they require the following FIRST principles to be successful alongside serverless-first.
Domain-first
Team-first
API-first
Microservices-first
Event-driven-first
With first-principles thinking, you look at the fundamentals and think differently to build solutions to business problems using serverless as the technology enabler.
Driving an automatic transmission car (auto gear) frees you from the hassle of changing gears and clutch control. However, you must still hold a valid driving license, start the car, and comply with traffic rules and safety measures before taking it to the road. Without these, your drive will not be safe, smooth, or long.
Indeed, serverless takes away most of the infrastructure and platform heavy lifting from you, but you need more than a developer's chair and a laptop to produce modular, extendable, secure, and sustainable serverless applications!
Domain-First
Domain-first thinking is heavily influenced by domain-driven design (DDD) principles. It is a forerunner to serverless-first thinking for enterprise-scale adoption.
Understanding the problem you are trying to solve with serverless is critical. It may be evident for a start-up or a small-scale business, for an enterprise with several operational areas, the distinction from a high-level and down to individual teams is essential.
As you break your business domain into subdomains and distill further, you reach the bounded contexts. These contexts reveal the boundaries and their distinctive characteristics, i.e., the domain models.
Who is responsible for protecting the domain boundary and implementing the domain logic?
How are you safeguarding the boundary to control the information flow in and out of a domain?
Within your guarded boundary, which technology choice helps you implement the business logic quicker to bring business value?
When you have a distilled subdomain with its boundary, you need people who are well-versed in that domain and speak the common (ubiquitous) language with the stakeholders. These people (team) must be aligned to focus on one thing and work together with a single purpose.
When you get to this level, it becomes easier for the next first principle — Team-first.
In an enterprise, it is critical to understand the ‘what’ problem you are solving with serverless.
Team-first
Amazon’s two-pizza team concept is repeated whenever someone talks about modern software development teams. While everyone quantifies the size of a team with their appetite for pizza, they often forget that these teams are intentionally kept small because the business domain they are part of is also broken down into a granular level. It gives the team its purpose and focuses on one thing and an identity.
The two-pizza team rule at Amazon stipulates that a team is no larger than can be fed by two pizzas. According to their founder Jeff Bezos, smaller teams collaborate better to move faster with development and releases. It demands an ownership culture by removing silos where a team has end-to-end visibility of its products.
Such teams have different names—product teams, feature squads, service squads, etc.
In their book Team Topologies: Organizing Business and Technology Teams for Fast Flow, Mathew Skelton and Manual Pais call them stream-aligned teams.
A stream-aligned team is a team aligned to a single, valuable stream of work (flow of work) aligned to a business domain.
Enabling teams
Not all teams in an enterprise are responsible for building services that express business logic. Some will act as enablers for other teams to perform efficiently. Team Topologies call these enabling teams.
Platform, DevOps practices, security, tooling, developer experience, and similar names may represent enabling teams in your organization.
The key point is that the enabling teams don’t work for business domain (stream-aligned) teams. Instead, they set the DevOps principles, deployment strategies, security measures, tools, service audit checklists, and other best practices to empower teams to work efficiently.
Domain boundary
When a team owns and operates its single-purpose product, feature, or service, it becomes the guardian to protect its domain boundary. The team employs adequate technical and communication measures for this purpose.
API-first is a thought process and implementation mechanism of such a measure.
Not all software teams in an enterprise will be building microservices!
API-First
Once you have identified and marked the boundaries of each subdomain, it becomes easier to answer the following questions.
How do we protect the boundary?
Who gets access to interact with the system?
How do external systems get access?
What information can be transacted across the border?
To effectively accomplish the above, you need to think of interfaces, i.e., Application Programming Interfaces (APIs).
An API-first approach prioritizes identifying and implementing interfaces to the system you are building. The API becomes a first-class citizen and plays a significant role in the application's tactical design.
As per established API design guidelines, a well-defined API definition makes it clear, concise, and consistent and promotes loose coupling and interoperability between multiple services within and outside of the product domain.
API-first is a thought process and implementation mechanism to guard domain boundaries.
Microservices-First
With a marked boundary (bounded context) and well-defined (micro) interfaces (API), it becomes easier to own and manage the implementation of the business logic specific to a subdomain.
Microservices thus offer the best development pattern to realize the domain logic. With traditional microservices thinking, a microservice is usually related to a bounded context, but it doesn’t need to be the only way.
When we operate within a boundary with an established communication contract aided by serverless thinking and the granular nature of managed services, it is possible to break down into smaller microservices.
As mentioned above, a single team guards the boundary and owns the microservices, thus reducing the cognitive load and increasing development velocity and flow.
Event-Driven-First
Event-driven architecture and asynchronous communication is an area that troubles many traditional engineering minds.
At AWS re:Invent 2022, Dr. Werner Vogels, CTO of Amazon.com, famously declared — “The world is asynchronous.”
Asynchrony and event-driven communication are the driving forces behind the managed services that power serverless. Event-driven thinking elegantly connects domain thinking with serverless thinking, upholding contractual boundaries and keeping microservices loosely coupled.
Identifying domain events and knowing what goes out (published) and what gets in (subscribed) are as crucial as API contracts.
For organizations going through their digital transformation with a serverless mindset, familiarity with domain events and activities such as event-storming is vital.
Asynchrony and event-driven communication are the forces behind managed services that power serverless.
Serverless-First
And the best is kept until last!
When an organization gets ready to adopt serverless, it has already set the cloud-first strategy to use the public cloud to host, develop, and operate its business applications over on-premises and self-managed legacy systems.
Serverless-first is the thinking to consider serverless as the best-fit technology choice to build and operate business applications to deliver value faster.
The book The Value Flywheel Effect: Power the Future and Accelerate Your Organization to the Modern Cloud sums it up nicely, “… it’s about doing the simplest thing to deliver value by removing the unnecessary baggage. Today serverless-first is the perfect strategy to achieve this”.
It’s about driving value for the business in this modern, fast-paced, and highly competitive world.
As software engineers, you must learn to leave the heavy engineering to the managed service providers and evolve your business solutions on top with a pragmatic and practical mind. Serverless-first should be part of that value-generation process.
To build a modular, extendable, secure, and sustainable serverless application, you need more than a developer’s chair and a laptop!
Conclusion
With reduced infrastructure and platform burden, serverless is easy to start. However, enterprise-wide engineering is not about a quick and easy start. When there are multiple teams and hundreds of engineers, you need to build the endurance for a marathon, not for a quick-burst hundred-meter sprint.
The FIRST principles discussed in this article are not a finite list. You may tailor this for your organization, domain, and the technology ecosystem and consider principles such as DevOps-first, Security-first, DevX-first, Event-first, observability-first, etc.
Learn from others’ experiences but listen to your own needs.
There are several enterprise-scale serverless adoption success stories in the industry. The purpose and end goal of each adoption may vary, but lowering operating costs is not the only motivation for serverless.
Starting the serverless adoption with the right mindset on a solid foundation allows it to be logical to make necessary adjustments along the way and be successful.
In an enterprise with multiple teams and hundreds of engineers, you need to build serverless endurance for a marathon and not for a quick-burst hundred-meter sprint.
Sheen Brisals is the co-author of Serverless Development on AWS: Building Enterprise-scale Serverless Solutions (O’Reilly, 2024).