DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workkloads.

Secure your stack and shape the future! Help dev teams across the globe navigate their software supply chain security challenges.

Releasing software shouldn't be stressful or risky. Learn how to leverage progressive delivery techniques to ensure safer deployments.

Avoid machine learning mistakes and boost model performance! Discover key ML patterns, anti-patterns, data strategies, and more.

Related

  • Building Scalable Data Lake Using AWS
  • Building a Scalable ML Pipeline and API in AWS
  • Breaking AWS Lambda: Chaos Engineering for Serverless Devs
  • AWS Step Functions Local: Mocking Services, HTTP Endpoints Limitations

Trending

  • A Modern Stack for Building Scalable Systems
  • Artificial Intelligence, Real Consequences: Balancing Good vs Evil AI [Infographic]
  • Comparing SaaS vs. PaaS for Kafka and Flink Data Streaming
  • Doris: Unifying SQL Dialects for a Seamless Data Query Ecosystem
  1. DZone
  2. Software Design and Architecture
  3. Cloud Architecture
  4. AWS Lambda’s Major Limitations

AWS Lambda’s Major Limitations

As the flagship serverless computing product, Lambda promises cheaper compute, easier architecture, and simpler development processes. But does it deliver?

By 
Ian Miell user avatar
Ian Miell
·
Updated Jul. 09, 20 · Analysis
Likes (9)
Comment
Save
Tweet
Share
17.3K Views

Join the DZone community and get the full member experience.

Join For Free

Since its inception in November 2014, AWS Lambda has been one of AWS’s most talked-about products. It’s the industry’s flagship serverless computing product, allowing customers to run workloads without thinking about the server on which they will run. Lambda promises cheaper compute, easier architecture, and simpler development processes. But does it deliver?

Lambda and Lock-In

Lambda allows you to write code in relatively small chunks that tightly integrate with other AWS services that run for a limited period, and is billed at the microsecond level. This is why analysts often place it under the Function as a Service banner.

Lambda’s tight integration with other AWS services can result in a form of lock-in that is at the root of many of its limitations. If you take a step back and think about what Lambda does, it’s obvious that any code written for it will not be portable across other computing platforms, be they on-premises data centers or other cloud providers. Tight integration with services like IAM, Amazon S3, API Gateway, or Amazon EC2 means that switching to a different provider may be impossible. It’s AWS’s way or the highway, and your application may be hostage to AWS’s fortune.

Does this matter? Maybe. You might have a regulatory need for a credible plan to move to an alternative platform (especially if you work in the financial sector). But even if this isn’t a requirement now, it’s worth learning lessons from history.

Those who remember the database wars may be familiar with stored procedure lock-in. Stored procedures were similar to Lambda in that they were effectively free to deploy to and only added to the compute load on the servers that had already been provisioned for the database. In that sense, stored procedures were a serverless platform that assumed the environment of the database they ran on. The downside was that it became very difficult to move away from a specific database provider, and, to this day, many businesses resent paying Oracle money to run their databases.

The time will likely come when AWS exercises a similar hold over your business. Is that something you are prepared to accept?

Development

At the other end of the strategic spectrum, what is it like to develop on Lambda? Because it’s serverless, Lambda can pose particular challenges to developers who are used to having environments ready to test their work.

A local environment running on your laptop can be difficult to arrange when it comes to AWS. Although options (such as LocalStack) do exist for local replication of AWS APIs, they are still relatively niche, and they are limited in their ability to accurately reflect and keep pace with the changes constantly being made to AWS.

Therefore, your best option for testing your new Lambda code is likely to set up a parallel AWS development environment. This can be costly to model and maintain, and, on top of that, you may need to develop a CI/CD infrastructure to support your Lambda lifecycle. 

Once in production, observability can be a challenge. Ironically, because you can’t log in to a server, you have to prod and poke the code from the outside to debug issues seen at runtime. The default option of Amazon Cloudwatch Logs can feel clunky and difficult to navigate. In particular, users complain that permissions and networking issues can be difficult to debug because you can’t access the server with a terminal in the traditional way to quickly figure out what the problem is.

Architecture

Before you consider using Lambda, it’s essential to determine whether your architecture is ready for it. It is very easy to fall into the trap of thinking that Lambda can solve all your AWS architecture problems — without realizing that there are still many decisions you need to make if your applications are not already running in a cloud-native way.

Using Lambda doesn’t mean that you can ignore questions about managing IAM roles and the fine-grained permissions needed to run Lambda functions safely. You will still need to think about how you use Amazon S3 or Amazon EFS if you need a persistent store for your application — and you’ll need to consider access control and networking architecture, just as you would with a non-Lambda application. The number of decisions required can be overwhelming and often reach far beyond the simplicity that Lambda seems to offer the architect at first glance.

Technical Limitations

In the context of architecture, it is also important to understand Lambda’s very real technical limitations. The maximum time a function can run is 15 minutes, and the default timeout is 3 seconds. This makes Lambda unsuitable for long-running workloads. The payload for each invocation of a Lambda function is limited to 6MB, and memory is limited to just under 3GB. These are hard limits set by AWS, so you can’t change them.

What can be changed by sending a request to AWS support is the default 1,000 concurrent executions limit, as well as the 75MB function code storage limit. There are also some complicated rules around scaling that limit Lambda’s capability to act as a web server for any service that you may need to significantly scale in bursts. For example, it will take at least a minute to cope with an increase of 500 concurrent executions. In other words, Lambda may not match a traditional web server for speed of execution and ability to scale.

Cold starts of Lambda functions (the time is taken to initialize the first run of a Lambda instance), along with the resulting latency on any response or work done for this first run, are other potential issues to consider if your workloads are time-sensitive. Amazon has made improvements in this area, but your exposure to this issue depends on which language platform you use.

Cost and Scale

At first glance, one of Lambda’s most promising features is its seemingly low cost. However, working out what Lambda will cost you is not easy. Several factors determine the cost of your Lambda functions. The first two are the number of requests made and the number of gigabyte-seconds (GB-seconds) your functions use. (GB-seconds are the number of seconds multiplied by the number of gigabytes of memory allocated to the Lambda function.)

In terms of requests, the first one million requests to Lambda per month are free (even if you are no longer on AWS’s 12-month Free Tier period). Then, you pay just $0.20 per million requests. As for GB-seconds per month, the first 400,000 are free; after that, you pay $0.0000166667 per GB-second.

But that’s not the only factor to consider. If you try to run a standard web service on top of that, the costs of API Gateway, Amazon CloudFront, AWS WAF, CloudWatch, and any other service you decide to use along with your Lambda function will start to add up. For that reason, a key consideration when deciding whether Lambda is right for you is how much you expect your application to scale.

Conclusion

Since its introduction, AWS Lambda has been a very popular addition to the AWS product range. While it holds up to its original promise of freeing application developers from worrying about server provisioning, it doesn’t give you a free pass regarding all the other things that infrastructure normally takes care of.

You’ll still need to think about the technical limitations of the product, security, identity, and access management, application delivery pipelines, developer experience, general architectural considerations, and — last but not least — cost implications. Before you take the plunge and commit your architecture to Lambda, make sure you’re ready to use it with your eyes open to these limitations.

AWS AWS Lambda

Published at DZone with permission of Ian Miell. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Building Scalable Data Lake Using AWS
  • Building a Scalable ML Pipeline and API in AWS
  • Breaking AWS Lambda: Chaos Engineering for Serverless Devs
  • AWS Step Functions Local: Mocking Services, HTTP Endpoints Limitations

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!