Darryl R.’s Post

Learn by example! Setting up an app with real time communication is a common use case today. Whether it's some type of social messaging app, a chat system, or something else - users expect to get immediate updates. There are many ways to setup something like this but one of the simplest approaches is to use managed tools on AWS like the API Gateway and serverless components like AWS Lambda. In the example below from Sadi Kirkbes a simple implementation of a real time app is coded in NodeJS that has JWT authentication and logging included using very little code. The example of is all setup with terraform making it simple to spin up and tear down. https://lnkd.in/eHMy-pfb

Combining Kubernetes with Serverless may sound like an oxymoron but it is a real approach you can use. Using Kubernetes may be overkill for many applications but there are cases where it is a requirement or a good fit due to regulatory concerns, the orchestration experience it provides, the requirement to work with other tools in Kubernetes or other reasons. Typically running Kubernetes in the cloud involves creating and managing worker node virtual machines in your cluster. For example on AWS spinning up EC2 instances. There is another option with the Elastic Kubernetes Service (EKS) on AWS using Fargate compute. With Fargate there still are servers (of course) but AWS manages them for you. Another interesting approach for Functions as a Service (FaaS) with Kubernetes is KNative. It allows you to run functions in your cluster without using services like AWS Lambda. This article from Luiz Eduardo Serrano discusses these serverless approaches with Kubernetes. https://lnkd.in/egRQVXXw

With any important data in the cloud you always want to have a backup strategy. Each service supports different backup approaches. With DynamoDB on AWS you can setup point in time restores, on demand backups, use DynamoDB streams to push data elsewhere or you can also integrate with AWS Backup. One level of security that might be worth considering is doing a backup to another AWS account or potentially to a different cloud provider. This article from se-piyush shows how you can use Terraform to setup cross account backups of DynamoDB tables using AWS Backup. https://lnkd.in/eRK4Ptpk

If you have a requirement to run your containers on AWS in a Kubernetes environment then you will likely end up using the Elastic Kubernetes Service (EKS). If your containers running in EKS need to interact with resources outside EKS that are running in your AWS account you will need to give them permissions. Many demo apps or not very secure approach’s involve assigning rather open permissions to worker nodes in your cluster allowing any container running on them to have all those permissions. The best approach though is to give the minimum permissions needed to pods themselves. This can be done on AWS using IAM Roles for Service Accounts (IRSA). With IRSA you associate Kubernetes Service Accounts with IAM Roles and then run pods with the service account that has the role with the permissions it needs. This article from Suraj Solanki shows how to set this up using Terraform. https://lnkd.in/eR_ks4bX

You should be using an Infrastructure as Code (IaC) tool to manage your cloud resources. When using Terraform for your IaC tool one issue that will come up quite often is that the state your terraform config files know about for your resources will be different than what is actually present in your cloud accounts. This is called "drift". There can be many reasons for this including manual changes done outside Terraform (either expected or not), internal changes by the cloud provider (like AWS updating versions of resources to include new patches), or others. When it comes time to doing the next "terraform apply" you will need to understand how to get your Terraform state back in sync as to not overwrite desired changes or to wipe out ones you don't want to keep. https://lnkd.in/equNZe2W

If your applications run in containers on AWS, one approach to consider using is Fargate compute with the Elastic Container Service (ECS). With Fargate you specify what amount of memory and cpus you want and AWS takes care of spinning up and managing the Virtual Machines for you. You can build your container images and store them in the Elastic Container Registry (ECR) and the Fargate tasks will pull them from there. This post from Kim di centa le van kim details building your container images, pushing them to ECR and running them inside ECS with Fargate. https://lnkd.in/egDCczPN

There are a lot of ways to waste $$$’s with cloud providers like AWS. Between NAT Gateways, EBS Volumes, and now IPv4 public addresses there are many common ways to get dinged. One that doesn’t get mentioned much in this category is Elastic Container Registry (ECR). This is a private container image registry that is very useful but the costs can add up if you push tons of image versions during development and don’t clean them up or set lifecycle rules. The article below from Prithvi Jethwa shows how ECR costs can add up and how you can setup lifecycle rules to help. https://lnkd.in/e6NJprbq