A Constantly Changing Landscape

The improved search infrastructure is a direction Google undertook in reaction, in part, to the speed at which information is added to the internet — specifically Twitter and then a few other social media sites. Closed systems like Facebook are shutting out Google’s ability “to organize the world’s information and make it universally accessible and useful.”  Yes, publically visible pages are displayed in search results but the overwhelming majority of data in Facebook may never be accessed by Google. That might not be a bad thing.

I’m sure many people would not want their profile indexed and displayed online to just anyone searching on Google. Despite the fact that many Facebook users complain about privacy issues, most users don’t understand that Facebook has had a good security system for some time. Not everyone knows how to use it effectively.

Google Caffeine

The Caffiene release in June of this year was a complete and holistic overhaul of their indexing system – with an obvious eye toward future growth, scalability and flexibility.

Google wrote on the webmaster central blog in June of the Caffeine release:

Caffeine lets us index web pages on an enormous scale. In fact, every second Caffeine processes hundreds of thousands of pages in parallel. If this were a pile of paper it would grow three miles taller every second. Caffeine takes up nearly 100 million gigabytes of storage in one database and adds new information at a rate of hundreds of thousands of gigabytes per day. You would need 625,000 of the largest iPods to store that much information; if these were stacked end-to-end they would go for more than 40 miles.

And that is just for today’s World Wide Web. Back in the early 2000′s, for those of us that remember, the Google index was rebuilt every month and had code names. In subsequent years Google started updating the index more frequently to once a day and then once an hour.

Now, in this latest release, the index is being updated constantly – every 10 seconds as Peter Norvig stated in March. It also sounds like their previous indexing system was tiered or layered — causing some layers to become as much as 2 weeks old before being updated.

Well, if you’re working on the indexing system so heavily then you can imagine some of the necessary infrastructure updates to support the new indexing system’s requirements.

GFS2 aka Colossus

The original Google File System is about 10 year old now and the biggest bottleneck has been known for some time: a single-master. Sometimes the shortest path to solving today’s business problem is by deferring other decisions to the future.

Sean Quinlan of Google states in an interview with ACM:

The decision to build the original GFS around the single master really helped get something out into the hands of users much more rapidly than would have otherwise been possible.

The new file system implementation breaks away from having a single-master in favor of distributed masters and distributed slave nodes for managing the file system. It really sounds like the new approach in GFS2 looks to design principals from large implementations of LDAP (Active Directory): where response time can be improved by stragetgic deployments of more slaves and masters — not to mention fault-tolerance. That provides redundancy and improves performance. The new implementation also relies more heavily on BigTable to store and retrieve node information.

Constant Improvement

The success of a software project is not determined by its initial success.

Imagine if Google had stopped at online advertising and called it a day. There would be no Answers, no Gmail, no Google News, no Webmaster Tools, no Maps, no Blogger, no Calendar, no Talk, no Docs, no Picasa purchase, no YouTube purchase, no Analytics, no Voice (GrandCentral), no Checkout, no Android, no Google Code, no App Engine,  no Base, no Google Tablet, no …

Successful software projects have good management who understand that success can be only temporary if you’re not constantly improving.

I know I’m late to finding this particular paper since it was first published about two years ago. Better late than never!

I found it interesting that Amazon uses a service-orientated-architecture of about 150 services to compose any one page. I just drew a few boxes on this page to illustrate some obvious ones that the end user sees. I’m sure there are other services working in the background that track how many times you’ve viewed the page, what parts of the page you scroll to and what buttons you click on to name just a few.

The paper goes on to describe four “other key principles” which I think are important architectural keys when building a SOA-based system.

• Incremental scalability – As new systems are added to the overall fabric of Dynamo, it increases the overall capability of the system.
• Symmetry – Except for processing capacity and hardware vintage, all nodes act the same.
• Decentralization – Peering instead of master-slave. The “master” will always become a bottleneck!
• Heterogeneity – Basically the Dynamo system allows the workload to scale out onto whatever type of server is available as long as the platform is the same. I bet that allows Amazon the flexibility of “purchasing and forgetting” hardware. The commodity hardware spans several generations of hardware improvements as servers are added and retired.

Some interesting solutions for large-scale systems:

• DHTs - Distributed Hash Tables
• Consistent Hashing
• Vector clocks
• Quorum
• anti-entropy based recovery – Couldn’t find a link for this concept.

Thanks to Werner Vogels for publishing the paper!

ASP.NET Charting Tools

The ASP.NET controls were released in the late fall of 2008. The chart controls were finally included in the C# 4.0 release as part of the standard ASP.NET platform.  If you’re looking for reasons to upgrade to C# 4.0, this three part series is a big reason to do so if you rely on reporting in your web application using SQL Reporting Service. Part 1, Part 2, Part 3.

Google Chart Tools

Google Chart Tools comes in two flavors:  Image Charts and Interactive Charts. Both sets have some very cool features. Your application just needs access to the internet.

This is a QR Code (That's also the message that appears if you have a decoder)

The only issue I see with using some external charting provider like Google is that you rely on them for core aspects of understanding your business. Say, one day, Google’s server’s go down for a 3 hour period — or the route to Google’s servers is unavailable. I see that happening about as often as the power going out at home — but it does happen. What does your application do to recover? What do you show when the graphics don’t appear?

That  minor issue aside, there are so many cool features with the Google Charting tools, that it outweighs the downside for small the medium sized applications. The good thing is that these tools are free but I wonder how Google views “customers” of its free services with respect to long-term API support.

Check out the googlechartsharp project at Google Code Project Hosting for a .NET implementation. Matt Durrant has another version with source code available.

Tip: If you want to use Google Chart Tools – Image Charts — over HTTPS, you need to change the base URL from

http://chart.apis.google.com/chart?

to

https://www.google.com/chart?.

Google doesn’t have a valid SSL certificate on “chart.apis.google.com”.

Example:

https://www.google.com/chart?cht=p3&chd=t:60,40&chs=250×100&chl=Sample|Chart

Some sample Google Chart Images

Idea Chart - Venn Diagram Example

USA Thematic Map

The R Project for Statistical Computing

R is a Unix-based statistical analysis package that has the ability to create any type of visual representation imaginable. Here’s a brief description from the About Us page at the R project

R provides a wide variety of statistical (linear and nonlinear modelling, classical statistical tests, time-series analysis, classification, clustering, …) and graphical techniques, and is highly extensible. The S language is often the vehicle of choice for research in statistical methodology, and R provides an Open Source route to participation in that activity.

• DryadLINQ – Microsoft LINQ implementation (awesome idea)
• qizmt – MySpace MapReduce .NET implementation.

• WebServius – 3rd party billing for your web service. Handles things like signup, metering, api key gen, quotas & analytics.
• DynInc – Who knew DNS could be so cool? Regional DNS routing, global traffic management, geo targeting traffic, load balancing. This is what sys admins do when they go to heaven.
• Twilio – Phone API (Press 1 for “Services”, Press 2 for “Billing”). I couldn’t remember their name for the longest time until last night when they were mentioned by the speaker from WebServius. Didn’t actually present.

• AWS feature rollout since November (A December to remember)
• AWS DB offering overview (EC2 AMIs, RDS and SimpleDB). Don’t forget the 4 hour maintenance window! Rollout of 5.1.4.2 is coming soon.
• Senior VP Engineering Bob Wise from  nuTsie.com (aka Melodeo)
• OpsCode‘s CTO Adam Jacob and VP Engineering Christopher Brown.

Take aways:

• Amazon’s 8th floor presentation room had some rockin’ views of the sound!
• Both presentations hinted that small AWS instances really don’t provide the best bang for your buck. Medium (High CPU) and Large sizes tend to provide better performance.
• Didn’t know that Windows 2008 R2 was now available on AWS (haven’t checked since December).
• CIDR addresses should be “/32″ unless you know what you’re doing!
• HIPPA compliance is at the App level, SAS 70 is at the physical layer.
• Locking your AWS instances can prevent accidental/unintentional shutdowns.
• memcached, memcached, memcached.
• Ecualyptus: Your own private Idaho (in the cloud) is AWS API compatible!