Serverless

Recruiting, retaining, and continually reskilling great engineering and development talent is very hard. The unfortunate truth is that it’s only going to get harder. As Marc Andreessen said in 2011, “Software is eating the world.”1

Focusing your technology talent on the business logic, data, and UX differentiates you from your competitors—especially if your competitors are out there focusing on building undifferentiated infrastructure, maintaining that infrastructure for decades, and spending both CAPEX and human time on that maintenance’s lifespan.

As Stephen Orban says, “If enterprises or startups are going to win, they have to go faster than their competitors.”2

So many conversations I have with customers revolve around an organization’s quick time to market. The word “agility” comes up on average every nine minutes in our meetings!

But few, if any, enterprises measure time to value as part of their business agility metrics. Few enterprises or even startups have a principle for maintaining or increasing development velocity over time.

Development velocity is the speed at which you can deliver an additional unit of value to a customer. Velocity is a metric for work done and is often used in agile software development.

Retrospectives are crucial today and have become more common with agile practices. Where are you spending too much time? What hasn’t added value? What worked? What did not?

Today’s agile software development teams are a heterogeneous mix of skill types; the tools they use to deliver solutions, even with microservices, can be incredibly diverse.

It’s not just the application code you must consider; it’s the surrounding elements. Identity management, telemetry tracking, logs, security groups, databases, management information systems—the list goes on. The time engineers and developers spend maintaining these tools could be spent pulling forward and solving user problems by applying logic, data, or a better UX experience.

The Leap to Light Speed

Removing the work (and continuing to abstract higher and more efficiently) is where serverless comes in. It has a profound impact on development.

Serverless is known for reducing costs. You can use it to scale massively on demand. But the most compelling reason to adopt serverless is that it’s the best way to achieve maximum development velocity over time and remove vast amounts of undifferentiated heavy lifting.

Serverless Principles

We should only maintain code that contains business logic. Writing any code creates debt. Write and maintain only the code you need.

We should not manage servers. There is no need to provision or maintain any servers or storage. There is no software or runtime to install, maintain, or administer.

We should have inherent flexible scaling. Your application can be scaled automatically or by adjusting its capacity by toggling the units of consumption (e.g., throughput or memory) rather than units of individual servers.

We only pay when we receive value. Pay for consistent throughput or execution duration rather than by server unit.

We should leverage automated high availability. Serverless provides built-in availability and fault tolerance. You don’t need to architect for these capabilities since the services running the application services provide them by default.

Switching to Serverless

Step 1. Upskill the workforce for serverless.

Step 2. Use mapping to evaluate the applicability of serverless to new applications.

Step 3. As you migrate and refactor applications, evaluate serverless technology to remove the creation of unnecessary software and systems.

Step 4. Put principles in place to reinforce the use of serverless to remove undifferentiated heavy lifting.

Step 5. Use the AWS Well-Architected Framework to ensure best practices.

Serverless on AWS

Serverless technologies feature automatic scaling, built-in high availability, and a pay-for-use billing model to increase agility and optimize costs. These technologies also eliminate infrastructure management tasks like capacity provisioning and patching, so you can focus on writing code that serves your customers.

Compute. AWS started the serverless movement in 2014 with a serverless compute platform called AWS Lambda. You can use it for nearly any application or backend service, and everything required to run and scale your application with high availability is handled for you. You pay only for the compute when a function is activated—there is no charge when your code is not running. It is an event-driven, pay-as-you-compute service that lets you run code without provisioning or managing servers.

Application integration. AWS has a number of serverless offerings to help remove the chronic heavy lifting companies have to do in application integration. Amazon EventBridge is a serverless event bus that lets you build event-driven applications at scale across AWS and existing systems.

Data store. Amazon S3 is an object storage service designed to store and protect any amount of data. Eight more services have emerged over the last few years due to demand for serverless data offerings: Amazon Elastic File System (Amazon EFS), Amazon DynamoDB, Amazon RDS Proxy, Amazon Aurora Serverless, Amazon Redshift Serverless, Amazon Neptune Serverless, Amazon OpenSearch Serverless, and Amazon ElastiCache Serverless.

These services are friends, not rivals. Serverless has often been measured against containers since both technologies provide similar benefits in terms of rapid development. But serverless computing and containerization don’t negate each other—they can work in tandem to build modern applications.

Competitive organizations use multiple mental models: servers, containers, serverless, and the edge. The key is having the right principles and encouraging and rewarding engineers, developers, and partners.

The journey is never done. Always abstract up the stack and refine your technical debt to increase developer velocity.

—Jonathan and Thomas

This is an abridged excerpt from Reaching Cloud Velocity: A Leader’s Guide to Success in the AWS Cloud (Second Edition) by Jonathan Allen and Thomas Blood. This excerpt has been adapted, condensed, and edited for clarity. All rights reserved. Reproduced with permission from Jonathan Allen and Thomas Blood.