The Great Divide
Serverless vs Frameworks architecture has to be one of the most talked about topics in the office. It’s contentious and sparks massive debate when discussed in open since both architecture types have evangelical proponents – this radicalization of certain technologies occurs too often in our industry.
Choosing the right architecture and tools in software development for enterprises matters. Note a slight nuance in this post, we refer to “framework” architecture here, assuming these services are deployed on a persistent server for argument’s sake.
We’re here to help readers understand how the industry arrived at the current state-of-the-art, explain the differences, advantages, and limitations of serverless and framework based architecture. We hope this blog enables readers to make informed decisions, because there should be an easy, meritocratic guideline for choosing the right path given your circumstances. Don’t be misled by strong vendor marketing… your software assets and depend on it.
First off – how did we get here?
An origin story
Remarkably, the concept of cloud computing was first introduced in the 1950s by IBM. At the time, universities and enterprises were able to utilise large-scale hardware for the mainframe through a “server room” where access was enabled by a “dumb terminal” – designed solely to facilitate several users accessing the mainframe. This was the first time shared access to compute resources was possible, which enabled better cost management of expensive physical infrastructure (yeah, the CFOs of the world can propagate to great tech innovation).
The first “virtual machine” OS came about in the 1970s again through IBM which allowed sysadmins of its System/370 mainframe to run multiple virtual systems on a single node. This is where the idea of “rented hardware” came about.
In the coming decades, personal computing became popularised, cheaper and prolific, giving rise to client-server architecture. Hardware was compartmentalised into one device to include CPU, memory, hard drives, motherboard and USB devices.
In 1985, the first “framework” came into existence with Apple’s MacApp for the Macintosh. This was originally written as an extended object oriented version of Paschal and later written in C++. Increasingly advanced GUIs prompted the necessity of frameworks as PCs developed and became mainstream as frameworks promoted standard structure for applications.
Then in 2008, Google App Engine gave rise to the concept of cloud based execution models, known as “serverless compute”. Amazon followed suit in 2015 with Lambda.
Why had both of these technologies come into existence?
The question of should shift from “why” to “where” the compute was happening. This was at the forefront of every developer’s mind. In 1999 the first Saas company was born. Developers could create software hosted and executed in one place, delivered over the internet to your personal computer.
Fast forward to 2023.
Understanding Serverless Computing
Serverless computing is a cloud-computing execution model where the cloud provider manages the server infrastructure.
The mega-vendors we were talking about earlier that provide serverless services include AWS Lambda, Azure Functions, and Google Cloud Functions. Some more niche, but growing providers include: Cloudflare Workers, Vercel, Netflify Functions.
What’s to like about ‘em:
- Scalability: Automatically scales with the application load.
- Cost-efficiency: Pay-per-use pricing model, no charges when idle.
- Reduced operational overhead: No need to manage servers or infrastructure.
What’s not to like about ‘em:
- Cold starts: Delays in execution while the server initialises.
- Debugging and monitoring challenges: Due to the lack of traditional infrastructure control.
- Vendor lock-in: Dependency on specific cloud providers.
Understanding Frameworks
Frameworks are software libraries that provide foundational structure to develop software applications. Think of these as the scaffolding and prefabricated parts for building a house. This article assumes that these frameworks are deployed on traditional server-based infrastructure, where developers are responsible for managing and maintaining the servers themselves.
Examples: Express.js for Node.js, Django for Python, Ruby on Rails for Ruby.
What’s to like about ‘em:
- Rapid development: Pre-built components and structures speed up development.
- Community support: Large communities offer extensive resources and support.
- Ecosystem and integration: Rich ecosystem of plugins and tools.
- Open source: community developed and enhanced, for free.
What’s not to like about ‘em:
- Learning curve: Can be steep for new developers.
- Framework lock-in: Code may become dependent on the specific framework.
- Potential overhead: Some frameworks might be too heavy for simple applications.
Comparative Analysis: Serverless vs. Frameworks
So what to use? Well, there is no clear winner. Let’s break them down and compare key drivers for choosing one or the other method of development.
- Scalability: Traditionally, serverless offers automatic scalability, while frameworks require manual scaling. However, we will discuss hybrid infrastructure later which deals with this issue.
- Performance: Serverless may have issues with cold starts, whereas frameworks provide consistent performance.
- Cost: Serverless can be more cost-effective for sporadic traffic, frameworks could be better for predictable loads.
- Development experience: Frameworks offer more control and flexibility, while serverless simplifies operational management. Serverless is quick to get started with. You can immediately deploy a Python script for example. However, these codebases usually blow up in complexity. They become unfeasibly challenging to manage over a long period of time and lack structure. This is why enterprise use-cases usually will defer to frameworks.
- Use case suitability: Serverless is ideal for microservices and event-driven architectures, while frameworks excel in traditional, long-running applications.
You can use both.
Framework within Serverless Functions:
- You can deploy applications written using a framework (like Express.js for Node.js, Flask for Python, etc.) within a serverless function. This approach lets you leverage the rapid development and structured coding benefits of frameworks while enjoying the scalability and cost-efficiency of serverless.
- For instance, an Express.js application can be deployed as a single serverless function on AWS Lambda, allowing each HTTP request to trigger the function.
Leveraging Serverless for Specific Services:
- In a more traditional, server-based application (possibly built using a framework), you can offload specific functionalities to serverless functions. This is useful for tasks that are event-driven or have variable traffic patterns, like image processing, data processing after a database update, or handling asynchronous tasks.
- This hybrid approach enables you to optimise costs and performance by using serverless for suitable parts while maintaining the overall architecture with a framework.
- This repo will also probably explode over time, and will require some kind of structure (eg just rolled into the framework)
Insurance pricing calculator use-case:
An example of such a solution we created for a large insurer where we leveraged serverless microservices within a framework to implement an insurance pricing calculator. The main application houses smaller, more light-weight pricing models running in a separate serverless endpoint as a separate microservice. This is compute efficient as not all models are needed at all times, and spun up when called.
Orchestration and State Management:
- For complex applications, especially those involving workflows or state management, frameworks can be employed to manage these aspects, while serverless functions handle the execution of discrete tasks.
Case Studies or Real-World Examples
Start-up case study:
Serverless might be ideal for managing inconsistent load and costs when a company is starting out. Nevertheless, we see that there is a case to be made against *serverless* architecture as the complexity becomes challenging to manage and transfer knowledge as the team grows.
When building for startup clients, PYGIO teams will leverage a commonly used framework to:
- Scale teams: having a widely used framework as the foundation for new builds allows us to hire quickly. New joiners can hit the ground running.
- Develop features rapidly: structure allows developers to spend more time on coding tasks.
Scaling up to enterprise case study:
Frameworks are useful for some of the larger enterprises we work with. Often these enterprises have their own servers to sweat. It’s clear that they have a good understanding of their traffic, so cost management is easier when using a framework. Some enterprises of course believe in this so much that they develop their own frameworks.
Enterprises may use a combination of both to assist with inconsistent loads – leveraging serverless for certain microservices. This helps:
- deploy new services efficiently, but
- can be challenging to find talent and scale teams.
Example:
At Beam, one of our projects which started from scratch, we’ve been using serverless endpoints to host our models (and thus saving cost), but as we scale, we’ll upgrade to persistent server instances (to accommodate more scale and real-time requests). We are now catering for enterprise level real-time request volumes).
The Future of Serverless and Frameworks
Serverless evolution:
- Serverless providers have started to support container images, increasing flexibility and control for developers.
- Container support enhances custom runtime usage, dependency management, and aligns with DevOps practices.
- Strategies like extended instance warming and AWS’s Provisioned Concurrency reduce serverless cold starts.
Framework evolution:
- Serverless-first development approach: New frameworks or versions of existing frameworks might adopt a ‘serverless-first’ approach, where the default assumptions and design patterns are aligned with serverless paradigms (e.g., statelessness, event-driven architecture).
Be sure to pick your architecture right upfront. This is why having an experienced practitioner is key to optimise short term and long term strategies.
More articles from the PYGIO team:
