I want to tell you a story. It’s about the major struggles of a small business to sell things on the web.
We created a t-shirt company, we’ll call it Blankenshirts. We started making shirts with funny slogans, and had created a small website to sell them. Behind the scenes, we also had a small set of administration tools to manage orders, process returns, and calculate shipping, etc.
One day, we created a HUGELY popular shirt, and the web caught fire about it. People were Twittering about it, someone linked to it from Digg, and before we knew it, we had two GREAT problems:
- The little webserver couldn’t handle the traffic.
- We were being contacted by other t-shirt vendors about re-selling our shirts.
Third Party Vendors
Up until now, we’ve been working on an application that was just for us. But there’s a huge sales opportunity here with other sites selling our stuff as well. So we create an easy to use set of web services that we provide to these other vendors. We’ve got a new challenge now though…we’ve got “customers” relying on our web services for their applications to work. So if our stuff goes down, their stuff doesn’t work either. Uptime, while generally reliable, is something that now affects more than just us. Compound that with the heavy traffic we’re seeing, and now we’re starting to see some bigger issues.
Addressing the Traffic Problem
So, we called our hosting provider and our development team, and got started on creating a small server farm. Something that would be more responsive to the kinds of traffic we were now seeing. But this introduces a whole host (no pun intended) of issues for their website:
- Concurrency. We need to make sure that all of the servers have the accurate inventory count so that we don’t sell more shirts than we have to sell.
- Load balancing. We now need to distribute the traffic load evenly across each of these servers, but also handle for situations where a server crashes or needs to be taken down for maintenance.
- Failover. Once this new datacenter is created, we still have a major problem that has to be solved. What happens if that datacenter catches on fire? Or has a power outage? Or an earthquake?
The failover problem, while it may seem frivolous, becomes VERY important when you’re talking about your business making money or NOT making money. And there are now other businesses relying on that uptime as well. That’s not something you can leave to chance.
Solving the Failover Problem
The obvious (and correct) solution to this problem is to have multiple datacenters. Maybe one on the west coast, and one on the east coast. But now our concurrency and load balancing issues just grew by an exponential amount. If a datacenter drops, we need to direct all the traffic to the other one. But we still need to accurately (and quickly) keep things like inventory up to date in each location. And that works fine while you’re only focused on selling to the United States. But we still have those other t-shirt vendors who want to sell our stuff as well.
Blankenshirts have become incredibly popular in China, thanks to one of our third-party vendors, TiananMen’s Wear. But despite our success, there are many complaints about the speed of our server response.
Getting around global network latency.
Our next step in our progression is to create datacenters all over the world, so that the Chinese customers can access data in the datacenter in China, and the U.S. customers can access the U.S. datacenters. And while we’re at it, we probably need one or two in Europe, one in Russia, one in Japan, etc. The point of this, for any company, is that this ends up becoming a HUGE investment. You need servers, real estate, heating, cooling, power, and the personnel to manage all of it. Before you know it, you’re a hosting company that sells t-shirts. Not a shirt company that just uses the web to sell their products.
Introducing Windows Azure
Azure is a set of services that allow you to build your business applications without worrying about nearly everything that Blankenshirts had to deal with even two years ago. Think of it as a cloud-based server operating system. You build your applications to be deployed to the Azure platform, consuming the 5 components of Azure (Live Services, .NET Services, SQL Services, SharePoint Services, and Dynamics Services), and all of the issues that Blankenshirts just encountered start to vanish.
Concurrency and failover across numerous global data centers are a thing of the past. Your applications are hosted inside Microsoft’s global datacenters, and are automatically distributed and managed.
It also solves a problem that many websites face each year at the holidays. Scale. Outside of holiday shopping, however, this is still a problem for many different sites. A few great examples are The Masters, The U.S. Open tennis tournament, or the Indianapolis 500. These events gather a TON of attention leading up to their respective events. They get even more traffic during their event. And as the weeks following the event add up, the traffic gets smaller and smaller, until it’s nearly none.
For this problem, these organizations generally have to have enough server capacity to handle the traffic at the busiest of times. But when it’s slow, they’re just bleeding money on all of the server infrastructure.
Because Azure also runs in a virtualized environment, you can actually choose when and how much to scale when you need it. So you’re only paying for the servers you’re actually using, not the servers you need once in a while.
In short, Azure is the future of distributed web applications. Keep your head (and eyes) on the clouds, because your next application might make sense to put there instead.