RFC: Powertool Java Plugin Support (Draft)

[serkan-ozal]

Key information

• RFC PR: (leave this empty)
• Related issue(s), if known:
• Area: (i.e. Tracer, Metrics, Logger, etc.)
• Meet tenets: (Yes/no)
• Approved by: ''
• Reviewed by: ''

Summary

As a Powertools community member, I would like to implement and share my own Powertools plugins/extensions (not talking about Lambda extensions) with the community through AWS Lambda layers so anyone can use it without any code change in their projects.

Motivation

To be able to provide community driven 3rd party Powertools plugins easier through layers without any code change.

Proposal

Plugins can be considered as wrappers/decorators around the user handler. Plugins are triggered before (with request) and after (with response and/or error) invocation (onion-like pattern similar to used by middy).

Management (discover, register, lifecycle, trigger, etc ...) of the plugins can be handled by a plugin extension (another extension like tracing, metric and logging). Plugins should also be able to discovered automatically by Java Service API without full classpath scan (to minimize coldstart overhead) when they are available in the classpath. So community can provide their own plugins as layer (or add them into the artifact/bundle as dependency). Then once they are added as layer by the customer, since they will be available in the classpath (/opt/java/), customer can plugin in/out without any code modification or redeploy.

User Experience

How would customers use it?

Adding the plugin as layer (or as dependency into the uploaded artifact/jar) will be enough from the customer perspective. Then plugin will be discovered and activated from the classpath automatically.

Any configuration or corner cases you'd expect?

• Order of the plugins might be important for some cases. So we should take care of it and think about whether we should give a way/configuration to customer to be able to order plugins? If so how?

• Plugins can also be disabled through environment variables even though they are available in the classpath at runtime without code change or redeploy.

• There can be 5 layers at most attached to a Lambda function. So if customer wants to use more than 5 plugins, which way we should advice? Adding them as dependency into artifact/bundle?

Demonstration of before and after on how the experience will be better

There will be reusable plugins from the community for the solutions of the common problems. So customers don't need to reinvent the wheel.

Drawbacks

Why should we not do this?

Do we need additional dependencies? Impact performance/package size?

We need to benchmark plugin discovery time from classpath (META-INF/services) whether it has significant coldstart overhead especially when there are many plugins.

Rationale and alternatives

• What other designs have been considered? Why not them?
• What is the impact of not doing this?

Unresolved questions

Optional, stash area for topics that need further development e.g. TBD