Intrinsic functions, service integrations, local testing and more are great features because of which developers like and use Step Functions.
This article focuses on the other side of Step Functions: it looks at how their features can be used to improve and strengthen organizations, handovers, internal discussions and collaboration.
A brief introduction
Before we dive deeper into how Step Functions can ease and improve certain phases of the software development lifecycle, lets learn what Step Functions are. Official definition:
AWS Step Functions is a serverless function orchestrator that makes it easy to sequence AWS Lambda functions and multiple AWS services into business-critical applications. Through its visual interface, you can create and run a series of checkpointed and event-driven workflows that maintain the application state. The output of one step acts as an input to the next. Each step in your application executes in order, as defined by your business logic.
You can think of them as glue between other AWS services (Lambda, Fargate, DynamoDB…). Their features, such as parallel execution, waiting, configurable retries and error handling almost make them (oh boy, I'm gonna say it) super glue.
To read more about Step Functions and their features, make sure to visit the Developer Guide.
Now that we know what Step Functions are, lets look at several software development lifecycle phases and how Step Functions can bridge gaps, create bridges and make everyone (yes, even product owners) happy.
Design (ideation) phase
If you asked three developers on how a certain problem can be solved you would probably get five different opinions. If you asked three solutions architects, they would all say "It depends" so we're not gonna focus on them today (❤ to all solutions architects out there).
To level the playing field, Step Functions come with a great feature called Workflow Studio. It is a low-code visual workflow builder with import/export capabilities and much more. Do check it out!
What does the Workflow Studio help with on the flip side? It allows developers and business stakeholders to sit together and model their business process visually. That process then gets translated to code, but that's besides the point. The point is you got them together. They are working on solving a business requirement together.
Komunikacija je vrlo bitna (Communication is very important) and you wouldn't understand this article if I wrote it in Serbian. The same goes for collaboration in a business setting. "Business" and "tech" must speak the same language to collaborate efficiently and not lose important details in the translation.
Step Function's Workflow Studio does just that -- levels the playing field with a common denominator that everyone can understand: arrows and rectangles. They are far easier to move and rearrange today than three months from now when running in production and hopefully making money.
Development phase
Stakeholders and developers sat together, they hashed out a solution neither side is happy with (a compromise) and now is the time to build it. Developers want to use this cool "new" service called DynamoDB. Stakeholders want it done yesterday.
Enter Service Integrations. With them both of these sides can have their cake and eat it too.
Optimized Service Integrations work with Lambda, DynamoDB, ECS, EKS, Athena and more - directly. That means you can run Lambda functions, run containerized apps, perform DynamoDB and Athena queries without writing custom code.
Less custom code == less code to test and maintain in the future. If time is money, and if money saved is money earned, then time saved is time earned.
Time for eating that cake. Time for new features. Time for security audits. Time for innovation and learning. Time to finally understand how DynamoDB single table design works (probably not enough time for that).
The same can be concluded for Intrinsic Functions. They are functions that are built into Step Functions and can perform basic data operations. More importantly, they save you from writing something similar yourself (and be responsible for maintaining it).
Handovers
Colleagues leaving is as inevitable as sitting in a two-and-a-half hour long handover session and still not knowing as much as that colleague forgot about the project.
Visual representation of a business process mixed with implementation details would sure help a lot, right? You have that with Step Functions!
Show this photo to anyone in the organization that is a little bit familiar with the business domain and they can understand what is happening. Show this photo to any developer in the organization and they'll be like: "I got you, I can take this over".
The only handover you need to have is about that first task with custom business logic. The rest is just piping data from A to B. Arrows and rectangles, nothing more (i'm trivializing a bit for dramatic effect).
Operations (maintenance) phase
Building a system is one thing. Operating it successfully is a completely different beast. Especially if you take into account that not every organization is mature enough to have application-level metrics (tracing), structured logging and runbooks for those P1s you tried to snooze but they alerted… again.
All of the above are important to have in an organization, and businesses (and investment funds) are investing heavily into observability tools and platforms.
So how can humble Step Functions help there? You tell me.
Can you tell me what is failing?
Can you tell me what is failing from this?
How about now?
"Arrows and rectangles" save the day yet again! You can immediately tell which part of the process went wrong. From there you can drill-down by viewing the Lambda function that failed or its logs:
Your operations team will thank you. Customer support agents will thank you. Structured logging and APM will for sure help from here.
Last but not least, I thank you for allowing me to show you how certain features of Step Functions can improve organizations, internal processes and collaboration in several software development lifecycles.
Top comments (0)