I’ve been following along the past couple of weeks in the “wake” of the article by the Prime Video Team. I’ve seen a lot of rebuttal-type articles by some folks that I respect so I didn’t want to continue to add more of the same opinions in that direction. I think people that have spoken up in support of Serverless architecture have done a fantastic job of articulating why and when not to. What I wanted to write was something in my more official day-to-day title as CTO and why I support Serverless design choices for my teams and customers. So consider this, Why Serverless, a CTO Perspective.
Golang Private Module with CDK CodeBuild
Even experienced builders run into things from time to time that they haven’t seen before and this causes them some trouble. I’ve been working with CDK, CodePipeline, CodeBuild and Golang for several years now and haven’t needed to construct a private Golang module. That changed a few weeks ago and it threw me, as I needed to also include it in a CodePipeline with a CodeBuild step. This article is more documentation and reference for the future, as I want to share the pattern learned for building Golang private modules with CodeBuild.
Custom API Gateway Authorizer with Golang
One of the nice things about building with Serverless is that you can design things in a way that the pieces are composeable. This means that you can put logic cohesively with other like-minded logic and then keep things loosely coupled from other components so that things are easy to change without being too fragile. When building an API, you often need an Authorizer of sorts to validate the token that is being supplied. In this article, I’m going to walk through building a custom API Gateway Authorizer with Golang.
Building Golang Lambda Functions
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.
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.