Consider the scenario that you wanted to host your business website on AWS. Given that it is so much easier than procuring your own hardware, you want to use AWS.
You containerized your application and ran it on your loaned EC2 instance. How would the public access it?
Use Route53, the DNS service from AWS to register your domain RajuSweets and expose your functionality against that domain.
You can expose EC2 directly. Is there a problem with that?
When your application scales, you can’t just rely on one machine.You have to be able to scale horizontally.
This calls for a layer in front. That layer is the load balancer layer.
What does the load balancer need to do?
It needs to expose itself to the public so that it will receive requests from internet. So, you can tie your load balancer to the DNS.
Where do I get the load balancer from?
From the AWS console, click under Load Balancers section to create a new load balancer. Load balancing is a common well needed thoroughly built functionality. It will take a few minutes for the load balancer to come up.
Wire this up to the DNS
We are clear that we want the ALB as the front end to our business. So we tie the adfsdf.elb.amazonaws.com URL to a more meaningful URL like rajusweets.com and expose with a CRECORD in Route-53.
Targets
ALB does not do any work. It just routes the requests to the targets. Target is where the application runs.
Target group
We are talking about scalability. So, one target would not work. You may need up to ten targets for doing the same thing. A group of endpoints capable of handling a category of requests. Band of brothers.
Different target groups for different requests
Now, for some requests, all you need to do is present static data — say high definition photographs of the sweets you are selling. For other requests, you need to do financial transactions making sure that money comes in at least one, and goes out at most once.
Also, EC2 AMIs can be of various formats — some optimized for memory, some optimized for processing etc, and your business has functionalities — some of which needs more memory, and some more processing etc. You may want to take these into consideration and break up your application into pieces according to the compute involved. Now, if you do break up like that, you would have deployed these functionalities into different kind of instances, more like group of instances, to handle fail over/load etc.
ALB Routing
Load balancer is responsible for the routing. For some requests, I am good enough, for some I need my veteran uncle, and for some I need my big brother. And I can configure the routing with rules — path based routing. If the path says /rajusweets/images , then those requests would go the images target group . If the path says /rajusweets/payments , those requests would go to payments target group .
It is sort of common sense that when you are fronting the application, you would also need to do the routing.
Health check
On the same lines of argument as the routing argument, the ALB needs to know whether the targets are healthy in a target group. Otherwise, it would just pass the ball where there is no fielder.
So, a target needs to say what URL can I call on you so I know you are healthy? Just for this purpose, the target builds a healthcheck endpoint which would return a 200 OK when it is running fine. This would be configured on each of the targets in each of the target groups.
So, when one of the four brothers die, the other three would need to handle the requests.
Autoscaling
If you just let the brothers die when they are unhealthy, your site is not going to last. That is where autoscaling comes in. That is not strictly an ALB topic though.
Keep-alive and idle timeout
When a client is buying sweets, there is a connection from the client browser to the ALB on one hand, and there is a connection from the ALB to the target on the other hand. These connections are not indefinite. There is a time out for both these — keep alive and idle timeout . These are also configurable when you configure the ALB.
Site down message
Sometimes, you need to close your shop to watch the world cup. You can go to the ALB and put a message saying Site down against the paths for which you wan’ t to do that.
Brother’s shop
Sometimes, your application is screwed up due to some bug, and you want to redirect the traffic to another site. ALB can be configured to redirect to a different site.
AWS Regions
EC2 instances are virtual machines running on a server rack physically situated in one of the AWS datacentres. If there is an earthquake, a minor one and the network cable to your baremetal instance disconnects, you will miss out on all the business for the day and your neighbor would have made more money. If you don’t want that you configure the ALB itself in multiple regions.
Note that the ALB itself is not running on a single EC2 instance. It is distributed across regions — mainly to help with earthquakes.
How do you know which target has more load?
That is something that the target needs to track. And it is not really the work of the target. The target is about taking in the money from the customer when he buys sweets. The AWS ecosystem automatically supports cloud watch events that tracks the memory, CPU usage on these EC2 instances.
Autoscaling — create new instance when all instances are at 80 % CPU utilization
This is again an autoscaling thing than a load balancing thing may be. So you can have rules configured to spawn new instances when every brother is at 80 %.
Sticky sessions
ALB supports sticky sessions for scenarios where you don’t want half the work to be done one target, and rest of the work done on another target.
Rules prioritization
You have listener rules on the ALB. These rules are ranked by priority. When I request comes, rules are applied in priority order on the request, and when met, applied. Application might mean a site down page, a redirect to brother's site or an actual handling at the images target group
