Advanced Serverless Orchestration with AWS Step Functions - AWS Online Tech Talks

everyone again thanks for joining us here today at advanced service orchestration with AWS step functions again my name is Chris months and I am a principal and lead developer advocate for servos here at AWS I've been at AWS now across a couple roles for a little over seven years but for the last almost three years been focusing entirely on this space of service so I doing things like this and talking to customers all over the world and helping them understand what services and how they can better use it inside of their own businesses now the topic that we talked about today is an important one it's around orchestrating the workflows inside of a surplice application and now service applications have a slightly different kind of looking field to them at the end of the day if you've been building them and when it comes to orchestration of components what we can do is actually really powerful with service I would say that what we're going to talk about today in terms of breaking down a larger business workflow and how you can integrate with various components that we have inside of AWS here will you'll find is that some really powerful architectural patterns could come out now when we talk about surplice this is a term that across the industry means a lot of things to a lot of people for us here at AWS though we kind of have a four key criteria that we use to define what service is and what allows us to basically consider a product to be able to be called service so those four criteria are as you see here so the first probably the most simple one is that there should be no infrastructure that you should need the permission or manage this means no virtual infrastructure in the sense of virtual machines physical machines or even any container orchestration that you yourself should have to manage set up and figure no operating systems we can figure and so forth the second is automatic scaling and this is a pretty core concept with cloud computing today as traffic or requests or events come in the infrastructure should scale up and then as they go away they should scale down and in this case you shouldn't have to think a whole lot about turning any knobs for capacity plan and you're worrying about if you have enough infrastructure to handle that the third is pay for value and in this case we talked about pay for value we talked about not again having a lot of resources sitting around that aren't being used so for mostly WS services that fall into the surplus family when you're not using them you're probably not paying for them maybe the lone exception be places where you have to pay for things like storage or data stored in a database and so what this means is that you can see really drastic savings compared to infrastructure that would be running 24/7 even if the structure that might be kind of following the peaks and travels of traffic in the case of a lot of the surplus products they respond directly to the events and requests that come in and so on you're not giving those events or requests you're not paying for them and then lastly being highly available in secure we consider security be our top priority for us here at AWS we also help our customers build highly available and resilient applications and so we have a lot of those both of those kind of capabilities and aspects built into the Surrealists family of products that we have here today now at the core of the service world for us is a product called AWS lambda and we're just about coming up actually on the fifth anniversary of us first announcing ADA Buist lambda in fact in November of 2014 and when we talk about lambda we talked about is sitting in the center of what we consider to be a service application now with a service application lambda there's basically three core components to it there is that service function so the lambda function that you have which is going to be written in one of some number of languages and today we have six languages that we support and manage maybe outside we also have a capability called a runtime API which allows you to bring almost any language that you could think of to lambda we have customers running Erlang Swift C++ PHP all sorts of things inside of that and so that function again is code that you write that you control that contains your business logic now how that folk that code gets executed is via an event source trigger being configured for your function today there are well over a hundred different services at AWS that can invoke a lambda function either directly or via one of the services that we'll talk about here today it's what this means is that there's a lot of different patterns for invoking lambda and responds to things like changes in your databases into data state request to influence of Amazon UK gateway or even things like Amazon Alexa and changes in resource state so for example in response to develop inter management tools in response to alarms from say something like YouTube this cloud watch or other systems that can kick off again invent based monitoring inside of your infrastructure and then what your function does is pulley up you so it does it talk to databases or data stores or other service API is that maybe our each of us is or existing your own infrastructure that business logic is is entirely yours and aligns with your business need now this is kind of the core of a basic example of when we talk about a surplus application but typically speaking there are again a lot of different things that you could do with this so you could build web applications such as those that are powering static sites or more dynamic web sites again be a typical EAP is our APEC gateway you can build backends so building things like the backends that powered mobile applications or IOT powered devices or even internal micro-services data processing so whether this be real-time MapReduce stream processing batch processing data processing ends up being one the large these cases for lambda that we see out there with customers today there's things like chat BOTS so being able to create a chat bot that interfaces either externally with your customers or sales or support reasons or even internally in your businesses to help you things like manage facilities set up meetings all sorts of things like that it was on LexA so for those of you that have a Amazon Alexa capable device at home or in your office Alexa is showing up in more and more places these days and with Alexa you can create what our calls that can be powered by lambda and the Alexa team actually says that lambda is the best platform for building and scaling skills in alignment Alexa and so with this you can power and enable all sorts of custom workflows again through Alexa capable devices Etha lastly I to automation and this is typically where a lot of people kind of dip their toes into the server space so again things like responding to incidents or events inside of your infrastructure whether they be security events or scaling events or responding to failures or things like that there's a lot of things that are possible with lambda now one thing though that becomes very apparent really quickly when you're building serve those applications is that those applications can get pretty complex very rarely do you just have kind of a straightforward sequential action that you need to take from start to end where one fun show you can talk to another and then that one talks to another without there being some level of complexity and so pretty quickly you start to find that there are things like multiple decision paths that you might have to go through you might have to have a multi-step process where maybe things have to happen parallel or you need to have them both complete before a third action can happen you also probably want to respond to failure so how do you deal with things like protecting downstream resources responding to timeouts or issues and so there's a lot of places where you could end up building a lot of this logic and a lot of orchestration into code but generally speaking we want to give you the ability to not have that in your application code and instead extract it out to a higher level in something that is ideally managed for you and so again some examples of this so again you've got code and you want to retry something so typically if you're making say an HTTP request to another rate service somewhere maybe you need to retry maybe do two exponential back-off how much of that do you do how do you handle that that could all be complicated code that you might have to write sequential tasks so you need some sort of business logic to be executed first and then second and then so on and again things that you might get to do handling failures making decisions based on the output of certain tasks and get things like parallelization there's a whole lot of kind of really core concepts in business workflow logic that you might be tempted to write and own the code for and so in these workflows there could be a lot of complex things that you want to do you could have tasks or calls to services that you want to retry for example a Web API where maybe you need to do an exponential back-off and a certain number of retries before you should have some sort of failure logic maybe you want to have sequential tasks so capability a calls capability B maybe that I think calls capability C or maybe you need to do some sort of decision based flow work after that so based on the output of B do you go see or do you go to D you probably want to have some ability to handle failures intelligently so if something fails do you respond with just a failure or do you try another path or is there some sort of other action that maybe you want to take and the beginners I mentioned earlier you might have parallel tasks that you want to take on such that two steps have to complete before a third can go and do its thing now you might be tempted to write all this logic into your final but we end up having an is basically more code around the workflow logic and handling of all of these various decisions than you do your actual business logic and then there are other concerns that you might have right so if this turns around scale maintaining state so for example if you were able or tried to do this inside of a lambda function you'd have to maintain the state of that workflow some we're dealing with errors and timeouts so if you have downstream errors and timeouts how do you handle that upstream without potential of that homeland of function timing out and so again you run it to various things that you'd like to do to make this easier these were concerns that we heard from our customers after we first launched lambda and that led us then to December 2016 announcing a service called a via step functions so just shy of three years ago we first announced step functions we're gonna spend most of the rest of this session here today talking about step functions now you see here a diagram of a workflow where basically we've got a whole bunch of the capabilities that we kind of discussed previously we're gonna go through again each of these here in today's talk now again step functions exists really to help you with a number of things but there's kind of three that come really core to me so one is a as you'll see here there's a visual aspect to step functions that allows you to have a visual workflow that aligns then with the business logic that you're looking to execute so we have some customers that have massively complex workflows I'm talking about 80 90 even maybe more decision trees failure paths and so forth inside of their step functions and they can do this again without having to write the code inside of their own lambda functions or their own application code which lends itself to the second aspect of this or the second key benefit again being able to write less code can be really powerful because it means then you focus more on the code that matters to you and less on some of this stuff which is fairly boilerplate and then finally step functions is at the end of the day a state engine which means that it's tracking the state of what's happening inside of your application now you don't have to deal with any low-level primitives of writing you're reading to a database as part of this are dealing with any sort of transactional aspects to that it's all managed by step functions for you and so this becomes a really powerful way for you again transition between these various aspects of the workflow that you have without having to manage all of that state directly yourself and so the way that it works is that you can define your workflow in JSON you can see Venn visualizations of that flow in the ATIS console if you so desired and you can also monitor the executions of it inside of the console now at scale and a day to day you're probably not going to have this open but could be a really useful way for you to troubleshoot what's going on inside of your application and your workflow so let's take an example let's say that I want to process a picture and what I want to do is I want to shrink it down so they can thumb nail of it I want to identify some capabilities or I should say some the content inside of that photo so what is it inside of it do I maybe want to use that metadata for some sort of search capability and then again I want to store that information now could I do this the side of a single lambda function potentially but if I were to think about the various aspects about this it's really separate bits of logic and separate bits of workflow that with step functions I can easily break out and again make more resilient write less of the the handling of the logic around this and be able to really really streamline my application code so this is an example of a step functions workflow that could support this idea so I'm gonna start off by getting my image I'm going to extract some image metadata so is this an image that I support so I can do a type check on it if it is that I can store the image made of data and then as you see here on the left hand side of this slide maybe I'm gonna use recognition to pull out information about it I'm also going to use a lambda function to turn into a thumbnail and then I'm gonna store that information and then the process ends now for some reason this was a not supported image maybe I only take JPEGs and you uploaded a tiff file or something like that then the not supported image type action can be executed and I could respond back with an error message or notify you somehow or just fail out the process and in terms of capabilities of step functions these various blocks here could represent a bunch of different things so I can have a diverse lambda functions be executed as part of step functions I could talk to dynamo dB as part of step functions I could have SNS say that there was a failure and what was being sent and so there's a whole lot of things as we get into here that you'll be able to do with step functions that again allow you to reduce the code that you're writing have really powerful workflows and again to have this scale and be really simple for you so at the core of step functions is a state logic DSL that we've written that is in JSON today and so you can see kind of a very brief example of this this DSL that we have here in JSON that is used for defining the workflow in States and so we see a bunch of information here tasks and things like input paths and result paths all of that kind of stuff and we'll go again here deeper into this here in a moment but the idea here is understand is that you can use JSON to really easily define this so it's not really any sort of overly complicated language there's just a couple of really core kind of types that are part of this and so it's a pretty straightforward language to work with and when we talk about the overall actions that are happening what you have is the concept of a task State and again in step functions manages that state for you and helps coordinate the actions in between the various tasks so there's a concept of input and output you see it kind of the top and the bottom of this diagram so the input information goes into an input path which has been broken up into parameters that state is then made available to the task or the you know the service or the code that I'm invoking out the other side of that comes a result path which goes into the output path which is then processed into output and so putting this all together basically what it means is that there's a pretty straightforward flow and logic to how data comes in and then data comes out and with that data can be information specific to the workflow and then on the outside result side similarly there could be information about the results which can then be used processed into the next step that you're going to workflow and they are going to use inside of your workflow now step functions DSL supports a concept of JSON path so what it means is that I have the ability to look into the JSON on the input and the output and go through the base the tree that we see here so if I wanted to in the input path find out or check for the author of a book we see here that I can actually search for that by calling or represented inside of the JSON by looking at the store structure and then the book structure then the waffler structure for the first object inside the Irate has been passed in and so again this makes it really straightforward to be able to process as we'll see here soon multiple items inside of the input path that's being set in and again allows us to also be able to look for just certain aspects of that data that have been passed in now I mentioned this earlier the console actually provides a really rich interface to understanding the execution details around your step functions executions so we see here an example of a workflow that has completed its execution we can really truly see that it has succeeded we can understand a bit more about the steps that it went through the actions for those you can dive into things like cloud watch logs for lambda functions some of the other capabilities we could track the timing of it and so this is one of the tools that you have to be able to diagnose and understand failures and potential issues and the performance of your step functions workflows I will talk a little bit more here in a bit about even some further capabilities that you have so I mentioned again that there's a number of capabilities inside of step functions and again all of this can be defined by the JSON DSL for the Amazon state machine language that we have here so this is an example of being able to handle retries of failures so what we see here is actually this is pretty robust this gives us the ability to do exponential back-off at retries allows us to define the maximum number of temps that we want to do before we consider this to be a failed action and so this allows us to basically be a good citizen when making requests a lot of services will tell you you know to come back and try again later we don't want to necessarily hammer that service over and over again so we can exponentially back off handle a certain number of retries and then again if that doesn't work understand that you know maybe there's something bigger here and then have a failure path we also have the ability instead functions to capture failures or exceptions and handle them in certain ways and this also supports the ability for you to handle custom failure messages from services like lambda so if you had inside of your lambda function code certain ways of handling and processing failures stuff functions that has the ability to handle specific actions or tasks after that based on what the error message is and so this could be really powerful for again having very you know complex and dynamic failure handling inside of your workflows based on what's happening inside of your lambda functions it doesn't just have to be kind of a generic failure code that you sent back you can be very specific and then have very specific next tasks that can be activated now I've mixed a little bit earlier we saw this in one of the previous slides that step functions can talk to a lot more than just lambda we have a number of integrations now for a to view step functions with first a number of different compute services so you can do things like kick off tasks in Amazon ECS or use Fargate you also have the ability to kick off a give us batch executions and so right there that's a whole bunch of different compute services that give you quite a lot of flexibility in your workflows you also have the ability to talk to services like Amazon sqs simple queue service and was like SMS simple notification service and this could be really powerful for integrating with other micro services or services that you have in your infrastructure that maybe can't directly integrate with staff functions today so you can very easily put objects into a queue where you need to buffer the amount of information going in to a service that's behind it you could use Amazon SNS to directly send messages to an HTTPS HP endpoint and so both of these again become really powerful in distributed systems you can also put data directly into dynamo DB and so dynamo DB is a non relational database here at AWS that can scale dynamically with workloads as well and then we've got two other services here Amazon Sage maker which is a machine learning service you can use that functions to integrate around doing machine learning tasks which is also really powerful and then finally ABS glue which supports things like tl workflow so you can use step functions as a key part of for example a data lake or doing data analytics or business analytics inside of your infrastructure and against everything from customer data to infrastructure information there's a lot of things that you could do with services like glue and again the end goal here is to reduce the amount of code that you might be writing and so we see here an example of trying to manage a batch workflow and so previously before we had these integration capabilities you see kind of on the left-hand side of the screen but you might have to do to support this so you might have a workflow where you submitted a job and then you would have a you know sleep function that basically takes some time to wait for a number of seconds before he kicks off another step that stuff can then go and look and see if the job is completed and if not go back and wait some more time if it is completed did it succeed or did it fail and then based on the outcome of that then have a function to send a message to SNS so you've got here basically at a minimum a need to go through six different lambda functions potentially or six different tasks to complete this workflow whereas we see on the right-hand side of the screen with this direct service integration it's just a lot easier so we can now tell step functions to directly kick off a batch of compute workflow and then based on the outcome of that directly publish a message to SNS and so in this situation you're actually running ready no custom code you're just writing the state function DSL JSON again you can integrate with compute well beyond just lambda so for example you can kick off a faregates or a far gate task fart gate is a container based offering that again works very similar to tenure based offerings that you see kind of all across the industry today so you can see that you can integrate with an e davis for gate task now if our gate we consider to be a service container offering here at AWS and that you don't manage any of the infrastructure or container orchestration today and so what this means is that step functions can directly integrate with long running tasks that can to you inside of our game or even tasks that need to run on say more opinionated compute resources so really powerful capabilities here and then after that part that far gate task has completed then you take the output of that and take on another action inside of your workflow an example of the JSON for this so we see here actually four step functions going and completely launching the Fargate task for us we putting out a cluster say the task definition and then going so far as to configure the network infrastructure around this so if this far gate tasks they have to talk to resources inside of a V PC like a relational database and so all this is possible here just directly inside of the start gate task definition similarly we can do things in this workflow like configure the SNS tasks off of this and again pretty straightforward we have the ability to based on the success or failure decide what the message is that we want to publish take output from the previous task and then pass that on forward and so again really straightforward juice on in order to make this happen here again is an example of you at runtime configuring the topic for the for these SNS tasks to resist and then again here the action that actually gets executed upon and so again in both these situations or at least in the situation of SNS you're not necessarily running any code to handle that obviously for the Fargate task you would have your application running inside of that container but again gluing these pieces together here it becomes really straightforward now we've got a number of new capabilities in step functions that have been launched here in just the last couple of months we're gonna walk through each of these I find each of these to be really really powerful additional components to step functions so the first is a concept of callbacks now we've had since the early days of step functions the ability for you to run human tasks and now those human tasks could be basically achieved by you know having a human on the other side of an interface who gets a notification and clicks a button and then it tells the task to complete but the callback pattern now is actually a lot more powerful you have the ability to have really long-running step functions where you know a process goes away and does a thing and then you can come back and have it finalized that process yourself and so based on this now you don't have to have the the kind of stuff functions workflow hanging around this could be an asynchronous task that happens and so previously where it would have blocked this again gives you quite a lot more flexibility so this could be useful for again long running tasks that need to run outside of your traditional workflow it could be really useful for for human based tasks and so again just adds another level of dynamic Ness and resiliency to your workflows another thing that we launched shortly after this was the ability for you to have nested or child workflows now the idea here is one of the things that we find is that as organizations start using step functions they start to come up with a lot of repeatable patterns inside those step functions you might have some sort of core business logic of a workflow that continues to exist inside of other aspects of your infrastructure or your application your architecture and so basically at the end of the day witness a child workflows allow you to do is create a reusable workflow that can then be invoked from other workflows alright so again missing itself is incredibly powerful because you can take then you know a bunch of simplified workflows and combine them into something much larger and then again reuse those work clothes again now this supports both asynchronous and an asynchronous model so you can block the parent workflow you could also have again like I said here an asynchronous model that is supports the callback model for calling back to the parent later on saying that work is done it's so there's different reasons for using both of those depending on your use case but again now this is a really easy way to simplify that it also supports the capability of having a heartbeat and so where you might have a task that has a certain timeout set for it the child tasks and now heartbeat back to the parent workflow saying hey I'm still doing this work this hasn't completed yet this even allows you to have the ability to via the callback model to the child tasks be asynchronous off the parent which is asynchronous and have it report back that it's completed a certain amount of work and then still continue to do other work that the parent maybe doesn't have to know anything about or be responsible for so again just gives you even more flexibility in the workflows and then most recently here just a couple weeks ago we added a new capability towards the parallelization aspects of what's supported inside of step functions now previously you could define a set number of parallelize tasks inside of workflow so we see here an example where I just have two tasks I want to execute at the same time I want to look up an address I want to look up a phone number and I want to pass that on then to the end result of this function but we just announced is dynamic parallelism and so via something called the map state as the name may sound here this allows you to take a dynamic number of inputs and then automatically execute a certain task or even potentially a nested child workflow inside of your workflow for each of those items and so this also allows you to have the ability to set a maximum concurrency so you can prevent say any sort of you know resource starvation inside of these workflows for whatever you might be talking to so really powerful thing we find that there are a lot of times that customers inside of workflow especially things like ETL workflows or data processing workflows may have an unbounded number of items that come in and whereas the previously parallel state would have had a fixed number you might have had to do some sort of looping inside the workflow to handle that yourself the map state just makes this much much easier so again really powerful and pretty straightforward to set up via the JSON the next thing we talk about is actually not the capability in step function its but actually an entirely new service that we announced over this past summer that exists inside of the same service orchestration family that we have step functions in this is an amazon event bridge now every one beverage is different in a number of ways compared to step functions whereas step functions is used to manage basically a predefined discrete kind of workflow between a number of capabilities inside of your application beverage exists to allow you to share events between potentially many different parts of your application in a way that's not directly orchestrated and so with this now it has the ability to take in a number of events for b2b services and then pass those on after being processed by rules to number of different targets now this is built on top of the scalability of cloud watch events which is the service that we've had here now at AWS for a while and so this is really meant from massive scale it's meant to enable kind of heavily distributed micro services based architectures and it's got really simple programming model towards it you just simply put events in you have rules that are defined then that pass those events onto targets and so what we can do with event bridge is they take an event that comes in from a single service and then pass that on to a number of other services in parallel kind of in a forked pattern if you will so we see that we can have a beverage talk to SNS to send a message to an HTTP server that's maybe running inside or on-premises infrastructure we could pass the message to event bridge or I'm sorry from a vet bridge to can use this data firehose which you can then put that into s3 and make it available for say biz telogen s-- we have a message from the vet bridge and passed into Kinesis fire hose then go into s3 and make it available for services like Amazon Athena to do bi analysis on top of it we can pass some data to ECS and we could pass the data to lambda again to talk to other services and then we could also use the vet Bridge to pass information into step functions now given that event bridge has integration with many many services across the AWS what this means again now is that you have a really easy way to have those services kick off step functions workflows and so it unlocks the ability for all sorts of events inside of the AWS ecosystem to now directly kick off workflows for you there's another thing that step functions can do with a bent bridge which is that step functions already has the ability for you to your report on lifecycle events inside of your step functions workflow and so those can then be passed into event bridge themselves passed into rules and then sent to other places so for example if you have tasks that fail or timeout you can take that information pass it through a rule and then maybe execute a lambda function to send a notification or to replay some information or to test things and so again what you get on both sides of the equation is that you can capture information about work so about lifecycle events with event bridge pass them to other aid abuse targets but then you can also use event bridge to execute step functions directly yourself so this is really useful again for auditing from serve ability for track individual workflows for responding to failure for gluing together all sorts of different AWS components into your orchestration and so again the two of these work hand-in-hand really well together so talk a little bit about some of the tooling that's available to you in building out your workflows and testing them now one tool that I would encourage you to go and grab today if you've never used it before is a tool called statement and you can find this on github in the ATIS labs organization under statement now this is a tool that's been open sourced by the step functions team and what allows you to do is to do linting on top of the state function D as a JSON DSL that you use for defining your workflows and so this should really be a key step in the overall development and deployment of your workflows it's gonna save you for those you know we're little typos or that times when maybe your JSON isn't valid and so I would definitely encourage you to get this tool and you know can include it inside of the workflows some of your development order flows for managing your step functions workflows the second is that you know some of the service products that we have lend themselves incredibly well to being able to scale up and scale down they're completely managed for you but there are a lot of developers that still want to have the capability to develop their applications locally and so one of the tools that we have that can help you with this is a step functions local tool and so we see here actually a screenshot from docker hub the local tool is made available to you either as a char that you can install locally or as a docker container that you can run directly inside of your workstation and your dev environment wherever it is that you might be building application code and so this has a number of capabilities built into it as well it has the ability for you to integrate with lambda functions running locally via AWS Sam just talked about here in a moment it also has the ability for you to integrate from the local environment up with services that are running directly in AWS so you can talk to the eight of your services from inside of your step functions here you can talk to different regions different endpoints and all that's very straightforward and easy to configure inside of the configuration file for step functions local we see here just an example of then using the A to B of CLI to invoke the local endpoint of step functions local to execute a command or basically to kick off a workflow and so this is really powerful and will help you get started next talk a little bit here about aw Sam so Sam is the mascot that we have here for server list and this is our a little squirrel friend that you see here in this slide let Sam actually stands for a lot more than that so Sam is short for service application model service application model or Sam is a extension built on top of cloud formation to really simplify the building and deploying of service applications and so there are a number of capabilities unique to Sam that basically again well it would take you from having to write many dozens of lines of JSON or Gamal and instead write just a handful or maybe tens of lion such a sonic ml now because it's an extension on top of CloudFormation it supports the ability for you to use any cloud formation resource inside of the template for it and you still use the cloud formation service to execute these templates to launch the resource stacks that are created by a and you get all of the underlying capabilities that exist inside of cloud formation as part of that now this is an open source specification and you can find out a lot more information in AWS Amazon com serverless slash Sam partnered up with the Sam template engine capability is a COI tool called a toga Sam CLI now CLI tool gives you a whole bunch of capabilities local inside of again your laptop your workstation whatever your is that you develop code first it can allow you to create new server lists applications no again this is gonna be based around just lambda in this case so it'll create for you a Sam template it'll give you some example code will give you a test event that you could pass in then it gives you the ability to mock the lambda service via two different ways one is via a mock API Gateway proxy style interface so this was where you would just basically throw a pearl command at a local interface and test out your API the second is via mocking the lambda services API now the length of service API at the end of the day is the thing that basically gives you the ability to talk to lambda and so with this you can pass in pretty much any event structure that you want including the event structures that come from step functions and so with this the step functions local interface you have the ability to directly interface with lambda functions that are running locally in your own dev environment via Sam CLI and this runs inside of a docker container locally as well so you do have top docker in your environment for this to work and so again what you end up with is basically two docker images that are running as active containers that are communicating with each other and it's pretty straightforward and suitable to get up and running so again how you can combine the two of these is that you can in terms of deploying is first you can have both local tools running again wherever it is that you develop code be able to update your step functions workflow and then update your lambda code and push them all at the same time then when it comes to actually deploying these out into your production environment or up into the cloud as it were you can just use the AWS step functions CloudFormation resources of state machine and activity and yes I realize that I missed an e on this but that's okay and then you could use the in Sam the ADA mr. bliss function resources to configure your lambda functions and all the various capabilities around that now given that you're creating all these resources inside of a template file and it's either going to be JSON or yamo in this case you could track all this inside of a CIS CD pipeline which means that you have the ability to version control of that file to track it inside of a code repository to test across multiple environments and kind of follow all of the good best practices that you would around CI and CD now one thing that we will say that is kind of a caveat to pay attention to you today is that versioning of state machines is tricky earlier this year we gave you the capability to do updates directly on existing step functions whereas previously that was something that you couldn't do so you can update existing step functions it will only apply to new executions that come in I won't impact anything that's in flow but when it comes to actually versioning State functions this is something today where you would either have to create a brand new state function and give it say a different name throwing some sort of you know semver type of structure to it if that was your thing but there isn't any concept of versioning today in step functions like there is in again this is something that we're aware of and I hope that in the near future we can give you some guidance on how you can do this better awesome so closing today we went through kind of a whole bunch of concepts around step functions again really step functions exists to allow you to remove the orchestration work that you would typically be writing a whole lot of code for and pass it up to a service that's going to manage that for you a lot easier it's gonna reduce the amount of code that you have it's can simplify that state management tracking and then it comes with a whole bunch of capabilities so obviously the ability to do decisions between tasks to handle retries things like exponential back-off to do you know complicated and custom failure handling and then to do things like parallel tasks recently here just in the last couple of months so you give you the ability to do callbacks so the ability for you to have a separate process or even a manual action in a call back in an async way back to your workflow nested child stacks which basically gives you the ability to have a workflow called another workflow which it allows for usability and simplification of your workflows and then again most recently here map or dynamic parallel tasks which allow you to give kind of an unbounded number of inputs in and have either individual tasks or even a nested child's task be kicked off as part of that now step functions is more than just lambda right you can integrate with Fargate ECS SNS sqs dynamodb vent bridge batch glue all sorts of things that you have the ability to do a number of capabilities with again that bridge could be a really powerful kind of sibling product alongside of step functions do things like capture information about what's happening with your workflows pass that on to other services like lambda or Kinesis or Fargate or put data out to again a number of different services the last thing when it comes to development testing step functions local plus Sam CLI gives evil you do a whole lot of this local inside of your own development environment they're both pretty simple tools to work with cuz they're you can come both bundled up inside of docker images and so getting started with them is as easy as downloading them doing a little bit of configuration and then firing them up so hopefully you found this all to useful for you here today you could read into this a lot further though by going to aws.amazon.com slash service and exploring kind of the full portfolio of servos products that we have here at AWS I mentioned a little bit about AWS Sam and how it could be really useful for helping to streamline building swordless applications you can find out a little bit more about Sam by going to aws.amazon.com slash service slash Sam again my name is Chris months you could find me at Mons at amazon.com or at Chris Mons on Twitter I want to thank you again for joining us here today in this tech talk I hope that we see you soon feel free to reach out if there's ever anything that I can help you out with in the service space here at AWS I'm happy to help but thanks again for joining us thanks again for all of your questions we're going to continue to try to push through and answer a couple more questions for you here I want to thank my Q&A team again and thank the hosts for helping us make today work so smoothly thank you have a great rest of your day