Serverless has been the new standard and I fell will still be the new standard for the functions and many more.

If you've heard about serverless computing and are debating which programming languages to use, the good news is that you're getting more options. The bad news is that you will almost certainly need to learn a new way of structuring your code. Serverless computing refers to a cloud computing paradigm in which users have virtually no overhead in terms of handling resources.

Instead, code is uploaded and activated in response to specific incidents, such as an image resizing feature that is activated when a user uploads an image to an online service. Developers are only charged while their code runs, to the nearest 100 milliseconds. All of the job of handling servers, containers, or other resources, including scaling with demand, is done for the developer: he or she only has to write the feature that is caused by the case.

This is not to assume that these small functions are limited to basic tasks like image resizing. The serverless architecture is well tailored to a wide variety of parallelizable functions, such as converting data fed into analytics engines and orchestrating calls to autoscaling engines. Consider Amazon's AWS Lambda serverless offering. A Lambda@Edge feature may be used to determine the type of content a web application can return to a user depending on their location and device type. Another potential use is a Lambda feature that connects AWS services, perhaps caused by Auto Scaling events or CloudWatch alerts and then calling other AWS services.

Which programming languages to use?

Some programming languages are well-suited to the event-driven model of serverless computing and are commonly supported by many of the main serverless platforms (AWS Lambda, Google Cloud Functions, Microsoft Azure Functions)."The ones that make sense are probably Node.js and maybe Python; there's also support for Java and.NET in both of these environments at this stage,"

Developers writing for serverless computing systems will increasingly use the language of their choosing. Java, Go, PowerShell, Node.js JavaScript, C#, Python, and Ruby are all supported languages for AWS Lambda functions. Google Cloud Functions supports Node.js, JavaScript, Python, and Go, but functions have an infinite execution period.

Azure Functions from Microsoft embraces a broader set of languages, including Bash, Batch, C#, F#, Java, JavaScript (Node.js), PHP, PowerShell, Python, and TypeScript, and has comparable pricing to Lambda. There's also IBM Cloud Functions, which supports JavaScript (Node.js) and Swift, as well as Cloudflare Staff, which can execute functions written in JavaScript or any language that can be compiled.

Google Cloud Run, which was recently announced, expands language support even more, allowing any language that can be run in a container, while AWS Lambda Layers enable developers to bring in additional code written in other languages.

Working with the limitations of serverless

In serverless computing, how code is organized is more critical than the language option, with code usually broken down into small blocks called functions that perform single tasks.

The latest UC Berkeley study Serverless Computing: One Step Forward, Two Steps Back outlined the shortcomings of what it called the Function-as-a-Service (FaaS) paradigm in terms of the kinds of activities that can be performed.

In brief, existing FaaS applications are appealing for clear workloads with individual tasks – whether they be embarrassingly parallel tasks contained in Lambda functions or roles to be run by proprietary cloud platforms.

Since these functions are only activated by an incident or an HTTP request, they cannot depend on providing continuous access to data each time a function is triggered. As a result, if a developer wishes these stateless functions to provide access to data or to send data between functions, external storage must be used.

Since doing so adds latency, serverless isn't always a smart option if the application requires permanent access to data.

"On a high stage, you're better off matching it to the platform's limits. If you have something that is heavily latency based or has a lot of I/O, it is best suited to another implementation architecture. You can code through them, but it's not something you want to do all the time"

Quite long-running computing activities are also unsuitable for running on AWS Lambda at the moment since and feature is restricted to running for a maximum of 15 minutes, although Google's serverless offering does not have this limitation. A Lambda function can also only be implemented 1000 times at a time, but this limit can be increased on request.

Most of the reasons you couldn't necessarily simply port current programmes from a more conventional model – say, a virtual system operating in the cloud – to a serverless platform is the disparity in storage access and how long functions can run for. Since the underlying mechanism and its limitations vary, the specification must be designed to account for these quirks.

• Many programmes written over the last few decades will expect to see a fixed disc with a filesystem on it and maybe a link to a database.

• They're written in such a way that they can't just boot up and shut down, so you have to split them up into little chunks.

Creating larger apps(Large Scale Apps) using a serverless platform

The question of whether applications will eventually be redesigned from the ground up to run on serverless platforms is still open, but Gartner's Ryan expects certain components within services to run on a serverless platform and work alongside larger, more complex applications hosted on traditional platforms in the meantime. According to Hall, developers must not only learn a new way of writing code, but also a new way of debugging them. The tools available for debugging serverless can be difficult to use and more restrictive than competing techniques for debugging conventional Apps. According to Hall, developers must not only learn a new way of writing code, but also a new way of debugging them. The tools available for debugging serverless can be difficult to use and more restrictive than competing techniques for debugging conventional apps.

simple worlds you are going to just add a new set of complexity to your architecture.

Thus, you need to clear in what you want and don't rely on any cloud you just need to learn what should it solve and cloud is just a work and never try to lock in for a single vendor only thus try writing the application and then try to solve them at a scale of cloud.

Thus choose one language

• JavaScript/nodejs
• Python
• java
• C#

and many more languages.

thank you all.