This is cross-post from my blog: https://www.vorillaz.com/scale/.

When it comes to hot topics, there is always a huge question that strikes controversy among the development community: Does the X/Y/Z framework scale properly?

In a world where how we develop web applications changes rapidly, the way we are also treating scalability has also changed along. New frameworks have emerged in the JavaScript community trying to simplify the process of publishing a web application, but they are also coming along with compromises, tons of assumptions, and they might not always be a good fit for every single use case.

In this detailed series of articles, I will try to provide a generic guide for quantifying a web application from one up to a few million users in a linear and progressive way, in a way that is affordable and actually makes sense. We are going to document each step, use open-source technologies, and create a plan for scaling without driving you bankrupt.

Choosing the best framework for the Job

For the purpose of this series, we are going to build a Next.js application. Next.js has been a widely adopted framework, built and maintained by Vercel. The reason for choosing Next.js is its popularity, along with the vision that we can actually decouple the deployment and scaling process without relying on a "major" deployment provider, still providing the same fundamentals.

While this guide offers generic guidance, you can use also Remix, Nuxt, Sveltekit, Blitz, or any other framework of your choice. The real advantage of picking Next.js or any other mentioned framework lies in its versatility.

It allows the creation of web applications with SSR (Server Side Rendering) along with API routes, making it a genuinely good candidate to demonstrate how we can quantify an application for both the frontend and backend. Furthermore, since Vercel provides A-class support for building, deploying, monitoring and effectively scaling, it's also a great case study on how we can build applications without solely relying on "the cloud", or at least "the cloud"m provided by a single vendor.

Leaving the Cloud?

In 2023, 37Signals began documenting their journey of leaving the cloud. The idea was pretty simple yet bold — they moved their main products away from AWS, deciding to purchase and deploy their own infrastructure on-premises, utilizing dedicated servers for deployment, monitoring and scaling on demand.
Of course, this approach may not be viable for everyone, as it demands a good investment in both money and resources that may not be available for you or your team since 37signals is a well established company with a some millions of dollars in revenue.

The economics might not be a good fit at first, especially for a project that is in its early days, considering that most major hosting vendors offer generous free plans that can keep you up and running for some time. Still, we can provide a few strong arguments for not choosing a major "provider" like Vercel, GCP, Azure or AWS and instead move along with a vendor that it offers more "generic" solutions, call me virtual or dedicated servers. And the benefits can be quite obvious.

It's Cheaper.

Vercel, fly.io, Render, or Netlify might not be good candidates for one-to-one comparison as they are services built around AWS, GCP, Azure, or Cloudflare. They function as "middlemen" companies, providing a better developer experience (DX) using resources with "better deals" on infrastructure than what you can get directly from the major cloud providers.

Vercel, for example, heavily invests in their scalability around the serverless ecosystem from AWS. Although the comparison might not be ideal, it's definitely cheaper to use a cloud provider like Hetzner, Scaleway, or DigitalOcean (and many others) providing a dedicated server or a virtual machine.

As of the time of writing this series (January 2024), for a naive comparison, the cost of an EC2 server in AWS (t3a.large) is almost $630 per month, while on Hetzner the a VM with the same specs, it's just $15.48. Considering there are also offers and discounts running throughout the year, you and your team can save even more money. Furthermore, providing a portable and versatile solution for deploying your web applications can be a lifesaver if the hosting providers of your choice decide to start price gouging.

There might be hidden costs that you might not even consider when talking about side projects. Due to limitations of platforms like Vercel, simple DevOps operations like hosting a MySQL database, running a few cron jobs, or using Redis can actually accumulate tons of hidden costs.

Also, the "infinite scalability" mantra that these platforms advertise might also lead to infinite costs. There are horrific stories out there from people who got billed with huge amounts of money from major vendors when they introduced a long-standing job or function. Managing your own deployments can be far more predictable and progressive, and that's also the main purpose of creating sustainable businesses on the web. Assuming that your traffic or users are in perfect analogy with your income, you can actually invest more money in your infrastructure needs as your business grows.

It's Versatile.

Since we have talked about the economics around bringing your own cloud, there is also a counterargument that comes up most of the time: Using AWS/GCP/you-name-it is a rigid and battle-tested platform. That might be true in most cases; still, you have to build your web applications around the ecosystem of the provider, which can be quite restraining. Even when we are talking about Vercel, Netlify, or Cloudflare, you have to shape your code, your architecture, and even your deployment decisions around the caveats, the compromises and the ecosystem provided by your provider.

On the other hand, a solid deployment solution using an industry standards, like deploying a Docker image, is so versatile and, at some point, a no-brainer solution. In the long run, if for some reason you are not satisfied with your provider, moving along to another provider requires minimal effort. You can even bring up a "multicloud" architecture where you use different cloud providers, actually reducing the cost more and increasing the availability of your system.

It's Privacy First.

Privacy might not be the first priority for most companies or solo developer, but it can also be quite a deal-breaker. When we started building Proxima, our business model required us to avoid overseas data transfers for our customers and all the data they were collecting. Thus, we chose to use infrastructure from companies not only physically located in EU soil but also owned by European companies. For that reason, we chose to move along with Bunny, Scaleway, and Hetzner.

Is It Secure Enough, Though?

Security is a main concern when it comes to deploying web applications. Considering that most of the major providers overpromote their security policies and safeguards, it might sound pretty unsafe rolling your own deployments. Still, we can counter-argue that most hosting providers are certified themselves with well-established web and physical security standards like ISO/IEC 27001. Furthermore, extra security services like the DDoS mitigation service from AWS cost extra and they might add up to your deployment budget.

You're Helping the Web Move Forward

Once again, this might not be a good argument for most people reading this article and might be a hot take of mine, but monopolies are not moving the industry forward. When an open-source project like Next.js is built around a deployment platform as a service, most of the work invested is actually trying to make money. Web frameworks, especially the most popular ones, should get shaped and move forward by the community. Once again, all the big companies are hosting and heavily investing in the big 4 cloud computing platforms (Azure, AWS, GCP, and Cloudflare).

As a logical assumption, most of these platforms are shaping their strategies around the needs and the investment of their bigger customers, and most of the time, your infrastructure needs won't be the same as the ones that a Fortune 500 company has. That's why these platforms tend to be so bloated for the common user and that's also why probably if someone has to deploy a service to AWS, it's almost certain that they might need to hire "AWS expert." Complexity and corporate bureaucracy have created a whole new industry.

Finally, we could also argue that since even for a small project, the bill can get up to a few thousand dollars per month, an equal distribution to the smaller hosting companies can push forward better services and a more flexible and sustainable ecosystem.

You Can Get as Complex as You Want

Developers tend to be attracted to complexity like moths to flames. It requires lots of effort to keep a system, and especially a deployment infrastructure with lots of moving parts, lean, well-documented, and established in a way that makes sense, especially as it evolves over time. In a nutshell, you don't have to overcomplicate your infrastructure setup from day one. As you get more users, you might need to reconsider your needs and your deployment and scalability strategy.

On the other hand, it's hardly unlikely to build an application that's super trivial to deploy; the "Hello world" applications are for demo purposes only. Using an architecture that progressively grows with your user base and effectively with your revenue stream can actually grow in a linear and projectable fashion.

Ok, What's the Catch?

There isn't any, actually. I am not trying to sell you anything, nor promoting one hosting provider or a framework over another. While I think a self-deployment platform can be quite an investment, especially for small teams or products that are starting now, it might not be a viable solution for everyone.

It can get quite tricky to work along with systems, infrastructure, and networking. It requires lots of reading, experimenting, asking hard questions, spending money, and time.

So, this plan might not be the perfect fit, especially if you're lacking time. Some teams can't afford spending too many resources on DevOps and system management, and that's totally acceptable. Use whatever tool, methodology, and act with whatever makes sense for you at the time being; just make sure you're aware of all the options available in the wild.

Moving Along

In this first part of our series, I've tried to sum up the good and not-so-good aspects of setting up your own web applications without sacrificing quality and staying within budget.

In the upcoming episodes, we'll break down the costs of our setup, find the best tools for each job, and kick off our deployment plan based on our userbase.