Serverless: To be or not to be

“Serverless” is quite controversial recently. Protesting/Conservative people think this technology is slow, expensive and hard to control (due to vendor lock-in), while advocates love it because it is flexible, fast, cheap and auto-scalable without DevOps… To me, both sides are right in their contexts… in the following clarification:

• Fast or slow: obviously, in comparison with other options, serverless is slower, mostly due to its nature of cold start and connection alive keeping. But, this symptom just happens at beginning phase, and in some contexts, when we expect the functions to run in minutes (not seconds), so several seconds is not much for consideration. For example, our company has built an engine for matching hundreds of orders, and the run time duration for this task must be under 1 minute. Hence, in this case, 1–2 seconds slowing at start is acceptable. (Actually, there are workarounds to handle cold start issue.)
• Cheap or expensive: the affordability level depends on many factors such as usage frequency and value of the function itself. If you use serverless for CRUD, it may be expensive, but if you use serverless for some kind of commercial apis or critical parts of your system, it’s totally worthy. In other words, serverless may not suit for high volume tasks such as transaction/crud apis, but impress in high value, high volatile demands. Moreover, think about other expenses such as maintenance/monitoring cost where non-serverless can take you more labour time than you expect.
• Flexibility: polyglot programming is quite challenging, but there are many cases such as event processing, data pipeline, machine learning when we need to use multiple languages to adopt a wide range of techniques, libraries under given requirements. Serverless, especially aws lambda, propose a sweet approach that calling such functions very smoothly via its SDK, so we can build some kind of chaining polyglot functions. I know we are still able to achieve this without serverless, but it is somehow trickier.
• Control level: for large scale system, serverless may be not appropriate because it is not only hard to control/monitor/debug, but also the system performance is mostly out of control/optimize/tweak because serverless is totally relies on vendor expertise and infrastructure. But on the other hand, under shoes of a product owner, the release time/speed to ensure the product market-fit or quickly satisfy user demands is a much higher priority over hard-core dev-ops tasking. As a result, the trade-off between time-to-market and solid self-control infrastructure is accepted, at least until the business goes big enough.

So my conclusion is, depending on your priorities and your specific problem, “Serverless” would be a good choice or not. “Serverless” is just another tooling of deployment, along with other alternatives such as vm, container, kubernetes, etc… If you use the right tool in the right place, you would maximize system performance and stakeholders’ requirements at the same time.