Serverless adoption is on the rise, but we’re still a long way from realizing its full potential. This is a key point stressed by Brian LeRoux, CTO and Co-Founder at Begin— a platform for building modern web apps, sites, and APIs.
“There is no doubt the future belongs to serverless, but the past is really clingy, and the larger space is still very early,” LeRoux told us in our recent report, For the Love of Serverless: 2020 AWS Lambda Benchmark Report for Developers, DevOps, and Decision Makers.
In this blog series, we’ve talked to serverless leaders about its thriving community, rapid upward trajectory, and heightened accessibility. In our interview, LeRoux touches on the competitive state of the industry, opportunities to improve onboarding, and why he’s excited about a new experimental JavaScript runtime.
What are the biggest organizational challenges facing serverless adoption in 2020?
Serverless is a movement predicated on the extremely large scale it takes to run a cloud. As cloud vendors grow, they buy and build more and more infrastructure, and in so doing, drive down the total cost of ownership. The services they offer increasingly become commodities. We started out renting cages and racks, moved to virtualization, and finally to renting a function executing in 100-millisecond increments. And while the definition of serverless has expanded to include concepts such as Infra as Code and Observability, the core ethos remains: outsource your undifferentiated, commoditized workloads and focus on core business value.
Of course, so many organizations are evaluating the different cloud vendor serverless offerings. While unfortunate, it is not unexpected that the various capabilities labeled “serverless” are currently very different between vendors. The very phase “serverless” also has enthusiastic advocates that can inflate expectations (myself included). Inflated expectations are great, but the next step in this story is the trough of disillusionment. The challenge I see in 2020 is that we are probably in the trough right now.
All cloud vendors have rough edges (some more than others). This is not to be unkind, but the delta between the leading two cloud vendors alone is significant. There is no doubt the future belongs to serverless, but the past is really clingy, and the larger space is still very early. While possible to port traditional monolithic apps with careful, deliberate, and intentional care (strangling the old monolithic legacy app into submission), it is far easier to start completely serverless. Even then, the path is still pretty rough. Our goal with Begin.com is to make AWS serverless frictionless also.
What are the biggest technical challenges facing serverless adoption in 2020?
These big markets tend to consolidate around two big players: PC and Mac. Google and Facebook. iOS and Android. The two leading vendors are AWS and Azure. Azure is trailing in revenue but growing faster than AWS. I’ll speak to each.
For AWS, the biggest issue we currently face is dealing with larger file sizes. You only get 512MB in /tmp on Lambda. Fargate is a fine solution to this, but it would be nice to distill the architecture down to a single-compute primitive. The second biggest issue we hear about is a desire for SQL database support.
Azure improvements will be exciting when they happen. Let’s go through the cloud fundamentals: network, compute, storage, and governance.
On the network side, we need Azure to make things easier for frontend developers. Standing up a CDN should be effortless, and the cache invalidation needs to be instantaneous. The offering today is based on Akamai, and there is too much old school friction.
For compute, the Azure serverless offering is still missing the performance and security of runtime isolation as we get with Lambda. Azure cloud functions are deployed in the aggregate to a container. Lambda, based on the open source Firecracker project, creates a “micro-VM” for each function execution. This isolation not only brings better cold start performance, but it’s also truly stateless, so you’re being billed in 100-millisecond increments, and this enables an extremely granular, least privilege security posture and the ability to mix and match runtimes in a single app.
Given there are also signs of industry consolidation to a de facto standard with Twilio, Netlify, Vercel, and Atlassian basing their own cloud functions’ offerings on top of Lambda, it’s overdue for Azure to create a competitive compute option. They could either jump in with Firecracker and work to commodify the space, or maybe take a stab at innovating a new solution like the Cloudflare offering, which is uniquely based on V8 isolates rather than a common runtime. Either path would be interesting. They were early to this space, and it would be great to see them build some momentum again.
On the storage side, Azure Cosmos—the managed database service—needs an on-demand billing capability. As a bonus, if they added native GraphQL capability, the frontend developer community would be stoked.
From a governance perspective, the big thing they need to fix is the Infrastructure as Code story, the ability to fully provision apps with their own native IaC solution Azure Resource Manager (ARM). Currently, you need to mix ARM templates with CLI tools and SDK calls, which is too much friction and opportunity for human error in a task that should be a single deterministic artifact that creates cloud resources.
I’m long on Azure overall, especially with their amazing dev tools GitHub, Visual Studio Code, and TypeScript, but the service capabilities story needs to improve.
Where do you see serverless heading in 2020?
From AWS, I’m expecting things to get faster and cheaper without any breaking changes because that’s what they tend to do. Also, I’m hoping they hear the mob and speed up cache invalidation with CloudFront.
The onboarding to this world is currently still quite rough. Our goal with Begin.com is to make this part easier.
What are you most excited about in 2020 regarding the state of serverless?
I’m excited by the new experimental JavaScript runtime called Deno. It has a lot of interesting characteristics that make it very desirable for serverless web development. It is sort of a do-over by the creator of Node. It’s based on V8, like Node, and has a great cold start. Deno supports ES modules natively, along with the popular TypeScript and JSX dialects. This means serverless-side rendering (SSR), either React (or Preact) with TypeScript, can happen in a Lambda without any third-party build tools. It’s pretty slick, and I think it will be a fun way to build web apps “serverlessly.”
What do you think is the biggest serverless myth that persists?
Lock in. If you can go all-in with AWS building apps using something like Architect or raw SAM/CloudFormation and only serverless services (like API, Lambda, and DynamoDB), you stand a very good chance of successful execution and an advantage over competitors.
Check out the full report or start monitoring, visualizing, troubleshooting, and alerting on all your AWS Lambda functions with New Relic Serverless.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.
