Performance varies widely within online-only and brick-and-mortar categories

How fast are these bracelets?

Mother’s day is a big time of year for jewelers.  According to a survey by the National Retail Federation, 31 percent of American consumers are planning to buy jewelry for the holiday this year.  Clearly there’s a lot of revenue at stake for jewelry retailers seeking to capitalize on that consumer willingness.

This pressure applies equally to e-commerce jewelers.  Online jewelry sales is big business: Internet Retailer’s Top 500 Guide counts 15 jewelers among its list of the 500 biggest e-commerce vendors.  Those 15 sites accounted for over $1 billion in category sales in 2010.

Website performance matters for any e-commerce vendor, but the issue takes on a distinctive hue when it comes to big-ticket items like jewelry.  As one might expect, average order size at online jewelry stores is consistently larger than at stores in other categories.  The largest jewelry e-retailer, for example, had an average order of nearly $1700 dollars in 2010.  What other B2C industry can boast such consistently large orders over the Internet?

These big orders mean that each visitor represents a large revenue opportunity—to lose any customers to a competitor because of a slow website would be distressing for any jewelry website owner.  With this in mind, we wanted to find out how some of the top jewelers stacked up in performance.  We compiled a performance benchmark including 15 jewelry sites in the Top 500 list, and tracked their performance. Click to see the results.

The Results 

Yottaa has real web browsers located around the world collecting performance data.  This data is then plugged into an algorithm that compiles it into a single score from 1 to 100, called the Yottaa Score.  This accounts for the relative importance of certain stages of the page load process regarding user experience, making Yottaa Score a distinctive measure of website performance from the shopper’s perspective.

The results of the benchmark showed a wide range of performance: we saw Yottaa Scores from 10 to 90.  The average was 51 and the median 57.

Interestingly, several online-only stores posted poorer performance than their brick-and-mortar competitors (B&M).  It would seem that B&M companies for which e-commerce forms a small percentage of annual revenue would devote less time to performance, while online-only businesses would make it a top priority.  That seems not to be so as a general rule.

In particular, Kay.com and Tiffany.com, sites operated by companies well over 100 years old, are near the top of the list for performance, while Jomashop.com and ICE.com, online only businesses, are at the bottom.  It’s worth noting that Jomashop runs its e-commerce on the notoriously slow Yahoo e-commerce platform.  It also appears that one online-only retailer, Limoges, took steps to improve performance during the time of the benchmark, possibly in preparation for the holiday

Images – A Necessary Evil? 

Product pictures are hugely important for e-commerce success.  For most consumers, seeing before buying is imperative.  This is especially true for jewelry, as high-resolution, extreme-close-up photography is needed to exhibit the quality and workmanship of the pieces.  Plus, photos of jewelry are more likely than other types of products to be shared on Social Media or email, by customers who want friendly opinions on their choices or simply enjoy looking at beautiful baubles.  (One jeweler, Gemvara.com, is already successfully leveraging this photo-sharing tendency using Pinterest, and others are following suit.)

These pictures, however necessary, slow down websites.  This could partially explain the relatively poor performance of some of the jewelry websites.  Looking at our benchmark’s complexity breakdown for Tiffany.com, one sees that the site has 69 assets on its homepage, mostly consisting of JavaScript.  There are only 15 images to load.

Tiffany.com Asset Breakdown

Jomashop.com, on the other hand, currently loads 244 assets on its homepage, with images taking up the lion’s share of the pie.

Jomashop Asset Breakdown

The performance difference between Jomashop and Tiffany is huge: 80 points of Yottaa score.  Tiffany is the best of show in this benchmark, while Jomashop rounds out the bottom.  Images are surely not the only factor in this performance differential, but it’s certainly worth noting that the number of images correlates so strongly with the performance in this case.

This weekend marked the third New England Givecamp in Boston.  From Friday evening to Sunday afternoon, over 150 volunteers provided technology solutions for 29 non-profits in a “community codefest.” Designers, developers, database pros and project managers alike donated their time to provide custom solutions for the organizations, including websites, applications, CMS customizations, office automation and more.

The Boston event was organized by Jim O’Neil, Developer Evangelist for Microsoft (Northeast US); Kelley Muir, Business Analyst; Ektron, an Enterprise Web Content Management system; and countless other volunteers and sponsors.

Jim O'Neil and Kelley Muir

The technology sponsors included Microsoft, Telerik, Twilio, Mashery, 10gen and Yottaa, among many others.  Microsoft’s New England Research and Development office and community center hosted the event, and thirty four other sponsors donated food and financial support.

Yottaa sat down with several of the groups on Sunday to learn about what they accomplished over the weekend.  Read on for three stories of GiveCamp in action!

MassSaves.org, A Financial Education Collaborative

MassSaves-ORG Current and New Website Design at #NEGC2012

MassSaves.org is a non-profit resource dedicated to helping Massachusetts residents and organizations build personal financial competence and capability.  They sought help from their Givecamp technical team in updating their Drupal website with a fresh design and better navigation.  They also plan on using this update to highlight their new messaging, while adding more social media programs.  The goal is for the MassSaves.org website to become a hub for information with workshop listings, educational resources and newsletters.  The group members in attendance were the happy recipients of advice from project managers, a new design from a web designer, and help with Drupal from the experts at Acquia.

New Hampshire Coalition to End Homelessness (NHCEH) (NHCEH.org)

NH Coalition To End Homeless Team at #NEGC2012

The NECEH is part of the Families in Transition organization, and was hoping to have a new website built during Givecamp weekend.  They worked with developer Ryan M. Sutton to put their ideal website in place.  That included a new site architecture and navigation to include a place for their content and educational materials.  The website offers education, research and advocacy information.

Brookfield Craft Center (Brookfieldcraft.org)

Brookfield Craft Center Team at #NEGC2012

The Brookfield Craft Center is one of the oldest creative study schools in the US, dedicated to teaching traditional and contemporary craft skills and fostering an appreciation of fine craftsmanship.  The organization, led by Heather Lawless, wanted its WordPress website to become a place where patrons could register for classes, create memberships, give donations, and eventually purchase the work of the school’s students.  The technical team discovered that many of the processes in place at the organization today required manual updates to the website, and worked as a team to add a creative calendar and database to the website.  We spotted and chatted with Bill and Maura Wilder on this team, both of whom regularly attend the Boston Web Performance Meetup.

There are 26 other stories we have not covered from this event, however we do know that the weekend long event will prove invaluable to the non-profit organizations that attended.  We also saw evidence of some great community spirit and budding friendships among the non-profits and the technical community.  Yottaa was proud to be a sponsor this year, and hope to be a repeat sponsor next year.

Check out our Flickr gallery from #NEGC2012

Are you interested in participating in a similar event in your community?  Have a look at the list of worldwide locations with Givecamp events to see if there’s one in your city at http://givecamp.org/

We are convinced that web performance challenges can be met with knowledge and access to data.  The problem is that as web pages grow heavier and more complex, so grows the amount and variety of performance data.  Developers need smarter tools to sift through this performance data, figure out where the bottlenecks are and what to do to fix them.

That’s why the Yottaa team developed our new waterfall chart. Starting from March 2012, all Yottaa users have access to the most powerful waterfall chart, ever.

An Unprecedented Tool

Waterfall charts have become indispensible tools for developers to analyze webpage performance.  Until now, though, waterfalls were limited: they displayed data one way (in the order that the assets are loaded by the browser) and offered very little help for data analysis.

At Yottaa, we analyze web performance every day and we know the pain. We decided to help ourselves and our customers by creating the most powerful web page performance visualization and analysis tool.

Our new waterfall now provides data filtering, sorting, details drill down as well as integrated actions. Developers and website owners can now investigate deeply into every asset: slicing, sorting, and filtering performance data as it’s conforms to the open HAR file standard.

This is the first of three blog posts in which the Yottaa team will discuss some of the features in our new waterfall. This week we’ll cover the new Filtering and Sorting functionality; next week we’ll cover the deep drill down data on individual assets; and third we’ll cover some groundbreaking features in development that will be released later this year.

Filtering and Sorting – You Can Teach an Old Dog New Tricks

First, to access Yottaa’s new waterfall simply enter a URL into the field on the top right of your Yottaa dashboard. (Click here to get a free account if you don’t already have one).  From the ensuing page, you’ll be able to select “Page Load Time” on the left-hand navigation.  Here you’ll find the waterfall tool, along with an interactive performance graph.

Across the top of Yottaa’s waterfall you’ll see columns with categories describing the assets.  These will be familiar for developers—URL, HTTP Status, host address, size, type, and timeline breakdown (the “waterfall” part of the waterfall)—but we’ve packaged them together here for convenience.

The real key is that for each column of values, the user can select what assets the waterfall will display and how they will be ordered.  Sorting (ascending or descending) for any of these categories will allow developers to clue in quickly on problem areas, without having to hunt through a vast timeline for the key stats.  For instance, by clicking “sort (descending)” on the “timeline” column, developers will immediately be presented with a clear, neat view of the slowest assets on their website.

Show Only What You Want To See

Additionally, on columns in which the values fall into categories, there is an option called “show only” that helps to further isolate desired pieces of data.  For instance, a developer could “show only” assets with 400 HTTP statuses, or only assets from a particular third party domain.  This flexibility will increase efficiency for developers seeking to find and fix performance issues as they arise in the development process.

This is especially the case for the “type” column. With the ability to separate all JavaScript files or all JPEG files, for example, from the rest of the website, developers will have greater insight into the components of web pages.

Why Is Sorting and Filtering Important?

Every time you analyze a waterfall chart, you are probably looking for answers to the following questions:

1. Which assets are slow?
2. Which domains are slow?
3. Which assets are problematic — for example, returning 404 error?
4. How many Javascript files are there?
5. How many Javascript files are loaded from this third party domain such as Facebook.com?

When you apply the new sorting and filtering capabilities, you will get answers to these questions instantly.

Try It Out!

In the next post, we will explore the deeper data that can be found by clicking on assets within the waterfall.  In the meantime, we encourage you to explore the tool on your own: just register here for access.

And please don’t hesitate to share any feedback on the waterfall in the comments or on Twitter @Yottaa!

Each week Yottaa CTO Bob Buffone digs into the data and evaluates the web performance of a new website.  Recommend a site for next week’s Expert Eval in the comments below or @Yottaa on Twitter! #ExpertEval

This week’s web performance review is for www.Grammy.com, which is built on Drupal.  The site is currently number 9,514 in the Alexa ranking, meaning simply that it gets a whole lot of traffic in the full scheme of the Web.  Unfortunately for all those visitors, the site takes about 20 seconds to download globally.  (See graph below or visit Yottaa’s profile page for Grammy.com for more detail)

It goes without saying that 20 seconds is way too long for a website to load. But a trained eye will notice that perhaps even more jarring than the long load time is the size of the page: 5.6MB — yes, megabytes!  Displaying the homepage calls for 4.6 megabytes of images alone.

I’d feel bad for anyone visiting this site using a mobile phone with limits on the data consumption. Looking at the data plans for AT&T, there’s a range from 300MB to 5GB.

So visiting the Grammy.com home page would consume, per plan:

– 250MB plan: 2.2% of monthly bandwidth and cost 34 cents per visit

– 300MB plan: 1.9% of monthly bandwidth and cost 37 cents per visit

– 3GB plan: 0.19% of monthly bandwidth and costs 6 cents per visit

– 5GB plan: 0.112% of monthly bandwidth and costs 6 cents per visit

That is a lot of money just to visit one webpage.

Zeroing In on the Issue

So what exactly are you paying for when you visit Grammy.com?  Well, the waterfall, as it always does, shows the problem…

By filtering the waterfall to just display assets from the “external.ak.fbcdn.net” domain, you can see that 4.2MB of image download largely comes from the Facebook.com activity feed.  Let’s investigate a bit further.

Looking at the activity feed on Grammy.com, you can see from the looks of the activity feed that this widget is pretty simple–a list of six items from the news feed with a little image next to each.  How can six  35×35-pixel images take 4.2MB?

The answer is that the image being show, in a 35×35 squares are not really that small. The image of Josh Baze is actually 560×843. Ouch!  What’s happening is Facebook is not “right sizing” these images, which leads to large load times and a HUGE amount of wasted bandwidth.

Async Loading Facebook Plug

In the webpage you will notice that they include the JavaScript for the facebook widget as follows…

<script src="http://connect.facebook.net/en_US/all.js#xfbml=1"></script>

This has a inherent performance issue because it will synchronously load the Javascript. On facebook’s developer page they tell you to load the Javascript using

<div id=”fb-root”></div>
<script>(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;
js.src = “//connect.facebook.net/en_US/all.js#xfbml=1&appId=20152740944″;
fjs.parentNode.insertBefore(js, fjs);
}(document, ‘script’, ‘facebook-jssdk’));</script>

which is the asynchronous approach to loading Javascript.

Conclusion

Avoid using the Facebook activity feed.  It is a huge performance problem. This widget should be 2 requests at most, and all of the images should be embedded as  dataURIs into the HTML file.

Bob (Buffone)

If you have a site that you’d like me to examine, add a comment here or tweet the name of the site to @Yottaa.

Yottaa – Optimize. Protect. Monitor.

The 2nd wave of cloud debate

Cloud Computing has reached a new adoption milestone, evident when recently the core debate about cloud computing has moved toward whether any given technology company will eventually outgrow a public cloud like Amazon Web Services (AWS), instead of whether to work with the public cloud or a private cloud. We believe that cloud computing is a cost effective solution, no matter the size of your business.

I recently spoke with Derrick Harris at GigaOm about this very topic.  It was nice to have the opportunity to share Yottaa’s cloud story and explain the company’s hybrid cloud approach. At Yottaa, we took a very unique approach to build our infrastructure. We use Amazon AWS extensively, from EC2, S3, ELB, EBS, SQS, CloudFront to IAM and plan to add a few others soon. We also use quite a few other cloud providers such as Microsoft and Voxel.   Beyond that, we built our own physical data centers as well.  Our network covers over 24 global data centers today. We call this a “hybrid cloud” or “a hybrid network.”

For context, Yottaa provides services in the cloud to optimize,  protect and monitor websites and web applications, dramatically improving website speed, scale, security and business results. More than 100 million unique visitors go through the Yottaa Network per month – that is almost 5% of the entire Internet population. Our systems continuously optimize themselves to find the right mix of public and private clouds in which to send traffic. We do this with the full understanding that some traffic is best routed and served to AWS, while there are other times served at our own private cloud facilities. For example, in our case, if a specific application has a unique requirement that can’t be met in the cloud (which is rare), such as in the locations that no public cloud exists, then we’ll use our own infrastructure.

Derrick’s recent article Worried you’ll outgrow the cloud? You’re not alone offers unique perspective and insight as per usual. However, there are a few things I didn’t communicate to Derrick clearly – so I want to clarify them here.

Cost

The big thing that I learned is that a company should always be looking at infrastructure and cost, especially so in this “cloud era” that we have many more options to optimize than before.  Of late there seems to be a common perception that when you reach a certain scale, using cloud computing is no longer cost-effective. I would disagree with this statement – for us, AWS has been and continues to be cost-effective for our workloads.

When it comes to optimizing cost factors, it may actually be easier to document, manage and predict in the public cloud than if you are managing your own hardware. On the public side, so long as your applications and workloads are designed for the cloud’s elastic computing, you can easily plan ahead on the cost-management side. All the costs land on the operational side of the balance sheet.

Private clouds become exponentially more complicated with a blend of capital and operational factors. You need to account for hardware and administration, not to mention management costs. Then you have the unused capacity issues, lower economies of scale, and higher opportunity costs.

More importantly, the strategic use of cloud services like AWS is how new companies like Yottaa can innovate beyond old companies. As an example, the 15-year-old  Content delivery network (CDN) industry has many well-known players who tout their “50,000 servers” as their unique advantage.

At Yottaa, we have a drastically different story about the number of servers: Yottaa can scale to 100,000+ servers in a matter of hours. In this cloud era, we should be talking about elasticity. Talking about the “number of servers” is missing the point.

Security and Performance

The debate of whether a public cloud or a self-created and controlled environment is better for security and performance will continue to rage. The real debate should be about how to leverage them to meet business requirements. The reality is that public cloud like AWS has no problem at all in delivering security and performance. We found that cloud providers like AWS and Microsoft have done an amazing job – their network level protection and defense is far more sophisticated than most private clouds can ever achieve. The real issue here isn’t whether a public cloud can deliver security and performance, but rather what a cloud customer should do. It’s important to understand the specific requirements of your applications so you can ensure high performance and security in whatever environment you deploy them in – whether that’s your own data center or the cloud.

The key is to understand the differences and tradeoff between different environments and manage them appropriately. For example, identify the special requirements for your application that you want to manage directly while running everything else in the cloud.  An example I talked to Derrick about is SSL acceleration. Due to its high IP address space requirements, we identified this is something that we want to manage directly and serve from Yottaa’s private cloud.

Monitoring

Just as with cost, companies need to examine their own applications to ensure high performance, no matter the environment – whether it’s your own datacenter or the cloud. At Yottaa, we pride ourselves on our ‘optimized approach’ by sending workloads and traffic to the infrastructure that is the best fit for any particular task.

From the beginning Yottaa architected both core and ancillary services to take advantage of the best qualities of each environment, which at the core include elasticity.  We will continue to expand our usage of public clouds like AWS. It has served us well and I’m sure it will continue to serve us well.

Our job here at Yottaa is to help our customers take advantage of that so they can make their website performance and security the best it can be, no matter what infrastructure they choose.

Last week Yottaa’s Beijing office hosted a landmark event: the first Web Performance Beijing Meetup.  It marks the first of what we at Yottaa hope will be a great many Meetups and a new era in sharing knowledge about Web Performance in the great city of Beijing.

This newest chapter in the worldwide Web Performance Meetups (#WebPerf) is off to an auspicious start.  The room at the Yottaa offices in the Heidan District of Beijing was filled with excited attendees–just a few more and it would have been standing room only!

Sharing Knowledge, from Boston to Beijing

The attendees heard opening remarks from Yottaa’s Jin Jian followed by a talk from Yottaa CTO Bob Buffone called “An Expert’s Guide to Making Websites Slow: Design Anti-Patterns.”  In the talk, Bob discussed a number of points in the design and update of websites where the decisions made can conspire to slow down website performance, and made suggestions for how to avoid those results.  After the talk, attendees joined in an informal question and answer session and general discussion of Web Performance.

With the success of the first meetup all of us at Yottaa are looking forward hosting another very soon.  Stay tuned for details!

Special note – we would like to thank Segey Chernyshev and all of the WebPerf meetup organizers around the world for their inspiration and support.

A key reason Yottaa is such a distinctive company is that we’re truly international: from the beginning our team has been split between offices in Beijing and Boston.  And while YoTeam members in Boston can often be found attending and speaking at local Meetup events, we couldn’t help but notice the unfortunate absence of Web Performance events in Beijing.  We set out to change that.

April 27, 2012 marks the first ever Beijing Web Performance Meetup. It will be held at Yottaa’s Beijing office in the Heidian District.

At the event, Yottaa CTO Bob Buffone will present a talk entitled “An expert’s guide to making a website slow! Anti-design patterns.” Bob will present in English, through a Chinese translator.

The talk will identify a number of key points in the development and updating of a website where the decisions made commonly conspire to slow down the website.  Attendees will leave the session with a list of do’s and don’ts on how to make a faster website.

We’re thrilled to be getting some of Beijing’s web performance professionals into one room for what’s sure to be an awesome discussion.  We truly hope that this event will be only the first in a long line of WebPerf Meetups to occur in this great city.

Click “Continue Reading” for details on the Meetup.

Date/Time: Apr 27, 2012 (Friday), 1:30pm – 3:30pm

Address: Yottaa Inc. – Suite 316, C-King Tower, 17 East Madian Road, Heidian district, Beijing (1000290)

Registration: http://www.douban.com/event/16321021/

About Bob: Bob Buffone is  Co-founder and current CTO of Yottaa. Before Yottaa, Bob was Chief Architect at Nexaweb. Through his work at Nexaweb, Bob became an industry leader in web performance and has been invited to many industry conferences such as JavaOne, the Server-Side Symposium, EclipseCon, ApacheCon, AjaxWorld and the Ajax Experience to speak on web performance. Before he joined Nexaweb in 2003, Bob was with Trakus, a technology company focused on tracking sports athletes in real time. At Trakus Bob designed a real-time distributed control system and many of its front-end applications. Before Trakus, Bob was at Cabletron designing network communications related software (FTP, TCP/IP, SMNP etc.).

Each Friday Yottaa CTO Bob Buffone digs into the data and evaluates the web performance of a new website.  Recommend a site for next week’s Expert Eval in the comments below or @Yottaa on Twitter! #ExpertEval

Each week I examine a website that exhibits performance challenges.  Some of these issues will be of the YSlow variety — less request, more compression, etc.  This week we took a look a Drupal site, the Jane Goodall Institute’s www.janegoodall.org.  The site has three issues that bear discussion.

1. Compression

The website does not use compression for test files like JavaScript, HTML and CSS.  Looking at the waterfall chart (via Yottaa) for the site, you’ll notice the homepage is compressed with gzip–you can tell because the response header Content-Encoding equals gzip.  However, as is shown in the screenshot below, none of the other assets on the homepage, nor other HTML files, are gzipped.  This reveals a missed opportunity for better performance on the homepage.

2. Data URIs

This website, like many others today, has a number of assets that could be encoded as data URIs.  Data URIs are a great way to “inline” small files (ones that are only a handful of KB’s each) so that they are fetched by a single HTTP request.

If you were to sort the waterfall for JaneGoodall.org by “asset size,” (as I have below) you’d see that there are 20 assets less than 5KB in size.  This group of assets represents another example of missed opportunity for performance improvement: each of them requires its own round trip, whereas they could become a single request by using a data URI.

3. Secondary Pages

Load times for secondary pages on JaneGoodall.org are much slower than the load time for the home page. Compare, for example, the Home page and Donation page.  Looking at the data you can see:

• Overall load time: homepage (5.13) vs donation page (11.34)
• Reachability: homepage (1.09) vs donation page (2.92)
• Page size: homepage (1.1KB) vs donation page (1.7KB)

Most developers optimize homepages, but secondary and tertiary pages must be optimized as well in order to achieve a truly well-performing site. The Jane Goodall Institute depends on donations to keep up the great work they are doing, so having a slow donation page could potentially cut down on the site’s conversion rate, even if its homepage loads pretty quickly.

This is a perfect example of the challenges brought on by sites that are manually optimized: each page must be optimized separately, by hand. Even though the Jane Goodall site is built by Trellon, it still requires each page to be optimized differently. This a difficult problem for the creators of the site.  The Goodall Institute chose to use a CMS to make managing their website easier, but now need to optimize each page differently.  In order to fix the problem they will need to dig into the template or CMS internals and figure out where to optimize each specific page.

If you have a site that you’d like me to examine, add a comment or tweet the name of the site to @yottaa.  Yottaa: Optimize. Protect. Monitor.

Bob (Buffone)

Yottaa’s DevOps team has just returned from Chicago.  But far from reveling in the success of the Bulls or taking pictures of a giant bean, the team spent their days holed up in a datacenter, expanding the geographic footprint of Yottaa’s hybrid-cloud network for the benefit of Yottaa customers.  That is to say, they just spent several days in a cold, windowless room with deafening white noise and security guards watching their every move. Thanks guys!

The DevOps team, led by Director of Operations Jason Parsons, installed new physical servers and configured a new data center location in one of the world’s best datacenters, located in Chicago’s South Loop. The new datacenter there joins the dozens of others in Yottaa’s hybrid-cloud network that we use to operate our Site Speed Optimizer and Monitor services.

Entrance to the datacenter in Chicago, photo by Jason Parsons

Decisions, Decisions

One of the biggest challenges in building a secure and effective network like Yottaa’s is determining which facilities, providers, and equipment will be optimal for the performance of the network.  Yottaa is continuously analyzing our geographic reach, researching the state of the art in network deployments, and ensuring that we are able to provide our customers with the best service in a cost-effective manner. We also must assure the utmost network security at all times.

One reason we chose this particular data center was for its location. Chicago’s geographic centrality in North America makes it a great location for traffic going to and from the millions of people in the upper Midwest and Canada.  The highest concentrations of datacenters in the world are in the Northern Virginia and San Francisco areas, which means the northern-central region can sometimes be underserved.  Not on our network.

We also chose the Chicago datacenter because it’s a top-notch facility: a “Tier 4 datacenter” as those in the industry would say. (Tier certification is performed by the Uptime Institute, and “4” is the top of the pyramid.  Specifics on what defines each Tier changes constantly as new technology is developed.)

Built in a former R.R. Donnelly Co. printing press structure, the datacenter has a distinguished and historical appearance on the outside, unlike the average datacenter that’s housed in an unremarkable bunker-like structure.  But more important than the appearance is what’s inside.  The center has over a million square feet of datacenter space, making it the largest datacenter of its kind in the world.

The Chicago datacenter has security features such as mandatory “man trap” access (think of the airlocks for entering and exiting space shuttles), a redundant liquid cooling system, and A/B power supply–meaning every piece of equipment is hooked up to two power sources so that if one fails the other can pick up the slack.

We could go on and on about the fantastic space-age features of this datacenter, but it should suffice to say: we feel safe putting our servers here.

The Challenges + Benefits of Unique Infrastructure

We want to achieve the best, most secure connections for our network while delivering the lowest latency for our customers.  Building a scalable network, though, presents its challenges, especially in a the highly complex world of hybrid-cloud networks.

Our software was designed from the start to work on best-in-class infrastructure, whether that means a cloud provider, a managed services provider, or our own physical infrastructure. For our own infrastructure—the stuff we use to provision, configure, manage, and monitor our servers—we designed from the ground up for it to work in any environment.  This means that we can’t rely on features only available from one provider–our infrastructure needs to be self-contained and generalizable.  It needs to accommodate the differences between various virtualization or “boot strapping” environments, thereby providing a way for us to automatically and easily scale across all of our facilities.

The Yottaa DevOps team has achieved this through robust infrastructure based on technologies such as the Linux Operating System, automated Kickstart deployments, and configuration management and automation with Puppet.  By designing these tools in from the start, our team is able to rapidly scale our services to provide the best performance to our customers.

To learn more about Yottaa’s network and see a map of all our locations, visit our Network Map

Every day, we at Yottaa make choices on what to bring into our organization and what to keep away. We have a fairly large team that spans two continents, two languages (中文，English), 12 hours, multiple teams and varying levels of experience. This complexity in our organization means we need to do some due diligence about our development choices. If it were just me or a small team, we could make a different set of choices on technologies.

Once we choose a technology at Yottaa (a language, library, process, or 3rd party) we need to turn our personal knowledge into organizational knowledge. This is a key point in the process: companies and organizations live and die based on their organizational knowledge. It’s true that personal knowledge is key when you start a company–it’s what the VC’s look for. But it’s important to convert that personal knowledge to organizational knowledge as quickly as possible, if you are to grow as a team and succeed.

In other words, it makes no difference whether there’s one person on our team that’s an expert in something. To let that person build a widget using knowledge only they have would be extremely dangerous to the team’s overall goals, unless that person can deliver from start to finish and the widget will never, ever need any maintenance.

In the process of developing organizational knowledge here at Yottaa, we discussed adopting CoffeeScript, a transcompiler of JavaScript that ostensibly makes the language easier to read and require fewer keystrokes.  It was proposed that we use CoffeeScript going forward for all our Javacript development.

We had lots of discussion internally about using CoffeeScript, and rather than explain our thinking I will place it here for you to read and draw your own conclusions.

—– Internal Email (Edited for grammar and completion of thoughts) ——

About the coffee script… We do not want to use coffee script at Yottaa. There are many reasons:

• – We are all really good developers that are capable of learning and mastering a fundmental language of the web. Using CoffeeScript takes energy and time away from the learning and mastering Javascript. It is true some of the knowledge you learn is Javascript but everyone we hire going forward must also learn CoffeeScript because we use it.

• – @ Yottaa we want our developers to learn skills that they can carry forward to other languages, projects and jobs in the future. Putting on a resume: “expert in JavaScript” is something that can increase your career and value (salary). If you know JavaScript well, the employer will “let” you learn CoffeeScript on their dollar.

• –Syntax is a personal preference, having developed code in many languages through the years, i have realized that it is all the same. The webpage http://jashkenas.github.com/coffee-script/ says:

CoffeeScript is a little language that compiles into JavaScript. Underneath all those awkward braces and semicolons, JavaScript has always had a gorgeous object model at its heart. CoffeeScript is an attempt to expose the good parts of JavaScript in a simple way.

• –Reading code and seeing the syntax {curly braces and semi-colons} means you are not looking at the right things or you do not write code in a consistant way. All of the syntax should fall away in your thoughts and what is left is the essence of what you are building. This concept should be practiced and mastered, because it can be used over and over again no matter what language you are using. Think of it like looking at painting, you know what they used to create it (watercolors, pencil, crayons…) but what you see is the essence of the painting. If the painter sucks… sure you will be looking at the pencil strokes, splogages made by the crayons, but that is because they suck. Writing code is an art: when you are done, the code should be beautiful. The syntax never prohibits beautiful code, your craftsmanship does.
• –Saving characters you type is NEVER a reason to choose a language. Not once have i said or heard anyone say: I cannot finish my project because i needed to type all the damn (i swear a lot, but will keep it clean today) “{}” or “;” We do not work at Gattaca.  Vincent wrote a program that as his boss exclaimed had “not one error in a million keystrokes”, we do not need to be so proficient at typing as Vincent. We can afford a few extra keystrokes and backspaces.
• –Unlike other templating languages we use SASS and HAML. CoffeeScript produces “executable” code that requires debugging. This debugging happens within the browser using tools like firebug, chrome developer tools… the code you are looking at is auto-generated and not your creation. This makes it harder to quickly grasp the code, because auto-generated code is NEVER masterfully create and beautiful.
• –”Simpler” is not always better, “Simpler” is not always easier, “Simpler” is not always faster. Learn the core technologies and learn them well; you will be better off in the long run.
• –We do not have anyone passionate about using the technology and also an expert in CoffeeScript. Sure the creator of CoffeeScript thought it is a good idea to create it. I can not disagree with that. CoffeeScript will work well for many people but we can not always choose technologies because other people are using it. We ourselves must be overwhelmingly passionate about it and we must also have an expert in the language. We can not start using something today if neither passion nor expertise exists.
• –You will still need to learn JavaScript anyways. You will always debug the code, CoffeeScript does nothing to fix logic errors, fence post errors, algorithm problems. You need to get into the code and make sure it works and figure out why. This will only occur in JavaScript.

@yottaa, we love it when there is overwhelming passion and expertise in a technology to carry it forward. Without passion it is hard to make anything successful.

Bob (Buffone)