I would rather disagree with these practices. Some of them are subjective and some will likely be outdated soon. > Each function should do only one thing. The

I would rather disagree with these practices. Some of them are subjective and some will likely be outdated soon. > Each function should do only one thing. The problem with one/a few functions running your entire app, is that when you scale you end up scaling your entire application. Sure, but is that a problem in general? Same thing can be said about a monolith vs microservices, and there is always a trade-off. A function with a larger code-base makes the code easier to navigate; may be easier to deploy. First reason about / compare cold-start times before making the decision to break the function. > Functions don’t call other functions Is the cost of calling the other function negligible (e.g. the functions are called rarely)? If yes, feel free to do it. > Use as few libraries in your functions as possible (preferably zero) Security risk is another discussion, not related to serverless. Worry instead about the cold-start time. If it's short enough for your use case - do use libraries. Should be no problem for Go, Node is usually OK. Java - native compilation is slowly approaching. > Avoid using connection based services e.g. RDBMS If adding another library is not a problem in your case, then why not? It's not too difficult to create a pool with a single connection. As for security, there are some new options like AWS Aurora IAM authentication. No VPC needed.