Developers have traditionally specialized in areas of comfort or expertise and the last thing they want to learn is infrastructure. They would rather play Halo ‘off the grid’ in a cold dark room with a Jolt cola and yesterday’s pizza crust. I would challenge that without intimate knowledge of the hardware, your app may not behave as anticipated. With this backdrop, fellow developers, let’s get out of our comfort zones and start to understand cloud infrastructure and how it can work for us. Let’s begin with Azure’s Traffic Manager in the context of a couple use cases.
Use Case #1
My organization needs the ability to sell product globally with target customers residing in New York, Sydney, and Beijing. There is seasonality to the business, so the application will need to scale on-demand for product sale cycles as well as around the holidays. Users are very discerning and demand app performance or they will go elsewhere. There could also be thousands of concurrent users. Now what? All I have is a half-baked PHP/MySQL/Apache app sitting in the closet over at mom’s house.
First, have a nice glass of Chateau Marqaux vintage 2009 and then fire up your Azure subscription, create some Web Apps, and deploy your PHP to the appropriate data centers across the globe. Next create an instance of Azure Traffic Manager (TM) with the ‘performance’ option, add the web app endpoints, route your user traffic through TM, and go enjoy a cigar on the back porch, you’re done (almost) ! This temporary solution positions you to rewrite the app utilizing cloud centric design patterns and technologies without throwing the business into full panic mode. Nicely done!
Traffic Manager and Cloud Design Patterns
Use Case #2
The reference architecture below is taken from the Azure documentation and depicts a typical Web-Queue-Work cloud design pattern with a few infrastructure upgrades to accommodate resiliency, scale, and durability. To accomplish this architecture we need to know a a few things about Azure AD, regions, and networking. Let’s start by examining the Azure Traffic Manager component and how it can help us achieve our app goals.
In our example we setup the Azure ‘Active Region’ resources close to where most of our customers will reside (East US). In the Azure ‘Standby Region’, we’ll make sure our resources point to West US since it’s an Azure Paired Region with the East US. Now let’s examine Traffic Manager routing options and select the appropriate method for our use case:
- Priority – Point all traffic to a primary location and in case of maintenance or issues it fails over to the secondary location
- Weighted – Distribute traffic evenly across a set of endpoints
- Performance – Traffic is directed based on user access location for better performance
- Geographic – Traffic is directed to specific geographic endpoints, which can help with compliance issues
In our scenario we are using the Priority method. This takes advantage of Traffic Manager’s Endpoint Monitoring feature, which probes each endpoint for health as configured. If it sees an issue then automated failover to the ‘standby’ region occurs. One can quickly ascertain how Traffic Manager can become your global load balancer of choice. You can deploy your web app all over the globe, add the endpoints to Traffic Manager, set routing for performance, and the user experience in New York, Sydney, and Beijing is consistent and what users would expect.
Multi-Region Web-Queue-Worker Cloud Design Pattern
Understanding Traffic Manager will ensure your apps and services are redundant, resilient, durable, and all those beautiful things we come to expect from the cloud. At Quisitive our developers are embracing IaaS (Infrastructure-as-a-service) in Azure and our customers are the beneficiaries.