Mobile networks are much faster than they used to be. You've probably heard of 4G, a suite of mobile telecommunications standards including Wi-Max & LTE that are delivering download speeds between 2 - 40Mbps on current generation high-end smartphones. A few popular handsets that currently support these standards include the iPhone 5 and Samsung Galaxy S III. You can expect that over the next year most mid-market smartphones will support these standards, too.

40 Mbps is fast. Really fast. So at speeds that fast, does mobile web performance optimization still matter?  If you're reading this blog post, you already know the answer is yes. But optimizing a website takes a lot of engineering time and testing, so we want to qualify why optimization is still a business necessity and quantify just how much it matters to your bottom-line.

3G & 4G network carrier latency & packet loss

Why does optimization matter?

As Stuart Cheshire (Stanford, Apple) wrote in 1996: It's the Latency, Stupid! The most important thing to understand is that for web performance, once sufficient bandwidth is available (about 5 Mbps is the inflection point) latency becomes far more important than bandwidth. Latency is typically measured in the Round Trip Time (RTT) – the length of time it takes for a request to go from the browser, to the server, and back to the browser again. Have a look at the graphs produced by Google below. In the chart on the left, we see that page speed increases dramatically from 1 to 2 Mbps, but gains after that become increasingly marginal. However, in the chart on the right, focusing on Return Trip Time, we see a nice linear improvement in page performance as latency decreases. For web performance, latency is king!

Latency per Bandwidth & Latency per RTT
Graphic credit: Ilya Grigorik (Google)

Latency is primarily determined by the physical distance the request must travel between the browser and the server. If the request needs to cross a continent or an ocean, it's going to take longer than a request that has to cross the street. The speed of communication is limited by the laws of physics (we can't go faster than the speed of light) and that isn't something anyone expects to change anytime soon! To read a lot more about latency & performance, have a look at Ilya Grigorik's blog post on the subject.

3G radio technology had some unnecessary latency, and this latency has been fixed by 4G technologies. Virgin Mobile, for example, reports that "Users of the Sprint 4G network can expect to experience average speeds of 3Mbps to 6Mbps download and up to 1.5Mbps upload with an average latency of 150ms. On the Virgin Mobile 3G network, users can expect to experience average speeds of 600Kbps - 1.4Mbps download and 350Kbps - 500Kbps upload with an average latency of 400ms."

150ms is a lot better than 400ms – sounds pretty good, right? Unfortunately it takes more than one round trip to establish communication between a web browser and a web server. In fact, it takes 3 round trips for the first bytes of data to actually arrive. 450ms is the best case scenario for a visitor on a high-end smartphone and a 4G network! And that's just for the first few hundred bytes of data. Still, a 450ms block in rendering isn't too bad, is it? But according to Google, the average top internet site has 42 resources in it. Fortunately the browser doesn't have to connect to the server 42 times - once a connection is established it can be re-used for subsequent requests. And web browsers try to help out by establishing multiple connections to each host automatically. The Google data shows top sites have an average of 8.39 hosts per page. Lets be generous and round that down to 8. If we were doing things serially -- that's an absolute minimum of 3.6 seconds under the most ideal circumstances.  Fortunately, the look-ahead pre-parser can parallelize some of this so the math gets more complex.  But for the majority of 3G phones and networks we could easily be looking at 5 - 10 seconds of delay to the page load time.  What does this mean in business terms?

Amazon's team famously discovered that 100ms of delay decreased sales by 1%. Using this formula, for our high-end smartphone example on 4G, that means these external resources have cost you about 29.65% of sales from your website for smartphone visitors. For visitors using an iPhone 4S running on a 3G network, this performance problem cost 63% of your sales. Other experiences are similar, for example, Shopzilla found that by moving their page load time from 4 - 6 seconds to around the 1 second mark resulted in a 7 - 12% increase in conversion rate.

Mobify's results - and why you definitely need to care about optimizing for performance on mobile!

The graphic below shows a cohort performance analysis for high-end smartphones. The test involved downloading a 20KB file from a cookieless domain cached across Mobify's CDN with more than 40 Points Of Presence (POPs) distributed worldwide. We further limited the test to iOS devices running iOS 6 and Android smartphones running Android 2.3 and newer. During the test we collected more than a million data points.

20KB smartphone image download speed – cohort analysis

From this you can derive that in North America:

• 92.16% of smartphones took > 200ms to load a 20KB file
• 63.93% of smartphones took > 400ms to load a 20KB file
• 44.71% of smartphones took > 600ms to load a 20KB file

The situation is almost exactly the same in Europe. In Asia & Africa the situation is much worse.

What can you do about it?

Many of you may be hoping that domain sharding & HTTP 1.1 features such as pipelining can help with this. Unfortunately, domain sharding is at best neutral and in many cases may cause a performance penalty due to the overhead involved in creating new connections. HTTP pipelining has a head-of-line blocking problem and offers at best a modest push in the right direction. Although new technologies and new undersea cables will continue to erode latencies, gains there will be marginal. The cost of improving 1ms of latency in an undersea cable, for example, is 25 million dollars per millisecond saved.

As a web developer, performance should be considered a feature that ships with your product. But performance optimization can be a costly process and often performance tweaks can significantly increase the maintenance, management and testing costs for a web project.

Mobify is committed to helping developers spend more time shipping core features, taking the heavy-lifting off of our customers.  Our platform provides a number of tools for optimizing the performance of your mobile and tablet websites powered by Mobify's cloud platform including the ability to:

• automatically compress resources
• automatically serve resources from our worldwide CDN
• whitelist select JavaScript resources
• lazy-load resources not needed when the page renders

Sign up for Mobify Studio for access to our cloud platform with these features, based on the open source  Mobify.js project.

In this post we’ll review the results of a real-world test with over three million samples showing that domain sharding is at best neutral and at worst harmful for mobile websites.

If you’re already familiar with sharding, you may want to skip straight to our results. Otherwise, we’ll begin with a brief introduction to the subject.

What is Domain Sharding?

Traditionally, web browsers place a limit on the number of simultaneous connections a browser can make to one domain. These limits were established in 1999 in the HTTP/1.1 specification by the Internet Engineering Task Force (IETF). The intent of the limit was to avoid overloading web servers and to reduce internet congestion. The commonly used limit is no more than two simultaneous connections with any server or proxy.

Domain sharding is a technique to accelerate page load times by tricking browsers into opening more simultaneous connections than are normally allowed. It's a widely-used optimization tactic that enables browsers to make better use of high-bandwidth internet connections.

The average web page references 44 different resources such as image files, stylesheets and JavaScript. Each of these resources need to be loaded for the page to render correctly, so domain sharding seems like a useful technique for increasing load times and, therefore, improving user experience.

However, there are two key reasons why domain sharding is no longer a best practice, and why web developers should particularly avoid it on mobile or responsive websites:

1. Additional network connections above and beyond the recommended limits are not “free”. Each connection comes with a setup overhead in the form of a DNS lookup and a TCP 3-Way handshake, as well as TCP slow start. For mobile browsers, the resulting latency is much higher than for desktop users. Additionally, this connection setup consumes extra CPU, memory and battery power--all considerations on mobile devices with scarce resources.
2. Many mobile browsers implement HTTP pipelining and no longer observe the old HTTP/1.1 connection rules.

Domain sharding works because web browsers recognize each unique internet name (a DNS entry such as www1.yourdomain.com, www2.yourdomain.com and so forth) as being a different server, even if in reality all those domain names resolve to a single server.

If you divide your references to static assets such as images, scripts and CSS files over several servers, the browser will open two connections to your web server for each server name. You may have noticed, for example, that resources on YouTube pages load from i1.ytimg.com, i2.ytimg.com and so forth.

The web, and web browsers, have changed

When the “two connections per server” rule was established, most internet users were using dial-up internet connections one-tenth to one-hundredth the speeds of today’s broadband connections. Most contemporary browsers no longer implement the two-connection per-server limit since 2010.

For example, the default for desktop Firefox is eight connections per server, and for Google Chrome and Internet Explorer 8/9 the limit is now six connections per server. For most websites, these values are high enough to effectively maximize bandwidth utilization. Additional sharding for desktop computers will only offer marginal improvements or may even penalize your site’s performance.

So what about in the mobile browser use case?

Here’s a table showing simultaneous connections by mobile browser type:

As you can see, mobile browsers also no longer respect the two-connection per-server limit.

So, is domain sharding still necessary? We wanted a definitive answer, so we ran some real-world tests.

Real-World Testing of Domain Sharding on Mobile Devices

Our test required downloading 15 images, each about 10 KB in size. By using a portion of our Mobify Cloud network, we were able to test using real users on real networks and real phones distributed around the planet with almost 3-million unique samples.

The test was limited to visitors using high-end smartphones such as iOS 5, Android 2.2+, BlackBerry OS 7 and newer devices. The backend was serviced by our global Content Delivery Network, so mobile visitors received data from a web server running in one of our 35 worldwide data centers with the images in memory geographically close to their location.

Here are our results:

Regardless of browser, when we added shards, the results were at best neutral and, in most cases, detrimental.

The lesson: the connection overhead for mobile browsers exceeds the benefits of having additional simultaneous connections.

Mobile Chrome takes the biggest penalty for adding more shards, performing half of a second slower when sharding is used, but Safari Mobile also pays a hefty penalty.

Domain Sharding Conclusions for Mobile Devices

Ultimately, sharding adds complexity to your infrastructure without providing performance benefits. In many cases, sharding can degrade visitor performance for your site.

Based on our data, we recommend disabling sharding for both for desktop and mobile visitors.

I'm passionate about the mobile web -- I use it every day to find my way around, shop, read the news, and keep up with my daily life.  I flinch when I see sites that are breaking my user experience with unwise technology decisions.

One of the core beliefs of Mobify's philosophy is One Web – that websites should have one unified URL for a given piece of content for all devices: desktop, mobile, tablet and anything new that arrives in the future.  In the early days of the mobile web, mobile-optimized websites redirected to an m-dot site – you visited mobify.com on an iPhone, you would automatically be redirected to m.mobify.com.

That was the first generation of technology for mobile websites. But m-dot websites come at a cost.  Here are six things to think about if you're considering an M-dot site.

1. Redirects are not good for SEO

In June, Google stated that they prefer a single URL for your web content.  Yes, you can use the canonical link tag.  Google might respect it.  It might not.  The algorithm they use is known only to a few select engineers at Google.  As they say in the fine print of the page "It's a hint".

2. Performance

With 3G latencies, you're looking at up to 2 seconds for the redirect to an m-dot to complete.  The visitor to your mobile site will count this against you, which negatively affects their impression of your site and reduces the likelihood of them returning.  With delays as small as 500 milliseconds resulting in a 1.9% conversion penalty, performance is money.

3. Subdomain Spaghetti

If your strategy is to serve a website for each device type, what will yo do for tablet optimization? And Smart-TV optimization? Or for the raft of new web enabled devices we’re going to see in 2013 – 2014?  Managing the redirect mess is a house of cards that gets worse the higher you build it.

4. Social Media

Redirects and hardware-specific URLs and websites are the kiss of death for social sharing.  If a visitor shares a link to your mobile m-dot website but their friends aren't on mobile devices, what happens? Desktop users will get the site designed for a 3.5 inch screen on their 24 inch monitors.

5. Email

Email remains the killer application of the web.  It's the #1 way we share content.  We all use it, all the time.  To make email links work across devices, they need to have the same URL or you end up in the same unescapable mobile dead-end world mentioned above with social media.

6. Philosophical

Every web resource should always live at one URL.  This was Tim Berners-Lee's vision and it was a good one. It provides simplicity, search-ability and user-friendly behaviour that has enabled the web grow into what it is today.

It's a good principle to uphold.  (Also, it's endorsed by Google.)

What can you do?

If you're considering launching an m-dot site, stop.  There's no good reason to do it when you have so many options for doing mobile the right way.

Responsive design techniques can help you with a One Web approach if you're able to do a full site redesign.  Add in Mobify's platform and open source, client-side adaptation framework for complete control over your website and its resources on any device – it's the result of our passion for the mobile web and strong beliefs about doing it right.  Don't have the resources for a complete responsive redesign?  No problem.  Mobify's platform can make your website responsive to tablets and mobile devices at a fraction of the time it would take to build your responsive site from scratch.

Developers can try Mobify for free here.

If you're looking for a full service partner for your mobile and tablet experiences, please look at our service offerings and get in touch. We'll provide value for building your mobile strategy from the very first call.

Facebook recently slowed the loading time of hundred of thousands of websites to a crawl.

The culprit of the performance drop-off? Facebook's 'Like' button.

When websites with the 'Like' button embedded tried to load, the 'Like' button was slow or unable to load. This caused web pages to lag, hang and generally load like molasses. The user experience was slow.

But this issue could have been avoided by following a best practice guideline – loading the script for the 'Like' button asynchronously.

(More on the differences between synchronous versus asynchronous signalling.)

Seeing the 'Like' button slowing so many websites hit home here at Mobify because we're always thinking about performance.

For years, we've been implementing the Mobify script asynchronously because our customers need world-class performance and reliability. We've also been recommending that they follow best practices and implement all their scripts asynchronously.

Why?

Because the performance of a website should not depend on a single point of failure loading resources, like a script.

Performance is directly related to customer experience, satisfaction and e-commerce revenues. We see it proven every day with a heightened sensitivity on mobile.

So we thought we'd share some of the steps we've taken and our own best practices on asynchronous scripts, redundancy and performance.

1. Redundant Domain Name System (DNS)

What is it?

The Domain Name System (DNS) translates domain names into IP addresses.

Why does it matter?

Humans like to use domain names like Google.com. Computers like to use IP addresses like 74.125.224.72.

When you type "google.com" into your browser, a DNS server translates that request into 74.125.224.72 where Google.com lives.

Try going to 74.125.224.72 in your browser and you'll see it load Google, while 74.125.224.72 appears in the URL bar.

Secure and reliable DNS is essential to any successful internet service – a DNS outage is almost a worst case scenario.

When a DNS outage occurs, browsers can’t look up a DNS address and are unable to match a URL to an IP address.  The browser will wait and keep trying for a very long time leading to a terrible user experience.

If your DNS is down, you're out of business on the Internet.

Best Practice for Redundant DNS

Mobify has DNS’s hosted in 9 different data centres across the world. The closest of those 9 will respond to a request. If that data centre takes too long to respond, the next-closest one will respond. Our goal is to return DNS lookups within 30-50MS globally.

The result is that our customers have 9 different layers of redundancy to ensure our DNS is fast and reliable.

2) Redundant Edge Nodes

What is it?

Edge nodes are distributed copies of websites built to deliver all the website resources (images, scripts, videos, text, etc.) very fast.

Why does it matter?

It still matters how far traffic has to travel. The shorter and less hops it has to do, the better.

We want to be able to serve visitors quickly whether they're in Japan, Brasil, New York or London.

We also want to have a lot of these scattered around the world, not only for speed, but also for multiple layers of redundancy.

Best Practices for Edge Nodes

We have 19 edge locations around the world. Their locations are reflective of our customers' traffic with coverage in regions around the world. We have at least one edge node on every continent except Antarctica and add new nodes as traffic increases in geographic regions.

The nodes work together to deliver performance. If an edge node ever takes too long to respond or fails, another node will take over the request.

This is especially important as performance is tied directly to financial success, where even 400MS lag – a literal blink of the eye – affects user behaviour negatively.

3) Backup Content Delivery Network (CDN)

What is it?

A content delivery network (CDN) is a distributed network of servers that work together to deliver content to users as quickly as possible.

Why does it matter?

A CDN is one more essential piece of the performance puzzle.

When people click on a link on a web page, hit a play button on a video or choose to zoom in on a product image, they want their request to be served as fast as possible.

A CDN makes serving these web requests faster and more reliable.

Best Practices for Redundant CDN

Even though it's rare, it remains possible that an entire primary CDN goes down and could take your website with it.

The key to manage this risk is to have a backup CDN standing by and ready to go.

All the information on the backup CDN needs to be identical to the primary CDN, meaning that it can be called into action in seconds and fired up by changing DNS records.

Our backup CDN is equivalent to our primary CDN but hosted with a different company with nodes in different locations.

We monitor our CDN performance constantly and will flip to our backup CDN if content (that we know should be served by our primary CDN) is missing, slow or unreliable.

We have a third level of redundancy as a final option: we will pass our customers' traffic directly to their desktop site.

Knock on wood, we've never had to use this option.

So there you have it, Mobify's best practices to avoid a Facebook fail and to ensure your mobile performance is world class.

If you're happy working with code – JavaScript, CSS and HTML5 – you can try out our Mobile Cloud platform as described above, right here:

Try Mobify for free

Congratulations – you're growing fast! Now for the hard part.

This post is about your office data environment, the one that lets your awesome developers create happy customers. We're not going to talk about scaling servers, data centers, or your applications; there's lots of great articles out there about that already.

If you're new here, here's a little bit about us:

• Mobify is a web platform for building beautiful smartphone and tablet websites.
• Today, Mobify's clients include $10+ billion market cap companies such as Siemens, Starbucks, Bosch, lululemon athletica and NBC Universal.
• Founded in 2007, we've gone through a lot of changes, among them the growth of our fantastic team. In this post we'll talk about some of the lessons we've learned along the way.

Our core infrastructure philosophy is: never have mission critical resources in one place.

Since it's not feasible to have redundant offices, that means we have no mission-critical infrastructure at our office and all key infrastructure is based on secure cloud access so our engineers can work remotely in the event our office is unavailable due to fire or other circumstances. Our mission-critical delivery infrastructure and every component of the software stack our engineering and sales teams use is either on their own development machine (backed up off-site every few hours) or distributed across multiple data centers around the world.

Growing Your Company: Powers of 10

Every data infrastructure technology that used to work for 10 people is going to break when you scale up to 100. (Likewise, when you move to 1,000.) If you expect this kind of growth, you should start planning well in advance. Office infrastructure is not part of the on-demand world. If you need to provision phones, internet, or order networking equipment expect a significant lead measured in weeks or months, depending on the responsiveness of your local telecom/network providers.

Even the jump from 10 to 20 employees is going to be a burden on your infrastructure. That business internet package you bought from your cable or DSL company, coming in at 15, 25 or maybe 100 Mbps, used to be enough for your needs. But the time will come when you need more, and the time to start planning is not the day it stops working for you.

One or two Wi-fi access points were more than sufficient. You could use cell phones or maybe one or two landlines from your cable provider or telco. But gradually things start to break. Your access points won't let new users join and you have to reboot them. Your internet provider goes down, or oversubscribes your zone bringing your internet to a screeching halt.

Power

You're going to want your core infrastructure, including phones, to be on regulated uninterruptible power supplies so a service blip from your power company doesn't interrupt important conference calls or forcibly restart everything in your network! Even a 1 second long power glitch can have a huge impact if it takes everything down. The easiest way to centralize your UPS infrastructure is to use Power-over-Ethernet (PoE) switches to deliver power as well as network connectivity to the wireless access points and phones.

Network

Gigabit ethernet is ubiquitous and inexpensive. You're not likely going to need more bandwidth for office functions. We use a 48 port L2 PoE switch from Netgear  with HDMI ports for stacking up to 288 ports. The HDMI port gives you 20 Gbps of inter-switch bandwidth so you can grow at a very reasonable budget. By the time you hit this number of ports you're going to be doing a major re-think of your infrastructure and making the next jump anyway.

Since we only have a couple of servers on-premises, we don't really need to worry about a server subnet. Keeping your network flat is going to make things easier to configure. Be generous with your subnet address allocations. There's lots of addressable private network space and it's better to have too many addresses in a subnet and not use them than it is to run out when you need them. We have only a handful of VLANs: two general purpose VLANs for clients split over the 2nd and 3rd floor of our building, a VoIP VLAN and Guest VLAN. For our general VLANs we use /23 networks that provides 510 available host addresses each although even with 4+ IP devices per employee we're using only a small fraction of that.

Wireless

For those of you that are new to managed wireless, it's going to be a bit of a "gulp" moment when you move from the world of consumer-end access points. Expect to move from paying $75 - 250 for an AP to paying $750 - $3000 per managed access point (AP), plus the cost of the controller.

Why would you do this?

The short answer is: consumer-end wireless APs don't scale. The choke point is usually the AP’s ability to handle encrypted traffic. The exact choke point will vary by the make and model of your AP, but somewhere between 20 and 50 clients you'll hit a point where the AP will simply stop accepting new clients. The CPUs on the consumer-scale devices were not intended for enterprise and encrypting traffic (you are using WPA2 encryption, right?) gets to be a little too much for them.

You can keep adding wireless access points, but they'll each have their own SSID. Plus, you'll want to roll out enterprise grade authentication for wireless clients instead of using a pre-shared key. Typically you'll want to use 802.1X for wireless authentication.

We use products from Ruckus wireless for our network. The Ruckus Wireless ZoneDirector 1100 is our controller and supports up to 50 access points and has a local authentication database for 1000 users. That's a good number – there's room to grow, and as we mentioned at the beginning of this article, you're going to want to start planning another major infrastructure leap at around 500 employees to make it to 1000. For access points we use a combination of Zoneflex 7962s and 7363s, all PoE powered.

There are two wireless "bands", 2.4ghz and 5ghz. Inside of these bands, each AP needs a unique "channel" separate not just from other APs in your environment but from all the other APs operated by other people in your neighborhood. If the channel gets shared with other devices, they have to compete for space resulting in interference and packet loss. The 2.4ghz range is shared with portable phones and microwave ovens, amongst other consumer devices and has a very limited number of distinct channels (effectively 4, due to overlap). The 5ghz band has at least 23 non-overlapping channels. Most modern APs will support both bands simultaneously, allowing clients to "choose" the best band. Our experience has been that wireless clients are not very good at this automated band selection and would often select the 2.4ghz band, even with "band-steering" provided by our wireless controller. Because we have a number of test devices in our lab that only work on the 2.4ghz band, we elected to create a separate wireless network for these clients at 2.4ghz, and have our primary network operate only at 5ghz. This has significantly improved the connection speed for most of our wireless clients.

Internet

You should invest in a symmetric internet connection (where upload speed is the same as download speed) even if your office usage patterns are asymmetric. Yes, symmetric connections are a lot more expensive. But all the download speed in the world isn't going to help you if your upstream queue fills up with TCP ACKs killing your window size. We use an Ethernet in the First Mile based technology that's worked great for us and delivers about 25 Mbps. We're not planning to expand this significantly until we start to have more than 200 network clients at which point we may move to 100 Mbps fiber; your own provisioning will depend on your usage of course.

Keep your old asymmetric connection around -- it's good to have a backup and it's relatively inexpensive. For bonus points it's not that complicated to get your router to automatically fall back if it detects a link failure in the primary connection.

Routing / firewall / network services

Your internal network is going to need to be routed somehow. We use a Linux based firewall / router running on a completely stock inexpensive 6 core AMD64 server. Inexpensive and stock are nice attributes because we can walk down the street and buy another one, or parts for it, from our local hardware supplier in about 20 minutes. This server provides a few functions for us but the core function is acting as a firewall and router.

We use a custom built set of firewall rules using the Linux kernel firewall, Netfilter. Netfilter also provides Network Address Translation (NAT). All routing and DMZ rules between our subnets is done here. Could we use a hardware firewall box? Definitely. With the Linux expertise we have in-house, there's not a good reason to do so at this time, this off-the-shelf box with high quality network cards can do all the firewalling and routing we need.

If you need an Intrusion Detection System (IDS) / Intrusion Prevention System (IPS), have a look at Snort.

Our internal firewall also provides traffic shaping (based on Wondershaper rules). This guarantees quality of service for our VoIP VLAN.

The utility server is also providing DHCP and DNS services to the internal LANs.

Email

We use a hosted email solution, so this isn't part of our office infrastructure per se, but there's a couple of things worth noting. We keep our corporate communication SMTP completely separate from email newsletters and automated application notifications. This helps guarantee deliverability of our corporate communications. For newsletters and automated email notifications from our application services such as password resets we use MailChimp and Postmark. For deliverability if you're configuring your own SMTP server, make sure you use and understand SPF and DKIM. Our hosted email provider includes virus scanning and removal services.

Backups

Most of our office is Mac based. At this time we're using Time Machine with a Network Attached Storage device. So far this has worked well for us. We're using a Synology DS1511+. Expandable to 45 TB, this is adequate for our immediate backup needs. Although this NAS device has the capabilities of acting as a general purpose file server, we use hosted services for our files and we don't take advantage of this feature.

We have an identically built DS1511+ at another secure location. Rsync based diff backups take place nightly between the disk stations.

VPN

Our utility server provides VPN access. We've provisioned a VPN based on OpenVPN and Viscosity.

Phone system

We've recently moved away from an appliance-based phone system to a system based on a distribute of Asterisk, the open source private branch exchange (PBX). Although the management interface of the appliance was nicer, we kept running into glitches involving touch tones (DTMF tones) with meeting services such as WebEx & Goto Meeting. The appliance was not especially expensive, coming in at around $1000, but overall we felt like it was a lesson learned that open technologies will tend to be more robust overall than proprietary devices. In terms of ongoing support cost the device cost us much more than the initial investment.

Our new phone system runs in a virtual machine on our utility server. This makes it portable to a more powerful standalone server if required, although based on current utilization we'd need to have 100+ active channels to start pushing limits. Our upstream provider gives us 20 channels (simultaneous calls) and a web interface to provision DID (incoming phone numbers) worldwide. With the ability to grow the number of channels on demand, we expect this configuration to be sufficient for the next few years.

For handsets and conference phones we use a combination of Polycom SoundPoint IP 335 phones at our desks and SoundStation 6000 conference stations in the conference rooms. We're quite happy with the quality of both of these devices, with excellent clarity of calls and a good speakerphone even on the IP 335.

Key Takeaway

When scaling up your business, especially a tech company, one of the most overlooked things is mission-critical infrastructure. Beyond 10 people, consumer-grade internet connections and hardware are going to be insufficient and significant time and effort must be put into building a base that will support your company as it scales and grows.