How Vercel is changing the cloud game

1. What is Vercel?

In all likelihood, many people know Vercel for being the creators of Next.js, a React-based Web development framework with SPA, SSG, and SSR capabilities. But frankly, after discussing what Vercel really is with my colleagues at work several times, it is way more than that:

Vercel is a cloud computing provider.

After reading that line, you may be thinking: "This guy has lost his freaking mind". Well, it happens that I know exactly what I am saying; bear with me.

Funnily enough, they do not introduce themselves as such in their main channels, like their Web site, but they technically are. You need to surf to this particular folder in a specific repository on GitHub to find the definition I like the most:

Vercel is a cloud platform for static frontends and serverless functions. It enables developers to host websites and web applications that deploy instantly, scale automatically, and require no supervision.

In other words, Vercel is a niche cloud computing provider where the niche is Web application development. It offers a higher-order abstraction on top of infrastructure utilities from generalist cloud providers by wrapping, encapsulating, and composing them into a developer-centric computing solution.

With this context, why do we consider AWS a cloud computing provider and not Vercel? The problem comes with the definition of cloud computing provider. Suppose AWS reshuffles its entire catalog of services keeping only serverless components such as Lambda, DynamoDB, API Gateway, S3, or Step Functions. What's the difference with Vercel, then? In this scenario, they both provide computing abstractions and offer them as a service; it just happens that Vercel provides higher levels of abstraction and defaults oriented for Web developers. Both offer building blocks, and developers will use them depending on how well these abstractions fit their needs.

Spoiler: For Web developers, Vercel abstractions fit very well.

In the era of serverless and infrastructure as a commodity, the definition of cloud computing provider is broader than we think. How do companies qualify as cloud computing providers? Doesn't Vercel provide cloud computing services? To be an authentic cloud computing provider, do companies need to own their entire stack, including hardware, to be a genuine cloud computing provider? Do they need to offer VMs and VPCs in their cloud computing catalog to be considered such a provider? No, I don't think so.

1.1. Vercel's managed service

Vercel's mission in this world is to empower developers to build a faster Web. This obsession for speed manifests itself in two main lines of action:

• Run the fastest Web applications on earth thanks to an auto-scalable, high-performance computing solution.

• Create the best tools for Web developers to build, deploy, preview, and ship Web applications instantly.

And both are interconnected. Vercel's Deploy-Preview-Ship (DPS) workflow allows developers to go from code to actual deployment of your Web application in a matter of seconds. For that, you can either import your project directly from GitHub or create a new one based on a template from a catalog of different Web technologies. Interestingly, if you decide to go for Next.js, Vercel also provides you with canned scaffolds for certain types of frontend architectures such as e-commerce, events, documentation, and blog Websites.

In the simplest use case, after you configure permissions and allow GitHub's Vercel app to access your repository, every commit will result in an instant build and deployment of your Web app onto Vercel. And it will happen in a question of seconds, giving you back an actual application URL you can try. This process reminded me of Heroku, and that's because Vercel is also investing in this kind of developer productivity to shorten feedback loops. Of course, there are multiple ways to make deployments with Vercel; in addition to GitHub's Vercel app, we have other alternatives such as Deploy Hooks, Vercel CLI, and the Vercel API.

OK, but what's the value of Vercel?

Let's suppose you are building a Web site with a mix of capabilities: SPA with React Hooks for the most interactive part, SSG for some pages with significant static information, and SSR for some low-latency data access. You can do that by utilizing Next.js or even Remix. As you can imagine, these applications need different pieces of cloud computing resources (infrastructure), so where do they get deployed?

Three alternatives respond to different stages in the technology evolution:

1. Custom built: You handle the entire deployment process and technology end-to-end. You would need to start by designing an entire build process where you identify, split, and package the different components of your Web App into separate bundles. That's because your SPA, SSG, and SSR pieces are deployed separately on different types of cloud infrastructure. Then, you would need to write a few lines of Terraform (or Pulumi, etc.) to get those bundles deployed into their pertinent cloud services. If you use AWS, those are services such as S3, Lambda, CloudFront, and API Gateway. Additionally, although you don't own those server-side computing resources, you still need to manage their status in this scenario.

2. Buy a product: Similar as above, but instead of writing your own infrastructure-as-code scripts, you buy it from the market as a pre-integrated product. I am thinking of solutions such as the Next.js plugin from Serverless Framework or this Terraform module created by the community. In this case, you are not custom-building everything from scratch, but you still need to manage the status of the serverless resources you have created. Also, you are now totally dependent on these frameworks to adapt to the potential changes in conventions and structure introduced by the different Web technologies (e.g., changes in Next.js build)

3. Subscribe to a service: You don't care how your components are bundled, where they are deployed, and how they are managed. Your infrastructure-as-code scripts are reduced to very few calls to a Deployment API with coarse-grained abstractions specifically designed for Web applications. Everything is given to you as a well-oiled build, deploy, and ship managed service where you only pay per user. This is Vercel.

In this last scenario, the entire build, deploy, and ship process is absolutely transparent to you, including managing the status of the server-side computing resources of your Web application.

We can represent these three alternatives with the following Wardley map:

As you move to the right through the evolution line, technologies keep adding levels of abstractions that come with limitations and constraints. That's the price they pay for industrialization and commoditization. If you are happy with them and fit your bill, they may be an exciting solution to your problems. In the case of Vercel, these abstractions, limitations, and constraints may pay off for a considerable number of Web development use cases.

1.2. Vercel's cloud computing abstractions

"Speed of developer iteration is the single most important factor in how quickly a technology company can move." Paul Biggar, founder of Darklang and CircleCI

Amongst all the computing and deployment characteristics of Vercel, there are two that bring my total attention: Serverless Functions and Edge Functions: Yes, with Vercel you can build, deploy, and ship APIs too. These are HTTP Req/Res constructs that can either be consumed by the frontend components ... or not. I mean, you could use Vercel to deploy an API without any visual components if you wish and expose it through an HTTP endpoint.

• Serverless Functions are pieces of code written with backend languages that take an HTTP request and provide a response. They are deployed on Vercel's Edge Network, which uses AWS Lambda under the hood running on different regions.

Note: Remember, even if these Vercel functions run on AWS Lambda@Edge, that's surprisingly not an edge solution as documented by AWS many times. AWS's proper edge computing solution is CloudFront Functions

• Edge Functions (in beta) are very similar to Serverless Functions except that they are deployed at the edge with CloudFlare Workers. I believe these functions can only be programmed in Javascript and are executed by the powerful V8 runtime. Additionally, with Edge Functions, you need to write a small piece of middleware that is executed before the request is processed and is very useful for use cases such as authentication, redirects, or A/B testing.

Let's take a closer look at Serverless functions. To me, the most impressive feature is that they can be written in a handful of backend programming languages. You just need to place that code under the /api folder of your Web app repository and next Vercel will automatically recognize these source code files and deploy them as Lambda functions on AWS.

Well, to be 100% accurate, Vercel DPS workflow does not deploy them directly as Lambda functions. Instead, Vercel uses a thing called node-bridge that spins up a Node.js server inside a Lambda function and then creates a request from the Lambda invoke event.

Source: Stack Overflow

This is what I was referring to before when I said that Vercel identifies, splits, and bundles different components of your Web application and deploys them onto various cloud services. For example, I am sure the SPA bundle is deployed onto something like Amazon S3, while these functions are deployed on AWS Lambda. However, both are contained within the same repository. I didn't try it, but you could even write your frontend part in Typescript and the backend part in Go, everything structured within the same Web app repository.

Vercel's work to encapsulate the underlying cloud complexity and create valuable abstractions for Web developers manifests itself brilliantly in the signature of these Serverless Functions:

import { NextApiRequest, NextApiResponse } from 'next';export default function handler(req: NextApiRequest, res: NextApiResponse) {  res.status(200).json({    body: req.body,    query: req.query,    cookies: req.cookies,  });}

If you are familiar with AWS Lambda and its handler function, you'll notice that the context and event objects are not exposed at this level by Vercel Serverless Functions. The main reason is that, from all possible AWS Lambda event sources, Vercel has restricted its usage to the HTTP Request/Response use case (most probably with requests coming from the API Gateway). This is precisely the scenario that makes more sense for Web applications.

This is interesting because, if we look at other Lambda-based solutions such as Netlify Functions we can see how they do expose the exact same parameters as the Lambda handler-function:

exports.handler = async function(event, context) {   return {     statusCode: 200,    body: JSON.stringify({message: "Hello World"})     }; }

Not sure why I have access to the event and context objects here. Does it mean that I can make my Netlify Function respond to another type of event that is not an HTTP Req/Res? Can I make my Netlify Function implementation respond to events from Amazon S3 even If I have no access to it? I am probably missing something, but I couldn't find an explanation for this design decision.

All in all, it is understandable to look at this cloud computing solution with skeptical eyes. You may be asking "OK, but if I use Vercel Serverless Functions I will lock in and lose control of the Lambda functions, their cyber-protection, etc". Well yes, in the same way that if you use AWS Lambda you lose control of your Virtual Machines, their cyber-protection, etc. And you were happy with that.

Evolve or die.

2. What are Vercel's integration use cases?

As you might have guessed already at this point, this post is not about Nex.js, and to be honest, I won't write much more about it.

This post is about how companies like Vercel are changing the cloud computing game by creating niche abstractions for Web developers. And that's where it can unleash its full potential: Vercel is a great place to deploy any frontend application. It is a platform for static sites and frontend frameworks, built to integrate with your headless content, commerce, or database.

So, let's look at its integration capabilities.

2.1. Integrating with your architecture on AWS

Suppose you are building a Web application with Next.js and deploying it with Vercel. You have some SPA pages and also one Serverless Function. Now, say you have other parts of your architecture running on AWS you want to integrate with. Concretely speaking, you love DynamoDB, and you want your Vercel Serverless Function to integrate directly with your DynamoDB tables on your AWS account using AWS SDK. Can you do that?

Short answer: yes.

Long answer: it's complicated (not complex). Your DynamoDB table is just one API call away, but you need to put in some authentication and authorization, which is not trivial. Although Vercel provides documentation on how to integrate with AWS services directly, I don't think that's a solid solution. Basically, this approach is suggesting that you to set up your AWS user's secret access key as an environment variable, so you can access them later from your function. Unfortunately, that's not a security best practice as many users express in this GitHub discussion. User secrets rotate, and I would never create a DynamoDB policy declaring an IAM user as a principal. Instead, you use IAM roles for that. However, you can't use the IAM Role assigned to Vercel's lambda function and declare it as the principal in your AWS DynamoDB policy ... because that role is managed by Vercel.

What are the alternatives? Well, at the end of the day, my DynamoDB scenario above is nothing but an HTTP API call encapsulated by an SDK function. So basically, I would use Amazon Cognito and OAuth 2.0 credential flows to control access to my DynamoDB tables from my Vercel Serverless Function based on the users group membership. I am pretty sure that this is similar to what other public DBaaS solution like Supabase do.

2.2. Vercel Integrations Marketplace

Vercel features an Integrations panel where you can select multiple aaS vendors from a marketplace to integrate with your Web application (and serverless functions). What's a Vercel Integration? Well, I thought I was going to find something fancy and complex, but it seems that an integration is just a shortcut for creating Vercel Environment Variables automatically, so they are ready to use in your code:

Hey, don't get me wrong. There is NOTHING wrong with that. Again, I may be missing something, and there may be more things and nuances behind Vercel Integrations, but I am not experienced enough to catch them all.

And here is where I have mixed feelings. Although apparently, you could create any backend with Vercel Serverless Functions, as far as I am concerned that's unrealistic. And if you think twice, I don't even think it's in Vercel's interest to become such an overarching framework encompassing multiple architecture layers. They are focusing on Web development, so the features and abstractions they give you to create backends are bounded within the context of Web applications. In other words, it may be that Vercel Serverless Functions provide their best value when they are used as Backends for the Frontend (BFF).

3. How can Vercel evolve?

As I wrote in my previous post about the future of cloud computing, solutions like Vercel are already playing in the services economy and offering their features as utilities you can pay per use.

Although, as a company, they are a very well-valuated startup in the hypergrowth phase, they still need an enterprise-grade customer base to grow organically. They have everything to succeed, and that's why they must pay attention to inertia so they don't die of success.

What's inertia like for Vercel? As I wrote earlier, I don't think Vercel is interested in becoming the next Heroku by providing overarching capabilities covering the entire development spectrum. In my opinion, they are doing pretty well focusing on their mission to enable a faster Web and optimizing the SDLC for Web developers.

3.1. Frictionless Deploy-Preview-Ship workflow

There is nothing more motivating for a developer than an efficient SDLC. That efficiency can be achieved through automation and, do you know what the highest expression of automation is? You guessed it, the answer is managed services. Imagine for a moment that you could have infinite resources to improve your CI/CD pipelines and SDLC so you can move from idea to live product almost in zero seconds at zero cost. It does make sense then to put the time you saved from not building those computing features yourself into something of greater value, such as improving your application's user experience. That is what managed services like Vercel do for you.

Let me raise another point. Once our Web applications are running on production and users find a malfunction, why do we fix those bugs at all? In the physical world, you would throw that product away and produce a new one through your super-optimized production chain. Why don't we do that with software? Why don't we throw the application away and start from scratch?

Well, I am playing devil's advocate here. The reason is that building software is not like building physical stuff, and the hard part is in the design, modeling, and problem-solving logic. But, what if we could optimize software's SDLC and make it almost negligible in the overall sum of efforts? What if Vercel DPS workflow becomes totally frictionless and tends to 0 seconds?

I am ranting here, but that is precisely Darklang's mission. I wouldn't go as far as Darklang with Vercel, and I am especially skeptical about the idea of creating its own kind-of-visual programming language. Still, I like the idea of instant deployments as you code, transparently. I mean, with an optimized DPS workflow like Vercel's, why do we need to build on localhost anyway? I guess we are not just prepared for that. To me, one of the main problems of Darklang is that it is too forward-thinking, too advanced for our time, and it does not resolve any of the problems developers have nowadays. In other words, it didn't consider our zeitgeist. It is not meeting their customers (developers) where they are.

Darklang

Finally, and always, in my opinion, Vercel should keep focusing on the following areas of action:

1. Industrialize cross-cutting capabilities that every Web application needs or uses.
2. Rationalize access to the ever-evolving serverless primitives from traditional cloud providers.
3. Create higher-order cloud computing abstractions and other frameworks oriented to their niche users, Web developers.

Of course, if you have reached this far and you want to know more, I wrote about this stuff in my book Building Software Platforms. Go and check it out! The first chapter is free.

PS: As I wrote this post, Vercel announced another promising capability called Platforms Starter Kit. While I only had the time to make a diagonal read, I could notice how this new solution ticks many of the boxes I have described in this article, especially the latest 3 points about industrializing, rationalizing, and curating Web developer experiences.