Many developers see AWS Lambda as the serverless path of the future, eventually leading to NoOps -- automating...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
the underlying IT environment to remove the human element of an IT team.
But, as with many new technologies, including the move to cloud, many enterprises are unsure how a serverless computing architecture will benefit them, and they remain unwilling to implement the organizational and financial changes necessary to go serverless. Instead, they opt for services such as AWS Lambda to solve back-end problems with traditional cloud deployments, taking management tasks away from developers who are freed to write code, while the service handles the underlying resources. Developers using AWS Lambda can alleviate application traffic, for example, or send text alerts when a certain event takes place in the cloud. But not all businesses are making the leap and using AWS Lambda.
Still, some savvy enterprises are taking a more heavily integrated approach to using AWS Lambda. Localytics, a Boston-based mobile engagement platform that focuses on analyzing mobile and web application usage, depends on a host of Amazon Web Services' offerings, including AWS Lambda, DynamoDB and Elastic MapReduce, to deliver services to customers. We spoke to Mohit Dilawari, senior engineering director, about how the company uses Lambda in its cloud deployment and where AWS could improve the service.
How does AWS Lambda help you achieve your IT objectives?
Mohit Dilawari: We have been an early adopter of Lambda for a while. The first Lambda [implementation] was while it was in beta; we were using [AWS Lambda] to process some of our event streams. Part of our offering is to give straight-up analytics on app usage. What we end up doing is processing data points or events from mobile apps within Amazon. We use Lambda as a way to process some of that data to glean interesting information about users.
We've connected Lambda to Kinesis. What we're putting onto the Kinesis Stream is all these data points that customers send to us. The Lambda [function] processes the data points and gets intelligent information out of there and stores it onto a [DynamoDB] database. We have about 22 Lambda [functions] in production -- we have chat bots and Slack bots that we use, and we have Lambda that helps us process data [and ones] that process S3 [Simple Storage Service] files. We use Lambda to its fullest extent.
What's been the biggest challenge when adopting a serverless approach?
Dilawari: It is still a black box -- and that's the plus and minus. You go to Lambda because you don't want to deal with infrastructure. But when there are things going wrong, you're not quite sure what happened. Sometimes, log diving doesn't get you the answer you want. That is one aspect of it.
The second aspect, I would say, impacts the Slack bot integration, where you have these cold starts. There are times when, if you haven't invoked a Lambda [function] within a certain amount of time, it will take a while for the virtual machine to fire up, accept and process your request. A lot of times, Slack requests require a response within three seconds; if you're not able to respond within three seconds, you'll time out and you'll have to reissue the command. So, it gives a less-than-ideal experience on your Slack bot.
There are a lot of pros to [Lambda], but there are certain use cases where it wouldn't be my first go-to. When it comes to the Rail stack, Python, Django, even with Scala Play -- these are frameworks and tooling that have been around for many years, and they're highly optimized for building out web apps. You can do this with Lambda, but the tooling there is still a little immature, and it's a lot more work. With Lambda, it takes a little bit of time; you've got to add in authentication and piecemeal everything together.
What other serverless computing technologies did you consider?
Mohit Dilawarisenior engineering director, Localytics
Dilawari: We looked at Iron.io. We also looked at Google [Cloud] Functions. But we are an Amazon shop at the end of the day, and we trust Amazon. We have a really good relationship with them; we're not looking to add in any third parties. We don't want to put our [service-level agreements] on the line when a third party goes down. Amazon's got the huge advantage, because what they're doing, which is super smart, is building this entire ecosystem. I think they see Lambda as something that is the future of their platform. So, I think they're going to double down on this, or triple down on it.
How complex is it to tie other services with Lambda?
[Serverless] released Java Lambda as well. That's extremely exciting for us, because we are a Scala shop, and we'd love to continue writing Scala. Scala definitely works well when writing in the Java ecosystem. Some of our use cases don't need an API; they're S3 notifications. So, we can still leverage Serverless for that.
Are you worried about AWS lock-in with Lambda?
Dilawari: With a framework like Serverless, if we were to move to Google or anything else, I think we'd be able to migrate over. I don't think it would be a transparent migration, but I think you can move over. I wouldn't be as worried about that.
How to configure AWS Lambda functions
Visualize Lambda deployments with a graph database
Generate an HTTP response header with Lambda