March 7, 2025|10:41 am
Serverless Computing
Serverless Computing & AWS Lambda, The Paradigm Switch
Amazon Web Services, AWS, is a leader in the field. Their definition of serverless sounds: “Serverless Computing most often refers to serverless applications. Serverless applications are ones that do not require you to provision or manage any servers. You can focus on your core service and business instead of OS, OS patching, provisioning, right sizing, scaling and availability.”
Serverless Computing is thus a model for running services or code in the cloud where the supplier dynamically allocates resources. Despite the name, servers are still used in the background, but all management and resource planning of these are done by the cloud provider. The developer does not have to worry about keeping track of the servers running the code, whether it’s when developing the code or when it is taken into operation. As a business, you simply get more time for your product and can focus on what gives value to the customer and the user.
In addition to not having to allocate and administer individual servers, physical or virtual, serverless computing is even more in line with most modern thoughts about system development where features or services are broken down to being standalone and scalable. The term microservices is the one commonly used to describe the thought behind.
THE BENEFITS OF SERVERLESS COMPUTING:
It lets you focus on the important thing; your product or service. Benefit from a platform without thinking about infrastructure and improving the productivity of developers. Get more time to focus on business goals and create products that reach the market faster. – It is easy. As a developer, you do not need to manage servers. Also, do not install software that should then be maintained and administered. No infrastructure or settings. These are work moments that in many cases are time consuming.
- It is cost-effective and provides better cost control. As a company, you pay only for the resources you use. Data processing without server is event-driven and resources are allocated as soon as they are triggered by an event. You are only charged for the time and resources required to run the code – through sub-session debit.
- It saves time. Working serverless is also much more time efficient. Both for the company and the customer. As I said earlier, it also contributes to the emergence of new products on the market.
- It is flexible and scalable. Your application will be scaled up automatically. It may be that some function takes more power, so the platform looks like it just gets more resources. With a more traditional architecture, you have to scale up the entire web service. There will also be more seamless connections between the different functions.
- It is reliable and safe. You get access to a robust, accessible and secure IT environment when needed.
- It is easy to build intelligent solutions. In serverless, there is built-in Artificial Intelligence within reach of developers.
PLATFORM AND SERVICES IN SERVERLESS COMPUTING
There are several different implementations of serverless computing. The main example today is AWS Lambda with about 70% market share, but Microsoft has Azure Functions, Google has Cloud Functions and Apache / IBM has OpenWhisk. AWS Lambda supports many application and backend variants, allowing you to run code without having to configure or manage servers. Languages supported in Lambda include Node.js, Java, C #, Go, and Python. As a company, you only pay for used resources and AWS measures the computing power you use in 100 milliseconds increments.
Combining AWS Lambda with other server-free services from AWS like S3, DynamoDB, API Gateway, Kinesis, SNS and SQS lets you create a powerful solution that has all the benefits we’ve previously watched. In AWS Lambda, there are also opportunities to integrate intelligence in the form of services such as Amazon Recognition, Polly, Translate, Lex or Transcribe in your apps.
AWS Lambda and serverless computing are used today in all types of industries and in all types of solutions. AWS itself points to, for example, iRobot with its over 20 million sold robots where the underlying platform is based on a serverless architecture based on AWS Lambda and AWS IoT or Thomson Reuters solution to handle and analyze over 4,000 events per second through Amazon Kinesis and AWS Lambda. See more case studies from AWS here.
No brainer, however, is that you can start with serverless and grow into it. Move individual features from a traditional platform to AWS Lambda or utilize server-less services when new features need to be used. Most importantly, serverless from now on is included as a platform to use the same as virtual machines or containers made earlier.
RECENT BLOG
Failure modes and rate of failure
Even though this all started with latency injection as in Yan Cui’s articles, latency is far from the only possible failure we can have in our serverless applications. In failure-lambda, failure-azurefunctions and failure-cloudfunctions there are now five different failure modes to choose from:
Identify Weaknesses
Injects latency to the executed function, controlled using a minimum and maximum span of milliseconds. This can for example be used to simulate service latency or to test and help set your timeout values.
Exception
Throws an exception in the function. Helps you test how your application and code handles exceptions.
Status code
Your function will return a status code of choice, for instance 502 or 404 instead of the normal 200. This gives you the possibility to test what happens when there are errors.
Disk space
Will fill your temporary disk with files to create a failure. If you’re using disk to store temporary files you can test how your application behaves if that disk gets full or you are unable to store to it.
Blacklist (courtesy of Jason Barto)
Blocks connections to specified hosts. Use to simulate services or third parties being unavailable.
All these failure modes can be used together with a rate of failure that you set. The default is to inject failure on every invocation but in reality, it is likely that for example a third party is unavailable on 50% of the calls made to that host or that an exception is thrown on a quarter of the invocations. Setting rate will allow you to achieve this.
