This content is part of the Conference Coverage: Your passport to AWS re:Invent 2016

Lambda problem stems from serverless service woes

AWS Lambda is a compelling serverless computing option, but several weaknesses and complications keep enterprise dev teams from jumping on board.

AWS introduced Lambda, its serverless service, in 2014, with some pretty compelling promises. AWS aimed to provide a way to write services that abstract the developer from necessary application processes -- making it easier to build a service and allow others to use it. But despite the compelling story Lambda has, adoption of the service has been less than stellar.

With Lambda, AWS takes away the boilerplate stuff that most developers manage when standing up a cloud service, such as a microservice. There is no need to configure subnets or load balancers with Lambda. Developers simply write the code, and AWS does the rest. However, the catch is that many businesses avoid serverless computing, opting instead for more traditional development approaches -- manually performing the entire server configuration.

Why are many companies saying "No thanks" to Lambda? AWS Lambda is not a tool, and that's the main Lambda problem. Developers want tools.

Why are many companies saying 'No thanks' to Lambda? AWS Lambda is not a tool, and that's the main Lambda problem. Developers want tools.

AWS attempts to provide simplicity, breaking up the service build into smaller and less complex steps. But, in some cases, that can extend the process out to an annoying amount of time. This is done to remove the complexity at the cost of speed. For example, if a developer wants to set up a connection between Python and Lambda, it's a 20-step process -- and that's a simple service with one endpoint and one argument. If a developer has just three services to build, it could be as many as 60 steps; developers hate that as much as running out of coffee.

AWS wants to provide building blocks that are more user-friendly. Unfortunately, those tools are not developer-friendly, and that makes all the difference. Developers can accept complexity, as long as it compresses time.

AWS also leaves connections to the resulting service up to the developer. The process for a connection uses Lambda and Amazon API Gateway, as developers need to deal with the API service to enable the whole serverless approach. Many developers claim that the Amazon API Gateway is a bit difficult to work with -- and would rather avoid it -- as 8-10 steps of the Lambda setup deal with Amazon API Gateway procedures.

AWS Lambda also lacks in documentation. For example, the documentation is unclear on what to do if an exception occurs and what the Lambda problem could be. While that could be fixed in the near future, it is annoying to developers who must switch from on-premises development systems to cloud-based Lambda and back again.

Understanding the ins and outs of working with APIs

As the use of APIs increasingly becomes a part of business strategies, developers need to know the ins and out of working with them. Take this quiz to find out what you know about APIs.

And there have been complaints about the error-reporting mechanism. Developers can run into a serious Lambda problem with this system, generating a bunch of potential errors. And it can be tricky to avoid those errors. It would be better for AWS to define the likely error and outline the processes to fix it. Developers new to Lambda can find that their Lambda-built service has all sorts of exceptions, mostly user-generated.

All these issues factor into why enterprises are avoiding Lambda, and they may continue to do so for some time. But AWS could tinker with the service to solve its Lambda problem.

Next Steps

How to configure your Lambda functions

Visualize Lambda deployments to check performance

Get Lambda to work with SQS

Dig Deeper on AWS Lambda