How to know if it is time to use serverless architectures 

How to know if it is time to use serverless architectures 

Serverless architectures can provide significant benefits over so many traditional architectures. Here we show the main perks we can find when considering a serverless approach.

Serverless computing emerged several years ago as a powerful cloud virtualization alternative. It is basically the ability to write and run code without having to worry about any of the infrastructures that is usually needed to run software applications. It is offered by all major cloud service providers, such as Amazon, Microsoft, Google, among others.  


Serverless computing can be thought of as a function as a service, which means that the provider will have everything already set up so the development team can focus on writing the business logic. Functions will be stateless by design and will only be active when the events that trigger them are detected (a login request, site search, a batch scheduler, etc.). This means that if there is no event detected, there will be no code running and thus, no charge for your company, as payment schemes are based on functions usage. 

serverless architectures

There are no servers to maintain, size, or scale — infrastructure is automatic and elastic, which makes the serverless architectures especially useful when the workload cannot be easily predicted. Services are configured to react automatically to the workload, so if more resources are needed, the provider will escalate the resources required to handle the current load.  

Code deployments become very simple, as the only action required by the team is to upload the code to the service and activate it. Everything else will be handled automatically. Usually, vendors have a set of monitoring and logging tools, so any problems can be traced or debugged when needed. 

As with any software platform, there are some common use cases where you may benefit from using a serverless approach. There are also some advantages and disadvantages. Let’s talk briefly about them. 


  • Event-triggered batch processes: This is a good example where you may benefit from a serverless approach. Code does not need to run constantly, and performance is usually not critical. 
  • Mobile applications backend processing: In a heavily client-based application, a set of backend services can be implemented using serverless functions and have them configured to respond to events from the application, such as login, site search, and authorization. Most providers also offer an API gateway that can be configured to act as a facade for the backend functions.  
  • Internet of Things (IoT): Some vendors have incorporated a set of tools aimed to help solve most IoT concerns. The process of adding support to multiple devices, having them connected, and storing and consuming data has become simpler. This allows less skilled teams to write business logic that handles data and complex synchronization scenarios. 
  • Backend services with inconsistent traffic: This is the ideal scenario for serverless, where a dynamic infrastructure becomes a real advantage over traditional vertical/horizontal scaling scenarios. Another similar scenario would be a new service or feature where it is hard to estimate the load it will have: it can simply be launched and there will always be enough processing power if it is heavily utilized. 


One of the main benefits of migrating some applications to a serverless environment is cost reduction. As services are charged on a usage basis, whenever the applications are not running, there is no charge. This of course may vary depending on usage, so in order to maximize the benefits, the systems need to be carefully designed with this in mind. Not every service will be an ideal fit to be migrated to a serverless environment, but the ones that do will provide a significant cost reduction. 

Another advantage is that the development team can focus more on the business itself, thus focusing on adding real value instead of dealing with deployment or infrastructure concerns. In addition, developers do not need to learn a new framework, as they can write functions using most common programming languages available. This leads to a reduction of the development costs as well. 

The operation management is greatly simplified also. There’s no need to worry about the server loads, to add or configure a load balancer, or even think of the number of servers that are needed to handle the current load. Those concerns will be handled automatically, so management will only need to look for the usage statistics and monitor any predictions made at planning time.  

Time to market is going to be another significant improvement in a serverless architecture. This is a direct consequence of having less development and DevOps effort to create, test, and deploy features to production environments. New features can be easily and quickly introduced with harmless deployments and can even allow experimental features that can be quickly turned on or off with A/B testing, for example.  

Other benefits come from the integration with other services provided by the vendor. Usually, the entire vendor ecosystem allows for quick integration among features, like database, storage, and message brokers. Using vendor tools will always provide the best integration.   


As with any platform or technology, there are some aspects that will need to be considered when planning a serverless architecture.  

Perhaps the most obvious disadvantage would be the vendor lock-in. Since every vendor has a different set of tools, interfaces, and configuration aspects, there is a part of the implementation that will be tied to the vendor specifics. The more integrated the serverless functions are with other vendor services, the more difficult it will be to migrate the architecture to a different vendor. The core of the business logic may be the same, but usually, the interfaces with other tools or even the external world will be different. 

serverless architectures

Local development of features may not be easy with some platforms, thereby pushing the development team to work directly in the cloud editors (sometimes not so appreciated by developers) or in the worst case, introducing an additional layer of complexity when testing is needed.  

Cold starts may be an issue, as some functions are “sleeping” until a trigger is received. This may cause some delays when responding to events after a long period of inactivity. Although this can be mitigated using some techniques, like carefully designing the code so artifacts are small or making frequent dummy requests to the functions, it is still something to be considered if performance is key to your application. Startup times usually depend on the language used, so that may limit the language choice as well.  

Security is another topic where an additional layer of complexity is introduced. Even though vendors will have a security implementation that can be leveraged, it is still another application to be secured and monitored. A new security implementation must be designed, and even if the vendor provides most of the required services, it is still another application that needs to be taken care of. 


A serverless architecture may provide significant benefits over a traditional architecture using servers or containers. It comes with a cost reduction — if carefully designed —, and the time to launch features to production will likely improve as well. Not every application of service is an ideal candidate to be migrated to a serverless environment — the idea would be to choose the right services that can leverage the strengths of the architecture.  

A good practice would be to migrate some services with unknown or inconsistent traffic that can communicate with other services from the same vendor, like databases or messaging systems. Start small, monitor the results, and only after that, continue to migrate or create new features. 

Comments?  Contact us for more information. We’ll quickly get back to you with the information you need.