Click Below to Get the Code

Browse, clone, and build from real-world templates powered by Harper.
Blog
GitHub Logo

Why So Serverless?

Here we go over what Serverless actually means, the pros and cons of serverless architectures and how to go about getting the best deal.
Blog

Why So Serverless?

Margo McCabe
Senior Director of Partnerships and Sales
at Harper
March 16, 2021
Margo McCabe
Senior Director of Partnerships and Sales
at Harper
March 16, 2021
Margo McCabe
Senior Director of Partnerships and Sales
at Harper
March 16, 2021
March 16, 2021
Here we go over what Serverless actually means, the pros and cons of serverless architectures and how to go about getting the best deal.
Margo McCabe
Senior Director of Partnerships and Sales

Since we hosted a livestream on building a serverless Next.js app with Harper 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.

Alt Text

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!

Alt Text

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 Harper 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 Harper. Harper 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
Alt Text

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!

Harper hosted a workshop on March 23rd where you can build your own serverless application! We were excited to host 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 Harper, and deployed it to Vercel. The application will utilize Next.js API Routes, which get deployed as serverless functions on Vercel, to connect to Harper 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.

Since we hosted a livestream on building a serverless Next.js app with Harper 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.

Alt Text

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!

Alt Text

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 Harper 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 Harper. Harper 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
Alt Text

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!

Harper hosted a workshop on March 23rd where you can build your own serverless application! We were excited to host 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 Harper, and deployed it to Vercel. The application will utilize Next.js API Routes, which get deployed as serverless functions on Vercel, to connect to Harper 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.

Here we go over what Serverless actually means, the pros and cons of serverless architectures and how to go about getting the best deal.

Download

White arrow pointing right
Here we go over what Serverless actually means, the pros and cons of serverless architectures and how to go about getting the best deal.

Download

White arrow pointing right
Here we go over what Serverless actually means, the pros and cons of serverless architectures and how to go about getting the best deal.

Download

White arrow pointing right

Explore Recent Resources

Blog
GitHub Logo

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Blog
Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Person with short dark hair and moustache, wearing a colorful plaid shirt, smiling outdoors in a forested mountain landscape.
Aleks Haugom
Senior Manager of GTM
Blog

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Aleks Haugom
Jul 2026
Blog

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Aleks Haugom
Blog

5 Architectures for Web Personalization

Personalization is a data-delivery problem. Every architectural choice reduces to two distances: compute to user, and compute to fresh data. This piece maps five real architectures against both axes, scored on a concrete retailer workload where stale or slow data breaks the business.
Aleks Haugom
Blog
GitHub Logo

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Select*
Blog
AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
A smiling man with a beard and salt-and-pepper hair stands outdoors with arms crossed, wearing a white button-down shirt.
Stephen Goldberg
CEO & Co-Founder
Blog

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Stephen Goldberg
Jun 2026
Blog

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Stephen Goldberg
Blog

Agentic Engineering Needs an Opinion: Why Scale Starts with Architecture

AI coding works in a sandbox because the environment is trivially narrow. Real systems have history, constraints, and blast radius. Coding agents make sound decisions only when the architecture is explicit and shared. Opinion isn't a constraint on agentic engineering, it's what makes it possible at scale.
Stephen Goldberg
Blog
GitHub Logo

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Shell
Blog
A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Person with long wavy brown hair wearing a bright pink shirt with a teal trim, smiling outdoors in soft sunlight with blurred trees in the background.
Bailey Dunning
Forward Deployed Engineer
Blog

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Bailey Dunning
Jun 2026
Blog

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Bailey Dunning
Blog

Building a Cozy Sandbox Game on Harper

A nature-restoration game with six biomes, 150 animals, and a real food web — built with a single Harper component as the entire backend. One YAML file wires the database, API, content seeder, and static host. The same binary ships offline on itch.io.
Bailey Dunning
Blog
GitHub Logo

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
A.I.
Blog
The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Person with short dark hair and moustache, wearing a colorful plaid shirt, smiling outdoors in a forested mountain landscape.
Aleks Haugom
Senior Manager of GTM
Blog

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Aleks Haugom
Jun 2026
Blog

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Aleks Haugom
Blog

Your Website was Built for Humans. AI Needs Something Cleaner.

The web spent a decade optimizing for browsers. JavaScript-heavy rendering, dynamic CMS templates, and client-side hydration made pages beautiful and machines blind. AI answer engines retrieve, parse, and cite content directly. If your best content is trapped behind a render cycle, a cleaner source wins.
Aleks Haugom