Golang

cdk8s (Cloud Development Kit for Kubernetes) is an an open-source framework (part of CNCF) using which you can define your Kubernetes applications with regular programming languages (instead of yaml). Some of the previous blogs on this topic covered the getting started experience and using cdk8s-plus library to further improve upon the core cdk8s library features. We are going to continue and push cdk8s even further. This blog post will demonstrate how you can use Kubernetes Custom Resource Definitions with cdk8s. We will start off with a simple Nginx example and then you will use the combination of Strimzi project CRDs along with Go and cdk8s to define and deploy a Kafka cluster on Kubernetes!

Replicate DynamoDB data from one table to another

This blog post will help you get quickly started with DynamoDB Streams and AWS Lambda using Go. It will cover how to deploy the entire solution using AWS CDK.

The use case presented here is pretty simple. There are a couple of DynamoDB tables and the goal is to capture the data in one of those tables (also referred to as the source table) and replicate them to another table (also referred to as the target table) so that it can serve different queries. To demonstrate an end-to-end flow, there is also an Amazon API Gateway that front ends a Lambda function which persists data in the source DynamoDB table. Changes in this table will trigger another Lambda function (thanks to DynamoDB Streams) which will finally replicate the data into the target table.

The previous blog post covered how to get started with cdk8s (Cloud Development Kit for Kubernetes), that is an an open-source framework (part of CNCF) using which you can define your Kubernetes applications using regular programming languages (instead of yaml).

You were able to setup a simple nginx Deployment and accessed it via a Service - all this was done using Go, which was then converted to yaml (using cdk8s synth) and submitted to the cluster using kubectl. This was a good start. However, since the core cdk8s library is pretty low-level (for a good reason!) the code involved lot of boilerplate (you can refer to the code here).

Infrastructure as Code (IaC) is a well established paradigm and refers to the standard practice of treating infrastructure (network, disk, storage, databases, message queues etc.) in the same way as application code and applying general software engineering practices including source control versioning, testing and more. For exampple, Terraform and AWS CloudFormation are widely-adopted technologies that use configuration files/templates to represent the infrastructure components.

Infrastructure-IS-Code - A different way of thinking about this

Imagine you have an application that comprises of a Serverless function fronted by an API Gateway along with a NoSQL database as the backend. Instead of defining it in a static way (using JSON, YAML etc.), one can represent these components using standard programming language constructs such as classes, methods, etc. Here is pseudo-code example:

This is the second blog post of this two-part series that uses a practical application to demonstrate how to integrate Redis with AWS Lambda. The first part was about the solution overview, deployment and hopefully you were able to try it out end to end. As promised, the second part (this one) will cover the Infrastructure aspects (IaaC to be specific) which is comprised of three (CDK) Stacks (in the context of a single CDK App).

Run your Go app on AWS App Runner service, integrate it with MemoryDB for Redis and use AWS CDK to package and deploy the app along with infrastructure

AWS App Runner allows you to deploy and run cloud-native applications in a fast, simple, and cost-effective manner. You can choose the programming language of your choice since App Runner can deploy directly from source code (in GitHub for example) or a Docker container image (from private or public repo in ECR) - all this without worrying about provisioning and managing the underlying infrastructure.

Hello and welcome 👋🏼 to this two-part blog series that uses a practical application to demonstrate how to integrate Redis with AWS Lambda. The first part (this one) covers the application - by the end of this blog, you should have the solution deployed, played around with it and in the process, have a good overview of the solution.

The second part is about the Infrastructure (IaaC to be specific) aspects - its mostly centred around AWS CDK along with some code walkthrough.

This quick-start uses AWS Cloud9 IDE to help you get up and running with MemoryDB for Redis, quickly

When I was initially exploring some of the AWS services (such as MemoryDB, MSK, Elasticache for Redis etc.), I usually followed the documentation that involved setting up EC2, SSH-ing into the instance, install/copy stuff (language, runtime, code, client etc.) and then try things out. Most often, the first step is the hardest, and it’s important for developers to have the least amount of friction as possible to “get going”.

This is a Go Lambda function that’s packaged and deployed using AWS SAM

Lambda Function URL is a relatively new feature (at the time of writing this blog) that provides dedicated HTTP(S) endpoint for your Lambda function. It is really useful when all you need is a single endpoint for your function (e.g. to serve as a webhook) and don’t want to setup and configure an API Gateway. Looks like I can’t seem to get enough of it! I have written a couple of blog posts on this topic that include a practical example of using it to build a serverless backend and then deploying that solution using AWS CDK.

Deploy a Serverless backend for Slack using Infrastructure-as-code (IaaC)

One of my previous blog post covered how to build a Serverless backend for Slack using by using Lambda Function URL as a webhook. Since I wanted to focus on the application itself, the infrastructure setup part was simplified - using AWS CLI, the function was packaged as a zip file, configured and finally a Function URL was created along with the required permissions.