Increase development speed with Serverless
Is it worth switching to a serverless architecture? A brief essay with my thoughts on the matter.
The Serverless movement is a hot topic in the developer community, largely due to the big players in cloud computing like Amazon and Google promoting the technology. An increasing number of companies are rewriting their technology stack to run on servers not only owned, but also managed and maintained by a third party. A quick web search generates multiple articles listing the most common reasons to choose Serverless as the foundation for both simple and complex systems.
No administration when the service handles provisioning and maintenance of servers and automatic up- and downscaling of capacity based on current traffic means less time spent on configuration and payment completely based on usage. Which in turn leads to more time dedicated to business critical features and quickly getting them to the users. These are some of the most frequently mentioned reasons to use Serverless and few express any contradictory opinions.
Given that it is of great importance when developing a product to get it in the hands of customers as soon as possible in order to truly understand their needs and if the product satisfies them, as well as the company that can deliver increased value to their customers in the shortest time possible will also get the biggest market share, should the single most important advantage with Serverless be the increased development velocity, especially of advanced systems.
Furthermore, a successful implementation of Serverless thereby increases the probability of a strong position on the market, although that is not without challenge. The concept is an extension of the microservice architecture that also has become very popular, where many small applications together form a system serving the end customer. Serverless though, takes this a step further when many core features like API, user management and logging are moved to the vendors cloud platforms and offered as separate services. To get to a point of increased time savings, investments have to be made in order to set up and connect these services together. These investments can, with a team with limited experience of Serverless, in the short term be counterproductive since the development speed will take a hit. It should be noted that there are frameworks trying to improve on this by gathering services and configuration in one place.
Serverless is undoubtedly an interesting movement and can lead to large time savings if implemented successfully. However, as with any investment, there needs to be enough resources to deal with the initial cost in time that can arise in order to take part of the supposed advantages of Serverless and therefore it might not be the optimal solution for a startup of which survival is dependent on how quickly it can capitalize on delivered features.