re:Invent 2022 wishlist - shoot for the moon

This is the second in my series of blog posts detailing my hopes for new features to be announced at re:Invent 2022. These are a little more pie-in-the-sky, shoot-for-the-moon etc. type ideas, however a guy can dream!

Step Functions custom intrinsic functions

Step Functions is great and it’s recently had a whole load of new intrisic functions added to it. I’d like it to go one step further and allow for the registration of custom intrinsic functions. I hear you ask, is this not just the same as using the same Lambda function in multiple workflows?

My wish is for there to be a registry where custom functions can be uploaded. These functions shouldn’t have the ability to utilise any external dependencies outside of the language’s core. For example, no creating an intrinsic function that does something obscure with boto3. There should also be a limit on how many milliseconds the code can take to run. Intrinsic functions in their current form are tiny units of functionality that execute almost instantaneously - the ability to create your own and upload them to a registry shouldn’t change this.

In my head, custom intrinsic functions could be defined via CloudFormation with syntax like the below.

AWSTemplateFormatVersion: '2010-09-09'
Transform: 'AWS::Serverless-2016-10-31'
Description: > 
  Creates a Step Functions intrinsic function
  registry and registers a function

Resources:  
  IntrinsicFunctionRegistryPolicy:
    Type: 'AWS::StepFunctions::IntrinsicFunctionRegistryPolicy'
    Properties:
      PolicyText:
        Version: '2012-10-17'
        Statement:
          - Sid: 'ExecuteFunctionFromAnotherAccount'
            Effect: 'Allow'
            Principal:
              AWS: 'arn:aws:iam::210987654321:root'
            Action:
              - 'states:ExecuteCustomIntrinsicFunction'
            Resource: 'arn:aws:states:us-west-2:123456789012:intrinsicFunctionRegistry/*'

  CustomIntrinsicFunction:
    Type: 'AWS::StepFunctions::IntrinsicFunction'
    Properties:
      Name: 'SliceString'
      Parameters:
        - Type: String
        - Type: Integer
        - Type: Integer
      Code: |
        def run(string, start, end):
            return mystring[start:end]

A workflow could then utilise the custom intrinsic function as below.

Comment: > 
  A workflow that uses a custom intrinsic function
StartAt: 'Slice string'
States:
  Slice string:
    Type: 'Pass'
    Parameters:
      value.$: 'Custom.SliceString($.fullString, 2, 5)'
    ResultPath: '$.slicedString'
    Next: 'Invoke external Lambda function'

AWS Serverless Specialty certification

I know there’s been lots of discussion in the community about a serverless speciality certification. As far as I know, there are no current plans to introduce one as the thoughts are that the other certifications cover the topic well enough. I’m not sure I entirely agree with that.

I’d really like to see a certification solely focused on serverless tools. Whilst the Solution Architect Associate and Developer Associate do cover a lot of the day-to-day uses of serverless, I believe that advanced serverless patterns are so commonplace now that there should be a way to identify that an individual can go that level deeper.

The types of topics that I’d expect to see in this could include various architecture patterns for orchestrating a serverless system, a deep understanding of EventBridge beyond just responding to AWS events, how to optimise the big-hitters of the serverless world such as Step Functions (when to use standard vs express workflows) and Lambda functions (cost vs performance, reserved concurrency etc.)

EventBridge graph visualisation

The final wish for this week keeps with the serverless theme. EventBridge is increasingly becoming the heart of a significant number of AWS architectures. Whilst AWS have released some tools, such as Schema Registry, to make the organisation and control of event driven architectures easier - what I’m hoping for is a way to visualise on a graph how events are flowing around.

For example: the graph could show the rates at which events are being fired; what resources are being triggered in response to events; whether events are failing to be delivered and if the schema has changed from what is expected.

I see this graph as not just a tool for operational monitoring, but also an easy way for developers to see what events a particular service is sending and also the rate at which those events would need to be responded to. Admittedly, good documentation for a microservice should make this abundantly clear; we all know what happens with documentation though!

Wrapping up

Heavy on the wishes in the serverless arena this week, we’ll see what happens. Two blog posts down, one to go! Check back next week for the final three items on my wishlist.