Choosing Go when Building Lambdas

So you’ve decided to build your first or your 500th Lambda function with AWS. Congratulations! That in and of itself is a great decision that will set you up on a solid foundation for operational excellence, ease of maintenance, flexibility to extend and a whole host of other positives that come along with Serverless. Now, what language are you going to develop this new Lambda in? I’ve been a tremendous proponent for choosing Go when building Lambdas and I’d like to walk you through why.


Testing Step Function workflows Locally

If you’ve been following along for a bit, you know how much of a fan of Serverless I am. And even more specifically, how much I love Step Functions. If you have the problem of needing a highly available workflow coordinator, you can’t do any better than picking it as your tool of choice. However, I am also unapologetically a fan of local development. And this is one place where I feel that Step Functions falls a little bit. So follow me along on this epic towards being able to test Step Function workflows locally.


CDK ASL Definition Extractor

I’ve been working a good bit lately to push testing down when using Step Functions and building some patterns with AWS State Machines Locally. In that same spirit, I’m wanting to be able to create the State Machine in my local container and that comes from the ASL. However, when using CDK and the builder libraries you don’t have an ASL file to work from. So I built this program which I’m calling CDK ASL Definition Extractor which extracts the Definitions from a CDK synth’d CloudFormation file.


Intersection of Technology and People

Admitting my Bias

There is so much buzz in the Serverless world about scalability, reliability, and nano-sized functions with the ability to generate faster speeds to market. These points are no doubt true and there are many other things to consider when picking the tech for your next project. But I’d like to take a look at why choosing Serverless is about more than those attributes. It can be about the intersection of technology and people.

I can admit my bias upfront that I love and often choose Serverless first. And in my current role, my teams are heavily leveraging Lambdas, SQS, SNS, EventBridge, DynamoDB and many other AWS Serverless stalwarts. But what I want to leave you with below is that choosing serverless when building a product can elevate your solutions thinking and center your thoughts around problem-solving which leaves the undifferentiated heavy lifting to be the focus of your partner in AWS.


Cross-Origin Allowlist with API Gateway

Cross-Origin Allowlist with API Gateway

Cross-Origin Resource Sharing is a topic that most developers don’t generally like to talk about it. It is usually a higher-level item that “is just in place” when building and shipping APIs. However, allowing * is not always the best approach. That is a touch outside of this article but I do want to walk through how to build a Allowlist of domains approach with API Gateway and Lambda.


Event-Driven Serverless Data Architecture

The Preface

Follow me along on a journey toward data unification. One of the applications that I work on is a modern, distributed, event-driven and serverless-based architecture. What that means is that data is completely isolated from other components and evolves at a different pace from its neighbor. This type of architecture is achievable using Event-Driven Serverless Data Architecture with AWS.

This is great if you are building a transactional system. You’ve got isolation, independent component scaling and feature delivery that goes at the pace of the team working on it. So what could be wrong? What possibly isn’t good about this outside of the fact that modern distributed systems are complex? The big issue is that all of this data is not in the same place.

What’s the point in having everything in the same place you ask? Simple. Source of truth for:

  • Reporting
  • Public APIs
  • Versioning
  • Audits
  • Data Sandbox

These are just the tip of the iceberg. When you are working on a big system with lots of data, having a single ingress and egress point is important when you are talking about the above.


EventBus Mesh

I’ve been thinking about this topic a lot lately when bringing EventBridge’s EventBus into some applications. On the current projects I’m working on with existing code, I’ve said 100 times, if EventBridge existed when I started them, I wouldn’t have so much SNS->SQS based code lying around. But such is life when working in evolving tech. Enter the EventBus Mesh


Subscribe SNS to EventBridge Pipes

Legacy Serverless to New Serverless

I’ve been thinking and working hard on how I can start to introduce EventBridge and Pipes into some of my existing applications. Unfortunately, I have SNS in front of a lot of my service code and you can’t natively subscribe SNS to EventBridge Pipes. So I’ve started pondering this idea of how to integrate Legacy Serverless Applications into an ecosystem as new features are developed with more modern Serverless concepts. What I really want is a way to connect SNS to EventBridge Pipes.


Canary Deployment for AWS Lambda

In life, when working on anything, small and iterative changes give us the best opportunity for feedback and learning. And it’s through that feedback and failure even that we get better. The same thing can be applied to building software. Small, iterative and independent deploys help us as builders understand if we’ve built the right thing and architected it correctly to handle the conditions asked of it. A technique called Canary Deployment is a popular model and the article below will demonstrate how to perform Canary Deployment for AWS Lambda

However, when deploying more frequently, we also need to do it safely. Shipping unfinished or potentially risky changes can have a big impact on our user base. No one wants to be in the middle of using your software only to be interrupted by a bad change. While we can’t be perfect in our ability to predict the impact or blast radius of a change, we can make it so that if the deploy shows signs of not being good, we can roll that change back without the need for human intervention.