Smart, fair thoughts here by @ryan_marsh about the Serverless Framework plugin system. Thread coming with my thoughts on good (and less good) uses of @goserverless plugins.
Initial tweet, since I can't thread on a retweet:
Initial tweet, since I can't thread on a retweet:
IMO, a SF plugin is best in three scenarios:
1) Extending the Framework's DSL to easily add more resources to your CloudFormation template. Example here is @acloudguru's Alerts plugin to add monitoring to your service.
1) Extending the Framework's DSL to easily add more resources to your CloudFormation template. Example here is @acloudguru's Alerts plugin to add monitoring to your service.
2) Plugins that help package up your Lambda function. Example here is serverless-python-requirements, as Python reqs + Lambda is a huge hassle w/o it. Lots of undifferentiated heavy lifting there. serverless-webpack, serverless-http, and serverless-wsgi also relevant here.
3) Plugins that add non-deployment functionality, such as improved local development experience. serverless-offline, serverless-dynamodb-local are good examples here.
The tougher examples are ones that @ryan_marsh mentioned where it's manipulating AWS resources on a deploy outside of CloudFormation. To me, it's almost always due to a limitation in CloudFormation itself. Two categories here:
1) CloudFormation doesn't support certain things. Examples here include when new AWS features come out and aren't supported (though CF team is getting much better/faster here!). A persistent example here is attaching a Lambda to an S3 event on an existing bucket. Can't do in CF.
2) Second category is when CloudFormation is just the wrong model, intrinsically. serverless-finch is a good example -- there's not a way (that I know of) to include static file updates within a CloudFormation template.
For the plugins around CF limitations, there's not a great answer. I agree the `aws s3 sync` is a good, safe way to handle it and would be my preference for large, production sites.. But many people, esp. w/o cloud experience, don't want to learn multiple different toolchains.
I think it gets to personal preference at that point, and I can see either. And finally, I disagree that SAM helps with this 🙂. If you don't want to use the iffy plugins w/ SF, don't use them! But with SAM, you don't get the great uses of plugins either.
cc @ben11kehoe, who initially brought this thread to my attention
