The Rise of Full Stack Serverless at Amazon Web Services
This week I talk with Nader Dabit, senior developer advocate at Amazon Web Services (AWS), about the state of serverless technology. Dabit also has a new book out, published by O’Reilly Media, entitled “Full Stack Serverless.” It’s a guide to building full-stack applications using React, AWS, GraphQL and AWS Amplify.
AWS is a leading proponent of serverless, having popularized the term from about 2015 with its Lambda service. Since then, Dabit has emerged as a prominent voice in serverless, with over 39,000 Twitter followers.
Serverless can be a loaded term, but basically it means to abstract away the backend so that developers can focus purely on the frontend. When I asked how Dabit defines serverless, he cited a Berkeley University paper (PDF) on serverless computing from February 2019, which summed it up with this equation: serverless computing = FaaS [Functions as a Service] + BaaS [Backend as a Service].
However, Dabit prefers to think of serverless more as “a development philosophy.”
“Cloud computing just has a really high barrier to entry,” he explained, “and I think there’s a […] hunger for frontend developers or developers that are just not into cloud computing, to start using it because of all the benefits that it offers.”
The serverless trend is really about giving developers the tools, libraries and APIs they need to build cloud apps. It takes the backend burden off them.
Although serverless is designed to help frontend developers build cloud apps, I wondered how common it is in 2020 to be a “full-stack developer.” These are developers who are experts at both the backend and the frontend. So I asked Dabit how the role of full stack developer has evolved over the past decade or so.
“When Rails [Ruby on Rails] was really popular,” he replied, meaning about 10 to 15 years ago, “you had this new generation of full-stack developers that [had] this really great attraction to build [both] the front and the back end. And I think that as the front end became more complex, over the last 10 or so years — with single-page applications and all the different tooling [for] building a single-page application — […] then the front end started becoming too complex for people to understand both in-depth.”
That’s led to the current era, where the full stack developer is — as Dabit put it — an “outlier.” Which is where serverless comes into play. It allows the frontend developer to build “full-stack” applications because serverless platforms like AWS Lambda automatically manage the backend.
According to Dabit, as long as a frontend developer understands how to consume API’s and has a familiarity with working on the command line, then they can become the equivalent of a full stack developer — at least in terms of the types of apps they can now build.
“It’s just much easier now with all these new abstractions that the cloud providers are offering, for a frontend developer to be a full stack developer without having to spend a ton of time specializing [across] the full stack.”
AWS Amplify and Comparisons to Netlify
Part of Dabit’s role at AWS is developer relations for AWS Amplify, a JavaScript development framework and web hosting service for mobile and web applications on AWS. This is a key tool in AWS’s serverless armory, since it enables frontend developers to get started straight away in building cloud apps. As Dabit wrote in his book, the Amplify CLI [Command-line Interface] “allows developers to create, configure, update, and delete cloud services directly from their frontend environment.”
Amplify is somewhat similar to the JAMstack companies I’ve been profiling recently, in that it offers a JavaScript development framework (like Gatsby and Vercel) along with the hosting part (like Netlify). Dabit told me that Amplify works with all the existing frameworks, like React, Gatsby, Vercel and others like Vue and Angular.
Where Amplify seems to directly compete with a JAMstack company is with Netlify. The Console, part of the Amplify set of tools, is described as “a static web hosting service” that provides “a simple CI/CD workflow for building and deploying static web applications.” That could equally describe what Netlify does (although there are some differences between the two).
Amplify and Netlify also both support serverless functions, which are units of programming that perform a specific task and are hosted in a managed service environment. They are typically triggered by events. AWS Lambda is Amazon’s service for running functions in this manner. Indeed, to use Berkeley’s terminology, Lambda is a FaaS (Function as a Service) platform. The Amplify toolset is complimentary to Lambda, as this diagram of an example serverless web application built on AWS shows:
Source: AWS
Netlify Functions actually relies on AWS Lambda for its functionality, but it claims to make serverless functions “painless” by comparison to AWS. The tagline for Netlify Functions reinforces that message: “Powered by AWS Lambda. Simplified by Netlify.”
API’s a Top Use Case For Serverless
I asked Dabit what AWS customers tend to use products like Amplify and Lambda for?
“I would say API’s are kind of the number one use case for serverless,” he said, “because you can use Lambda to talk to any of these other services in AWS. So you can use [Lambda] to talk to a database, you can use Lambda to talk to your Authentication Service, you can use Lambda for pretty much everything.”
Speaking of API’s, this is where GraphQL comes into the serverless paradigm. GraphQL is an open source data query and manipulation language for APIs; some have compared it to SQL, but for APIs rather than databases. Since the term is mentioned in the sub-title of Dabit’s book, I asked him how important it is for cloud applications nowadays.
“What we’re seeing is that people are replacing a traditional API gateway with a GraphQL API,” he replied. “And it’s a really good use case because when you’re working with a microservice architecture and you’re kind of piecing together all these endpoints, a lot of times you have inconsistencies around the API creation and the API documentation and all that stuff.”
Like the React JavaScript library, GraphQL came out of Facebook in the 2012-15 period. Since GraphQL APIs are organized in terms of types and fields, not endpoints, it makes it easier to track multiple APIs in a specific application.
“What GraphQL offers is a unified graph of your data, and all the ways that you can interact with it,” Dabit said. “So any new developer can come into your application and look at your GraphQL schema and understand everything that’s going around, as far as the data layer is concerned.”
What Dabit is seeing at AWS is customers creating their GraphQL API and then “migrating over all their endpoints.”
But wait… there’s a service for that. In addition to its many other cloud services, AWS offers a managed service for GraphQL, called AppSync.
Indeed, after talking to Dabit and browsing his new book, I realized that while AWS is certainly making life easier for developers in the cloud era, there is still a lot to take on board. Serverless may mean abstracting away the backend, but every year more and more stuff gets piled onto the frontend.
Less dealing with servers, perhaps, but developers have many services to deal with now. Which brings its own set of complexities.