Building a serverless event driven Slack Bot

Editor's Notes

• #2: Welcome so great to see so many people in here today! During the next 40 minutes we are going dive deep into event-driven architecture in a microservice setup. We will look at some of the services that can be used in AWS to build out such a architecture. And we are going to dp a demo and build an event-driven slack bot. My name is Jimmy and this is Building a serverless event driven Slack Bot
• #3: The agenda for today.
• #4: As said My name is jimmy. I’m father two girls, not afraid of anything…. Serverless, Ambassador…
• #5: More and more teams build distributed SW using Micro Services, I’m rather sure that many of you in here is doing that as well. In such a distributed system the services need a way to communicate with each other. Often we do that using synch API and rest calls. This can however post a challenge as the system grows and we have more and more communication paths added. Services start to being more and more couple and need to know about each other. Often we add a Orchestration service like AWS Stepfunctions CLICK
• #6: Synchronous API integration, let me illustrate that with me telling my children to brush their teeth.
• #7: Not that bad? But what if we have a downstream service? Asking youngest to also tell the oldest
• #9: So now I need to find a way to solve this, normally including The Mom….. So using Orchestration, and a service like AWS Stepfunctions can help.
• #10: In a MS world we often integrate services using synch API. Building loosly coupled services integrating with an well defined API. Start with one not that bad…. Then two….
• #11: Almost looks like a classic monolith with very tight couplings. Gone is the loosly coupled services that we want.
• #12: So let’s take a deeper look at this using a made up online Pizzeria. The pizzeria is run by two brothers, Mario and Luigi. Yes they left the plumbing industry and started a pizzeria!
• #13: Order online
• #14: Flow Customer Order –> Order Service call the other services! Adding orchestration
• #15: Downstream error…..
• #16: NO Pineapple error flow!
• #17: Error flow! Luigi had introduce a Loyalty service!
• #19: What is an event!!
• #20: What do I mean with Observable?
• #22: No Pinapple error flow! So easy!
• #24: Extending is easy!
• #26: Before we jump into our demo and build this pizzeria order flow as an event-driven slack bot, let’s look at the services we will use.
• #28: Talk about 2 types of patterns, centralized and de-centralized (Single / Mulyi Bus) Single and Multi Account All the patterns allow us to decouple the publisher from the subscriber. The service that publish doesn’t really need to know who is listening in the other end.
• #29: Look at centralized advantnages and disadvantages Advantagesallow you to manage all routiing, security and polciies in one place, single deployment) All routing centralized, concentrating all communication to a single event bus ( Enables central management of resources Allows you to easy integrate applications with few changes. Disadvantages As number of intregrations grow so does the complexity and resource utlilization. Can become a Single point of failure. All routing is centralized…. Prevents autonomy Single point of failure
• #30: Caresteristics……
• #31: In all of our patterns we have three services……. Events flow though a central bus. Handle by an infrastructure team (or similar) Easy to manage, easy to get started and easy to integrate new services. But as said before, when ## of integrations grow so does the complexity. Can hinder autonomy since there is a central managed resource, probably managed by infra team.
• #32: In a decentralized approach routing is spread across multiple event buses and the publisher often becomes the logical owner of that bus. The service owns the mechanism to distribute the events. Even if more buses are more work from a operational approach it enables autonomy and doesn’t become a single point of failure On the other hand, designing distributed systems, managing all resources, can become a huge challenge if not done properly from the start. Applying this as an afterthought is almost impossible. So the time to get started might be longer, integration of new services and applications require more change and take more time.
• #33: Caresteristics……
• #34: Now each service own its own bus and publishes to that. Interested services can now subscribe for events in each service that they are interested in. Since we are in single account we can target resources in each service, cross service boundries. No need for extra busses, One thing that can become a problem is thar since there is no central bus, each service need to know about other services buses. This can quickly become a complex integration and onboarding new services can take time. Imagine in a system with10, 20, 100 services that you are interested in events from
• #36: I normally recommend that you create subscriptions, so each service that is interested in an event creates its own rule, One Rule One target. Yes there is support for 5 targets That would create coupling on filter and not event!
• #37: When building on eventbridge I would recommend that you create subscriptions. With that I mean that you create one event rule for one target. Even if EB support up to 5 targets per rule I still say this should be a 1-2-1 mapping. Why? If you create one rule with multiple targets you will create a coupling on the event filter. And if you hit the 5 target limit what are you suppose to do then? Create a second rule with the same filter and start adding new targets? What if you need to update the filter? You will impact several targets that might not be what you wanted to do in the first place, leaving you to start breaking things apart again. So instead we create subscriptions where we create the coupling on the event it self, and we set one target for one rule. It’s easy to add more target, just create a second rule and add the target to it. And the filter in every rule can change without affecting any other target. However…. This of course can lead to several rules having the same filter and that could create problems on it’s own. But in my opinion it’s still better to create subscriptions and deal with a rule explosion.
• #46: Before we jump into our demo and build this pizzeria order flow as an event-driven slack bot, let’s look at the services we will use.