Flipping business rule code in Serverless

Lambda versus step-functions

Over the course of five years, I have the positioning of business rules changing in Serverless landscapes. In the past Lambdas used to rule the landscape and contain all my business rules, increasingly I see the business logic split and scattered to peripheral services. AWS Step-functions has become a really powerful service that could overtake the role of AWS Lambda. This article explores the pros and cons of architecting in this new style.

Let’s put step functions at the heart of our platform!

Lambda in the driver's seat or not?

Some time ago I wrote a blog titled ‘Managing Serverless Spaghetti’. Half a year later I want to reflect on the implications in a different manner. In my previous blog post, I wrote about the downside of extracting business rules and config from lambdas and what you could do about it. Today I want to take a different perspective and embrace it. You can skip over the intro if you have experience with step functions.

Small step functions intro

‘Step functions’ has become one of my favorite services in recent years. It offers a way to create flows, visualize, and manage system state. Using conditionals you can create flow and even loops. It creates finite state machines that once turned on, you can track and trace their execution. For more explanation, you can read up on its AWS docs.

Step functions editor

Step functions at the core of your platform

I consider step functions as a coordinator or conductor. Where AWS service used to be a collection of disconnected tools where my lambdas contained the ‘glue code’ to wire these different services up, you can now use step functions to be that glue function.

AWS step-functions in charge of coordination

With over 200 integrations step-functions can now direct lots of AWS integrations natively without the use of Lambdas. In terms of platform architecture, I would recommend that switching to native integrations should be a deliberate act. Mixing and matching of step-function styles will inevitably lead to poor visibility of your system’s business rules.

In the step-function native interaction, your Lambdas still have some role to play. But I like to see them as small utilities. So: business rules and decision-making should be stripped away and migrated to the state machine. What's left is a collection of micro-functions that offer utility functions unmatched by AWS’s offering.

Consideration on AWS step-functions for native-integrations

Before you migrate your Lambda code to step-functions you might want to consider some consequences and rationale.

Pros

• If you are invested in using step-functions anyway, you could potentially save costs on lambda execution depending on how its implemented.
• Visibility of business logic by externalizing conditionals to step-function flow structures.
• If you prevent too much diversity, this is a good way to prevent Lambda Pinball.

Cons

• The cost of data processing could rise as step-function native integrations will likely lead to more complicated state machines with more steps (so more costs).
• The infrastructure script will rule the application landscape. While I love modern tools like CDK I think the visibility of your business rules is not on par with application-level coding.
• Infrastructure project's code quality is usually entangled up to the stack level and maybe beyond. In the application we have spend decades to improve abstraction and isolation on solutions. I have yet to see similar facilities coming from CDK framework or Terraform.
• Testing practices for step-functions is not on par with the plethora of tools on the application level. Today, it would take an integration test approach to test the intricacies of state machine executions.

To go all-out on AWS step-functions or not?

I think AWS step-functions is a really nice service. It usually gives me great joy to use it, especially in lower-volume interactions. In the bottom line, I would recommend using it for significant business logic. That way the value it wraps matches the cost model better. For multimillion executions, this model can become too costly.

The most important consideration that you need to make is about the slippery slope of where this is heading. One could argue that the transition to step-function will get you into a low-code domain of sorts. The improved Studio UI offers a visually appealing interaction to model your state machines. However, there are tools for this in the market (e.g. Outsystems, and Mendix) that offer something similar. So should you then not go all the way to a more mature tool? The big difference is the native integration with AWS services. That's unmatched in the current low-code offerings. So depending on your requirements, this could be your new best friend.

Do step-functions or lambda wrap most of the business logic in your environment? Let me know in the comments!