I *LOVE* what the @awscloud #EventBridge team is doing for #serverless, and this new Schema Registry is an amazing next step! Here are my initial thoughts on this... aws.amazon.com/blogs/compute/…
EventBridge _should_ become the glue that ties together all your cloud services (eventually w/ two-way message bindings). This means that the number of event types (don't forget SaaS partners) is going to increase exponentially...
Security best-practices will evolve to prefer multiple event buses so you'll have fine-grained access control across SaaS vendors, AWS service events, and custom messaging. The cognitive load to understand all those nuances, limitations, and event structures is overwhelming...
A centralized registry certainly helps with this, but requiring teams to document their own events is likely a fool's errand. The "schema discovery" mechanisms that the EventBridge team added makes this process simple, and *nearly* hands off for devs...
So now, teams building new microservices (or enhancing existing ones) can search for interesting events in their "custom schema registry" (and I would guess, eventually, SaaS provided schemas). BUT WAIT, THERE'S MORE...
Devs can download the EVENT BINDINGS which makes autocomplete in your IDE a snap. I tried the #TypeScript ones for a custom event I created... and it is 💯!
And one more note on the MASSIVE NUMBER of schemas. With the introduction of Event Destinations, I'm feeling like the go-to pattern will be Lambda->EventBridge for nearly every asynchronous task. This will allow other services (and other Lambdas) to subscribe to Lambda outputs...
Think about the possibilities of a highly-decoupled, near infinitely scalable piece of business logic that becomes its own *Event Source* that other services can subscribe to! 🤯 The future is now my #serverless friends!
Oh yeah, and go see @mikedeck talk about this at #reInvent. portal.reinvent.awsevents.com/connect/search…
