Hi there,
I first picked E, but then changed my mind, because I put myself in that situation and the question literally says "quickly distribute traffic". Now, while C might be the best answer for the long run, but if you are in that situation you don’t really have much time to setup a load balancer and configure your environment. The fastest way to solve this problem is to spin up new EC2 instances and add their public IPs to the multi-value answer DNS record. DNS caching is only for existing sessions and cached for 5 mins normally and our ecommerce website is overloaded with NEW sessions.
Anyone agree or disagree?
2 Answers
Hi Saud,
I like you reasoning but you might be getting into the realm of the "Practitioner’s Curse" here. I suppose "quickly" is a relative term and I think we’d need to deal with DNS cache expiration in either case with multi-value answer Route 53 entry or ELB. The one aspect for me in this question that would steer me toward ELB is the eCommerce aspect. Normally, eCommerce carts use sessions to keep up with a browser’s cart, so we’d want to have something that supported sticky sessions. A round-robin DNS resolution does not provide this for us and a browser might be directed to another server…which would not be good. Does this make sense?
–Scott
This is one of those questions that, while it technically has 2 "best answers", we have to think about what AWS thinks is the best answer. In most cases, AWS architecture solutions lean towards a more manageable direction, than tactical. The DNS solution would work, but it’s limited in its effect and management of the larger picture of an eCommerce web site.
I also fixated on the word "quickly" which drove me right to the multi-value DNS answer. When I thought more about it, I jumped right to the ALB since that makes better sense than just DNS and honestly does not add much more time to a deployed solution.
In all cases DNS is part of the solution. No matter what you do you will have to update DNS since the public DNS entry will have to be updated to point away from the EC2 instance to the ALB (or to change the dns record type to multi-value).
One other nit is sticky sessions. That’s something that should never be required in a modern cloud app. I have seen them in production quite often (this week as a matter of fact, and the dev refuses to fix the problem — oh well..). Session data should NEVER, NEVER, EVER be stored on the local web server — did I say NEVER EVER? AWS has a few options to resolve that prickly problem. ElastiCache and DynamoDB come to mind.
Apps really need to have stateless built in from the start. That solves so many issues in all app stacks. Yes, there are old apps that do store session data locally and they might benefit from sticky sessions. Let’s do our best to help devs "see the light" and make their apps perform even better by putting session-related data where it belongs…:-)
Hi Scott, thank you for your response. Yes, it makes sense, and I agree that sticky sessions are a must if user sessions are stored on the application servers. However, my reasoning was based on the assumption that sessions will be stored in a central database or cache server, which is a best practice.