"The Cloud" has become the buzzword du jour for a reason.
Not only have web-based applications continued their migration to the cloud,
i.e. scalable hosted platforms, but more and more solutions providers are
coming online to offer cloud-based hosting services to enterprising companies.
This abundance of cloud hosting allows developers of social networking apps and
games to build robust, engaging apps that can meet often unpredictable traffic
needs. Single-person game developers, for example, can build mobile apps with
affordable back-end support that scales based on their success. And larger
operations can fire out cutting edge social marketing apps that are ready to go
viral overnight. Such is the power and opportunity of cloud hosting.
One of the earliest, and most popular, cloud platforms is
Microsoft’s Windows Azure. As a scalable host, it gives current .NET and developers
using other languages such as PHP and Java an ideal space to launch their web
apps without worrying about cumbersome operational issues. Using the Windows Azure
SDK, developers can deploy their current code base to their Windows Azure
account, often with very little tweaking.
That said, the savvy developer will review his or her app’s
architecture to make sure it takes advantage of the benefits, while navigating
the differences, of cloud-based hosting. Some of the changes of habit that are
required may not be readily apparent to someone new to the cloud. Some of the
biggest opportunities are revealed only through a careful and thorough
exploration of the platform.
Fortunately, two companies have offered up their real-world
experience on this matter. One, Gestone [http://www.gestone.com] has a new
social networking service currently in pre-launch. The other, Thuzi
[http://www.thuzi.com], while cultivating a reputation as a forward-thinking social
media marketing firm, has based its microsites on Windows Azure ever since its
first wildly successful campaign for Outback Steakhouse in 2009. Both companies
have been working with Windows Azure since its Community Technology Preview and
had much advice to offer developers new to the cloud.
Meet Gestone
Andy Harjanto started Gestone (pronounced like "guest-tone",
which stands for "Get Stuff Done") because he wanted to create a lightweight collaboration system that leveraged existing social media like Facebook, Twitter, Linked-in to create
a more natural communication tool for team members. "Gestone tries to support
the normal cooperation inside the team as well as federation between companies.
In the old days of SharePoint and Windows NT, you basically used the file
system and allowed others to access your corporate network. Time has changed
things quite a bit. With all the social media, companies are actually on
Facebook and Twitter. IT workers are on Facebook. We constantly have streams of information
coming to us. How do we filter out this information?"
Gestone shifts the project management paradigm by letting a
team member of a project become "CEO" of one of that project’s Work Items.
Gestone creates a Facebook page for that Work Item, complete with a headline
goal, team members, a "time bomb" for time-sensitive tasks, and all the social
interactivity one has grown accustomed to on Facebook Pages.
"What Gestone tries to do is take the things important to
you and let you work in some context, instead of just streaming status updates,"
says Harjanto. "You can create a Work Item, which is a context. You then
collaborate like you collaborate on Facebook, with updates and attachments. We’re
trying to be a more modern collaboration tool than a file based or streaming
based collaboration system."
When Harjanto began development on Gestone in September 2010
in Bellevue, Washington, he had two things working in his favor. One, 14 years
of experience at Microsoft working on such products as Active Directory and
Windows Mobile, gave him a background understanding of the options available
when coding to a Windows platform. The other, a prior successful startup called
Guppers, gave him the practical experience of using Windows Azure as a
production platform. That history brought him insight into dealing with data
management issues, an insight relevant to his new company.
Guppers, a texting company focused on the business market,
was "a little bit complex," says Harjanto. "We were routing to SMS, Email, Chat
gateways. We were using a data center. The cost of doing the data center is
high, especially if you’re hiring people. The machine actually crashes
sometimes. When [Windows] Azure was announced, we’d already played around with
it for awhile. Microsoft invited us to be one of the featured startups when
they announced [Windows] Azure at PDC in November 2009. When we switched to [Windows]
Azure, we knew that all of the data itself was backed up. So I could sleep more
easily at night. When I started Gestone, it was a no-brainer that we were going
to use [Windows] Azure."
Using Visual Studio Ultimate 2010, Harjanto is building his front-end
in Silverlight (C#) while architecting the back-end for maximum portability to
future platforms. "I’m a big believer, especially in business applications, in
a very rich user experience. I was actually hoping to use HTML 5, but it’s very
early in the game – browser support is not there yet. I chose Silverlight to
deliver a rich user experience, including right-click and drag and drop
functionality. We’re planning to use [Windows] Azure when we port to iOS. The
goal is we don’t change anything on the back end, we only change on the front
end."
Meet Thuzi
While Jim Zimmerman is CTO of Thuzi, he prefers the title "Head
Developer". A coder at heart, he’s the guiding force for a team of about 25 to 30
people, half developers, half designers, with "a few sales guys" thrown into
the mix.
Thuzi specializes in social media, primarily marketing applications.
Like Harjanto, Zimmerman found having a data center to be too expensive and
unpredictable and has since gotten rid of it entirely except for source
control. "Every app or product that we do," he says, "is done with [Windows] Azure
in mind and architected to scale. We don’t know for sure if an app will go
viral, so a lot of times we’ll over-anticipate so we don’t look bad in case it
does go viral. We’re used to a large scalable pattern. Even small apps could
scale to 1 million users. Once you get used to the pattern, you don’t see any
reason to go back.
"About a year and a half ago we used [Windows] Azure for the
first time in CTP. When we got started I knew we had seen only one Facebook app
ever go viral – not many marketing apps were doing it at that point. I knew
that I didn’t want to risk buying four servers and have
it be an app that didn’t take off. I didn’t know how many servers to buy
anyway. I could do some math and figure out requests per second but that’s
about all I could do. If the campaign was good and I didn’t provision enough
hardware, I was in big trouble. I needed a scalable solution. Since I was an
ASP.NET MVP, I was going to lean towards Microsoft anyway. Google stuff was Python
only – I’m not interested in doing that. Amazon was basically the same as
having my own data center. Microsoft was easier to scale and I didn’t have to
worry about the VMs (virtual machines). It was more of an app mindset while the
others were more infrastructure."
His first full-scale Windows Azure app turned out to be the "Bloomin’
Onion" loyalty campaign
[http://www.microsoft.com/casestudies/Windows-Azure/Outback-Steakhouse/Restaurant-Chain-Outback-Steakhouse-Boosts-Guest-Loyalty-with-Social-Networking-and-Cloud-Computing/4000005861]
for Outback Steakhouse. The goal of the campaign was to reward the first half
million Facebook "fans" with a coupon for a free Bloomin’ Onion. After an eight
week development cycle, Thuzi launched the app on November 5, 2009, hoping to
hit the 500,000 fan mark within 30 days. They reached it in 18.
Lesson Learned: Use Windows Azure Tables
One thing both companies learned early on was that using SQL
on a remote data cluster posed new server dynamics they hadn’t anticipated.
Says Zimmerman, "We were getting throttled in SQL. At first we weren’t
understanding how the cloud works. You’re on this huge SQL cluster – most
programmers haven’t programmed on a cluster. You usually only see them in
enterprise apps. The way clusters work is sometimes they load balance, they
shift over, sometimes the connection string works on one server or the other,
and sometimes they take down a VM."
Zimmerman says that in the cloud, connections become intermittent
and can potentially timeout at unexpected times. "If you’re making a connection
to a database right when the timeout occurs, it makes an exception. If you don’t
have code to handle it, you’ll get an error that appears to be random." The
lesson here is that while this reinforces the need for thorough error handling
code, it also makes a strong case for one of Windows Azure’s key features:
Windows Azure Tables.
At Gestone, that’s the approach Harjanto takes. "I use a SQL
table mostly for the account information, but I like the [Windows] Azure table.
It’s very, very scalable. With SQL, when you have millions of transactions, you
have to do some connection, partitioning management kind of stuff." With
Windows Azure, however, Harjanto can map one table per project, effectively
siloing projects from one another. "By doing that I get a couple of benefits.
One is a security perimeter. Two, if the company wants to archive, I can easily
archive the whole table without having to worry if any record from other projects
are included accidentally. I can archive the whole thing easily.
"A Windows Azure table is pretty much scalable. You can add
billions and billions of objects without degradation of performance because
they’re distributed, and they work through entity key /value pairs. It’s the
same with Google or Yahoo. They don’t do traditional SQL Server. For
scalability they do an EntityKey / Value pair database."
Lesson Learned: Careful Queries
The solution works for Zimmerman, as well. But with one
caveat. Because of the structure of Windows Azure Tables, primarily their lack
of indices, he found that he needed to architect carefully. "If you forget to
put an index on a table and you add a million rows, or you have an old app with
leaky bits, connections not being closed, bad code, etc, you’ll do a table scan
and get kicked off of the [Windows] Azure table. You get a ‘back off and retry
in 10 seconds’ message and other error codes you’re not used to seeing."
Understanding this, however, led him to architect differently, including adding
code that tested for throttling (the ‘back off and retry’ message) and
instructed the data layer how to handle it. "The solution is to architect it correctly.
Every query you do, if you have a WHERE clause make sure there’s an index on
it."
Phrasing queries correctly was the key, so to speak, to
Harjanto’s success, as well. "You’re basically limited to two keys in [Windows]
Azure. You have a partition key and a row key. So if you want to do queries outside
the row key or partition key, it’s going to take a long time, especially if the
project is very large. But if you do a query based on partition AND row key, it’s
very, very quick. The way they do it is that everything with the same partition
key is stored in the same logical server. So for everything with that partition
key you can go to the same server quickly. Therefore, you need to be extra
careful in designing your tables, especially for performance reasons.
Understanding your key scenarios is the key."
Lessons Learned: JSON and BLOBs
In conjunction with Windows Azure tables, both companies
have hit on an elegant solution that other highly scalable sites use: document
storage. "That’s how Facebook scales," says Zimmerman. "They don’t have
databases, they use BLOB storage. Each user has his own JSON array, his own
stored document. When you return to the site it just goes back and gets that JSON.
You can support 100M users that way. All you’re doing is updating their little
store." Doing this gives Thuzi the ability to build microsites that can handle
the unpredictable traffic of an overnight sensation.
For Harjanto, this same technique has become central to the
power of Gestone. "If you look at the way our data is structured, we’re storing
hierarchical data. Projects have many Work Items. Those Work Items have mainly
Post updates, like Facebook. Every member of the team can make comments. Within
Post updates, you can also (in Gestone) do file attachments. Or you can make notes
or maybe even store a small database, like a spreadsheet – all the quick
business widgets that can go inside the Post updates. It’s hierarchical with the
objects we need to store. So [Windows] Azure tables are perfect. The [Windows] Azure
table doesn’t store blob files, just key/value pairs. The way we store all
those things, we serialize them into JSON format, a long string. That long string
goes with the Post update, which is actually stored in the table. In the case
of a PowerPoint file, for example, I create a JSON string during the Post
update which is actually a reference to an [Windows] Azure BLOB. We can do a
lot of versioning that way – if two people update the file, we keep both files."
Summary
Both Andy Harjanto at Gestone and Jim Zimmerman at Thuzi
learned one thing most of all: Windows Azure offers a highly scalable,
versatile platform on which to build data-heavy and often unpredictable apps.
To sum it up, here are key takeaways that developers can bring to their own
Windows Azure projects:
- When traffic is unpredictable and scalability is an issue, go
with a cloud platform, specifically Windows Azure
[http://www.microsoft.com/windowsazure/windowsazure]
- Take advantage of Windows Azure Tables
[http://msdn.microsoft.com/en-us/library/dd179423.aspx].
- Make sure your error handling takes into account typical
cloud behavior, such as load balancing and possible connection timeouts.
- Include indices in your WHERE clauses and include both partition
and row keys.
For more information on these two companies and the work
they’ve done with Windows Azure, check out the following.
