Myths busted about using AWS Lambda

There are many myths when it comes to using AWS lambda. It is known as a game changer, something that can reduce the development time drastically. AWS Lamdba seems to be all about simply write the code and let AWS handle the whole infrastructure.

Last year, we were in dilemma whether to use lambda to create our microservices or to use the old fashioned containers. Considering that this is the first time we were going to use lambdas, we didn’t know much of the nuisances behind it. There was a lot of pressure from the management to get the work done within the timeline because of compliance issues. We did a through analysis to determine what suits us best — containers or AWS. We ended up using Lambdas, because of 1 simple reason — its going to be faster to develop and host the application. As it turned out, that was not the case. I am writing this article to bust some of the myths by telling you the lessons we learnt hard way —

Myth 1- Lambdas do not need DevOps

Sure Lambdas will not need DevOps work if you are living under a rock or working on your personal project or working in a startup where there are no rules as long as product works. But as the saying goes — first cut of code is always easier, its the second one that takes time. If you are working in a big organisation, you simply cannot bypass the processes and add code from a S3 bucket. Code has to be audited, well documented. On top of that, it has to be checked for vulnerabilities, run test cases and other quality tools. On top of that, you need segregation of duties between CI and CD. You can add collaboration and code review to that structure. You need a pipeline around it to make it all happen. Reading code from S3 bucket is not a pragmatic solution

Myth 2 - Lambdas can replace containers

Containers are there for a specific task and as of now, Lambdas are not mature enough to replace them. Let me ask a simple question, consider following scenarios —

a. You are living in a suburb with your family and you need car on daily basis to commute to work, to pick/drop kids from school

b. You are on a holiday for few days on a remote island. You need a car to visit places

As you can imagine, first scenario requires you to have car on regular basis whereas second scenario is one off event. Renting a car on a daily basis for first scenario would be costly, whereas buying a car for second scenario will be too much.

What I am trying to point out is that there is no single solution for different use cases. Containers serve very specific purpose and so does lambdas. If you are looking for a purely computing service that does not require synchronous calls to other services and is time-bound , lambda is a good choice. However, if you are looking for a making multiple transactions or an orchestrator, then container based microservices can suit you better.

Myth 3 - Lambda does not cause additional work

Till last year, lambdas came with this particular nuisance of cold start — if you are not aware of this problem. Cold start is when lambda has not been used for a while and it needs to boot up a new instance of lambda.

In that case, it will take some time to load some libraries and spin up a new instance. For us, since we were using Springboot based microservices, lambda took time in seconds for cold start. This was not unacceptable, for that we had to write pinger that will keep on hitting lambda and keep it warm. Not the ideal solution, but that was required so that lambda does not take time in seconds.

Myth 4 - Lambda code is cloud agnostic

One of the requirement was to make code portable so that it can run on other cloud provider services such as Azure Functions. Since Lambda is an AWS service, we had to make explicit code changes to make it portable. This is entirely different in container based docker images, wherein you can lift and shift to any cloud provider.

Conclusion

I do not want to say that container is better than lambda or vice versa. It’s just that you need to understand the requirement and use the right technology. It needs to be fast, robust, easy to maintain and easy on the wallet. Because at the end of the day, solution need to solve a problem for a very specific use case. Your customers will be happy to have a secure and fast transaction, and not because you ran it on a particular technology stack !

Related posts:

Standing at a distance watching your little ones grow and become a better version of yourself can be what you are given Can be a hope you can nurture while time floats by

The Capricorn Moon was conjunct Pluto this morning when Putin announced moving Russia’s nuclear deterrent to “special alert” and, of course, the US says this is unacceptable. We also have Venus…