Previous Serverless Version 0.5.x VS terraform

Github | Website

- With Lambda, you manage creating and building the container yourself, as well as updating the Lambda function code. There are tools out there such as sst or serverless.com which help streamline this.

If you'd like to use Lambda, usually you need to engineer FOR it, from day one, you don't (often) get to choose some other framework and shoehorn it into Lambda and Serverless. There's some great frameworks to help deploy code into Lambda easily and create REST endpoints for things, one such frameworks is serverless.com that helps easily deploy to it, but it lacks a framework for doing REST that also supports local emulation (as easily). For that, I recommend a framework by AWS called Chalice. This is an amazing REST framework that runs a proxy that works locally and deploys exactly the same on Lambda, it is Python however.

After knocking out a README with a set of goals and a list of TODOs to check off as I made progress, I spent about 10 hours over a weekend trying to get something to work. I used serverless for making Lambda easier, Github Actions for the deploy pipeline and store my credentials; and sadly I rolled my own access_token refresh logic because I couldn't find a helper that just did that for me! wtf!?

The backend is built with serverless.com (lambda, dynamodb, sqs, appsync). The good thing is that all the backend is stored in a file and you can deploy multiple stacks on the same account using seed.run . You don't really need EC2/Fargate when you have lambdas and you know that most of the time will be idle time. The same with cache I wouldn't think of it right now until you see the workload you are facing. Dynamodb once you understand it and have a proper design it's the fastest thing you can have. On my appsync calls I'm using Dynamodb as a cache because it's cheaper...

Apache Kafka allows for asynchronous communication in a distributed ecosystem. It allows producers to publish messages on topics that are then ingested by consumers interested in those topics. As a concept, pub-sub models have been around for ages. However, the beauty of Kafka is in the how — using partitions and consumer groups, Kafka can scale the rate of consumption of messages with minimal dev and economic overhead. In this tutorial, I’ll take you through how to provision a managed Kafka cluster using the AWS Managed Stream for Kafka (MSK) service. We’ll use the serverless framework to create and maintain the infrastructure for MSK and the supporting VPCs, subnets, etc.

I run my personal project on AWS. I has been running for 4+ years now and I never had a local environment. I took the serverless route. That is appsync, lambda, dynamodb, sqs to build the stack. I'm using serverless.com to have all the resources defined in a yaml files which will deploy multiple stacks. I'm using seed.run to manage that part because it's much more simple than to do it manually.

The solution is deployed using serverless.com

State Encryption was one of those long requested features[0] (I had it on my ideas list for years[1]) that Hashicorp didn't have much incentive to build. I don't think it has to with distancing opentofu as such, but the opentofu team prioritizing the right things that customers actually need.

[0]: https://github.com/hashicorp/terraform/issues/9556

[1]: https://github.com/captn3m0/ideas#-mars-terraform-remote-htt...

https://github.com/hashicorp/terraform/issues/34402

I’m not a lawyer and have no idea who is right or wrong but I understand why Hashicorp is scrutinizing this.

Just to give an example of the power of Go for CLI builds, you may have already used or at least heard of Docker, Kubernetes, Prometheus, Terraform, but what do they all have in common? They all have a large part of their usability via CLI and are developed in Go 🐿.

Each app’s front end is built with Qwik and uses Tailwind for styling. The server-side is powered by Qwik City (Qwik’s official meta-framework) and runs on Node.js hosted on a shared Linode VPS. The apps also use PM2 for process management and Caddy as a reverse proxy and SSL provisioner. The data is stored in a PostgreSQL database that also runs on a shared Linode VPS. The apps interact with the database using Drizzle, an Object-Relational Mapper (ORM) for JavaScript. The entire infrastructure for both apps is managed with Terraform using the Terraform Linode provider, which was new to me, but made provisioning and destroying infrastructure really fast and easy (once I learned how it all worked).

For example, integrating Terraform for infrastructure as code (IaC) into the IDP can streamline updates and rollbacks.

In this project, you will understand and get hands on experience around the entire concept around CI/CD from applications perspective. To fully gain real expertise around this idea, it is best to see it in action across different programming languages and from the platform perspective too. From the application perspective, we will be focusing on PHP here; there are more projects ahead that are based on Java, Node.js, .Net and Python. By the time you start working on Terraform, Docker and Kubernetes projects, you will get to see the platform perspective of CI/CD in action.

Infrastructure as Code (IaC) is an important part of any true hosting operation in the public cloud. Each of these platforms has their own IaC solution, e.g. AWS CloudFormation. But they also support popular open-source IaC tools like Pulumi or Terraform. A category of tools that also needs to be discussed is API gateways and other app-specific load balancers. There are applications for internal consumption, which can be called microservices if you have a lot of them. And often microservices use advanced networking options such as a service mesh instead of just the native private network offered by a VPC.

To quickly deploy the architecture, we will be using Terraform. With Terraform, we can automate the deployment process and have our infrastructure up and running in minutes.