Does it makes sense for your app to be serverless? As with most development decisions, the answer is: it depends. What does serverless really mean? In this article, we’ll break it down for you.
This article is part of our FAQ series that will be answering basic questions related to mobile backend as a service (MBaaS). Other articles include: “What is API as a Service?” and “What is Mobile Backend as a Service (MBaaS)?”
In its most traditional sense, “serverless” is technically a misnomer. (Just as the term “backendless” is a common misnomer assigned to backend as a service platforms; backendless apps still very much have a backend.)
A serverless application still relies on servers to run its backend, but the application developer does not own those servers or keep them on-premises.
In essence, serverless computing is a form of cloud computing in which the cloud provider runs and maintains all servers. The result is that developers can focus on building the logic of their backend and assume there will be physical resources to execute it. In other words, serverless doesn’t mean “without a server”, but instead “without a specific server”.
The serverless provider manages the allocation of machine resources. This means the provider ensures that functions and logic on the server are executed at a consistently fast operating speed by serving from additional servers when needed.
Serverless computing suits development teams of all sizes that are looking to build and deploy quickly without the distraction of server maintenance. Although serverless computing comes at a cost – the price typically fluctuates based on the quantity of resources consumed – it is often still far more affordable than internally managing your own servers.
To expand on the previous point, one of the great benefits of serverless is the ability to scale freely. With in-house servers, you will typically carry far greater server capacity than you need most of the time. This is to ensure your app doesn’t crash during periods of heavy activity. Thus, times at which those servers are unused (idle) or only lightly used becomes a sunk cost; you’ve paid for those servers whether they are in use or not.
Similarly, with cloud-based server hosting such as AWS, Google Cloud, and Azure, someone within your organization will be required to monitor server usage and spin up additional server instances when demand requires it. Otherwise, you will need to set up more instances than you need in order to be covered during peak usage times. However, unlike in-house servers that you own regardless of demand, this manual management can be automated with a cloud architecture.
With serverless, on the other hand, you only pay for the server resources you actually use. This may be described as pay-as-you-go. Additionally, serverless providers will build-in the costs associated with the servers’ operating systems, such as licenses, installation, dependencies, and patching.
When considering the cost of in-house servers vs. cloud servers vs. serverless computing, you not only need to consider the costs related to the machines, but also the cost of team members managing your servers. This cost comes in two forms: operational cost and opportunity cost.
Simply, this is what you must pay directly to employ, train, and cover benefits for an employee (or multiple employees) to manage your servers. In the early stages, a company may be able to handle server management with minimal effort from a developer. However, this still subtracts from the time that said developer can spend working on the application.
While some server management can be automated, there is still great value to having the flexibility to manually adjust server resources when necessary. Additionally, if the application is available internationally or allows 24/7 access (as most apps do), then you will want to have someone available to handle potential outages at all times. This becomes a significant drain to personnel resources.
On the other hand, most serverless providers offer 24/7 monitoring and support. Most also include an “uptime guarantee”, meaning that they guarantee the servers will be functioning as close to 100% of the time as possible.
Serverless is valuable for development teams of all sizes. Whether that team is one individual or a large group, taking development time away from a team member and dedicating it to server management is rarely the ideal use of their time.
This is not limited to startups and small companies, either. Many enterprises have development teams tasked with building new applications, new features for existing apps, or internal-use applications.
While the enterprise may already have internal servers and teams that manage them, it may still be more cost-effective to host the app’s development and testing environment with a serverless provider. That way, the enterprise’s internal resources are reserved for more essential functions, such as supporting apps that are already live and in use.
Just because a server is hosted in the cloud does not mean it is a serverless setup. On the contrary, many cloud server hosting services like AWS have a basic setup that is practically identical to keeping servers on-premises. This is because you are still responsible for all of the server setup, software maintenance, and load-balancing required. The only thing the provider covers is maintenance of the hardware itself.
AWS Lambda, however, is fully serverless.
Not all scaling solutions are created equal. In-house servers are said to be scalable because you can add additional servers to meet your needs as you grow.
On the other hand, serverless computing is said to be elastic because it enables you to both increase and decrease your machine resource usage depending on your needs.
Serverless computing does come with some potential drawbacks that should be considered when choosing your server architecture.
Some applications simply require too much computing power for a serverless provider to handle. Serverless providers may have stipulations regarding the workload that they will allow an application to put on the servers. It may also simply be cheaper to bulk-provision the servers in-house for such workloads.
It may be more difficult to identify the source of latency within your application when using a serverless provider. You may not have the same ability to use debuggers or other testing tools. You also may not be able to completely replicate the performance characteristics in a local environment due to proprietary elements of the server environment.
Hosting your application in a shared environment can create the potential for additional exposure to security breaches not possible with an in-house setup. It is important that you find a serverless provider that does not expect to be absolved from all responsibility in the event of a breach.
Some serverless providers, including Backendless, offer the ability to run your application on dedicated servers. This can help you avoid such a risk, at an additional cost.
Many serverless providers use proprietary cloud environments. Thus, you may have to allow the provider’s employees access to your own proprietary code that you deploy on their servers for maintenance purposes.
Because serverless computing is provided by a third-party, migration must be considered. If you reach a point where you want to change providers or switch to in-house hosting, you will have to navigate the migration process which can be quite cumbersome.
Backendless offers excellent support for migrating your backend from another service or host to our platform.
We will discuss Kubernetes in more detail in a future article. In the context of this article’s topic, however, Kubernetes (also known as k8s) can be thought of as a way to make on-premises servers serverless. Allow us to explain.
Kubernetes is an open-source container orchestration system. In simple terms, it is a system designed to replicate a server environment and setup across multiple servers. This serves two primary purposes:
First, with some simple automation rules, Kubernetes allows for easy automated scaling by distributing server demand horizontally among all servers included in the cluster. Second, Kubernetes serves as a failsafe for applications in that no functionality is tied to one particular server. Thus, if any one server goes down, all other servers in the cluster are capable of replicating that server’s functionality.
Backendless Pro uses Kubernetes to support easy scaling for businesses looking to maintain and manage their server infrastructure in-house.
Choosing the server architecture that best fits your business needs can a complicated task. Our goal with this article is to help you better understand the differences between serverless, cloud, and in-house hosting.
Once you understand these different approaches, you can decide which best fits your business’s and application’s needs. Backendless Cloud is our primary serverless option. Backendless Pro is designed primarily for in-house server management. Managed Backendless is the best of both worlds.
We hope that this provided some clarity about the meaning of the term serverless. If you’d like to see if Backendless is the right backend platform for your application, you can begin a free trial of Backendless Cloud here or install Backendless Pro on your own machine for a free trial.
In future articles, we will cover additional topics that may not be well understood by non-technical personnel. These include terms such as codeless programming, user authentication, and more.