Why are so few funded startups using serverless?

A few days ago I asked this question on Twitter:

The value prop for startups to use serverless is very strong IMO, yet it seems that most still aren’t using it. I heard stat from a recent large accelerator cohort that only a small % were meaningfully using serverless. Why do you think adoption in funded startups is so slow?

I got a load of really interested replies, of which I’m sharing a curated list below.

I’ve grouped the Twitter comments into the following categories:

• Simple lack of awareness or misconceptions of the benefits that serverless can bring
• Startups need to iterate quickly and using serverless slows teams down in the critical early stages
• Steep learning curve for developers
• Founders don’t have time to learn any new tech stack (nevermind serverless) and stick to what they already know
• Poor DX of existing cloud services and tools
• The touted benefits of Deployment and scaling aren’t major concerns of early-stage startups
• VC spend does not encourage efficiency in terms of team size
• Serverless developers are hard to hire for
• Founders or senior developers can be stuck in their ways and don’t want to learn something new or spend time upskilling teammates
• PAYG pricing model can cause unwanted billing surprises
• Technical founders actually enjoy the challenges of tinkering with lower level tech and servers
• Lack of serverless relational databases is a deal-breaker
• Vendor lock-in concerns
• Serverless is not amenable to lift-and-shift of an existing application so can’t benefit from being introduced when a startup is scaling up (added by me)

Now many of these criticisms are contentious and you may disagree, know how they can be greatly mitigated or think the opposite is true for some items (as do I). Nevertheless, these perceptions still matter and I believe my Twitter audience skews heavily pro-serverless, so these mostly aren’t from non-believers but instead from those who want serverless to become mainstream.

Here’s the long categorised list of people’s comments… (mostly unedited, so excuse typos & formatting)

Simple lack of awareness or misconceptions of the benefits that serverless can bring

• no continuing education in tech means senior talent doesn’t know and understand the benefits of serverless, and so they don’t pick it. The lack of CE in tech and dev means that significant improvements to SDLC take longer and longer to get adoption over time.
• As many others have said already, I think awareness is a big factor - leadership doesn’t know serverless and tends to stick to what they know (less risky), especially when they’re under time pressure to show results.
• I think the biggest reason is simply that they are not aware of the benefits and are still using traditional server-based architectures. Once more become aware of the benefits of serverless (scalability, flexibility, cost-savings, etc.), I think we’ll see a faster adoption rate.
• A cynical observation of funded v un-funded: Majority of investors/VC’s with dev knowledge have traditional arch experience. If a startup starts talking Serverless the majority of investors return blank stares and the startup doesn’t convert to funded.
• Lack of understanding. This thread is mostly full of people contrasting FAAS and monoliths, but you can deploy a monolith to Lambda, just like you can deploy multiple services to one machine. Runtime deployment topology != logical application topology.
• From talking to people at meetups & conferences, there’s is huge gap in serverless understanding between active tech community & many teams in the corporate world. Awareness & how-to-do successfully yet to reach many. To get products over the line they stick with known stuff.

Startups need to iterate quickly and using serverless slows teams down in the critical early stages

• until it’s as easy as Rails to spin up a serverless project with everything you need in year 1 of your company, I don’t think serverless will get much more traction. it’s why we’re shifting this year beyond IaC into providing application stacks
• I think we have to be open about the fact it’s easier to build a monolith and deploy it somewhere. Doesn’t even need to be container based. Most startups build rapidly then throw away as users give feedback, devs in that cycle don’t want any extra work then a re-arch is expensive
• They’re probably going to try building a microservices architecture which complicates and further slows development.
• 1. Development iterations are too slow 2. Can’t debug
• IMO: decision taking and yak-shaving. Shipping a monolith is an easy one-time decision that lets the company move attention to validating value prop, etc. Unless the team is serverless savvy, basic architecture will likely be chosen mostly on the basis of “simplicity”.
• 2. in the idea => prototype => product lifecycle in early stage startups, this might appear as over-engineering
• The very first versions of your product will always be a monolith (assumes serverless != monolith)

Steep learning curve for developers

• now that I have the skillset it’s easy for me as well but going from knowing nothing about AWS/serverless to a correct project took me at least 6 months of research + being fairly senior + the free time to do so rails type frameworks you can get up to speed in a week
• that’s a big part of it but also even more basic things like what does testing look like, how do I think about local development, how do I manage config, etc lot of expertise to develop yourself
• Training staff/new hires is also a challenge, learning serverless is not “one thing” - often have to learn new paradigm (distributed sys), new way of working (testing, deployment, etc.), new tools, maybe new prog lang (e.g. java cold start perf is unacceptable), and AWS!
• It’s the compounding effect of having to learn all of these things, all at once, which makes it really daunting. And most don’t have a structured training & onboarding process, esp as tech leadership is figuring things out for themselves.
• there is still a lack of complete training in full stack serverless tech
• Skill. To use things like Lambdas properly and handle failure scenarios has devs running back to the safety of a monolith. I get it, but try and do serverless where possible because the long term gains out-weight the short term teeth grinding. The lack of an OS is joyous.
• things that are not talked about a lot for serverless are: 1) it forces a different code structure 2) it forces a different way of thinking 3) its a spectrum Going from a monolithic workload to serverless one isn’t 1:1 hence the shift.
• Steep perceived learning curve that’s actually even worse than it seems.
• Cloud Development with Serverless is way more complex than just hosting a Node Server somewhere
• Lack of familiarity with distributed systems, leading to low dev velocity
• the whole team need broad knowledge and experience to deliver serverless solutions efficiently. Too many rough edges.
• The message-oriented architecture learning curve is steep, but that’s true even if you’re deploying a Java monolith.
• Is challenging even for seasoned developers to make the transition to the “serverless mindset”.
• Learning curve - esp when localized testing gets added,
• lack of experience with access controls(IAM etc)

Founders don’t have time to learn any new tech stack (nevermind serverless) and stick to what they already know

• People use what they know to build their product ASAP and they don’t have time to research new stuff. If you can build something in 10 minutes with Django monolith rendered in the backend & hosted on a server, you shouldn’t experiment. Business first, tech later.
• Looking at the startups around me, the majority of them have to start with inexperienced tech teams or outsource their software to agencies in the beginning. So I think the main factor is just a lack of skillset.
• Past experience and the pressiure to build &ship fast. They aren’t looking to learn new ways of organizing, developing, testing and shipping stuff.
• startups want to move fast, and see any new-skill-learning as a waste of time

Poor DX of existing cloud services and tools

This is really a subset of the earlier category as these contribute primarily to speed of shipping.

• Isn’t it just the complexity of AWS?
• Full stack framework like Rails have a good local DX, are fast to build with, have plenty of developers and examples available.
• The serverless DX is still awful and experienced developers are hard to find. Developers with no/limited serverless experience will make mistakes slowing down development.
• Better tools are needed. I think this will be either: 1. An opinionated full stack framework that includes a good local DX but deploys to serverless. or 2. Pro low code development tools. <— What I’m working on with StackToolbox
• Some more “marketing” on opinionated tech stacks would help decision fatigue challenges. Choosing rails, or LAMP, or insert-acronym-stack means making 100 decisions at once.
• A productive local dev environment takes a bit of thinking. This results in frustration for those who don’t manage to get it right.
• The missing link with regards to serverless adoption has been extending that seamless developer experience to managing global dynamic state.
• Tried at a previous job and had beef with serverless framework. IMO it’s better now but still poorly documented complexity layered atop Cloud Formation. Great for zero to something, hard for something to great.
• AWS has the ux/ui of a 1987 polish postal office
• Lack of popular web framework. Speed bootstraps. @springboot Java,@abpframework .Net,@strapijs NodeJS,@djangoproject Python
• I suspect massive general serverless adoption will become possible only when the devs won’t need extensive knowledge about the underlying platforms and their nuances.
• I say the above as a huge serverless proponent. But the config, DX, and debugging experience is still much too hard for most startups to take the risk of tech they don’t know well.I think DX-centric (not AWS!) serverless will help, e.g. @vercel , @Netlify , @convex_dev
• I still find observability harder in Lambda + connection management etc

Deployment and scaling aren’t major concerns of early-stage startups

• Serverless solves deployment and scaling which are “later” problems that funded startups can solve by hiring a devops team. Full stack framework like Rails have a good local DX, are fast to build with, have plenty of developers and examples available.
• the people who see the value of serverless immediately (DevOps) aren’t the ones who must do the feature architecture to move there (Dev) best we can do is suggest it early for new projects
• there’s plenty of platforms that ship a container for you with little effort or awareness of what’s going on they don’t realize they’ll pay a price for migrating off it later but that’s what we’re competing with when companies are making these initial decisions
• They don’t need to scale from the beginning and they’ll move faster with a monolith. And once they do, vertical scaling handles a lot.
• serverless has 2 benefits for startups: 1. Avoids containers & Linux config/admin if no founder has that experience 2. Easier/cheaper scalability when you’re huge In my experience, (1) is relatively unusual and (2) is too distant to justify the serverless complexity tax.

VC spend does not encourage efficiency in terms of team size

• Also doesn’t help that we’re a decade+ into a frothy bull market where VC dollars have been plentiful. As things tighten, serverless is poised to help some companies do less with more (mostly speaking in terms of hiring, less in terms of infra/saas costs).
• VC’s are in part remunerated for deploying capital into resource hungry startups. ie, high rate of burn is rewarded with more capital, if the growth stands up. So being efficient is almost a handicap, certainly less relevant.
• the huge cost savings are not too appealing when you have several, VC-funded millions in the bank
• Some well-funded startups tend to think that they HAVE TO hire lots of people to show growth.
• I wonder if bootstrapped startups have a higher % of serverless usage because they’d actually benefit from the cheaper operation costs and would be willing to climb the steep learning curve from day 1 versus funded startups
• startups often don’t care about opex as much

Serverless developers are hard to hire

• The serverless DX is still awful and experienced developers are hard to find. Developers with no/limited serverless experience will make mistakes slowing down development.
• Not enough broad competency/experience. Finding your first/second hire who would pick it to build a stack off and train a team around. More startups re going serverless than id expect actually
• Cloud Developers are highly sought after and expensive
• Because the resources (e.g. developers) who know how to deal with a serverless architecture are scarce

Founders or senior developers can be stuck in their ways and not want to learn something new or spend time upskilling teammates

• As someone who set up a serverless solution for a startup I can say most still don’t know or want serverless. There is a lot of “traditionally” schooled dev’s out there who don’t want it. I can see how people get tired of the need to constantly having to explain yourself
• I’m willing to bet there’s a huge negative correlation between years of experience of the tech cofounder and likelihood of using serverless.

PAYG pricing model can cause unwanted surprises

• Billing footguns
• Serverless is not cost transparent, we have read enough stories about it killing businesses
• Fears around pricing - dynamic scale, uncertain price
• The perception is it is too expensive. I hope that will change.
• complexity in billing and risk of getting charged (again - lack of experience)

Technical founders actually enjoy the challenges of tinkering with lower level tech

• I think it’s more to do with the tech co-founder enjoying playing with the hardware. I see young tech people in start-ups avoiding serverless (and cloud for that matter) despite knowing its value because they derive pleasure from building their own.
• For some is even uninteresting since this paradigm by design contains less craftsmanship. Done correctly ~80% of the logic will be handled by managed services. less room for creativity. To my view solving “biz problems” through serverless is more of an architecture exercise. Is certainly interesting to figure out which managed services to utilize and how they will be integrating with each other but the developer would be mostly utilizing the cloud provider SDKs.

Lack of serverless relational databases is a deal-breaker

• I find SQL has a lower cognitive load when the scale is small and there’s a need for analytics or rapidly changing ways to use the same data. I’m a serverless NoSQL noob though which contributes. These days I’d go with ECS/fargate then k8s.
• Is the expectation among the serverless folks that Dynamo would be the typical database for a serverless app? If so, that could be a reason people shy away at startups where relational databases are easy to use without needing to know query patterns in advance.

Vendor lock-in concerns

• It’s 100% lack of flexibility
• Fear of lock-in

---

I’ll try to write more of my thoughts on some of the items listed here in future emails and articles. If you’ve any particular areas you’d like me to cover, I’d love to hear from you, just hit reply.

— Paul