Built-in Drawbacks

#1. Vendor lock-in:

Serverless, in other words, means outsourcing your services to a 3rd party vendor. Moreover, that means that you won’t be having much control over many key aspects of system downtime, forced API upgrades, loss of functionality and much more.

This seems to be an inherent limitation that serverless applications face. Through multiple choice of integration patterns, APIs and documents, different vendors enforce different levels of lock-in models.

What lock-in means is that if you want to move from one vendor to another, you’ll need to update your operational tools, change your code and may even require changing the architecture. The fear of vendor lock-in is one of the major drawbacks of serverless.

#2. Statelessness:

This is a huge benefit which enables scaling easily as a matter of increasing concurrency but managing it is quite tricky. And moreover, it comes with the drawback of inconsistent performance which we will discuss later.

Apart from the components that are designed to store data, most of the other serverless parts are stateless. By definition, the information in stateless functions doesn’t persist beyond their immediate lifespan. And hence, this gives the birth to complexity while we consider the interaction of these components with another.

With the implementation of FaaS functions, you can have a code in your app but the cache is rarely of any use. As soon as your cache is ‘heated’ for the initial usage, it is likely to be thrown away as the FaaS instance is torn down.

#3. Local testing:

This is one of the most mind-numbing difficulties of serverless application architectures. In case of non-serverless applications, developers have local options on-hand where they can test the application and observer whether it will work or not during and after the deployment. However, with serverless architecture, end-to-end testing of application is quite more difficult.

Because, at present, most of the vendors aren’t providing with the local implementation which, in turn, forces developers to use the regular production implementation. This means remote testing for all your integrations. Sounds like a big deal? It is.

Because the units of integration with FaaS functions are a lot smaller than with other architecture. These typically consist of separate pieces and hence managing them is quite challenging. And therefore, we rely on remote testing a lot more than we do for other types of architectural style.

#4. ‘Cold/Warm’ start: Serverless performance is quite inconsistent

One of the most common issues is how long does it take for a FaaS function to start which is referred to as a cold start. On the AWS Lambda, this means initialisation of our code as well as initialization of our container which houses the code. The cold starts happens when lambda function hasn’t been invoked for a while or if its configurations have been altered.

Once it has been invoked, the container can handle events without going through that same process and these ‘warm’ invocations of the Lambda functions are quite faster. It is recommended that 99.99% of events should be processed by a warm container.

However, the uncertainty between ‘cold’ and ‘warm’ is difficult to predict which leads to inconsistent serverless performance issues.

#5. Security:

As soon as you consider the serverless approach, you are exposed to a whole new level of security issues which can be summed up in the following points:

With serverless, data is now in transit between various functions . Each time we transit data from one place to another, the chances of the data to be leaked and tampered with increases since the surface area increases.

. Each time we transit data from one place to another, the chances of the data to be leaked and tampered with increases since the surface area increases. With greater flexibility, comes the greater opportunities for attackers to get to your system. The only way to tackle this is to treat each function with its own security protocols.

to get to your system. The only way to tackle this is to treat each function with its own security protocols. No wonder, serverless has made the motoring extremely hard. With more number of functions, comes the hardship of monitoring them. Remember, you may create tons of functions due to its low operational cost, but keep in mind the total cost of ownership, including the increased risk of having unused, vulnerable and stale code in production.

Production Drawbacks

#1. Deployment:

The interaction between the underlying platform and the application is facilitated via API calls. Since serverless applications are, in fact, a bundle of many small individual components, deploying an entire application is typically not a good idea.

Due to this basic difference in the architecture, it is often a challenging task to align the deployments of large-scale serverless applications.

#2. Execution:

One of the publicly criticised limitations of serverless is limited execution environment of FaaS function. Unlike legacy servers, they don’t have an indefinite amount of resources and they are executed on limited CPU, I/O resources, memory and discs.

For instance, AWS Lambda functions come with an inherited memory of 1.5 GB and will be terminated after a maximum of 5 minutes. As the FaaS platform is evolving, you can expect some expansion in the execution environment. Moreover, designing the architecture within the limit of this environment will add you the benefit of more scalable architecture.

#3. Monitoring:

While you may not like the limited execution environment but at the same time monitoring of these metrics is out of your concern. However, metrics responsible for business functionality still needs to be monitored.

But the limit to which the monitoring is well supported of these functions is a mix-and-match. For example, AWS Lambda has multiple ways of monitoring can be performed but some of these are poorly documented. Also, there is a considerable lack of support at present in distributed monitoring. And hence, once all of these functions are in the commonplace, serverless systems will come off as an easy operation.

#4. Remote testing:

The ability to perform remote testing comes along with its inherent inability of local testing. This is due to the fact that certain vendors make the remote testing possible but up to a very lesser extent. For example, you can do remote testing at component level but not at the serverless application level.

It is quite exhaustive to test a series of serverless components without setting up an account with the vendor to make sure that testing isn’t affecting the production resources and also, that the limitations provided by the platform are equally met.

#5. Debugging:

At present, we are stuck on the debugging part as we have to accept whatever the vendor provides us. This might be okay in certain cases but AWS Lambda provides you with extremely basic functionalities and hence it is a big turnoff.

What we are looking for really is integration with 3rd party services for debugging and open APIs.