1
00:00:00,120 --> 00:00:01,950
Welcome to the Architecture 
Corner. 

2
00:00:02,000 --> 00:00:04,110
Great to be here. 
Today we're looking at some 

3
00:00:04,120 --> 00:00:08,230
really interesting significant 
updates coming to AWS Step 

4
00:00:08,240 --> 00:00:11,040
Functions in 2025. 
Yeah, the G Sonata support and 

5
00:00:11,050 --> 00:00:13,910
the new IO processing model big 
changes. 

6
00:00:13,920 --> 00:00:16,410
Exactly. 
Mario Bittencourt flagged these 

7
00:00:16,420 --> 00:00:18,430
recently. 
Our goal today is really to 

8
00:00:18,440 --> 00:00:21,330
explore how these innovations 
might streamline low code 

9
00:00:21,340 --> 00:00:24,290
development for you, making 
those complex workflows, well, 

10
00:00:24,300 --> 00:00:26,510
hopefully more powerful and 
easier to manage. 

11
00:00:26,520 --> 00:00:29,390
I think foundational shift isn't
too strong a term here. 

12
00:00:29,480 --> 00:00:32,369
You can really change how we 
approach designing these state 

13
00:00:32,380 --> 00:00:34,330
machines. 
OK, foundational shift. 

14
00:00:34,370 --> 00:00:37,150
I like that. 
So before these updates, working

15
00:00:37,160 --> 00:00:41,250
with step functions using the 
Amazon states language ASL, it 

16
00:00:41,260 --> 00:00:45,060
often felt a bit complex. 
What were the main hurdles you 

17
00:00:45,070 --> 00:00:47,700
saw people running into? 
Yeah, complex is putting it 

18
00:00:47,710 --> 00:00:49,880
mildly sometimes. 
There was definitely a steep 

19
00:00:49,890 --> 00:00:52,660
learning curve, mostly because 
all those different O fields, 

20
00:00:52,730 --> 00:00:55,740
Yeah, input path, output path 
parameters, result selector, 

21
00:00:55,750 --> 00:00:59,700
result path, just figuring out 
which one did what and when to 

22
00:00:59,710 --> 00:01:01,710
use. 
It that could be confusing. 

23
00:01:01,770 --> 00:01:06,050
It really could, and the bigger 
issue maybe was if you needed 

24
00:01:06,060 --> 00:01:09,720
data from way back at the start 
of your workflow, like several 

25
00:01:09,730 --> 00:01:11,780
steps later. 
Oh yeah, the pass through 

26
00:01:11,790 --> 00:01:13,140
problem. 
Exactly. 

27
00:01:13,240 --> 00:01:16,650
You have to manually thread that
piece of data through every 

28
00:01:16,660 --> 00:01:19,950
single intermediate step. 
It made the state definitions 

29
00:01:19,960 --> 00:01:22,630
messy and honestly pretty 
brittle. 

30
00:01:22,880 --> 00:01:25,250
Like playing telephone with your
critical data. 

31
00:01:25,300 --> 00:01:27,890
Lots of boilerplate just to keep
info alive. 

32
00:01:27,940 --> 00:01:31,290
OK, so it sounds like these new 
updates directly tackle those 

33
00:01:31,300 --> 00:01:33,250
pain points. 
What are the key improvements? 

34
00:01:33,260 --> 00:01:36,440
So 2 main things. 
First up, variables. 

35
00:01:36,510 --> 00:01:39,660
Think of them like little 
temporary storage spots right 

36
00:01:39,670 --> 00:01:43,040
inside your workflow execution. 
OK, you can save data, change 

37
00:01:43,050 --> 00:01:45,820
it, refer back to it later 
without having to pass it output

38
00:01:45,830 --> 00:01:48,140
to input between states. 
They have a clear scope get 

39
00:01:48,150 --> 00:01:50,380
updated when the state finishes.
And they can hold a decent 

40
00:01:50,390 --> 00:01:54,080
amount of data. 
Yeah, up to 256 KD each and you 

41
00:01:54,090 --> 00:01:56,210
get a total of 10mm for the 
whole execution. 

42
00:01:57,090 --> 00:01:59,180
That's pretty generous. 
It might mean you don't need to 

43
00:01:59,190 --> 00:02:02,960
use, say, S3 quite as often just
to shuttle larger payloads 

44
00:02:02,970 --> 00:02:05,460
around internal. 
That alone sounds like a huge 

45
00:02:05,470 --> 00:02:09,490
win for cleaner workflows and 
managing state less plumbing. 

46
00:02:09,500 --> 00:02:12,980
It really is less plumbing, less
cognitive load, trying to track 

47
00:02:12,990 --> 00:02:15,020
where data is is coming from and
going to. 

48
00:02:15,490 --> 00:02:18,960
Which brings us nicely to the 
second big thing, simplified IO.

49
00:02:19,010 --> 00:02:23,340
OK, basically they've taken that
confusing list of five IO fields

50
00:02:23,550 --> 00:02:25,800
and boiled it down to just two 
concepts. 

51
00:02:25,870 --> 00:02:28,530
You've got arguments for the 
data you feed into a task, 

52
00:02:28,540 --> 00:02:30,450
right? 
And output for the date of the 

53
00:02:30,460 --> 00:02:32,030
state makes available when it's 
done. 

54
00:02:32,100 --> 00:02:33,650
That's it. 
Much simpler mental. 

55
00:02:33,660 --> 00:02:36,980
Model arguments in output out. 
OK, that definitely sounds more 

56
00:02:36,990 --> 00:02:39,530
intuitive. 
So cleaner data flow, simpler 

57
00:02:39,540 --> 00:02:42,590
IO. 
But the big promise is often 

58
00:02:42,600 --> 00:02:46,140
about less custom code, right? 
How does Jason Outta fit into 

59
00:02:46,150 --> 00:02:48,190
this? 
Yeah, Jason, Audi S kind of the 

60
00:02:48,200 --> 00:02:49,950
engine driving these new 
capabilities. 

61
00:02:49,960 --> 00:02:52,790
It's a query and translation 
language specifically for Jason.

62
00:02:52,860 --> 00:02:54,970
OK, I've heard of it, but how 
does it work here? 

63
00:02:55,040 --> 00:02:57,710
Well, it's the syntax you use 
now for defining those arguments

64
00:02:57,720 --> 00:03:01,030
and output fields, and also for 
manipulating the new variables. 

65
00:03:01,380 --> 00:03:03,920
And the cool thing is, Jon is a 
pretty powerful. 

66
00:03:03,980 --> 00:03:08,010
O you can do logic inside the 
step function definition itself.

67
00:03:08,060 --> 00:03:09,760
Exactly. 
You could do things like filter 

68
00:03:09,770 --> 00:03:13,290
arrays, maybe pull out only the 
orders marked fragile from a 

69
00:03:13,300 --> 00:03:16,130
list. 
Or you could calculate a sum 

70
00:03:16,460 --> 00:03:20,450
like the total value of items in
an order, even generate hashes. 

71
00:03:20,460 --> 00:03:21,930
Without needing a Lambda 
function. 

72
00:03:22,000 --> 00:03:24,430
Often, yes. 
For those kinds of data 

73
00:03:24,440 --> 00:03:27,650
manipulation tasks that 
previously might have required a

74
00:03:27,660 --> 00:03:30,900
dedicated little Lambda 
function, you might now be able 

75
00:03:30,910 --> 00:03:33,620
to do it directly within the 
step function state definition 

76
00:03:33,670 --> 00:03:36,760
using J Sonata. 
Wow, OK, so that could genuinely

77
00:03:36,770 --> 00:03:41,100
mean fewer moving parts, simpler
deployments for certain logic. 

78
00:03:41,190 --> 00:03:44,280
Potentially yes, less code to 
write, deploy and manage 

79
00:03:44,290 --> 00:03:46,860
separately. 
But like with any powerful tool,

80
00:03:46,870 --> 00:03:49,870
there are trade off to consider.
It's not all smooth sailing. 

81
00:03:50,510 --> 00:03:52,700
Always the case. 
What should people be thinking 

82
00:03:52,710 --> 00:03:55,020
about as they start using this? 
What are the potential 

83
00:03:55,030 --> 00:03:57,140
downsides? 
Well, two main things jump out. 

84
00:03:57,150 --> 00:04:00,080
First, you could end up 
fragmenting your logic if you 

85
00:04:00,090 --> 00:04:03,780
have some business rules in 
Jonata within your ASL and other

86
00:04:03,790 --> 00:04:07,240
related logic in say a Lambda 
function called by another 

87
00:04:07,250 --> 00:04:08,740
state. 
Right, it could get harder to 

88
00:04:08,750 --> 00:04:10,710
see the whole picture. 
Exactly. 

89
00:04:10,960 --> 00:04:14,370
Really complex Jason at 
Expressions embedded directly in

90
00:04:14,380 --> 00:04:17,640
the workflow definition might 
actually be harder to understand

91
00:04:17,649 --> 00:04:21,079
and debug than straightforward 
code in an IDE. 

92
00:04:21,329 --> 00:04:25,760
Hmm, OK, maintainability could 
suffer if you go too complex 

93
00:04:25,770 --> 00:04:28,360
with the embedded logic. 
What's the second point? 

94
00:04:28,490 --> 00:04:30,300
The second is around automated 
testing. 

95
00:04:30,830 --> 00:04:34,100
The tooling and frameworks for 
automatically testing complex 

96
00:04:34,110 --> 00:04:37,620
JSON on expressions, especially 
within the context of a step 

97
00:04:37,630 --> 00:04:40,640
function state, aren't as mature
as what we have for standard 

98
00:04:40,650 --> 00:04:43,200
code like Python or Node JS and 
a Lambda. 

99
00:04:44,340 --> 00:04:47,680
So you might need more manual 
testing or find it harder to get

100
00:04:47,690 --> 00:04:50,860
the same level of confidence for
really critical transformations.

101
00:04:50,930 --> 00:04:53,270
You might, yeah. 
It's something to be aware of, 

102
00:04:53,340 --> 00:04:55,700
especially for logic that has 
significant business impact. 

103
00:04:55,710 --> 00:04:57,600
You need to plan your testing 
strategy carefully. 

104
00:04:57,670 --> 00:04:59,960
Makes sense. 
So clarity and testability are 

105
00:04:59,970 --> 00:05:02,580
key things to watch. 
But overall the benefits seem 

106
00:05:02,590 --> 00:05:04,780
pretty clear. 
Potentially less code, maybe 

107
00:05:04,790 --> 00:05:07,780
faster delivery, lower 
operational overhead in some 

108
00:05:07,790 --> 00:05:09,560
cases. 
Absolutely. 

109
00:05:09,630 --> 00:05:12,010
I think the winning approach is 
going to be a balanced 1. 

110
00:05:12,130 --> 00:05:15,160
Using variables in the 
simplified IO seems like a clear

111
00:05:15,170 --> 00:05:18,120
win almost everywhere. 
It just cleans things up. 

112
00:05:18,170 --> 00:05:19,860
Yeah, that feels like a no 
brainer. 

113
00:05:19,870 --> 00:05:21,580
Right. 
The more strategic part is 

114
00:05:21,590 --> 00:05:25,210
deciding how much logic to push 
into play Sonata versus keeping 

115
00:05:25,220 --> 00:05:26,850
it in dedicated compute like 
Lambda. 

116
00:05:27,610 --> 00:05:31,060
That depends entirely on your 
specific needs, the complexity 

117
00:05:31,070 --> 00:05:33,040
involved in your team's comfort 
level. 

118
00:05:33,110 --> 00:05:37,150
So use the simple stuff widely. 
Be thoughtful about the advanced

119
00:05:37,160 --> 00:05:40,220
Jon auto transformations. 
It's about finding that sweet 

120
00:05:40,230 --> 00:05:42,520
spot for your context. 
Precisely. 

121
00:05:42,990 --> 00:05:44,380
OK, this has been really 
insightful. 

122
00:05:44,390 --> 00:05:46,480
Remember, you can check the 
description For more information

123
00:05:46,490 --> 00:05:50,120
on these updates and a reminder 
to subscribe for free to the 

124
00:05:50,130 --> 00:05:52,100
Architecture Corner newsletter 
over at 

125
00:05:52,110 --> 00:05:55,700
architecturecorner.substack.com.
Definitely worth digging into 

126
00:05:55,710 --> 00:05:57,740
the specifics of this impacts 
your workflows. 

127
00:05:57,900 --> 00:06:00,320
For sure. 
It leaves me wondering, though, 

128
00:06:00,390 --> 00:06:04,200
as we get these powerful locode 
tools, how do we ensure we're 

129
00:06:04,210 --> 00:06:07,320
not just optimizing for initial 
speed, but also for that crucial

130
00:06:07,330 --> 00:06:09,440
long-term clarity and 
maintainability? 

131
00:06:09,810 --> 00:06:11,280
That balance feels key.