Rebuilding a CRUD application in AWS Lambda is a little bit.. not using the right tool for the job :) Actually it's a good article, I liked the read, and IMO it represents a different point of view, when thinking about serverless architecture. And I can imagine everyone starting with serverless feels the same, I was at the same page as well, I understand your pain! But...
You have to understand, and I can't stress this enough, that building serverless applications requires a very different mindset! You can't just jump in from NodeJS or whatever other language into serverless with the same approach to architecture and expect the same outcome. You have to think different, have a slightly deeper understanding of what was the intention of Lambda and DynamoDB, read some whitepapers and examples from AWS of serverless applications. And I can understand, that mindset change is awfully difficult without right examples.
I guess this will be quite a long comment, maybe it'll become an article at some point, but let's start at the beginning.
You can always direct the solution in a different way, because you are the professional here (I get it can be hard, but you're paid for being a pro!), a client can choose a stack, sure, but they should also understand the underlying implications of choosing it, which actually you've listed quite clearly here (dynamo structure, cold boot, tied logic and etc.) This article is really a perfect example when not to use serverless.
DynamoDB is a document store and you should treat it like one. I know it is called a Database, and you can do some querying there, but it's expensive and usually not needed. Sorry, should not be needed. Use another tool to satisfy those needs.
Now the logic problem - AWS Lambdas are independent, stateless, throwaway and parallel functions. They can die at any point, there can be many of them. Your logic problems, where separate lambdas have to communicate, have to be solved by using intermediates for exchanging information like AWS SQS and AWS SNS, with DynamoDB or S3 as a message store for example. On the other hand, if you're talking about libraries, all of the functions can share them, well TBH, all of the functions can be deployed from one repository without any hassle! Which leads to my next point...
You can't be deploying Lambdas one by one! That's why you might have out of date code running in Lambda. When developing serverless, API versioning becomes an important thing... But AWS provides a great tool for dealing with this problem - CloudFormation (with serverless transform aka SAM). You define your infrastructure (lamdas, dynamo tables, etc.) and deploy it all at once, then AWS takes care of everything running properly and without interruptions.
Ah, the cold start, oh how many complaints and posts and tweets about that, people pinging their lambdas. But have they ever thought about how those containers run and why are they being killed? AWS wouldn't be so elastic if they didn't. And if your lambda has a cold start constantly - you have too little calls to use AWS Lambda at all! Yes, if you're not at scale, you don't have hundreds of requests per minute at least, AWS Lambda is a waste of effort because you have to deal with bigger response times, which don't make any sense.
Use the right tool for the job! AWS serverless is awesome if used in the correct environment and for the right job. Infinite scaling is beautiful when you have thousands and thousands of lambda calls, each posting a SQS message, triggering more lambdas down the line. It works like an orchestra ;)
Sorry for the long post, but I wanted to tell that it's not as bad as it sounds from this article. The author was in an unfortunate circumstances and had to work with a chosen tool, not correct for the job, I hope my comment sheds some light.
This is awesome! Thanks for such a great comment. One of the reasons I decided to actually write a post is to find somebody who knows more stuff than I do.
This was my first experience with serverless and with AWS also (I don't count S3 and simple lambdas) and, unfortunately I didn't have anybody around to help me with the stuff, so I had only myself.
The goal of the article was to show that serverless might not be appropriate for every project in the world, but probably my mood influenced on the very text a lot, yeah.. I did end up in not the best conditions, therefore after the project my mood was not the best.
I agree about DynamoDB. Now I always say to people, that if you don't have the key to your document, you are screwed. Queries will be slow and expensive... But I could do nothing about it, so I was designing the indexes to avoid table scans at least. Didn't really like that too.
After all this and your comment, I think serverless might be great to migrate to, when you already have big enough client base, who trigger your API a lot. You won't have to deal with cold starts at least :)
Thanks for CloudFormation advice too, I wish you were around when I was working on that thing!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Rebuilding a CRUD application in AWS Lambda is a little bit.. not using the right tool for the job :) Actually it's a good article, I liked the read, and IMO it represents a different point of view, when thinking about serverless architecture. And I can imagine everyone starting with serverless feels the same, I was at the same page as well, I understand your pain! But...
You have to understand, and I can't stress this enough, that building serverless applications requires a very different mindset! You can't just jump in from NodeJS or whatever other language into serverless with the same approach to architecture and expect the same outcome. You have to think different, have a slightly deeper understanding of what was the intention of Lambda and DynamoDB, read some whitepapers and examples from AWS of serverless applications. And I can understand, that mindset change is awfully difficult without right examples.
I guess this will be quite a long comment, maybe it'll become an article at some point, but let's start at the beginning.
You can always direct the solution in a different way, because you are the professional here (I get it can be hard, but you're paid for being a pro!), a client can choose a stack, sure, but they should also understand the underlying implications of choosing it, which actually you've listed quite clearly here (dynamo structure, cold boot, tied logic and etc.) This article is really a perfect example when not to use serverless.
DynamoDB is a document store and you should treat it like one. I know it is called a Database, and you can do some querying there, but it's expensive and usually not needed. Sorry, should not be needed. Use another tool to satisfy those needs.
Now the logic problem - AWS Lambdas are independent, stateless, throwaway and parallel functions. They can die at any point, there can be many of them. Your logic problems, where separate lambdas have to communicate, have to be solved by using intermediates for exchanging information like AWS SQS and AWS SNS, with DynamoDB or S3 as a message store for example. On the other hand, if you're talking about libraries, all of the functions can share them, well TBH, all of the functions can be deployed from one repository without any hassle! Which leads to my next point...
You can't be deploying Lambdas one by one! That's why you might have out of date code running in Lambda. When developing serverless, API versioning becomes an important thing... But AWS provides a great tool for dealing with this problem - CloudFormation (with serverless transform aka SAM). You define your infrastructure (lamdas, dynamo tables, etc.) and deploy it all at once, then AWS takes care of everything running properly and without interruptions.
Ah, the cold start, oh how many complaints and posts and tweets about that, people pinging their lambdas. But have they ever thought about how those containers run and why are they being killed? AWS wouldn't be so elastic if they didn't. And if your lambda has a cold start constantly - you have too little calls to use AWS Lambda at all! Yes, if you're not at scale, you don't have hundreds of requests per minute at least, AWS Lambda is a waste of effort because you have to deal with bigger response times, which don't make any sense.
Use the right tool for the job! AWS serverless is awesome if used in the correct environment and for the right job. Infinite scaling is beautiful when you have thousands and thousands of lambda calls, each posting a SQS message, triggering more lambdas down the line. It works like an orchestra ;)
Sorry for the long post, but I wanted to tell that it's not as bad as it sounds from this article. The author was in an unfortunate circumstances and had to work with a chosen tool, not correct for the job, I hope my comment sheds some light.
This is awesome! Thanks for such a great comment. One of the reasons I decided to actually write a post is to find somebody who knows more stuff than I do.
This was my first experience with serverless and with AWS also (I don't count S3 and simple lambdas) and, unfortunately I didn't have anybody around to help me with the stuff, so I had only myself.
The goal of the article was to show that serverless might not be appropriate for every project in the world, but probably my mood influenced on the very text a lot, yeah.. I did end up in not the best conditions, therefore after the project my mood was not the best.
I agree about DynamoDB. Now I always say to people, that if you don't have the key to your document, you are screwed. Queries will be slow and expensive... But I could do nothing about it, so I was designing the indexes to avoid table scans at least. Didn't really like that too.
After all this and your comment, I think serverless might be great to migrate to, when you already have big enough client base, who trigger your API a lot. You won't have to deal with cold starts at least :)
Thanks for CloudFormation advice too, I wish you were around when I was working on that thing!