Using CDK for building Golang Lambda functions is a super simple process and easy enough to work with. It is well documented and is a subclass of the Function class defined in aws-cdk-lib/aws-lambda. Unsure about CDK or what it can do for you? Have a read here to get started and see what all the fuss is about.
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.
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.
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.
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.
