Paul le fou blog

Dependencies

[ERROR] Runtime.ImportModuleError: Unable to import module 'app.main': 
libc.musl-x86_64.so.1: cannot open shared object file:
No such file or directory
Traceback (most recent call last):

That is a complete log that you can see once you deployed your python app. If you google this the answer will be as the first entry in amazon docs. The more you read, the more insane it’s sounds to me.

To fix this problem they suggest 9 steps, which include creating a EC2 instance with the same operating system that your lambda runs on, which is famously known and run by pretty much every computer Amazon Linux 2 AMI or the Amazon Linux AMI. (no joke)

This error occurs if your python code failed to find a dependency that you need. And to fix it you need to use 2 proprietary amazon services and both of them run (lambda) or should run (EC2) proprietary operating system. Now, even if it is cheaper right now (which I’m not sure) how easy do you think it will be to move this piece of logic to some other cloud providers or host it yourself? Or as a developer, how convenient is this dependency management? At least they could’ve said which dependency caused a problem…

How do I run it locally?

Technically, it is possible. They have some tool called sam. And for azure (using their tool) I even was able to run it locally. I think you can make it work with aws too. But that’s not what I see most people do.

Most likely, you would see tests. The typical workflow would be like this. Deploy lambda that just prints what it receives, write a business logic based on what you’ve seen in the logs, cover it with tests. I swear, I thought this was only me, but no, pretty much everyone whom I know does that.

And even if you’d be able to run it locally, which is a pain in the ass (see if you can find a tutorial on how to run locally existing lambda), what you will see is that you are using shared resources.

So if you use SQS in your lambda, and you’d connect to your dev environment, be ready to see other people messages in this queue. Of course, you could create an env per developer (sqs, dynamo, aurora and what’s not), the lambdas cheap anyway, right?

Much more convenient than docker-compose!

Why do I need them anyway?

The main selling point is that you don’t need to worry about infrastructure, and you can jump ahead and start developing business logic to bring the value to the product.

I’m not sure that I’m sold on that. You’d still need a CI/CD like with any typical app, you’d still need to set up database (unless you decide to use a managed service, that you can use on your typical app, but should not really), you’d still need to create a sensible app layout, arguably it’s even worse in lambdas because you tend to write everything in a single file and as a complexity grows you have to move things around.

The only thing you are actually cutting on is, really kubernetes, which is a fairly complex stuff, so yeah, there is a benefit if you look at this way. But do you need it at the beginning?

If you have a docker-compose file, the development is much more convenient, you have more power and better understanding about your application, and it’s not hard to modify this file to use as a deployment for docker swarm.