AWS, Lambda

In modern application development, the clock can be your biggest enemy. User expectations are sky high and change rapidly, technology evolves quickly, and backlogs are not getting any smaller. This means that getting functionality out the door is important, as is removing the barriers to doing so. That is why tooling that improves time-to-value is a crucial consideration.

AWS Lambda (the serverless computing service on the AWS cloud) is one such tool. Lambda provides a solution not only for delivering software more efficiently, but also more quickly.

Here are some key ways in which AWS Lambda accelerates Time-to-Value:

Reduced Operational Complexity

AWS Lambda falls into the category of “serverless code,” which means the underlying infrastructure is invisible to the developer. It is the extreme form of Platform-as-a-Service (PaaS), where what matters is code quality, not where it runs.

If DevOps or Ops teams have proper Identity and Access Management (IAM) Roles set up, then they get to sit back, relax, and let the developers work, which means security is the only real point of contention/interaction that may be required prior to a developer creating new functionality.

Event-Driven Architectures

Lambda functions are created on the basis of templates, which essentially are the languages you plan to script in. Code is created in-browser, or via Zip upload. The key when you consider using Lambda is that its execution is predicated on events, which means that in order to leverage it, your application architecture needs to trigger an event that your functionality can run on. There are endless possibilities for using Lambda, but the most common use cases are going to be around operational jobs, or data-driven events such as creation of an object in S3.

The power of Lambda comes with its integration with other AWS services. The more services you have in AWS, the more possibilities you have with Lambda, because Lambda is integrated out-of-the box with AWS service APIs. For example, S3 has several code templates that relate to various actions that can occur in an S3 bucket.

As the technology becomes more common, you can imagine that use cases will expand out to where Lambda functions are talking to other Lambda functions, or connecting with other external APIs for more complex setups. 

These synergistic integrations of AWS services is where innovation is sparked and time-to-value accelerated. 

Add Functionality Without Redeploying

To get functionality to your users quickly today, you still have to consider your deployment pipeline. Let's take, for example, a web frontend running entirely on Lambda, the backend of which could have objects stored in S3 and a database in DynamoDB. The application could be a simple listing website where users can list new items. If the development team wants to add a new feature where users can upload images of the items, without Lambda they would have to integrate this functionality into an existing code base, and wait for the next deployment cycle. In that cycle, the considerations around containers, services, and compute will impact when the code is deployed—and potentially the involvement of the backend team to create API calls or events to support the upload of image files, manipulation, and retrieval.

Yet, with Lambda, developers can modify the core frontend application to allow for image upload, and create a new Lambda function that responds to the S3 event of an object being created. This event would modify the image with correct formatting and write the final blob back to S3. This would trigger another event for the frontend application to display the image for the user to confirm. This new feature could be written by the development team in a few hours and be deployed immediately (instead of having to book in a deployment in two week’s time), and users would benefit from the value right away! 

Creating functionality is one thing. Responding to unexpected changes in application behavior is something else. Because Lambda functions are so easy to get up and running, development teams can respond to potential backend issues that new functionality has created. (For example, realizing that a new feature to rank listings was launched, but there was no logging for it. So developers do not know how it’s being used.) A Lambda function can quickly be created that watches for events in DynamoDB for a new rank being added, and log the action. With Lambda, this function can be created without deploying the whole application, in less than an hour, and at the moment they realize the oversight, instead of having to go through a whole new deployment cycle and additional backend dev.

Challenges with Lambda

Serverless code is a new concept, but it piggybacks on the goals that PaaS has had from day one, and use cases for things like CRON. The limitations today as far as what you can do with Lambda are mostly around how it fits into the development pipeline. It’s less about the functionality that is available. For example, testing is not as easy, and testing of Lambda functions does not integrate directly into your standard CI test runs, but AWS has a built-in testing tool to make quick manual tests easy.

In addition, exceptions are not as easy to catch. You do not have a lot of control of or knowledge of when the function runs. And other than the console, by default you do not have much visibility of the success or failure of a run based on the Lambda function code itself. For more complex Lambda functions, you need to then consider external exception monitoring and logging tools.

Zero-Entry Barrier

Because there is essentially a zero-entry barrier to writing a new Lambda function, there is nothing that prevents developers from moving quickly to introduce new frontend functionality, or backend operational tasks to the application. This means that the time-to-value, or the rate at which functionality makes it into users hands, is much faster.

With more functionality for users sooner, development teams can experiment, and fail fast, with less risk. Developers are unshackled, and by keeping on top of the demands of the user base, satisfaction goes up. And, instead of backlogs being dragged forward by slow releases, development teams can keep pace with their innovations.

  • Benjamin Wootton

    Co-Founder and CTO

    Benjamin Wootton is the Co-Founder and CTO, EMEA of Contino. He has worked with tens of enterprise organisations on DevOps transformation and is a hands-on DevOps engineer with expertise in cloud and containers.

    More Articles by Benjamin