App 2025 Episode 1: Amazon EventBridge as the backbone of your app

well that's awful couldn't hear me that whole time I'd like to thank you all for letting me know that you could not hear me that whole time though basically what I was talking about was the beginning of what's on the slide so we're gonna go over this architecture today yeah spoken ISM frak Berg thanks for letting me know we're gonna I need to check my stream deck setup it's what I get for reliant on technology right we're gonna go over this architecture as a concept and then we're gonna do a little bit of diagramming on the fly with a specific example that we're gonna build out and then over the course of this series we're gonna build that application off with almost everything except the like core business logic whatever your core competitive advantage would be so I'm pretty excited about it and let's let's take a quick look through our agenda here so there's the third bullet there I want to give a big shout out I didn't know that he was gonna be giving this talk today to meet up but apparently he did been Ellerbe is a he's an AWS service hero and he's written an excellent blog post that you can get here in the channel by just entering the links command or I'm gonna drop it in here for you as well it's called a vent bridge storming and we're gonna use that as the basis for you know discovering our events and defining our events and figuring out what we need to build here so I just want to make sure that he gets recognition for that work there's a link to his blog post in there so we're working off a Benelli breeze technique super applicable exercise that your team can do in under a week to begin building an event-driven application and then the last thing we'll do is create an event bridge custom event bus if you happen to be joining us from the AWS channel about an hour ago Eric Johnson gave a great half hour session on Sam and event bridge this is gonna be a little simpler than that we are gonna use Sam as a cheat sheet and I'm gonna show you how I do that it looks like we're having some Network issues as well let me know if you start seeing network issues on your side and I'll see what I can do but it looks like I'm back up but definitely go back to the AWS channel and check out eric johnson sessions with sam video from today let's see i'm still buffering well i guess everybody's home we're actually in the middle of a windstorm here so hopefully my internet will pick up maybe it's just downstream I'm gonna I'm gonna keep driving on let me know in the chat if you cannot hear me otherwise I'm just gonna pretend like everything is okay and then just ask me your questions as we go okay let's see adjey geek definitely seen networking issues let's see here all right y'all bear with me there's always there's always some kind of fun right so let's see if we can change this low latency settings here I appreciate your patience y'all it's you know whatever you try to do it's gonna get a you're gonna get hit eventually yeah I'm seeing like massive bitrate drop so it's definitely my connection here I'm sorry oh I'm on gigabit fiber but you know the middle of a storm everybody's watching Netflix what are you gonna do see latency mode low latency let's return this to normal latency so I'll be a little bit behind y'all you may see another jump as this setting changes but again I'm here and this is live obviously I wouldn't put this on the air if I'd recorded it and this would happen so just ask me your questions as you go so again just in case I missed it the shout-out to bin Ellery for this methodology AWS serverless hero and let's let's get into it y'all all right oh look I got some crazy screen and death stuff going on over here man yo this is fun you've seen my OBS window now let's do this that looks a little better huh there it's fixed Rob look here it's fixed says edj geek whatever you do don't call him @j geek he doesn't like them alright thanks y'all so alright I haven't seen my stream catch up to it but I've seen this catch up to it so fun times y'all fun times alright so when we talk about this architectural pattern I went over this once but I was on mute so we can go over it again if you see me or caught me in a meet-up or a conference recently we've probably talked about this architecture of the future which is what I consider app 2025 it's one of the ways that once you start building with it it becomes so self evident that this is how apps are gonna be built but you know it just takes a while to adopt things like this it shares a history with service-oriented architecture but one thing that's different is all of these services are server lists now so you don't have to think about installing licensing running managing all of these things you just think about the interactions between them and again the core competitive business logic of your company is the only thing that you have to focus on which frees you up to build customer value which is again one of those key tenets of service so if we look here I've got a little a little basic diagram here that we're gonna work on together this is an event-driven architecture and again you've got an Amazon event bridge custom event bus for your application and then time is moving left to right and as you see you put an event on to the bus and rules filter those events to different listeners and those rules will send it over to a workflow which processes those in some amount of time and then eventually they'll put their own output events back on to the bus right and this just sort of repeats right it's the whole concept of observability of events rather than command driven imperative programming and one of my colleagues Julian Wood is gonna be presenting a webinar on this on April 28th so it's he's gonna go in depth to the event-driven architecture and the advantages that it has as well as Amazon event bridge so make sure you check that out if you can't wait until then there will be a shorter session again we've been Ellerbe and another my colleagues James Bezeq on Twitter on April 17th so lots of good event bridge content coming up but if we look at the sorry I want to go back to the architectural pattern real quick so we talked about event bridge sort of as the backbone in the application and we're gonna build that out today and then AWS step functions workflows that do all the work so when we're talking about events here we're talking about business events right domain events if you're familiar with domain driven design we're not talking about technical events unless this is a technical application like if if you're technical events or your business then that's what you're managing but here we're talking about things like a customer subscribed an order was placed an order was returned these business domain events and then your workflows are analogous to your business processes which should already be really well defined and understood by your company so you can see that this is a way of making your your architecture really reflect your organization it's like a positive application of Conway's law really really powerful to get to that shared understanding between engineering and development teams and business analytic teams there's another part of this it's not yet represented in the diagram but for example your data stores will be handled largely via service integrations for things that aren't latency sensitive the service integration is just when one service calls another service directly without some piece of glue like a lambda function in between an AWS lambda function and one of the things that's so powerful about these is that they're not bound to run or dependencies or even the vulnerabilities that might show up if you choose one of those they are AWS native which means that we're just handling the transformation and in there they're actually just declarative transformations rather than imperative transformations so they're you know rigorously provable and you get all the benefits that you get whenever you use declarative language and then finally some audit and monitoring considerations if you're responsible for security you should be looking at this architecture and your eyes should be lining up right or if you're on an internal IT audit team or you're an external IT auditor whenever I talk about these rules and the filters right here that kick off workflows well they have multiple listeners a rule can pass events to or can trigger an invocation for up to five listeners but one of those listeners can be an SNS topic and Amazon SNS topic which means that you can have this massive fan-out right and so you can define the events that you want to listen to for from an audit perspective a high-risk event right if you have a account funding transaction for over ten thousand dollars or an account withdrawal for over ten thousand dollars or if you have you know X number of transactions in a period of time like just ways that you can build these things up so that your audit functionality is also declarative and then put that off somewhere else where only your audit team has access to it same thing for security whenever you see those high risk evaluations or operations you can filter on those so that your security team gets exactly the information that it wants to see without being overloaded and again just the ability for an event to be published you don't have to know ahead of time who's gonna care about it so all you do is just put the event out there and then it's up to the consumers to determine that they want to that they care about it and that they want to see it and I do want to point out thanks to Julian wood he's dropped to the the link to sign up for his webinar that webinar is titled choosing events queues topics and streams in your service application and that's going to be a much deeper dive into this whereas right now we're sort of looking at the architecture of a specific application that we're building all right so enough about that we're gonna come down to here and this is just that basic architecture to demonstrate that but if you go into the post from bin Ellerbe that I dropped earlier it gives you an eight step process for understanding the events that are in your system and arriving at ultimately out of arriving at an architecture and the first step of this is event discovery so I want to go here and talk about our let's see give me a new window here I'm gonna I'm gonna go find some events that I listed our application is gonna be called just any company right it's a we're gonna use a SAS company as an example and I chose a SAS company because we as builders are probably familiar with the concept of software as a service but also because there's some core business things there that we can look at that will be in all line of business applications and then the like the operations inside of it we're just gonna leave we're not even gonna build those out we're gonna model them about will model the bounded context for the domains etc but we're not going to write the code for those because that is where you're gonna write your code and at this point you probably already know how to write your code for your company's business so the first thing you do for let me come back over here to our diagram the first step in event storming is event discovery and this is where you just get your team together and you just start listing all the events that are gonna occur in your application and so I did some work on this yesterday and we got 1 2 3 4 5 6 7 8 9 10 11 that I came up with so that's 1 2 3 4 5 6 7 8 9 10 11 and it's not important at this point to put them in any kind of order it's not important to try to group them it's not important to do anything other than this is just a brainstorming session where all your stakeholders sort of say look these are the things that happen in our business we you know provide a license a subscription renews and they're gonna be noun past tense verb right so a customer subscribed or a customer cancelled or I'm actually reading the ones that we're gonna use now or a subscription expired a subscription renewed so this is at this stage how you get to those events so I'm gonna give these here customer subscribed and again these aren't in order so I'm just gonna put them anywhere customer cancelled you don't even need to worry about consistent terminology at this point right if I call one thing and I did this even with myself just brainstorming in one place I called it a customer another place I called it an account that's okay this is not the step for that right it's and you may never reconcile that that's why the bounded contexts are so important subscription expired we've got subscription renewed we've got payment bailed we've got payment it's exceeded you can tell I don't think in order right because the next one's payment attempted which has to come before both of those but that's alright that's another step payment attempted alright I want to talk about this concept real quick for these next events operation initiated this is um this is a concept just for this for this series as we build operation is just any core business operation right so rather than building out like all the examples in like bike shedding or yak shaving over like how do we actually want to run our business we're not trying to build a business here this is the part where your team will do this so whatever is hello Rupp 12 thanks for are you up to up I like it are you up hello this is the part where you just want to get everything out alright but this is also these sort of operation ones or where I've got none and where you're going to have so Operation initiated operation succeeded and operation failed those are just my sort of generics and last but not least I came up with a count created because of the concept that you know maybe you allow people to sign up without a subscription as a test or whatever you know you can I'm not here to tell you how to run your business but these are just examples right and I've sort of kept these minimally scoped so that we can focus on the concepts your team will get these to whatever depth it understands it's processes so that's the first step in event Stormies event discovery now we're gonna highlight all these and bring them over here into [Music] actually not gonna do that yet so step two is temporal sequencing so we're just putting all the events in time order left to right so if we do this here let's see how I did this ahead of time the first thing that happens a user shows up in an account is created right like none of the rest of this happens until they have an account and then let's say we have it gated the simplest scenario right you don't have a subscription you can't use it there's no free tier so the first thing they have to do is a payment attempted and then there's a payment succeeded or payment failed I kind of uh missed having those two together on when I did this last night it was late last night when I was working on this y'all so you know if you see a mistake it's a mistake call me out and and let's fix it all right so payment succeed or payment failed all right at that point hopefully payment succeeds and we've got the customers subscribed right so all this makes sense so far now that they've subscribed they can do stuff so operation initiated and then again sort of the same either it succeeded or it failed scenario which is where you get into like monitoring and alerting observability of your application and then maybe at some point you know their monthly period is up they're gonna renew and then eventually either you know they let's hope this doesn't happen that they cancel or you know they let their subscription expire but this is sort of left to right we've put these in the order that we expect to experience all of them so it's nice of moobot moobot must be dropping those links in there for you every five minutes it's cool whenever I set something up in the stream and forget about it so hopefully you're all seeing those as well but again if you need the docs or the links just use the docs or links command there in the chat and we'll provide them to you so that's step two temporal sequencing right pasture looks great let's save that now the third step is trigger detection this is optional and so I'm not even gonna go into it go check out Ben's blog post you'll get the details and determine whether or not you need to do it for your organization and then step four we're gonna categorize these into entities and aggregates so I'm gonna copy all of these and pull them over oh look at that it's nice that it took them out of order for me but it actually helps we're not gonna deal with aggregates we're just sort of gonna deal with entities here so we see we've got customer customer or what else account created so all of these are sort of related concepts right I should look at that look at that I didn't even do that on purpose y'all but it doesn't actually fit exactly but whatever so we can make this don't worry I'll fix all this for us so this is a customer entity right send that to the back all right well maybe maybe that wasn't the smartest place to put the text for that all right try to make I know this screen is a little small let me see we should be able to bring this bigger a little bit now that we've got them grouped together e DJ geek says you see him thanks buddy thanks I am on a mission to pronounce your name the way that you wanted to be pronounced evermore oh great song by the way Nevermore okay so that's the first one then we've got this subscription entity that we see coming around over here subscription expired what else would go in here didn't we have like a subscription cancelled I don't know did we we had subscription renewed subscription expired customer cancelled and I guess I pulled that back in over here you make me sound like an overt no IDI see I almost did it I almost called you the wrong name II baiji geek is not an ogre he's a lovely person and if you watch his streams you'll see that so this is our screw please copy those let's make that our subscription entity right here just delete that subscription and this is just like a real quick way of modeling our domain right this really what this is so at this step you'll notice we're still not like writing code right we're gonna write some code today I promise it's literally like 11 lines it's fantastic we're gonna write so little code for this application you're never going to believe it but it's how it's gonna go and then we have so it's like we've got two more domains that are becoming clear here that are coming into focus we've got payments you don't have to make little hexagons out of all these right I just it's pretty so you know you're gonna you gotta take time to appreciate the little things in life so like when your application gives you a pretty little beehive there yeah you know use it let's see let's group these bring these down bring that over here alright so that was what payments I don't even remember anymore we'll figure it out that's about yeah payments cool and this then must have been operations this when you're building your actual model it's probably gonna be much much much much much much bigger right and in fact this will probably be like several groups if you were doing like e-commerce you might have fulfillment you might have inventory you might have returns you might have all these other things that are core to your business right so this sort of operations domain will just repeat over and over and over so that's step four now we're gonna take all of these and copy these over let's see how this pace I have no idea what's gonna happen it's gonna be great we take these okay okay all right I'm mad about that that's that's workable we can work with this and we categorize these into bounded contexts and the goal here is to minimize and in fact eliminate communication across contexts because when you have communication across context contexts then you have tight coupling right if if a context can't create and consume its own events if it needs another context and you actually haven't modeled that right so when I was doing this for our application I figured we can leave customer relations alone I think we're gonna need to bring these into one thing called Finance sorry we're gonna create we're gonna bring these two into one thing called customer relations so we're gonna take this guy right here alright so now we've got a little customer relations one here we've got we're calling this billing and to be honest with you again I was building so late last night I don't remember if I put this here or here this is the sort of thing that you will bike shed about and argue back and forth but ultimately it's gonna be the organizational terminology that wins out here that decides where this fits does do subscriptions belong to customers and do subscriptions belong to billing doesn't matter as long as ultimately you get agreement on it and then for us operations and again this is going to be several different contexts so oops I need a little text box here and we'll call this what did we call this customer relations the more I look at this the more I think I built it the other way but you know what it's a live stream so here we go let's see okay that's step 5 categorization in a bounded context again I'm hitting the surface on all of these things so definitely go check out Ben's post to get the to get the details and how you can make this work for your team so the sixth step is really just giving names to our micro services right so once you've created these bounded contexts you've actually named your microservices and so in our case we've round up with three of them that we've called customer the customer service billing service and the operations service yes these are micro services no these are not single lambda functions and I think Ben touches on this in his post as well resist the temptation to put everything about one service into a lambda function there's a lot of reasons why you don't want to do that one they're more difficult to maintain too cold starts can be significantly longer depending on how many dependencies you include and depending on your runtime three that lambda function has to have all the permissions to do all the things that that service does rather than only the things that each piece needs to do right so if you think about a concept like CQRS or command query responsibility separation a and a customer writer only needs access to write only customers into the datastore or as a customer reader or even just an address reader would only need access to read only the address information about a customer to generate a label right so it wouldn't even be able to read PII so you can make that a very low risk function which means if it has a vulnerable dependency that's high but it has no access to data then you've got like a medium risk right so it's a risk mitigation measure I really strongly recommend against building lambda lifts as we call them or monolithic lambdas there are some reasons to do it if you if it's the right answer for you then you will know but if you don't know then it's not the right answer all right so that's the sixth step in this process right and and again if we were to think about these in terms that that e DJ geek would appreciate we could consider each of these a Sam an AWS Sam application and we'll come back to that a little bit as we get to the command line so here we are that's step six step seven we can come back over here and we create a single custom event lambda fix not lambda fix I am the lift that is an unofficial term and I'm using it so you know or monolithic lambda a monolithic lambda is like if you take an express J s application and then just jam the entire thing into one aw s lambda function that's what we're talking about there as opposed to a lambda function that takes a single highly granular type of input performs one business operation and returns a single highly granular type of output right that can be tightly restricted so step seven in a vent storming is makes sense super I feel like no I didn't i was worried that i lost my chat thing there but no i see you at least on my screen there it is EDD j geek makes sense so we come back to our architecture here in step seven is just to create a single custom event bus and we're gonna go do that in cloud formation but I want to return to this real quick a workflow is not a micro service and a micro service is not a workflow right so in each micro service we would expect to see multiple workflows but we're not diagramming these out at this point in fact there's not really like a way that you would diagram all of those because they're not known at build time right this is an architecture that enables iteration so you don't necessarily want to try to envision all of the future workflows that will run against this you just want to know the ones you have today know which micro service they belong to and then capture those okay all right so I promise you some cloud formation that's exciting isn't it let's see got a little empty repo here nothing in it so I'm gonna cheat I'm gonna show you a little hack here that I like to do I never create my own cloud formation as Eric will tell you one fun thing about Sam is that it is a superset of cloud formation or transformation on cloud formation so we can do something like this and create a quick start right here and then that gives us an application to read me in my case I make file because I did it with go in a template well the templates all we want so we can move that to right here now we can get rid of the rest of the app right and so now cloud formation so tada this is a sample Sam template for a shared for a SAM app that is true that is correct but we're gonna we're gonna bash it up right not not bash like the born again shell but we're just gonna assault it so we don't actually need that transform so we'll take serverless out since we take serverless out don't need Global's because we don't have functions we don't need a function because we don't have functions don't need any of these outputs because you know how many outputs so this is very like not interesting right but this is any company Amazon event bridge event plus okay and this is just our you know just right in the description event bus declaration for the any company sample SAS application cool well this is pretty boring because there's nothing in it so it doesn't do anything honestly the real reason I do this is because I always forget this key string and for me the salmon is as fast as going and looking it up but we're also gonna go look stuff up so let's see alright there's a vent bridge in the console we'll come back to you this is I already had this pre-staged but fun fact about cloud for me and generally you can just do aw s : : whatever you're looking for it doesn't necessarily have to be in the right order event bridge that's gonna be the wrong thing right the docks you're probably still going to get there all right so it's kinda been purchased documentation going to the user guide etc but in this case as you would have seen from Eric's episode earlier the proper resource type for a custom event bus is AWS events event bus so let's bring all this in real quick no resources what are we gonna call you I'm super creative so I'm gonna call it event bus just like Eric I have paste issues we're gonna name this any company you can name it anything you want this event source name Eric talked about this a little bit in his session as well event bridge is powerful one thing that it does we haven't talked about is ingest third party events so from other SAS providers like Zendesk for example of customer service tickets you can ingest those events directly and what happens is the provider passes it to your AWS account without ever leaving AWS and you create a custom bus that's set up to consume those events that is one thing that event bridge does another thing that event bridge does today is you have a be default event bus already in your account in every region where it's available that is receiving all of your AWS account events so that you can listen to them as well and that's because this grew out of cloud watch events but as I said this event source name this is specific to that third party use case which we're not doing our architecture is first party it's how we're building our our company's application so as boring as this is that's it this is all we do to create our own event bus now I also want to get into these properties and turn values the ones that we're gonna be concerned with are the AR n in the name the name is like we already have it because we've already named it but the AR n will be useful for anything that consumes this stack so anything that that wants like your your line of business applications your micro-services will need to know the AR n of the event bridge event bus to put their events onto the bus and to listen to or to put their rules on there as listeners as well so let's get the event bus AR in the air in of the event bus and the value little get at what did we call this thing it's right there in front of me event bus AR m right we'll do the same thing for the name I forgot to turn our presentation mode you know this is my favorite screencast mode all right name the event bus name let me save it right okay so this is complete I do want to show you one more thing but this is a complete cloud formation template gives us one stack one resource on it that's the event bus and the properties of that event bus coming back out are you up twelve says get the cloud formation extension four vs code as it can get to all the syntax hints for CFN resources to vs code see every time I do this I learn something so I learned that today I'm gonna do that in just a minute I promise thank you for that tip there are you up to well okay so we come back over here and it's easy-peasy AWS CloudFormation deploy stack you can also use tab tab tab completion here two arguments stack name what are we gonna call this thing let's cheat let's see what I call it last night when I was testing oh nothing apparently there we go there's stack name any company that makes sense since that's the name of our company and our our product here so AWS CloudFormation its deploy that's why I know that was working for me two arguments template and the stock name and so we'll go ahead and deploy this now it's nice that that output is somewhere that we can consume as an AR n but I do want to go back to this and what would be even better would be if we had it as a AWS Systems Manager parameter store value that we could then provide access to other accounts where the Micra services would run or other values so that they can get it okay so successfully created updated stack any company that's awesome we can come back here to event bridge and look at our event buses and we'll see now that we have one custom event bus that we've created here any company and default permissions here right so that's all it takes to get that on there that's not very exciting and that's by design right so as we move through this series next week we're gonna build an AWS step functions Express workflow to handle one of these business processes and at that point we'll show you how to create rules and filters and hook them up to listen to the event bus to consume those events challenge accepted I don't even know what the challenge was but cool I told you I wanted to do one more thing so we'll go back here in our cloud formation and let's give ourselves the SSN parameter this one I looked up last night it is yeah sometimes it's too easy parameter it would be great if I had the cloud formation extension 4 vs code installed which would then give me the hints are you up 12 see this is another place where you could have saved me some time in fact I probably could have finished typing while I was talking about that but I just wanted to let you know I appreciate you properties description the AR in the event bus for other services to consume name slash event bus your in type string value and again we'll just get that attribute here from the event bus so that it's a dynamic reference go back over here easy day there's no special syntax for create on a stack so just run that off again now what's interesting here yeah cuz I deleted the stack so it should I don't think I have one of these already let's see demo gods have been kind to me so far it's terrifying forty one minutes into this and I haven't like had a complete melt her got about the whole audio thing at the beginning so alright super successfully created stack we can go over here to open up systems manager parameter store and look at our parameters tada there we go there's our bus right there right so now we can use I am to restrict or enable access to this so that applications know where to go to look for events to listen to events and to put events back on to the bus alright so let me check my agenda here create a shared schema alright there's two more things I want to talk about step eight in this process what we've done here with step seven create a single event bridge event bus step eight is creating a shared schema this is a place where it's best to just go into the documentation that command is bang Doc's exclamation point Doc's here in chat will give you a link to the event bridge documentation go in there and have a look at schemas we will get into them in future episodes the reason schemas are so powerful is with schema registry you get agreement about what a schema looks like what a format looks like across services so the owning service owns its schema right it's responsible for them it defines them it has final authority over them but it doesn't do any good if they don't share them so we have AWS event bridge schema registry which is a place to share those share and discover those schema again we'll cover all of us in a future episode as we continue to build this application but you can see where this is going that you know each of your line of business applications knows exactly what it's putting onto the bus and consumers know exactly what they can be out there looking for even without having to communicate with those departments so pretty pretty powerful stuff there and that step eight is building a shared schema so that is the complete walkthrough of Ben's blog post again a very quick walkthrough very purpose-driven so I would suggest that you go back and have a read of that it's in the links in this channel I want to go back to vs code for a second and talk about structure so what we've done here is put that template here in the route that's actually not how I want to leave this this is like classic operations stuff right so let's make an operations directory and then let's move the template there and realistically when you're building this application this is this is now its own repo right we want to have everything in one place for the purposes for learning purposes so that you can see it but each team each microservice etc would define its own single or multiple repos right so just because we're putting everything in one repo here not the best practice you would if you had your code separated into multiple repos you could have multiple CI CD pipelines even for multiple providers just you can do whatever works for your team self-organizing tools or self-organizing teams using the tools that help them work this is for demonstration purposes but then we can also do things like in it and I'm gonna do this because I'm not gonna do that because I'm so used to doing that what did we call our micro-services I'm gonna die I'm gonna go out on a limb here I'm gonna do this in no js' so that I can reach more of you so that we can take better advantage of the event bridge schema registry so I'm gonna go pretty far outside of my comfort zone I've written some no js' it's been a while but we'll do that to build our services the first one we had we had customer billing and operations right so we can just create these three services that at this point do nothing billing and operations right oh yeah that was that's right that's because I had to create that where I already had one that wasn't very intelligent I mean was it I tell you what it was smart enough to fail that so let's move operations to event bus can't do that let's do the same thing again operation y'all remember that game from like the 80s you're the doctor collecting all you pay and he had the little tweezers like appear you had to pick the bone out based on what you rolled that game was hard I can't drove me nuts okay so this is sort of what what this is gonna look like and what we're gonna build out over the the lifetime of our project here right right now these aren't much of anything but eventually they're gonna be complete microservices not eventbus that's just where our event bus cloud formation lives but so each of these is going to be a Sam application they were gonna build out and that's that that's what I wanted to cover for today let's do a quick review of what we've learned we went over the architectural pattern generally which is an event bridge event bus moving left to right through time with events going on to the bus being listened to by business processes that I like to think of generally represented as AWS step functions workflows that sort of run they sort of hang off of the event bus consuming events and typically putting you know output events back on to the bus until eventually there's an event on the bus that nobody cares about or the only consumer doesn't output events right so like an audit type consumer might be the last one to consume an event and it doesn't need to provide any notification back that it captured it we talked about our specific example that we're gonna build out which is any company software as a service company we're cheating a little bit with the operations domains we used bin alibies events storming model to build out our events and to categorize and group them to put them within bounded context and to define our micro services and then we went in wrote some cloud formation some very basic cloud formation to create an event bridge custom event bus and used the Sam CLI to create the skeletons that we're going to build out up for these for our micro services that we bound and named so I'm gonna stick around for a little bit if you've got any questions please do ask them but I want to point out again Eric Johnson sessions with Sam every Thursday on the AWS channel one hour before this great resource to learn more about Sam he has another series happy little api's which is Tuesday at that time slot that's 1:00 p.m. Eastern 10:00 a.m. Pacific every other Tuesday that will be next Tuesday is the next episode for learning about HTTP API that are newly generally available again AWS service hero bin Ellerbe thanks so much for the sort of the context for this session but will also be with a dub u.s. serverless developer senior developer advocate James Bezeq on Twitter on the 17th that's a week from tomorrow at noon Eastern 9 a.m. Pacific and again AWS senior developer advocate Julian wood will be presenting a webinar on Amazon of Enbridge on April 28 and that link was previously in the chat so lots of good resources coming up on that our next episode you would think I would know this off the top of my head but I don't let me go back to it I just don't want to give you the wrong name and I know it has to do with AWS step functions Express workflows yeah so I've titled it Express workflows for quick running processes Express workflows are limited to five minutes of execution each which means you know it's it's pretty much got a complete there it's not for your year-long executions like standard workflows a degree a step function standard workflows which will also address later so thank you all for joining today I hope you found this useful thanks for sticking with us through some of the technical difficulties the audio I haven't seen any questions in here Turin gal looking forward thanks for streaming I'm looking forward to providing it for you thanks for joining us apologies if I mispronounced your name that's kind of my thing it's what I do I don't do it on purpose you know you sometimes you just gotta take a stab at it again I'm gonna I'm gonna pop in here are you up twelve excellent stream thank you very much thank you for the recommendation we're gonna jump over here and get the cloud formation extension while we're still on before we forget about it AWS scripting guy just gonna install that one it's gonna click just gonna click and install everything install it all right now if we go back over here let's close this let's look see what this thing does for us real quick since we're still alive that one are you up to a perfect looks like I got the right one unknown tag get attributed let's see oh look at all this so extension prove er whatever prove er of type AWS oh alright there's all kinds of kinds of stubble a this cloud front distribution type aid okay why not let's have a cloud front distribution excellent see how that works there and then we adjust these gives us all of the cash pay okay so you see what that's doing there is putting in the cloud formation snippet in yeah mol so awesome tip there are you up to all much appreciated added a new extension to my toolkit there again I don't see any other questions so thank you everybody for joining I will be back here next week same time and I will be back on the AWS channel Tuesday at the same time that's 2 p.m. Eastern 11:00 a.m. Pacific for the next episode of AWS step functions where we cover parallelism and concurrency basically three places to handle them at different areas in AWS step functions and AWS lambda we're gonna dive deep into where you should be handling those and how you can handle them at each point so thanks everybody it's been a pleasure I'll see you Tuesday and Thursday bye

Channel: Serverless Land

Views: 2,356

Keywords:

Id: jYmZH7j_MXA

Length: 53min 12sec (3192 seconds)

Published: Thu Apr 09 2020