Episode #116: Infinite Serverless Workflows with Sam Dengler and Justin Callison

October 25, 2021 • 52 minutes

On this episode, Jeremy and Rebecca chat with Sam Dengler and Justin Callison about Step Functions support for 200+ AWS services, what developers should think about when building their serverless workflows, the role of orchestration across bounded contexts, and so much more.

Sam Dengler is a Principal Solutions Architect and Justin Callison is an Engineering manager of Workflow service (including Step Functions) at Amazon Web Services.


Jeremy: Hi everyone. I'm Jeremy Daly.

Rebecca: And I'm Rebecca Marshburn.

Jeremy: And this is Serverless Chats. Hey Rebecca, how are you doing?

Rebecca: I am good. How are you doing? And then I have a question for you.

Jeremy: Oh well, I'm doing well. Soccer season is almost over. It's short two-month season, but I will be happy to get my Saturdays and most nights back. So I'm looking forward to that.

Rebecca: Wow, it does feel like a really short season because I feel like I just asked you about what you were doing and you're like, "Well, soccer season is starting." Yeah, over here, it's starting to get a little cold and gray. And so you know what season is starting going to the art museums on the weekend season. And I've been doing that a lot lately and I seems some pretty cool shows. And so I don't know if art season is coming up for you.

Jeremy: I wouldn't say art season is coming up for me. re:Invent season is coming up for me, which means that I probably will be overwhelmed by a million different announcements. And I am going to re:Invent. I think I mentioned that. Oh actually, no, I didn't mention, I mentioned that in my newsletter, but I am going to re:Invent. So I will be there and I look forward to meeting a bunch of people in person. I look forward to the small intimate gathering of maybe about 30,000 people as opposed to 55,000. So that should be interesting. But yeah, no, I am noticing it's getting cold though. I have my sweater on today. But yeah, art museums, I like art, but I don't know if I'm going to spend my Saturday going into one.

Rebecca: Well, we'll go back to the one the thing that you did say you're going to be doing, which season because it's very apropos for our two guests today.

Jeremy: Yeah, definitely.

Rebecca: Our two guests today are employees at AWS team members on the Step Functions team. I'm so happy to introduce them. They're here to talk about a couple pretty major releases and very, very cool releases from AWS Step Functions. So we have the Engineering Manager of Workflow Service, including Step Functions, Justin Callison, and the Principal Solutions Architect at AWS, Sam Dengler. Hey Justin, thank you so much for joining. What have you all been up to?

Justin: Well, soccer season is underway up here in Vancouver as well. So that's been keeping us busy and that and dodging the rain. And we're wrapping up baseball. So my son is wrapping up his first season of kid pitch. And so it's been a really exciting time and they've had a great time. But like Jeremy, I'm glad to getting some time back on my schedule soon.

Jeremy: Right. And Rebecca mentioned works of art and I have to say this new release 200 Service Integrations with Step Functions is honestly a work of art. It is beautiful, it is amazing. Tell us a little more about that.

Justin: Sure. So I'm really glad to hear that you see it that way. It's certainly been a passion project for the team. We've been really excited about the opportunities to make Step Functions more accessible to a broader set of folks, but also all of AWS more accessible. So we've been working hard on this and we're really excited to have it out there and see the reaction we've been getting to it.

Rebecca: So before we even dive pretty deep into exactly what this is and its new capabilities with AWS SDK Service, let's start with the before. Can you describe what the release itself changed about that before? I've seen a pretty great like Marcia wrote for the AWS blog talking about what you had to do before in terms of making Lambda Function. And that just added more complexity to having to do these things in order to integrate with Step Functions. So can you talk a little bit about the before state and then we can dive into like really deep about how this is changing that and then technicalities around it.

Justin: You bet. So to start at the beginning, so Step Functions launched in 2016 with a direct integration with Lambda and it created this new model of serverless workflow. And that's the way the service operated for several years. And then you in 2018 at re:Invent, Werner launched what we called Service Integrations. And at that point we had a set, I believe there were eight services where we took specific API options that folks often use in their workflows and we made them directly accessible from Step Functions.

Justin: And what that did is it saved our builders from having to write lambda functions in order to invoke those services for the very common things that they're doing. Just made it simpler, easier to do and less maintenance. And so since then, we've added some more. We've seen a lot of interest from our customers and we stepped back and said, "Well, we can keep adding the most popular ones that folks ask for, but what can we do to think bigger on this?" And that's what led us to what we launched here. And we said, "Let's do an integration with AWS SDK. So we can make over 200 services and over 9,000 API options available directly from Step Functions."

Jeremy: All right. So Sam, you're a solutions architect. So you probably work with a lot of customers in trying to get that feedback from in terms of what they're looking for. And is this something where it was like people just didn't want to use the lambda function. They wanted to encapsulate more of this functionality or is where was the Genesis? I get the idea of like, "Hey, it would be cool if it did all these things, but where was the pressure coming from?

Sam: So I think it really is from our pace of innovation with a AWS. We're constantly adding new services and features and capabilities that make it really easy for customers to extend the functionality of their serverless applications very quickly. And so that is really resonating with customers as they see new things, launched that they want to include in their applications, they get it's very easy to pull those in. And Step Functions more and more has become a way a place of they can go to do that.

Sam: So in the case when they a high value service like say recognition, something that can take an image and detect labels and they see the outcome they want, what is the value or the purpose of incorporating this functionality to their application, but then they're forced to introduce an intermediary proxy, a function to do that really where it's just a form of glue in between the workflow and that service, then they see that as unnecessarily point of friction or impediment.

Sam: So wherever we can remove that, so the customers can move more quickly and focus on delivering value fast that really resonates with customers. We've seen in social media that they're really excited about eliminating a set of functions that were really there for doing any business compute or transformation, but were solely there for transporting and proxy and communication between the workflow and our services they really like the fact that they can reduce that complexity in their serverless architecture.

Jeremy: Yeah, and it's funny you said the word glue in there because I remember maybe six years ago or so when Warner announced Lambda that Lambda was the glue. Like that was that thing that helped tie all those services together. And this is just another higher level you or higher level abstraction, I guess on top of that. So I guess from a standpoint of this a better after state I guess where it was before versus where you're going now, is this something where you see Step Functions getting to a point where workflows are the preferred, maybe the ideal way to handle any type of this orchestration here as opposed to needing to send things into Lambda function and Lambda functions might just be for custom business logic, for example?

Sam: Yeah, so I think like most solutions there's trade offs over time. And really customers can be most successful when they get into a pattern of making decisions, building things and being comfortable and reevaluated that they think they build over time.

Sam: So today, Step Functions has a certain set of capabilities that are really good fit for building workflows that are more focused on an application, a serverless application that involves integrating other AWS Services directly. And there might be less of a need for a Lambda function in certain scenarios. That might be the ability to focus Step Functions more on purely custom logic and transformations that's focused and differentiated Step application instead of just the integration and the transportation of data between services.

Sam: And then as Step Functions says a lot of things planned in the future, there's going to be new capabilities that come to it and Lambda functions over time, which will change folks' decision matrix on trade offs and what is a good fit or not. But I definitely see like as we rethink what is a serverless application over time, a workflow becomes more part of the conversation. And what are we trying to achieve and what is the value each of our serverless services bring into the overall solution and then picking the right tools for the job and having an easy way to combine them in a total solution?

Jeremy: Awesome. And it's funny because again, you talk about transportation, you talk about transformation. And I remember Chris Munns very early on discussing Lambda functions and the purpose of Lambda functions. And the idea was that you use Lambda functions to transform data, not to transport data. So that if you're moving something from S3 to somewhere else, there's generally a better way to do that than to pull the data into Lambda function and move it. So that is an interesting way I think that people can think about it where Step Functions becomes a really good orchestration tool for transporting data. And then when you have those transformations that maybe the Step Functions can't necessarily do because you can still do some transformation I think, but the idea would be to use that Lambda function to do the transformation.

Sam: Yeah, that's right. And it's always going to be a continuum, right?

Jeremy: Right.

Sam: There's a no total order on our decisions, but that is I think two of the things to think about. I think another thing to consider is just the developer experience. You have in writing, authoring and testing and deploying code and how we do that inside of a Lambda function or a set of functions, the life cycle around those functions and how that relates to the development and deployment experience about Step Functions, again, what we have today and what we have planned in the future. And then how those things relate, how do the life cycles of functions and workflows, how are they related or different?

Sam: And we talk to customers who see them to being tightly coupled and their life cycle and deployment patterns and some that see them very loosely coupled and being able to compose function across different workflows so that they essentially are independent of each other. So there's lots of ways to think about combining these in your applications. And there's really no wrong answer. It's more around really just thinking through your use case, analyzing the options and making the right trade-offs.

Rebecca: Sam, you were talking a little bit about the future like when you're thinking about the future of serverless applications and then Justin, and I want to go back to something you said where you were like when you were thinking specifically about the Step Functions Service, how you could think bigger than you're adding a few things here, a few things here. And that was like, "Okay, what if we were able to have it like work with any service that has the AWS SDK, which is over 200.

Rebecca: And so not to get too far into doc culture, but I think there's something special for a lot of people when they're like, "Oh, I've heard about Amazon's doc culture and all these things." And one of the specializing questions that is often asked in those docs without giving out like IP of Amazon or anything like that, is that idea of saying, what do you wish that you would overhear someone about this at a party? And that question is meant to scope like how do you see this when it's built in the future actually affecting people's day-to-day life?

Rebecca: And I am curious if throughout that doc writing process and envisioning what that future is, perhaps something around what was that answer that you gave when you were like, "All right, how do we wish to overhear someone talking about this at lunch or at a party?" What is that future state? And then how did that scope back to what you all launched?

Justin: So maybe I'll jump in and answer that. So have to remember exactly what we wrote when we were doing that, but-

Rebecca: Exactly, Justin. It's better be verbatim.

Justin: I got to no... The thing that I was hoping to hear from people was to say, "Wow, it's now way easier for me to understand the capabilities that are available to me in AWS and much easier for me to take advantage of them to improve my business, improve my technology." That's what I wanted to hear from people. Not just the ability for us to really just to see what's there to understand, to discover because we provide so much capability. And as Sam was saying, we don't have a perspective that we there's one right answer to these things. There are many answers depending on what you are doing. And that's great, but it can create a challenge because there are so many pieces. So making it a lot easier for people to discover what's there and then to take that and build it into their applications.

Rebecca: So I'm curious, now it's been out for a couple weeks and what is the initial. I know initial customer feedback is like, "Yeah, love it." But I'm sure there's also things that are like, hey, actually this or what if now could do this and people build on those ideas and they see what is there and then what even more could be there. And so I'm curious if there's like specific customer feedback that you've gotten or known pieces that you're already working toward, even building more on top of. And then maybe if there's any surprising stories that you're like, "Oh, we didn't realize people would use it like that. And that is really cool."

Sam: Yeah, so I think it's really, it's been a game changer. And I think to Jeremy's question earlier about rethinking what a serverless application is, I think most of us in this space are developers who come from software engineering backgrounds and we think about code as being the thing that we express the problem that we're trying to solve.

Sam: And one of the great things about serverless in customer conversations is, I'm so much more quickly connected to the customer, the business problem, and the thing that we're trying to solve outside of necessarily even the technology stack. And as we have more purpose built capabilities, those can offset some of the code we would traditional write in our applications.

Sam: And when I use there's a feature we haven't really gotten into yet around the workflow design, it's a visualization on building your workflows, in my customer conversations, it's really fun actually to pull that up and have a live conversation where we're pulling in and actually building out the workflow as part of our conversation and seeing how quickly that represents the problem the customer's trying to solve. And there's a really, it's a very addictive feedback loop in having a conversation that's so quick, so closely connected to the problem you're solving and having the result be available so quickly.

Sam: And I think that part of this new capability and the SDKs is really resonating with custom and saying, "Wow, I can build and actually change something much more quickly now combining all of these a AWS superpowers in my applications." And I think now they're thinking, "Well, what else could I do? What are the other things that I could connect to or where else am I having to glue things together? And what else could Step Functions do to help me simplify those problems?"

Sam: So it really is sort of I think been a light bulb moment for a lot of customers or one that they've hoped for a long time and hoped to have seen come now that's here that's really opening the doors and their ideas on what else they can go of build. And I think that's, to me what's most exciting is how it's inspiring others to build.

Justin: Yeah, I would echo that, Sam, that this is what I've been hearing as well. And what the feedback that's been most interesting is just the creativity that it's unlocking with folks. They're thinking about new things. And I think we are still very early. We haven't had this out there that long. So that's what I'm most interested in in seeing the different ideas people have about how they're going to apply this in their applications.

Justin: We're also super excited along those lines about something fun we're doing, which is, we'll be launching this week a contest we're calling Flex Your Skills to have people show us some examples of really, really cool things that they've done with us. And so I could share a length with later with you on how we can get others involved in that. We're really excited about that and just an opportunity for us to make everyone make a world aware and be able to share some of the cool things that they're thinking of.

Jeremy: So speaking of creativity and thinking about new things, this is some... So I'd like to get a little bit technical here, and hopefully we don't lose some of the casual users as we get into maybe some domain-driven design and some concepts around that. So you mentioned or one of you mentioned this idea of stitching together multiple Lambda functions, maybe even across accounts, cross boundaries, things like that. So maybe let's start small and let's start in-service or interest service workflow.

Jeremy: So without getting too deep into bounded context and all that kind of stuff, but I guess my thought here is, there are multiple ways to do interactions. And maybe micro orchestrations is the way to refer to them where like you drop a file into S3 and it can trigger a Lambda to function. And that might be more of a simple one, but then you have some more complex ones as well where maybe you've got things like Lambda destinations where those are firing off based off of a state. So if it's a success state or a failed state, you get something firing off there those to integrate with.

Jeremy: EventBridge and some of these other things, as well as you've got DLQs, you've got Retry, there's bisecting of batches and all these other things that are tied directly to some of the services and some of those event mapping, some of the integrations. So I'm curious from an in-service or interest service perspective, do you see... And then maybe the question is more about how do you think customers should think about this, or are we all still trying to figure this out is, should you be using Step Function as a way to have a little bit more explicit control over those? And I know Step Functions can't duplicate all of that, but I think there are cases where Step Functions might work really well, maybe hitting EventBridge, triggering a Step Functions, looking at DLQs, deciding whether or not there's something that needs to be done.

Jeremy: How much of those workflows do you think can take over some of these other integrations and how should users be thinking about this? Should we be thinking about writing workflows to handle these DLQs situations, or maybe pick up some of these other things that might have existing integrations? I know it's a really long and convoluted question, but these are the things that bounce around in my mind. And so it's hard to articulate them usually when they're in my brain. So anyways, just thoughts on that overall. If there was even a question in there.

Sam: Sure. I'll go first and Justin, you can jump in. So I think when we're thinking about the type of coordination that we need in our architectures, there's lots of choices and it really comes down to the type of coupling and the amount of coupling we want to have in our systems. And again, there's different forms of coupling. You can have loose and tight coupling and different dimensions. And there is no right answer, again. It's about understanding the landscape and picking right trade-offs for the problem you're trying to solve.

Sam: And so an example where we do have a business process where the goal of the process, there is an expectation very intentionally on the sequences of actions that will happen, how errors are handled, how retry are handled, where you really don't want to lead it up, it is a tightly coupled process for a reason. In that case, you, you do need orchestration in order to perform that sequences of actions and your choices are to use a service to help you do that or build it yourself.

Sam: And oftentimes when I'm having conversations with customers that are trying to understand this choice, I ask them to look at what Step Functions does because outside of the integrations, it has a lot of features that help developers solve this orchestration issue. So there's built-in logging, for example, in history tracking, we check state in the standard workflows checkpoints so we get exactly want execution in everything in the workflow. So there's actually a lot of benefits from an operational and execution standpoint that Step Functions brings. And so I used it as a reference for if you don't want to use this at least take a look at what it provides because you might consider building something that does something very similar for yourself. It's a great example of what's required in order to provide those backward looking capabilities for troubleshooting and auditing, all of those things are required after we ship our code and we have to operate something in production.

Sam: And I think in the past when we looked at orchestration tools in '90s and 2000s had a bad rap because they were expensive, they were a single point of failure, high licensing cost. Serverless is what has been the game changer in that space. Step Functions is a highly scalable serverless infrastructure and pricing option for handling that orchestration, which really lowers the risk that we typically had when we had to depend on an orchestrator to handle that problem for us. I'll say one more point about the other option to let Justin tie into it.

Rebecca: Say it.

Sam: When we went loose coupling. So Jeremy, you mentioned the interplay between EventBridge and eventing with Step Functions, this is becoming a very popular pattern where we have events that trigger workflows, there might be a very small amount of sequences of actions that will happen. And the result of that will be another event that's produced. And so we can get this nice combination of flexibility between bounded context or microservices, but we can have the nice deterministic and tight coupling within those microservices as well. So they really play very well together. We see events drive workflows and workflows produce events and that's becoming a really common pattern in our customer conversations.

Jeremy: Right. Yeah, and maybe before you jump in Justin, you can talk a little bit more about the next aspect and you talked about cross-bounded context and so forth. So I'm not sure how familiar some of our users are with the idea of microservice communication and what some of those things are, but you talk a lot about how tight coupling and loose coupling. So in the microservices world, I know you know this, but I'm just going to give a quick explainer for any users who don't, you really have two methods, one being Orchestration, one being Choreography, but you have EventBridge that handles the at orchestration where you basically send an event out, the service itself does not need to know about. The downstream service it just says, "Hey, I've created an event in any other service that's interest can listen to that." Whereas Orchestration, you do have to have more of that tight coupling.

Jeremy: And I've seen a lot of patterns especially as people are starting to wake up to the fact and follow AWS recommendations that even microservices should be split across AWS accounts. So you have maybe your user service in one AWS account and that might have three different accounts associated with it. Maybe you have a dev prod staging, maybe you have hundreds of developer accounts associated with that. So it gets very complex very quickly. And I've seen these patterns where you have a state machine with Step Functions that are orchestrating these requests across, you got to make a call to the user service. And then it's got to call out to an external API and hit Stripe or something like that. And then once it gets that, it can call the inventory service that can do these other things.

Jeremy: So there's these very complex patterns when you start thinking about cross context or a cross bounded context for different domains. And there's multiple ways to do this. With Step Functions, you can hit an API gateway so you can call an API gateway directly if you want to interface with a service that way, you can use API gateways and proxies if you need to proxy a call to a third-party service, a third-party API, get the data back from that. Those are some really cool patterns you can do there.

Jeremy: You can also reach directly into another account and invoke a Lambda function directly, which always makes me really nervous because just exposing that internal implementation is dangerous in my opinion, but I'm just curious what your overall thought on that. Are these the type of patterns that you think Step Functions were designed to do? And how do you see that? Do you see this as like a separate orchestrator service that's outside of the bounded context of all these individual microservices? Or do you think it's something that needs to be a little bit more tightly coupled in order for... Again, I apologize. I'm rambling here without a question, but essentially, do you see that as something that Step Functions was designed to do to handle this type of cross-service communication as opposed to just creating workflows within a service?

Sam: So I think the answer here is, it's useful for both. So my personal perspective is, I think of Lambda, API Gateway, Step Functions, EventBridge as being the four pillars of serverless. And you take these and you deploy them. And I see them deployed at creating those boundaries between bounded contexts where you will absolutely want to use although you may use them in inside.

Sam: So I don't think it's one or the other. The biggest thing and in my experience as a technologist, one of the biggest challenges is describing those service boundaries and those in bounding context and being able to change them over time. So I agree there may be patterns of going say across account to Lambda functions. I see risks for doing that, but you might have a good reason for doing it.

Sam: But we will often see where customers will want to take Step Functions and use it within a bounded context inside of a service. And they'll also then want to maybe use that between those. Using EventBridge is great, as you said, to have the natural Pub/Sub and really make sure that this is loosely coupled. But we also sometimes say even between those services, there's an overarching layer of orchestration that's necessary. So it's really depends on the situation and we want to provide technology to that that provides great solutions in all of those cases.

Jeremy: Now, I'm interested in the external API call. So I know a lot of people use a Lambda function. They'll hit a Lambda function. That Lambda function make an API call, bring the data back, pipe that into the next state. I'm curious, I like playing around with using a API Gateway with a HTTP proxy to do some of those external calls. Is there any plans to build a generic HTTP API endpoint call as a task in Step Functions? Or is this still something that we have to work around that either with the API Gateway proxy or Lambda function?

Sam: Well, we have heard that feedback before and as always we listen to customers and we look at how to fit that functionality in. There's nothing I can share at this point. But the pattern of API Gateway was intended to help with a lot of this as well where you oftentimes you want to be able to call those things, but then API Gateway provides you a lot of capabilities to create an appropriate interface for working with that within AWS. So that pattern has been helpful and we've seen a lot of interesting use cases there.

Justin: I'll chime another example. This is my architecture video from Taco Bell that I think is a really good one for your listeners to look at too. And it's a case where Taco Bell needed to do an integration and combining Orchestration and Choreography with Step Functions and EventBridge with some of their delivery partners like DoorDash or Uber Eats or whatnot. Essentially, they're using a pattern where they are generating the task token, which is a service integration pattern that you can do with Step Functions that allows external parties to do callback mechanisms and resume the execution of a workflow.

Justin: They're essentially generating those task tokens and associating them, stashing and associating them with their partner correlation IDs. And then they can either invoke through a Lambda function and call those third-party partners drill. They could proxy through an API Gateway as you mentioned. And we have some customers that are actually using a feature in EventBridge called API Destinations, which provides an outbound mechanism for integrating with third parties has a really neat feature. It actually allows you to set a maximum TPS on outbound requests to your partners. So really helpful in cases when you can per reduce more traffic than perhaps your partners can handle.

Justin: But essentially that task token then can follow to your partners directly and then be used as a callback mechanism, either directly to Step Functions or through an intermediary, maybe like an API Gateway to handle a web plug response that can be used to resume those workflows. So I think as you mentioned, Jeremy, lots of ways that we can go about combining our AWS Services. And I think we will always look at simplifying those sharp edges at where we hear from customers where we can improve the experience. But those patterns, those serverless and integration patterns are available today for customers to explore.

Jeremy: Yeah, and I do love API Destinations with the built-in circuit breaker/quota management that's there that is something that was desperately needed, I think for a lot because there's a lot of people trying to build that on their own. So very interesting stuff. But yeah, I do love that idea of having that task that can perform because to me, that just seems like a really obvious task. And actually, there's a great video by Marcia Villalba on FooBar channel going over this new launch and talks about how there's no Lambda functions in there.

Jeremy: And so I think that's one of those common things, reaching out to another API, pulling that data down and to simplify that process would be pretty cool. But of course, you probably don't want to duplicate the same functionality as API destinations. But anyways, it's still cool stuff. And like you said, there's a lot of different options and it is all possible now. And if there's any way to simplify that workflow, that'd be even better.

Sam: I wanted to add one thing, Jeremy, which was, last year we launched for Step Functions as well synchronous express workflows. And the reason I want to bring that up is that when builders are asking this question of which technology should I use and where should I apply it? When they see limitations of, well, I can do these things, but I can't do those things, they're reluctant to embrace that technology sometimes because they want to have something that's ubiquitous for them. And we heard from customers, they said, "We love workflows, we love what we can get, but the asynchronous nature isn't always what we need."

Sam: And so with synchronous express workflows, now people can use Step Functions, can use these capabilities. And if they need to have an interaction within their architectures that is synchronous, they can do that. And if they want to then move to a synchronous, they can do that as well. And so it makes it a lot easier for them to apply this technology across the different challenges that they face.

Jeremy: Definitely.

Rebecca: So I think an interesting thing that we've been hearing from our guests and then around the water cooler, I guess, is that if that's what people say anymore, is that a lot of these new services or feature releases or integrations or what have you like things that Lambda can do, for example. In some ways, chip away at that principled simplicity of Lambda. And so while it adds more capabilities, it also adds more complexity. And so there's this tension between being able to do more things with more things and all of a sudden that changes that beautiful, like lightness, if you will, of Lambda. And that's to say obviously these are again, maybe not obviously Jeremy, well check ourselves.

Rebecca: But our guests coming here are our pretty big fans of serverless and Lambda. They likely would not be coming to join us. And so I think it's more of a discussion topic around like how far is too far? And when you add complexity, are you taking away from the core principles of Lambda and serverless as a paradigm? But to me, the Step Functions capabilities with the AWS SDK Service is like, it actually feels like an antidote to that. And it's actually, although it can allow you to technically do more stuff with more services is reintroducing a lot of simplicity into how you use these services and put things together, you actually get to remove that glue, if you will, of Lambda functions. Is that a way that you all see it by sometimes adding, building a new thing is actually injecting a ton of simplicity?

Justin: I think so, Rebecca. So we talked earlier about microservices and in my experience in technology that when I started at this, most of the applications were modelless and those worked well to a certain point and then they started to break down. And so one of the patterns that we've seen over time in technology is to break down our technology components into smaller and smaller pieces. They're more independent. We can scale easily from a workload perspective and from a development perspective, we can change more quickly. But what it's done is, it's taken complexity that was previously handled by a compiler, and now it's pushed up into another level. And so there's a trade-off that happens there and you get the benefits of those small things, but now you're getting more and more overhead putting into making sure these things all work together.

Justin: And I absolutely see that pattern with serverless where people love it and then they get started and they love the small pieces of it and they find that, oh, over time they're spending more and more of their energy on the things that don't actually add value. And I do see Step Functions as an antidote to that of allowing to really focus on the parts that are most valuable and then allow service like Step Functions to take care of the things that aren't.

Jeremy: Yeah, and I tell you one of the patterns that I really like. And I know we've flirted around this a little bit, but is this idea of the intra service or the inservice use of Step Functions where a lot of times people write what I call fat lamb to functions where they connect to a bunch of different services, they pull the data together, they do some trans transformations and then they eventually come out with a result on the other end. And some of the times these run asynchronously and that's perfectly fine. So the amount of time that they take doesn't really matter. But you put all that complexity into the code and then all your retry and all this other stuff have to be built in. And then that's when you get into the dead-letter queue sort of situations where it's like, "Did this event even make it through?"

Jeremy: And I really like this pattern of creating very small discrete pieces of business logic in a Lambda function that does something, some transformation or whatever, and then having that workflow or having that Step Function orchestrate a bunch of those things together. And the ability now to add in these other services. Now, it's cut out a lot of these Lambda functions. So I really do like that intra service thing. From a global perspective, I like Choreography more than I like Orchestration across multiple services, but at the same time, there are a lot of patterns like both of you have said where it's probably not a bad thing. Depending on what your use case, if you do have to coordinate multiple things, you can do it that way.

Jeremy: And again, there's no better way in my opinion to orchestrate a saga if people are familiar with saga patterns and to be able to do the rollbacks and the retry and all that kinda stuff that there then by using a Step Functions. So I think that's just one of those things where we have to start identifying these patterns and calling them out where it's like, you've got one pattern that's just very low-level interest service pattern that's meant to run some discrete action within a bounded context, and then potentially if need be using this larger context of cross domains in order to or cross bounded context, I guess, in order to have that orchestrated or do that.

Jeremy: And then like you said, mixing matching these patterns with EventBridge with orchestrators if you need to. But it just opens up a whole new world of people's thinking. And again, I appreciate Rebecca's questions. She's like, does it make things simpler? I think it does make things simpler because you can see them and they're more logically laid out, but at the same time from a developer's brain, you're probably like, "I'm usually used to just writing things synchronously in code. All of a sudden, this enters a whole new paradigm for me."

Sam: Yeah, we have this conversation a lot with customers. Is it simpler or not? Well, like you said, Jeremy, the simplest thing is to have some synchronous quote that runs single threaded and you have a lot of control over reasoning about what's going to happen in the expectations for the execution of that code.

Sam: But to Justin's point, like at a certain point, how does that scale? How do you operate that and how does it fit the traffic patterns? And that's why we move to microservices and distributed applications where we follow the CAP theorem and can scale things in different ways, but they're trade-offs. Now, we have complexity that we didn't have before. We have new capabilities and we can scale and build and scale wonderful things that we couldn't do before, but they come with trade-offs to consider.

Sam: And I think that your point around using the bounded context as a guide for where Orchestration versus Choreography is a good one, I think it's a good place to start. And a lot of... These are old concepts that are new to a lot of people now that the tools are easier to incorporate in the serverless world where you can use them to build stuff faster. But I think it comes back to these ideas and coupling. And if we think of coupling as a measurement of the dependencies or the awareness of an expectations for these coordinations between the systems, it's a good guideline for what is the right choice.

Sam: I've had conversations with customers that discover this space and say, "Oh, we'd really like to have an EventBridge conversation." And I said, "Okay, great. Tell me what your requirements are." And all of their requirements point to a high level dependency and awareness between systems and expectations. And we say, "Well, I think you should take a look at Step Functions that actually has the tools that will help you solve your problem more immediately." And then other customers that want very loose coupling. And they're trying to build that into a tight an orchestration workflow where they need to think about where they actually need looser coupling for more flexibility, need to split those things apart.

Sam: And so to your point, like things with the saga pattern where we're talking within or a cross bounded context, they can still apply. It's just really more on the expectations of the coordination and the problem we're trying to solve. And that I think is a good guideline for where to start and how to combine these things together.

Jeremy: Right. And I think the big thing around coupling is, the holy grail of microservices really, I think, is independent deployability. That one team can work on a service and they can deploy that. And then when you start adding in, even if it's temporal coupling or whatever, you have an orchestrator that's making calls to these services. As long as that contract stays valid and you're not breaking contracts, that's one of the things that I like about this idea of, again, using these to do these orchestrations and saga patterns because it's perfectly valid use case to do that as long as you've maintained those bounded contexts within that service, create that contract and expose that contract and the whole information hiding and internal workings and try to keep that separate because if you let that bleed over into your Step Functions and into these cross context orchestrations, that's where I think you can get into problems.

Jeremy: So I think you're right. I think just think about it in terms of keeping these discrete pieces of logically or these discrete services separate, and then using this to just use a public contract or I guess, private depending on what service is, but a private contract in order to communicate with them.

Sam: Exactly. And I think a good example in where Lambda still fits in this context, I think Rebecca's question, you can think at AWS we have 9,000 plus SDKs that you can call. I think of these as like super powers. I just love the Machine Learning Services because I get so much value out of making an API call that is just beyond me to be able to. I'm not an ML expert. So the fact that I can send an image and get back labels for it is like magic me. And I just love incorporating that.

Sam: But there might be... I've talked to customers, I think to your point, Jeremy, where maybe they have a custom machine learning model that they want to execute and it's not a good fit for AWS services. Well, perhaps it's a great fit for Lambda function and doing on-demand machine learning inference call. And so if we think about Lambda as being custom capabilities that our services don't support or don't have the features that you need, then you start to see where your Lambda's functions really become custom superpowers, right?

Jeremy: Right.

Sam: That wrap either AWS Services or own business superpowers and incorporating it into a workflow just like you would via AWS services. So there's definitely a place for Lambda in our serverless architectures. And I think as Justin was mentioning, it's really the combination of all of these services together that give you a solution. None of them can really stand on their own.

Justin: Yeah.

Jeremy: Totally agree.

Justin: Yeah, when we launched this release, there's a lot of discussion. People are using the term "Lambdaless" and I have a different perspective. I think of Lambda more. I think it's about using Lambda more for the things that it is best at and not using it for those things that you really don't want to.

Jeremy: Right.

Rebecca: Yeah, Lambda value add. Lambda more is better. So Justin, earlier, you're like, "Yeah, we've heard that feedback before, but I can't really speak on it." And then you gave us a wink our listeners couldn't see it, but I'm kidding. You didn't wink, but I felt like there's a wink there.

Justin: It gave you this trouble.

Rebecca: Yeah, no, no. Yeah, I do have to say that out loud that you did not wink. There was absolutely no indication that there's anything you could actually talk about in terms of what's coming up next. But we should talk about a few other recent releases that are complimentary to this. So Step Functions Workflow Studio and the Data Flow Simulator. I'd love to give you all the opportunity, give you the floor to talk about those a little bit since we focus so much on the integrations possibilities with 200 other services, but tho those things are also new and people are excited about them. So if you could talk a little bit about that and how that fits into this picture as well.

Jeremy: Yeah, and let me just interject quickly because honestly, I think that the Step Functions Workflow Studio is probably the best or at least one of the best developer experiences within the AWS Console. There's so many things. I know the DynamoDB team redid the whole items, look up stuff, but it's still like six clicks to get to an item. There's all kinds of issues with that. I've been playing around with the workflow studio and it's amazing. It's so nice. And I love the Data Flow Simulator. That makes it so much easier to build these things and understand that throughput. But again, well, maybe I just sold it for you, but anyways, tell us more about it.

Justin: Sure, sure. Well, I'll also give a little bit of context too. So first off, it's really fantastic to hear that feedback because this is something we are passionate about and the team has really leaned into for a long time. And so a while back, we recognized with Step Functions that we had customers who used it and loved it, but we knew the developer experience was challenging. There's a new domain specific language that you need to learn, you have to separate. So there was a lot that you had to invest in order to get that full value.

Justin: And so a while back, we organized ourselves to say, "Look, how do we really focus on improving the developer experience?" And we knew that wasn't going to be a one and done thing, and we've been investing over time, multiple changes in order to get there. And it's really culminated, I think with Workflow Studio of us being able to make a huge leap forward.

Justin: And so with Workflow Studio, now someone who's coming in doesn't... If they're a new user, you don't need to learn this underlying domain specific language that is Amazon state's language. You can get going visually. You can discover the capabilities of the services and the AWS integrations, but also of this workflow language without having to get into the nitty gritty. And that has been hugely helpful for a lot of our new customers to just get started and to understand how to work with this.

Justin: But it's also been incredibly helpful for experienced users. I like to dog food and use our service. I use it all the time. I love it. I come in and I can put things together and I can start to as Sam was saying, I can visually construct what I want, put it together and then I can move over and maybe I'm going to do some other things in serverless app model after using CloudFormation, et cetera. But it really allows me even as an experience user to get started on it. And so we're really pleased with that. I think we have more to do to continue to make that better, but we're really proud of what we've been to do in the reception that folks have given to us.

Jeremy: Yeah, my suggestion, Justin is when you select like, let's say you select API Gateway as a task and you drop that in, then when you go in it gives you the JSON, it gives you the... So you can fill in the information.

Justin: Yeah.

Jeremy: And if you parametize that and I could select from all my API Gateways and things like that, that would be amazing.

Justin: Yeah. Okay. I'll take that back to the team.

Rebecca: So I know that you can't talk about any releases coming up at re:Invent, but I do wonder if there's anything you can tell listeners around whether or not you're going to re:Invent. I'm not exactly sure this year is if there's a booth and so they can find out more at the Step Functions booth, or if there are specific talks. Sam usually give one, I know that where you know what themes you're focusing on so people can look for these when they go to be like, "That's the talk I want to go to, I want to learn more about how to interact with this." Like everything that you've talked about today. Like how do I work that into my workflows now? And so I'm curious if there's already talks that are scheduled for that people should look out for.

Justin: There are. The catalog was just released this week. And we have talks across the serverless track and we have a sister track called the Application Integration Track. But really, there's a lot of overlap in these services as we were talking about really, we see them in combination quite a lot. So we'll have event-driven architecture talks. We'll have talks on orchestration for performance improvements and optimizations, lots of serverless information. There is a, as you mentioned, Rebecca, also a booth, a serverless booth people can visit on the vendor floor. And this year, the breakout session talks are going to be prerecorded and released during the week. So for those that can't attend in person, you will have a quick access to the materials to view at home as well.

Rebecca: Nice. And if people want to get started today is there the best place just to go awsamazon.com/stepfunctions, or is there a certain place where you're like, "Go read this blog first. Go see that this is my architectured video from Taco Bell first." What are some of the things that you'd say like, "This is the best way to get started?"

Justin: So my recommendation is to go to serverlessland.com. It's a great website that our developer advocate team has created and maintained. You can find videos, articles that have all been co-located there as well as a set of serverless patterns. Jeremy, I know you've done some work in this area as well, but it's a great place to discover how we can use these services in combinations and have a quick deployment of these things in your code. So from there, you can discover the other videos that we have in articles to get started.

Rebecca: Oh my gosh, I love the authors of Serverless Land. Those DAs are epic. Good call out.

Jeremy: Yeah, no serverlessland.com is like a go-to resource for so many things. Also, again I know Eric Johnson Justin's been speaking of authors of Serverless Land. He had a Twitch episode recently about the launch of it. I mentioned Marcia Villalba FooBar video on it, which I think is super helpful. I know that Yan Cui, the Burning Monk has a Step Functions course as well, but it probably a little bit out of date with... Doesn't mention these new things, but and probably doesn't get into the Workflow Studio and those sort of things.

Jeremy: So, but anyways, there are a lot of good resources out there for Step Functions. But so much has changed. So really, yeah, I think probably the best place to go is officially AWS for the time being. And then I'm sure others will write a lot of content about this because this is a great release and your team has done an absolutely amazing job. So congrats to all of you.

Justin: Thank you.

Rebecca: Yeah, and when a daily practitioner developer, someone like Jeremy says this is the best developer experience they've had, that is very real. It's not always easy to say that about AWS Services. So like double kudos from someone who's been able to be an observer of a lot of these conversations and it doesn't usually go like that. We're like, "This was a great developer experience." And so that's really awesome.

Rebecca: You two, thanks so much for joining us and sharing your knowledge with the community and sharing about this launch, especially obviously there's a wave that happens when you do launch it. And there's probably a lot of things where you're like, "Wow, I'm just actually tired now, but then all this info comes flooding in and people have all these questions." So we appreciate you fielding ours.

Rebecca: And in terms of not just where people can get started with Step Functions and the serverless paradigm in general and great resources to find, but how can our listeners find out more about you, your Twitter handles and if there's anything that you want to say one more time about the creativity contest happening, we can help get that shout out in the show notes as well.

Justin: Yeah, sure. I'll give you a link to... So I'm on Twitter. I, I'm probably not the most interesting person to follow. I think Sam's probably a lot better than I am. But yeah, I'm really excited about this contest. I'm really to see what folks are going to do with this. So that'll be out there. There's instructions, it's managed through a GitHub repo that we've set up and I'll share a link that you can include in the notes. And we'd love to see people participate and show us their creativity.

Rebecca: Cool. Also, Justin, I would maybe counter to say, it's not an odd, it's an end. And so you could follow Justin and Sam. You don't have to choose. And Sam, where should people find you?

Sam: I'm on Twitter as well. And yeah, I try to do my best on social media. I can't hold a candle to our awesome DAS like Eric. And so I follow more than I post, but I try to be active and amplify all the awesome things our team is doing.

Jeremy: Awesome. All right. Well, we will put all of that in the show notes, as well as some of those other links we mentioned. Thanks again. We appreciate you being here.

Rebecca: Yeah, thanks gents.

Sam: Thanks for having us.

Rebecca: Thank you.