Serverless architecture is “quickly” becoming the new way to deploy code and run software applications and services. First FaaS (Function as a Service) platform was offered by Zimki in 2006 which didn’t achieve commercial success, and 2 years later was followed by Google App Engine. 15 years doesn’t mean exactly quickly, but in recent years it started to gain momentum primarily since it eliminates the need for building and managing your infrastructure.
While going serverless can greatly enhance business and developer processes, like any other cloud-based service, it comes with its own set of pros and cons.
In this article, we’re going to talk about what it means to “go serverless,” and what the subsequent pros and cons are.
An Overview of Serverless Architecture
The term serverless architecture tends to cause a lot of confusion because it doesn’t necessarily mean that there aren’t any servers involved.
Serverless architecture, otherwise known as function as a service (FaaS) is a cloud-based service model that allows applications and software services to run without the need for the entire infrastructure.
With serverless architecture, your cloud service provider provides the infrastructure by using multiple machines to allocate the necessary resources and charges you for computing power required to execute your code – in general is a function describing a cost of code execution time multiple by the number of executions.
When you go serverless, there’s less of a need for human resources as well as computer power since you’ll be outsourcing rather than building your own on-premise infrastructure.
How FaaS Differs from Other Cloud Vendors
Other types of cloud vendors include:
- Software as a service (SaaS)
- Platform as a service (PaaS)
- Infrastructure as a service (IaaS)
Essentially, all of these vendors provide a service that aims to eliminate the need for server management in terms of hardware or software—or both.
SaaS allows users to use cloud-based applications, think Google apps, SalesForce, MailChimp, etc.
PaaS provides a cloud-computing base that provides a platform where business applications can be developed, run, and managed. Think Heroku or Azure Web Apps.
Cloud infrastructure services, known as Infrastructure as a Service (IaaS) allow for access to highly scalable and automated compute resources (virtual machines, storage, networking, etc.) in a fully self-service way on-demand (as-needed) without the need to buy physical hardware. Think Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure, and so on.
So, what exactly separates serverless architecture (FaaS) from the rest of these service vendors?
Basically, with FaaS, your applications are composed of individual and autonomous functions that are hosted by the provider. This allows them to run code without reserving any resources and automatically scaling up and down as the frequency for the functions fluctuates.
The Pros of Going Serverless
Having backend services provided as needed is one of the greatest advantages of going serverless. It’s one of the primary reasons many businesses and developers choose to go serverless.
Here are the rest of the pros involved that come with going serverless:
The pricing of serverless architecture is a huge benefit. Essentially, with serverless architecture, you only pay for what you use. It also gives you a real opportunity to think about optimizing your costs because it’s easy to see which parts of your systems are the most expensive and slow.
Not only does this provide convenience and flexibility in terms of your budget, but it also allows you to reduce your yearly operational costs. By only paying for the functions you use, you end up paying less in server-related fees as well as any pre-purchased capacity. With other services, you typically pay a fixed price for all resources available to you even if you don’t use them at a full scale.
Don’t forget that using FaaS comes with new responsibilities. When you are paying for used resources (time and invocations) it helps you save money. It also means that when your code is slow or it doesn’t work as planned it could end in additional and unplanned costs. You could find many horror stories about extensive costs on the Internet.
Since you won’t have to manage your infrastructure and take care of your backend functions, you’ll be free of any maintenance issues that would normally occur if you were running your server.
When you go serverless, your cloud-based provider takes care of the maintenance, which includes any updates, patches, and network and gives you the ability to easily start using new services.
One of the most favorable benefits of serverless architectures is that it’s inherently scalable. As mentioned earlier, serverless architecture was designed to scale automatically as the user base increases or decreases
Not only does this save you money, but it also saves you time and effort.
Serverless functions are by design created to handle very specific tasks which implementation could be easily changed in contrast to typical monolithic apps.
That means developers can change their code in bits (by function) or all at once to release new products. It also means that any updates, patches, new features, or fixes can be implemented quickly.
The Cons of Going Serverless
While serverless architecture is growing more popular, it’s not exactly suitable for everyone.
Here’s are the cons to consider:
Newer Security Concerns
This may sound conflicting, but going serverless can also raise security concerns.
This is because the majority of your security will depend on your vendor. The issue is that vendors typically run multiple client applications on one server at a time, which can cause vulnerabilities that lead to cyber-attacks.
Monitoring, Testing, and Debugging Challenges
One of the greatest cons with serverless architecture is that there’s no real way to see how your coding will perform once you deploy it since there’s no visibility when it comes to the backend processes.
This makes it incredibly difficult to replicate the environment of the serverless architecture, which means that testing and debugging become a serious challenge for developers.
Different FaaS implementations provide different methods for setting up logging and monitoring functions. For example, AWS Lambda allows writing logs to AWS CloudWatch, Azure Functions use App Insights that could be costly and hard to correlate with logs from other parts of your systems.
Cold Starts and Additional Latency
Serverless providers charge you by the amount of time your code is running which means that your code only runs when it needs to.
This means the types of applications you can efficiently and cost-effectively run on a serverless architecture are a bit limited.
Additionally, your serverless code could essentially need to re-boot—referred to as a “cold start”—each time it’s when it happens, causing latency. However, this is only the case for the less-used code. Regularly used functions will be kept ready for activation, but this also is a place for new additional paid services or using antipattern which requires calling the functions to keep them running all the time.
Increased Vendor Dependency
Since you’ll be allowing your vendor to provide all of the necessary backend services for your applications, this will increase your dependency on said vendor.
All vendors even if they offer the same features provide their implementation. Therefore, after initially setting up your serverless architecture with one vendor, you may have a hard time switching to a new vendor should the need arise.
Serverless architecture doesn’t make sense for everyone. In specific use cases, you could benefit from a faster go-to-market, decreased server and maintenance costs, and high scalability. When used wrongly it could also generate new challenges.