Week 34, 2019 - App Mesh Routing; Nested Step Functions; CodeBuild Runtimes

By (4 minutes read)

Both App Mesh and Step Functions gained some long-awaited functionalities, and I take a brief look at some improvements to the out of the box runtimes for CodeBuild.

App Mesh Routing

One of the limitations I brought up in my comparison of App Mesh to Istio was the lack of more Routing possibilities. As that came shortly after these were expanded for ALBs that was especially disappointing. As App Mesh has a public roadmap however, I also knew that it was only a matter of time until this would be improved. And that has now happened.

With this release it is now possible to add routing rules based on any header. This can be any type of header, from a session cookie to custom headers you want your application to pass through. Having the routing handle headers makes it easier to have more fine grained control over what a user of the service will see and can do.

However, with the additional control comes additional complexity as well since you will now need to define a priority for your rules. Which makes sense as the rules can conflict with each other. Oh, and of course, this is where I need to point out the usual limitation: CloudFormation hasn’t been updated yet to support this.

Nested Step Functions

Step Functions in AWS are pretty great. They are state machines that let you connect various services together and by following the path you can work around some limitations and build very powerful serverless solutions. Unfortunately, they can also get really big and unwieldy. If you have a complex system that might need to perform dozens or even hundreds of actions it becomes difficult to manage in a single state machine.

Which is why the new support for nested workflows1 is so nice. This allows you to call another Step Function similar to how you would call for example a Lambda function or Fargate container2. Which means that you can split up your large function into a number of smaller ones. Or if you have some actions that are repeated across different Step Functions you can now break these out and maintain them in a single place.

All in all, this is a powerful update that allows you to more easily manage your Step Functions.

CodeBuild Runtimes

In the past month or so, CodeBuild has improved its offering of out of the box runtimes. It actually started even earlier when earlier in the year3 they switched to Ubuntu 18.04 as their default runtime. Considering that until that time they only offered Ubuntu 14.04 this was long overdue.

With the change to 18.04 however they also offered a new way of working where you define which runtime needs to be active for your builds. At the time this was limited to a single language, but last month they added the ability to have more than a single language active.

And last week they added an Amazon Linux 2 runtime as well. This works the same way as the Ubuntu version, but Considering that is still offered as the top pick for running your instances, it’s really nice to see there is now an actual way of testing your applications on there.

While I’m happy to see some improvements to CodeBuild, it still has its fair share of shortcomings. Especially when compared to something like GitHub Actions4. In general though, I really want to see the Code* range of products be improved so I’m happy to see something happening.


  1. Step functions, workflows, and state machines are all terms I see used for the same thing. It would be nice if AWS had decided on a single term, but it looks like we’re stuck with this. And to be fair, at least these are all pretty good names. ↩︎

  2. Yes, Fargate is supported by Step Functions as well. ↩︎

  3. I know emails went out regarding the removal of 14.04 in May, but I can’t find the actual date they made 18.04 available. ↩︎

  4. Technically speaking, GitHub Actions should probably be compared to CodePipeline as it does a lot more than just build, but that would only make it look even worse. ↩︎

comments powered by Disqus