AWS Lambda is essentially Functions as a Service or FaaS platform of the AWS. The AWS Lambda refers to a computing service which enables you to run codes without having to provision or manage servers. However, it is not synonymous with server-less computing as many argue. The Lambda will execute the code only when it is needed and it scales up automatically. You only have to pay for the computing time and there are no charges when the codes are not running.
So, the main idea behind using the AWS Lambda is you get to upload and run app codes without any administrative oversight. It will look into your app’s scalability and it can offer high availability. Like the AWS Lambda, other reputed cloud hosting providers such as Google Cloud and Microsoft Azure have also come up with server-less platforms.
- When you are planning on creating a Lambda function you can choose to develop it from scratch by choosing preconfigured templates or using some functions which some other user had earlier uploaded to the app repository. When you wish to create a common app or service you are likely to find implementations which you can borrow from. So, you need not re-invent when you have an option to borrow. So, it is possible to ship an app which uses Lambda functions by simply using a template and then changing a few variables or parameters.
- A strong reason to use server-less functions is freeing yourself from managing back-ends. But, when the Lambda function uses much of the container’s CPU or memory or it uses the underlying file system of the host you need to specify the resources. FaaS providers have also begun to make SLAs; the AWS has also accordingly released one which assures 99.95% availability for each AWS region. This feature shows that Amazon is committed to this service and it also suggests that more businesses will be adopting the Lambda functions for their development.
- When you start an AWS Lambda function it will need some time to get activated. This initial runtime has been referred to as “cold start” and the subsequent runs are not going to need a cold start; they will therefore be quicker. When you leave such functions inactive the AWS shuts them down eventually. So, you will again go through a cold start when you run it the next time. You may even reduce effects of cold start by making the functions small and reducing multiple dependencies. You may also use a “keep warm” method for ensuring that functions are not terminated. For instance you can use the Serverless WarmUP plugin for scheduling a “warm up” for running functions after every few minutes.
- While the FaaS model can change ways in which one deploys apps, it is also important for you to change the way in which software is written to adapt to such a model. AWS Lambda will use concurrency for scaling up functions. In the traditional apps, engineers needed to plug functions into a framework for running parallel requests. But with Lambda, concurrency will be managed by the AWS. Automatic concurrency implies that you must be cautious when you handle processes such as recursion. There are some elegantly-engineered functions which need recursion and in AWS Lambda when there is an outer function the AWS will have to spin up concurrent instances which may cost you a lot of time and money.
- You need to know the function limits for using AWS Lambda. For every function request the AWS will set limits on disk space, memory allocation and execution time. When the function requires greater memory or its lasts very long, it may need to be re-factored to become efficient. Alternately, you can break the function down into smaller functions. AWS Lambda will also use concurrency for scaling functions but there is a default limit for each region. So, you can expect reactions when these limits are crossed. When you work with languages which need large deployment packages, you can even hit package limits. As of now, the AWS has deployment limits set at 256 MB for unzipped packages and 50MB for the zipped packages. So, you must be alert regarding elimination of unwanted libraries and keeping the functions small. When you are dealing with a set of specialized functions you can combine these into a single function so that you do not need to deploy the same library across the Lambda environment. You can even monitor these limits using the New Relic AWS Lambda Integration.
- Finally you can use complementary services when you use the AWS Lambda. For instance you may use Cloud9 which is an Integrated Development Environment or IDE that is browser-based. Since it bundles plug-ins, SDKs and libraries, it is easier to deploy Lambda functions from this service. To integrate Lambda functions with local workflows you may use the open-source service AWS SAM CLI. This will let you use the server-less model or SAM for locally developing, testing and deploying functions before placing them in production. Another useful service is the open-source Serverless Framework which lets you develop and test the functions locally and then run these when they are ready.
To sum up, you may not need server-less functions for every task. With launch of cutting edge technologies users are going to be keen to use these to resolve old issues. The idea is to use server-less functions or services in combination with others to fit into modern architectures. So, there are many cloud users using server-less together with traditional servers in a hybrid cloud. This is because while some apps are fit for server-less frameworks, some are not.