terraform-aws-sns-lambda-notify-slack
terraform-aws-elastic-beanstalk-environment
| terraform-aws-sns-lambda-notify-slack | terraform-aws-elastic-beanstalk-environment | |
|---|---|---|
| 1 | 1 | |
| 41 | 298 | |
| - | 0.3% | |
| 5.1 | 5.3 | |
| 23 days ago | 7 days ago | |
| HCL | HCL | |
| Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
terraform-aws-sns-lambda-notify-slack
-
development workflow for software engineers when using mainly serverless and managed services
Just for example look how module "notify_slack" uses (context = module.this.context) output values from the module "this".
terraform-aws-elastic-beanstalk-environment
-
Ask HN: Heroku to Beanstalk?
- If your instance health checks are too stringent, it can become frustrating to try and get your application back in the healthy state. Consider a scenario where your health check page (e.g. /health) pings a non-essential cache database. If your cache database goes offline, EB will treat your application as unhealthy. I recommend keeping the health check page very simple, and setting up separate alarms for other services.
To add to/counteract some points seen in another comment:
Cloudposse has modules that make beanstalk quite manageable with Terraform: https://github.com/cloudposse/terraform-aws-elastic-beanstal...
"Hard to attract talent": I'm skeptical this is an issue in most cases. After all, EB exists so that you don't have to think too much about the infra. For simple use cases, a general understanding of the infra components (not EB-specific) will go a long way. However I can understand talent/developer time could be an issue you're doing something really fancy with EB, such as making heavy use of EB extensions.
"Not the future": This sounds like another way of saying "it's not trendy". Whilst I agree, this point doesn't weigh heavily for me, as I'd try to focus on doing what's right for the application and the team.
What are some alternatives?
AWS-E-Scooter-Tracker - Use AWS Lambda to Pull E-Scooter and E-Bike Location Data, store in S3 & Redshift using Data Vault Data Model, Server to Google Data Studio Dashboard
terraform-aws-dynamic-subnets - Terraform module for public and private subnets provisioning in existing VPC
terraform-aws-ecs-web-app - Terraform module that implements a web app on ECS and supports autoscaling, CI/CD, monitoring, ALB integration, and much more.
terraform-aws-elastic-beanstal
Splunk_Infrastructure - Production Ready Highly Available Splunk Infrastructure Setup using Terraform, Puppet & Jenkins
terraform-aws-ec2-instance - Terraform module for provisioning a general purpose EC2 host
terraform-aws-rds - Terraform module to provision AWS RDS instances
terraform-aws-tfstate-backend - Terraform module that provision an S3 bucket to store the `terraform.tfstate` file and a DynamoDB table to lock the state file to prevent concurrent modifications and state corruption.
sidekiq - Sidekiq worker on Render
terraform-aws-jenkins - Terraform module to build Docker image with Jenkins, save it to an ECR repo, and deploy to Elastic Beanstalk running Docker stack