So, I’m not new to Lambda, but I am new to SLS. I’ll be using it for production very soon and I’ve had the same considerations and issues. For example, when using Lambda with SQS triggers, you’ll find there are additional SQS permissions needed, which are not necessarily documented in the most obvious places and the whole process becomes somewhat trial-and-error … (see How to grant access to SQS in Serverless.yml).
In any event since these are micro-services we are pushing out with SLS, and … on their own should be simple, non-proprietary functions … I also maintain the philosophy that each of these (non-proprietary) functions should be sharable … or portable in the sense that I can give it to any 3rd party to use or develop … on their own AWS account … using what ever liberal or conservative permission scheme they desire. So in other words, just as I expect a developer to have their own GitHub account, I also expect them to have their own AWS account, which shouldn’t be an issue since there is a free tier available. It also means that I don’t have to manage other accounts for other environments. My SLS project will always include unit tests for the http endpoints, and a deployment script which executes these tests the moment sls deploy completes successfully. Your situation may be a little different … but hopefully this gives you some ideas.
Regarding the idea of what a micro-service is … yes that can be tricky, but the first thing I consider is … is this a function I can share publicly or is it proprietary. If it’s proprietary (e.g. contains specific SQL which I don’t want to share with anyone) … then most likely the service/function is not designed properly in the first place and the proprietary part should be moved back to the calling application. Thus when these services are stripped of proprietary logic even domain specific functionality, and in turn become more generic … they naturally end up looking like proper, generic, micro-services.