Since we hosted a livestream on building a serverless Next.js app with HarperDB and Vercel, I thought it might make sense to do a debrief on “serverless.” We’re starting to see the word more and more, but do we really know what it means or why it’s growing in popularity? Let’s look into this.
One author states that:
Serverless computing is an execution model for the cloud in which a cloud provider dynamically allocates—and then charges the user for—only the compute resources and storage needed to execute a particular piece of code. Naturally, there are still servers involved, but their provisioning and maintenance are entirely taken care of by the provider.
Another article describes:
Serverless architecture refers to a kind of illusion, originally made for the sake of developers whose software will be hosted in the public cloud, but which extends to the way people eventually use that software. Its main objective is to make it easier for a software developer to compose code, intended to run on a cloud platform, that performs a clearly-defined job.
Finally, another author claims that serverless doesn’t really mean one thing, but that it encompasses two overlapping areas. Originally the definition of serverless was a broad generalization, but the term has evolved into a more precise definition like the second point below:
1) Applications that incorporate third-party, cloud-hosted applications and services, to manage server-side logic and state.
2) Applications where server-side logic is still written by the application developer, but, unlike traditional architectures, it’s run in stateless compute containers that are event-triggered, ephemeral, and fully managed by a third party.
So, serverless doesn’t really mean “without a server.” It refers to software that’s hosted in the cloud, or a stateless container, where the user does not need to worry about management, hosting, or maintenance. Servers are still used, but serverless vendors generally provide backend services that are charged based on usage, instead of charging by a fixed amount of bandwidth or number of servers. In the simplest terms, a serverless system is a way to build an application without having to manage the infrastructure. The overall goal of serverless architectures is to reduce administration and maintenance headaches while enabling increased flexibility and innovation. Sounds like a dream come true!
Examples
You might be familiar with AWS' serverless service model called Lambda. Or maybe you’re more of an Azure Functions or Google Cloud Functions fan. Vercel is another cloud platform that enables you to deploy serverless functions. For example, let’s look at HarperDB Cloud instance provisioning. We utilize a serverless architecture that uses AWS Lambda functions for instance provisioning, including allocating AWS resources and metadata creation, with backend data services powered entirely by HarperDB. HarperDB utilizes a REST API as the native interface, making it ideal for serverless functions to consume, as connection limits aren't a problem. There are certainly other examples of serverless - just think of any software that runs when called and disappears when it’s done.
Benefits and Drawbacks
As with any technology or architecture, there are pros and cons to serverless computing. Martin Fowler points out that, “Serverless architectures may benefit from significantly reduced operational cost, complexity, and engineering lead time, at a cost of increased reliance on vendor dependencies and comparatively immature supporting services.” This article also provides some great insights, but I’ll summarize from a few different sources below:
Pros
- Simplicity; remove the need for infrastructure setup, configuration, provisioning and management
- Cost savings; new economic model of cloud computing provides opportunity for increased efficiency and reduced cost; only pay for resources you use; less overhead
- Scalability and latency; the cloud distributes the workload for you so it’s easier to scale horizontally; global access points reduce transmission time
- Increased productivity; developers can focus on their code or their project instead of administration and housekeeping
- Improved security; developer may be more likely to produce code that conforms with best practices because they are constrained to code constructs that work within the serverless context
- Save time; reduce the number of steps involved in production, development, and deployment
-
Improved utilization; usage based fee structure, customer leases a function instead of a server
Cons
- Cloud lock-in; many services are specific to one cloud provider, which locks the cloud provider’s customers into one infrastructure and prevents redundancy and cost savings (learn more about this here)
- Security / risk; no longer own or control the OS, container, or application runtime
- Uncertain service levels; some service level agreements are not yet fully defined for serverless architectures
- Monolithic tendency; organizations tend to deploy all functions on one platform, sharing the same context, which can make it difficult to scale
- Communication; developers and operators may lack communication as developers no longer need to understand the requirements of the systems hosting their code
Well, there you have it folks! The definition of serverless computing has evolved over the past few years, and Wikipedia currently summarizes it well, as “a cloud computing model where the cloud provider allocates machine resources on demand, taking care of the servers on behalf of their customers.” All in all, as long as each individual team or organization works to understand which serverless architecture or technology is the best fit for their unique goals, it seems that the serverless pros outweigh the cons. However, if you don’t do your due diligence and get locked in with a specific cloud provider, you may end up with high costs and a lack of redundancy. Put in the time upfront for technological decisioning in order to reap the benefits later on.
But wait, there’s more!
HarperDB hosted a workshop on March 23rd, you can follow along to build your own serverless application! We hosted Lee Robinson, who works at Vercel as a Solutions Architect and leads DevRel for Next.js, for this fun interactive event. Lee built a serverless Next.js application using HarperDB, and deployed it to Vercel. The application will utilize Next.js API Routes, which get deployed as serverless functions on Vercel, to connect to HarperDB via our REST API. Vercel is a cloud platform for static sites and serverless Functions. It enables developers to host websites and web services that deploy instantly, scale automatically, and require no supervision; all with no configuration. Next.js is an open-source React framework for web development for both server-rendered and static web applications.
- Watch the livestream
- Spin up a free HarperDB instance to code along with Lee
- Lee's code on GitHub
- Register for a free Vercel account
Top comments (4)
Pretty nice description. I like serverless for less resource intensive tasks. I find that just about regardless of model, there's some warmup involved with the dynamic allocation which is not nice when you aim for the lowest latency imaginable for your apis for example.
I completely agree, it's important to make those architectural decisions early.
Serverless is for lazy developers, which means it is for me!
😆 perfect! Nothing wrong with wanting to do less work