Using Application Load Balancers to Refactor Monolithic Applications - TriNimbus

Using Application Load Balancers to Refactor Monolithic Applications

Recently AWS announced a new load balancing solution called an Application Load Balancer (ALB) which provides several enhancements for routing HTTP/HTTPS traffic. In addition to supporting features like WebSockets, HTTP/2 support and enhanced logging/metric collection, a new content-based routing system has been implemented.

The initial release supports path based routing for up to 10 priority based rules. This means if an ALB receives a request, the routing rules would be processed from lowest to highest priority until a path condition match is found, otherwise the default rule would be used. Each rule can leverage a different Target Group of resources to process requests.

For example if an ALB received a request for https://<DNS_Name_Targeting_ALB>/shopping/payment/startcheckout the first first rule in the following configuration would direct requests to the MyPaymentAppTargetGroup Target Group of instances.

alb 2

If the request sent to the ALB was https://<DNS_Name_Targeting_ALB>/shopping/products the MyShoppingAppTargetGroup Target Group would be used instead, as the first rule condition doesn’t match.

This ability to match paths from a URL to route requests to a Target Group has several advantages. Target Groups can leverage instances types that are more effective for specific workloads, route sensitive traffic to an isolated set of secured instances, breakout metrics by function (Target Group), and allow partitioning of an applications without having to redesign application URIs.

With these new features available, we can now leverage ALBs to help in breaking up monolithic applications by using smaller steps.  For example if we have a large application that would benefit by migrating part of the application to a microservice architecture, we can use path based routing to direct requests to a new set of resources as follows:

  1. Identify path pattern match conditions.
  2. Review any dependencies required to decouple the application components.
  3. Design the architecture to support the new microservice component.
  4. Deploy the new microservice architecture.
  5. Create a new Application Load Balancer with 2 Target Groups. One for the main application, and one for the new microservice.  Note: CloudFormation support is already available.
  6. Test using the new ALB based application before updating public DNS entries to ensure the new ALB and the new Microservice are working correctly.
  7. Consider solutions to migrate traffic from an existing Classic Elastic Load Balancer, to the new Application Load Balancer. For example you may want to use a Route53 Weighted Record set to send 10% of the traffic to the new ALB to reduce impacts, before routing the remaining traffic from the Classic Elastic Load Balancer.
  8. Keep the Classic Elastic Load Balancer around to allow for a quicker rollback and to ensure all cached DNS entries expire before removing the old ELB.

With each additional function that you want to decouple, you can add additional path routing rules to the ALB potentially without needing to adjust application code.

Over the long term, plan to adjust application code permanently to separate microservices URLs from the main application to reduce single points of failure and avoid hitting any path pattern rule limits.

One last feature added to the Application Load Balancer is support for instance port mapping. This is significant if you are using Docker with ECS Service Auto Scaling and Service Load Balancing.  When a new task is started it can now use a dynamic port to register with the Target Group, allowing multiple similar tasks to be run on the same ECS Container Instance. See this Blog post for additional details on enhancements if you are considering using Docker for your new application.

As a final thought, while Application Load Balancers have a lot of new functionality that make them a very useful tool, not all application workloads will be able to use them. If you need assistance with optimizing the scalability / high availability of your application workloads, or are interested in migrating to a microservice architecture, TriNimbus can help validate, design, implement and support you with your transition.