Recently updated on March 25, 2024
This article examines serverless, aka Function as a Service (FaaS), architecture and contains the following chapters:
2. What are the Benefits of Serverless?
3. What are the Disadvantages of Serverless?
4. Is Serverless GDPR Compliant?
5. When it is Better to Go Serverless?
6. Conclusion
What is Serverless?
Serverless is a cloud computing model that allows creating software without spending time developing and adjusting server infrastructure because specialized computers do it themselves.
Don’t let the name “serverless” deceive you. There are still special servers that handle all the server tackling automatically, without developers’ interference. As serverless.com put it, “Just like wireless internet has wires somewhere, serverless architecture still has servers somewhere.”
Serverless is also known as function as a service (FaaS), which describes this model slightly better.
When a usual cloud-based application is developed, a programmer should think about how a server will handle a user’s requests, how many server resources to allocate, etc. With the serverless approach, programmers can forget about the server-side and worry only about the functionality of an application.
“How does serverless work?” you ask.
To simplify, FaaS servers create individual “containers” for each request an application sends. After the request is performed, the container is destroyed.
To create a serverless application, software developers should divide its code into individual functions for a cloud to perform.
The most famous serverless providers include AWS Lambda, Google Cloud Functions, Microsoft Azure Functions, IBM Cloud Functions.
It is important to note that it is possible to create purely serverless applications – the applications that run solely on clients’ devices or use peer-to-peer architecture and are not bound to any server/cloud.
What are the Benefits of Serverless?
The serverless approach offers some great benefits. Here are the most business-relevant of them:
1. Lower Costs (with a big IF)
Serverless can be more cost-effective than the traditional cloud approach. Usually, you have to buy/rent a specific number of servers to cover the expected load, and often most of these servers will stay idle because the number of user requests is not constant. In this case, with serverless, you pay for what you actually use.
However, if a project requires substantial computing resources, serverless is not a cheaper option. Currently, it is better to rent/buy usual servers for any high-performance applications that handle millions of requests if your motivation is to cut costs.
In addition, with serverless, developers spend less time developing an application because they don’t deal with the infrastructure and will not worry about scaling the servers’ capacity in the future. As a result, the overall costs can decrease quite significantly.
Why buy 1000 servers to cover all possible scenarios, if you can simply scale on the run and pay for what you actually use.
2. Better Scalability
The serverless model allows for better scalability because your team will not be concerned with adjusting and tuning servers when the number of users grows. Overall, you need a smaller team to support your serverless application and make it grow as your business grows.
Also, you will not have to buy/rent additional servers to scale, which is always a hassle that can cause a lot of inconveniences.
3. Increased Productivity
Overall, with serverless architecture, your software development team can spend more time on UI/UX and an application’s logic to make the piece of software more appealing to a customer and more efficient. At the end of the day, your customers do not know what is going on under the hoof, so the developers can focus more on the attractiveness of the application.
However, developers need a slightly different mindset when developing a serverless application due to its specifics, which may cause some frustration during the initial stages.
4. Reduced Time to Market
With serverless, a product goes online much faster as it decreases the friction of the server-side hustle. Yes, programming for serverless requires developers to have a slightly different mindset and get used to a new programming paradigm. However, afterward, everything becomes so smooth that it is often difficult to go back to the traditional server-based development.
What are the Disadvantages of Serverless?
Serverless is a fairly young architectural approach with its share of weaknesses. However, FaaS is being constantly polished, so some of the below-mentioned disadvantages may disappear soon enough.
1. Limits
If you work with serverless, you need to consider task memory and processing power limits imposed by a provider. Therefore, in the case of an unpredictably heavy load, some tasks will not be executed within the given timeframe.
2. Latency
Serverless platforms keep rarely-executed functions “at the back,” shutting them down. It means that when such a function is invoked, it will need some time to start. This time can be quite substantial, which will result in a latency increase.
3. Migration (Vendor Lock-In)
A third party that provides FaaS services has complete control over the server environment. Also, serverless platforms have unique features and characteristics, and an application needs to be coded to fit the chosen cloud. This means that it is very complicated if not impossible to migrate to another platform; developers will have to rethink and rework an application if migration is required.
4. Testing is Pain
Not bothering about server-side infrastructure is great until it isn’t.
Unfortunately, conducting quality assurance of the serverless applications falls under the latter category. There are several layers to this problem:
1) Local Testing. In order to test a serverless app locally, you need to replicate a serverless environment on the local machine. Most of the top vendors provide tools that help achieve this, but the tools have their limitations.
2) Integration Tests. Integration tests are complex and expensive. The units that need to be integrated are smaller and more numerous. Therefore, with serverless, you will have to run plenty of cumbersome integration tests.
3) Debugging. To hunt down the root cause of a problem, testers and developers need to rely on logs more because a classic runtime debugger is not available.
4) End-to-End Testing. Considering, mentioned above, serverless is overall a bad match with end-to-end testing.
In the IT world where quality assurance plays a pivotal role, such testing complications can be a major issue.
Security
Your serverless application is as secure as the vendor’s infrastructure it is running on. There are not OS-based security features that developers can control, only unportable, platform-specific are. Also, a serverless app consists of many smaller units each of which can be used as an entry point to the system.
GDPR
Everything is not so unequivocal with GDPR compliance in the serverless world. Anyway, this topic deserves a separate chapter. So…
Is Serverless GDPR Compliant?
Yes… kinda, but developers should put an effort into achieving GDPR compliance with the serverless approach.
GDPR disrupted the world of IT and bent a lot of companies to its will by the power of terrifying fees. Serverless appeared in somewhat of limbo because of the GDPR because the access to the information and an ability to manage it or provide users with the requested data is limited.
The developers need to ensure that the app’s users will have
1) The Right to Data Portability. A user has a right to have a copy of all personal data you store.
2) The Right to Be Forgotten. A user has a right to have his personal data deleted.
3) Privacy by Design. The security policies should be taken into an account from the earliest stages of development.
4) Notifications about Breaches. All breaches must be reported within 72 hours.
Even though FaaS providers have tools that help achieve a GDPR-compliant result, developers still have to minimize risks by ensuring that a project
– Doesn’t store everything. Analyze what data exactly you need to store to minimize risks.
– Makes it easy for users to delete their data.
– Deletes obsolete data.
– Ensures that you get clear consent from your users regarding using personal data.
– Makes sure that no third-party has access to personal data.
– Logs everything.
All in all, different serverless vendors require different approaches to achieve GDPR compliance. Therefore, there is always a necessity to examine the chosen provider attentively and plan development accordingly.
To conclude, if a project deals with sensitive data, it’s better not to use serverless.
When to Go Serverless?
The number of mentioned disadvantages may scare you away from serverless but don’t do hasty judgments. In many cases, the disadvantages do not outweigh the benefits and conveniences of the FaaS. In reality, serverless is a saving grace for many companies, which otherwise will struggle with server and overhead costs.
For instance, Netflix uses serverless to manage its video uploading, backup management, and some security features; and Coca-Cola uses serverless for its vending machines.
However, the question of when it is better to use serverless is a tricky one. As a young technology, serverless has not gained its legs yet. It evolves and changes.
Therefore, it is impossible to unequivocally claim that a hypothetical project “X” is completely suitable for serverless while a hypothetical project “Y” is not. The final decision depends on the circumstances, context, and predictable future of a project.
However, considering the current state of serverless, some general recommendations can help make such a decision.
Serverless is NOT an optimal decision with
1) Tiny projects. Small and simplistic applications that do not require much time to code better stay with traditional architecture. You would not be able to save many resources as developers will need to learn new frameworks and get used to a new programming paradigm for a tiny bit of coding.
2) Humongous high-performance projects. Applications that will need to process millions of requests will be more expensive if serverless.
3) Projects that deal with sensitive data. If you can’t risk giving access to data to third parties, then don’t.
4) Projects that will migrate. Migration is pretty much impossible with serverless because of the vendor lock-in.
5) Highly secure projects. Applications that require meticulous and highly-customizable security are not the best match for serverless.
At the current stage of the technology’s development, the projects mentioned above are not the best match for serverless because it may lead to increased costs or undermined security of the applications. Therefore, it is better to use serverless for middle to big projects that are not high-load and do not deal with sensitive data.
Therefore, serverless CAN BE an effective option if you have a project that corresponds to the above description and
1) Can be broken down into individual functions, which are active most of the time. Functions that are mostly idle will increase latency when invoked.
2) Has functions that require a short period of time to run (For instance, Lambda allows for a maximum of 5 minutes)
3) Will often scale.
For such projects, FaaS can be a real game-changer.
Deciding whether to use serverless is not the easiest task, and it requires a clear vision of a project and software development expertise.
Conclusion
Serverless is not a perfect match for every project out there. However, when the serverless architectural approach is relevant, it decreases costs, allows for unprecedented and smooth scalability, and increases productivity.
Even though serverless is not a fully established technology and has its downfalls, it has a bright future ahead. With each upgrade, FaaS platforms become more efficient, intuitive, and convenient. Perhaps some time into the future, IT professionals would not be able to imagine their lives without the serverless and smooth development process it grants.
As for now, we should carefully consider the specifics of a project and our goals to get the maximum benefit out of this disrupting technology.