This is the topic of the tech stacks we should pick for our architecture. I still want to show my perspectives even thought we can find many articles about pros and cons of lambda.
I have been working on both lambda functions and ruby on rails. I found that lambda function is so good. But I have to re-write my code even thought copy and paste.
Lambda
Pros:
- The biggest pros is we only pay for what we use.
- Saving money. If a lambada function is serving the api gateway and users don’t request anything, AWS won’t cost us.
- We don’t have to do devops, just focusing on writing our code. We event don’t care about blue green deployment. AWS does it for us.
- Auto scale the instances to handle massive load.
- It has cloudwatch integrated for tracking logs.
- Can develop by many programming languages.
Cons:
- Re-write the code for each lambda functions. This is what I don’t like.
- Spending more time on orchestrating and organizing our functions.
- Because of saving cost to it has code start. It rebuilds docker image if a new request comes after long time not received any. I encountered this issue when the tablet in a vessel sends request to lambda (via gateway) and failed due to timeout. Because the internet in vessel is not really stable so it requires more time for message to arrive the gateway. It takes every more time of latency when aws build images for lambda. This API request would be failed due to timeout.
Ruby on Rails
Cons:
- We can use fargate for severless or just use EC2 for on-demand. Cost.
- Can save money with fargate as lambda. It depends on the time consuming due to cold start. It takes even longer time than lambda. Consider using EC2 instead. Cost.
- Need to do devops. If using fargate, we need to lauch ECS cluster, setting containers up, building deployment pipeline.
- Services might be coupling.
Pros:
- Re-use the code – speed up development time.
- Writing clean code using design patterns, best practices, many gems support.
To sum up, for lambda:
- We should use lambda for the processes not affected by cold start.
- Using it for asynchronous processes, even driven architecture.
- The processes run in short period of time, not regularly.
- Minor additional services. Sometime we don’t want to add extra code to current code base.
- Small service so we can code faster and use lambda for efficient cost saving.
- Do not use lambda for massive service because it requires more development time and it works regularly in long available time, not take used of lambda pros. Writing more code, taking more time to write additional code due to logic connection.
Because in this article, I compare between lambda and rails which I know best so I prefer to combine them in an architecture. I use Ruby on Rails for medium services that requires good, consistent logic and fast development. I let lambda handle the smaller asynchronous services with even sourcing.
I actually know that we can deploy rails to lambda function. If you used to do this, please don’t hesitate to tell us your points at comment below.