Serverless platforms limit programming language options
Serverless computing can reduce infrastructure costs and streamline development processes, but don't assume that your programming language of choice will be available.
In software development, the sky is often the limit when it comes to technology stacks for a new project. Unconstrained by pre-existing application code, developers can generally choose the languages, frameworks, infrastructure and tools to best solve the problem at hand. But with serverless platforms, this isn't always the case.
To be fast and efficient, most serverless vendors limit their number of supported programming runtimes to only the most profitable or supportable technologies. This enables them to focus on improvements to their serverless platforms, without the added complexity that comes with support for multiple languages. But it also limits the options for developers when they attempt to move to a serverless environment and means that language choice might dictate the serverless provider they choose.
What's in a language?
AWS Lambda, the first serverless platform in the cloud, initially only supported Node.js. This set the tone for other services, such as Google Cloud Functions and Microsoft Azure Functions, which also launched with native Node.js support and not much else. While most serverless vendors have expanded their runtime support to include other popular programming languages beyond Node.js, no provider supports all languages.
Some serverless platforms and services, like IBM's OpenWhisk, offer nonstandard support for arbitrary languages through Docker containers, while others, like AWS Lambda, require a less traditional implementation to use an unsupported language runtime. But the complexity of managing a custom runtime environment counteracts the benefits.
Usually, developers' first instinct is to use familiar technologies to solve problems quickly, without sacrificing quality. In serverless computing, developers are instead driven toward vendors they trust and then select a programming language from their much smaller list of available technologies. It can be uncomfortable, but potentially unavoidable.
Know language caveats
In many cases, it may not be possible for developers to choose a serverless runtime they're familiar with.
Before developers choose a serverless programming language, they need to know its pros and cons. As with traditional application development, there are distinct advantages and disadvantages of a compiled language vs. an interpreted one. Depending on the serverless platform, interpreted languages may suffer from slightly longer cold starts. However, it's also possible to accelerate development and productivity through tests built with interpreted languages.
Remember the standard library
Consider how extensible an available language is. For example, while JavaScript may be an appropriate language to develop serverless functions, a vendor may not support TypeScript compilations. This could be a deal breaker within organizations that value or enforce strongly typed languages. Additionally, serverless functions are intended to be small and fast, so a language with a strong and efficient standard library will make a significant difference in the spin-up time of your functions.
Become bilingual
In many cases, it may not be possible for developers to choose a serverless runtime they're familiar with. Traditional languages, like C and C++, are underrepresented in the serverless computing domain, while other popular languages, like PHP and Ruby, have relatively limited support. In this instance, it is important to consider not only the maintainability and learnability of the available languages, but also the marketability of each. Always factor in growth, as the wrong choice could make hiring and training more difficult in the long run.
