Application Load Balancers (ALB’s) aim to move much of the functionality currently offered by web servers like apache and nginx into the cloud. This means certificates, http to https redirects, management of dynamic containers and having different pages of your web application handled by different applications or lambdas are all handled by ALB’s.
Moving to containers brings predictability that works in development will also work in production. Containers stop you wasting money on large servers that have 3% utilization by having multiple containers consume all the available resources. Services such as AWS Fargate can remove the maintenance of servers the containers run on.
Once customers are on Amazon EC2’s most move to containers and or serverless. Moving to containers is normally completed in a phased approach application by application. Implementing ALB’s is usually a shorter project that benefits all applications at one time. It is almost always a good idea to use ALB’s with containers, however we recently found that trying to get an ALB installed before the container environment was built would waste many thousands of dollars.
In one client example when implementing ALB’s before containers there was rework in the AWS CloudFormation templates. There was a large amount of work required because of modifications to automation and orchestration software. Automation software examples are Jenkins, Bamboo and TeamCity. Orchestration software examples are Puppet and Hashicorp Consul. The main driver in using ALB’s was to get more security using AWS WAF (Web Application Firewall) and help with AWS Direct Connect routing. The choice to use ALB’s was abandoned until the container environment was implemented.
The post ALB’s before Containers or Containers before ALB’s appeared first on PolarSeven.