Serverless Adoption Survey — The numbers so far

AWSStrategyDaily Email

Last month I started a research project into the gains and pains development teams encounter when adopting serverless in AWS. Specifically, I am hoping to uncover patterns between traits of the adopting organisation and its engineering team(s) pre-adoption, and any positive or negative experiences they had during the implementation.

My survey has been open for 4 weeks now. I’m pretty happy with the quality and quantity of responses (127 as of this writing) so today I want to share some of the results of the quantitative questions in the survey and my initial observations on these.

The key findings

I’ll give the breakdowns below, but these are the headline results:

  • Flexibility of Scaling is the main factor for choosing a serverless solution in the first place with Faster Feature Development in second place.
  • Debugging & Monitoring is the number 1 pain point encountered when building and operating the serverless workload by some margin. Testing and Developer Workflow are 2 and 3.
  • 66% of respondents will use a serverless architecture for their next development project.

Who was surveyed?

The survey was completed primarily by people in senior engineering roles across a wide range of company sizes who have built at least one serverless application on AWS in a professional team capacity.

Here’s the breakdown of responses to questions on organisation headcount, job titles and serverless experience level:

Organisation headcount
Job title
Serverless experience level

The main drivers for moving to serverless

Factors for choosing serverless

These are quite interesting. Flexibility of Scaling is clearly the most important factor for why respondents choose serverless over their previous stacks, with Faster Feature Development in second place.

As a strong proponent of the Total Cost of Ownership benefits that serverless brings, I’m slightly miffed that Smaller Engineering Teams is probably the lowest ranked driving factor, beneath even Lower Cloud Bill. If your application’s cloud bill is higher than your engineer’s salaries, then you are probably in a small minority. (See also: You are thinking about serverless costs all wrong).

The top pain points when building with serverless

Top pains when building with serverless

Respondents could choose at most 3 options for this question (with variations of “Other” comprising all the single response items). No surprises that Debugging & Monitoring is the clear top pain (57% listed it as being one of their top 3 pains). The number of SaaS products already targeting this space is testament to this being a significant problem for folks running serverless applications (and distributed workloads in general).

Testing comes in second place. I’m not surprised that so many struggle with it as I often do so myself. In any software architecture, implementing a good testing strategy has never been easy in my experience. But the distributed, asynchronous and remote characteristics of serverless applications make testing them particularly challenging.

Developer Workflow is a close third. This is quite a broad category that I will be doing more analysis on during interviews, but it mainly covers issues such as tooling and remote vs local dev environment.

A surprisingly low score (9.9%) for Vendor lock-in/Lack of portability—a major reason touted against adopting serverless in the first place. I guess that ship has sailed for most respondents who have gone all-in with their cloud provider and for whom portability is much less of a concern now.

Using serverless in the future

Will you use serverless on your next project?

Almost two thirds of respondents stated they will use a primarily serverless architecture for their next project. I’m actually surprised this number isn’t higher (given post-purchase rationalisation bias), but only 13.1% stated they would not use it again, with the rest undecided.

What’s next?

In this post, I haven’t covered any of the qualitative freeform answers included in the survey responses. I hope to send you more information on these within the next week or so as there is a lot of great insight in there that will add more colour to the aggregated figures shared here.

I’m also continuing video interviews with survey respondents who have kindly volunteered their time to tell me more about their experience building with serverless. At the time of writing, I’ve completed 5 interviews with many more on the calendar for the next few weeks.

The survey is still open, so if you’ve built a serverless application on AWS in a professional team capacity, I’d really appreciate it if you could take a few minutes to fill it out and maybe even share it with your network. Here’s the Google Form.

Have a great weekend!

— Paul.

Originally published .

Other articles you might enjoy:

Free Email Course

How to transition your team to a serverless-first mindset

In this 5-day email course, you’ll learn:

  • Lesson 1: Why serverless is inevitable
  • Lesson 2: How to identify a candidate project for your first serverless application
  • Lesson 3: How to compose the building blocks that AWS provides
  • Lesson 4: Common mistakes to avoid when building your first serverless application
  • Lesson 5: How to break ground on your first serverless project

    ☎️ Serverless AMA

    Need quick guidance on a specific issue on your AWS serverless project? Or just wondering where to start with serverless?

    Book a call and ask me anything.

    Learn more >>

    🛫 Serverless Launchpad

    Ready to start building your new AWS serverless project but need help with getting everything setup?

    The Serverless Launchpad is a done-for-you DevOps service installed in under a week. You get a leading-practice multi-account AWS environment, a scaffolded codebase and architecture including the common AWS serverless services, isolated cloud environments for individual developers, automated delivery pipelines right through to production and much more. Everything is IaC, extensively documented and handed over to your developers.

    Learn more >>