Author Archive: Kevin Hazard

March 30, 2015

The Importance of Data's Physical Location in the Cloud

If top-tier cloud providers use similar network hardware in their data centers and connect to the same transit and peering bandwidth providers, how can SoftLayer claim to provide the best network performance in the cloud computing industry?

Over the years, I've heard variations of that question asked dozens of times, and it's fairly easy to answer with impressive facts and figures. All SoftLayer data centers and network points of presence (PoPs) are connected to our unique global network backbone, which carries public, private, and management traffic to and from servers. Using our network connectivity table, some back-of-the-envelope calculations reveal that we have more than 2,500Gbps of bandwidth connectivity with some of the largest transit and peering bandwidth providers in the world (and that total doesn't even include the private peering relationships we have with other providers in various regional markets). Additionally, customers may order servers with up to 10Gbps network ports in our data centers.

For the most part, those stats explain our differentiation, but part of the bigger network performance story is still missing, and to a certain extent it has been untold—until today.

The 2,500+Gbps of bandwidth connectivity we break out in the network connectivity table only accounts for the on-ramps and off-ramps of our network. Our global network backbone is actually made up of an additional 2,600+Gbps of bandwidth connectivity ... and all of that backbone connectivity transports SoftLayer-related traffic.

This robust network architecture streamlines the access to and delivery of data on SoftLayer servers. When you access a SoftLayer server, the network is designed to bring you onto our global backbone as quickly as possible at one of our network PoPs, and when you're on our global backbone, you'll experience fewer hops (and a more direct route that we control). When one of your users requests data from your SoftLayer server, that data travels across the global backbone to the nearest network PoP, where it is handed off to another provider to carry the data the "last mile."

With this controlled environment, I decided to undertake an impromptu science experiment to demonstrate how location and physical distance affect network performance in the cloud.

Speed Testing on the SoftLayer Global Network Backbone

I work in the SoftLayer office in downtown Houston, Texas. In network-speak, this location is HOU04. You won't find that location on any data center or network tables because it's just an office, but it's connected to the same global backbone as our data centers and network points of presence. From my office, the "last mile" doesn't exist; when I access a SoftLayer server, my bits and bytes only travel across the SoftLayer network, so we're effectively cutting out a number of uncontrollable variables in the process of running network speed tests.

For better or worse, I didn't tell any network engineers that I planned to run speed tests to every available data center and share the results I found, so you're seeing exactly what I saw with no tomfoolery. I just fired up my browser, headed to our Data Centers page, and made my way down the list using the SpeedTest option for each facility. Customers often go through this process when trying to determine the latency, speeds, and network path that they can expect from servers in each data center, but if we look at the results collectively, we can learn a lot more about network performance in general.

With the results, we'll discuss how network speed tests work, what the results mean, and why some might be surprising. If you're feeling scientific and want to run the tests yourself, you're more than welcome to do so.

The Ookla SpeedTests we link to from the data centers table measured the latency (ping time), jitter (variation in latency), download speeds, and upload speeds between the user's computer and the data center's test server. To run this experiment, I connected my MacBook Pro via Ethernet to a 100Mbps wired connection. At the end of each speed test, I took a screenshot of the performance stats:

SoftLayer Network Speed Test

To save you the trouble of trying to read all of the stats on each data center as they cycle through that animated GIF, I also put them into a table (click the data center name to see its results screenshot in a new window):

Data Center Latency (ms) Download Speed (Mbps) Upload Speed (Mbps) Jitter (ms)
AMS01 121 77.69 82.18 1
DAL01 9 93.16 87.43 0
DAL05 7 93.16 83.77 0
DAL06 7 93.11 83.50 0
DAL07 8 93.08 83.60 0
DAL09 11 93.05 82.54 0
FRA02 128 78.11 85.08 0
HKG02 184 50.75 78.93 2
HOU02 2 93.12 83.45 1
LON02 114 77.41 83.74 2
MEL01 186 63.40 78.73 1
MEX01 27 92.32 83.29 1
MON01 52 89.65 85.94 3
PAR01 127 82.40 83.38 0
SJC01 44 90.43 83.60 1
SEA01 50 90.33 83.23 2
SNG01 195 40.35 72.35 1
SYD01 196 61.04 75.82 4
TOK02 135 75.63 82.20 2
TOR01 40 90.37 82.90 1
WDC01 43 89.68 84.35 0

By performing these speed tests on the SoftLayer network, we can actually learn a lot about how speed tests work and how physical location affects network performance. But before we get into that, let's take note of a few interesting results from the table above:

  • The lowest latency from my office is to the HOU02 (Houston, Texas) data center. That data center is about 14.2 miles away as the crow flies.
  • The highest latency results from my office are to the SYD01 (Sydney, Australia) and SNG01 (Singapore) data centers. Those data centers are at least 8,600 and 10,000 miles away, respectively.
  • The fastest download speed observed is 93.16Mbps, and that number was seen from two data centers: DAL01 and DAL05.
  • The slowest download speed observed is 40.35Mbps from SNG01.
  • The fastest upload speed observed is 87.43Mbps to DAL01.
  • The slowest upload speed observed is 72.35Mbps to SNG01.
  • The upload speeds observed are faster than the download speeds from every data center outside of North America.

Are you surprised that we didn't see any results closer to 100Mbps? Is our server in Singapore underperforming? Are servers outside of North America more selfish to receive data and stingy to give it back?

Those are great questions, and they actually jumpstart an explanation of how the network tests work and what they're telling us.

Maximum Download Speed on 100Mbps Connection

If my office is 2 milliseconds from the test server in HOU02, why is my download speed only 93.12Mbps? To answer this question, we need to understand that to perform these tests, a connection is made using Transmission Control Protocol (TCP) to move the data, and TCP does a lot of work in the background. The download is broken into a number of tiny chunks called packets and sent from the sender to the receiver. TCP wants to ensure that each packet that is sent is received, so the receiver sends an acknowledgement back to the sender to confirm that the packet arrived. If the sender is unable to verify that a given packet was successfully delivered to the receiver, the sender will resend the packet.

This system is pretty simple, but in actuality, it's very dynamic. TCP wants to be as efficient as possible ... to send the fewest number of packets to get the entire message across. To accomplish this, TCP is able to modify the size of each packet to optimize it for each communication. The receiver dictates how large the packet should be by providing a receive window to accommodate a small packet size, and it analyzes and adjusts the receive window to get the largest packets possible without becoming unstable. Some operating systems are better than others when it comes to tweaking and optimizing TCP transfer rates, but the processes TCP takes to ensure that the packets are sent and received without error takes overhead, and that overhead limits the maximum speed we can achieve.

Understanding the SNG01 Results

Why did my SNG01 speed test max out at a meager 40.35Mbps on my 100Mbps connection? Well, now that we understand how TCP is working behind the scenes, we can see why our download speeds from Singapore are lower than we'd expect. Latency between the sending and successful receipt of a packet plays into TCP’s considerations of a stable connection. Higher ping times will cause TCP to send smaller packet sizes than it would for lower ping times to ensure that no sizable packet is lost (which would have to be reproduced and resent).

With our global backbone optimizing the network path of the packets between Houston and Singapore, the more than 10,000-mile journey, the nature of TCP, and my computer's TCP receive window adjustments all factor into the download speeds recorded from SNG01. Looking at the results in the context of the distance the data has to travel, our results are actually well within the expected performance.

Because the default behavior of TCP is partially to blame for the results, we could actually tweak the test and tune our configurations to deliver faster speeds. To confirm that improvements can be made relatively easily, we can actually just look at the answer to our third question...

Upload > Download?

Why are the upload speeds faster than the download speeds after latency jumps from 50ms to 114ms? Every location in North America is within 2,000 miles of Houston, while the closest location outside of North America is about 5,000 miles away. With what we've learned about how TCP and physical distance play into download speeds, that jump in distance explains why the download speeds drop from 90.33Mbps to 77.41Mbps as soon as we cross an ocean, but how can the upload speeds to Europe (and even APAC) stay on par with their North American counterparts? The only difference between our download path and upload path is which side is sending and which side is receiving. And if the receiver determines the size of the TCP receive window, the most likely culprit in the discrepancy between download and upload speeds is TCP windowing.

A Linux server is built and optimized to be a server, whereas my MacOSX laptop has a lot of other responsibilities, so it shouldn't come as a surprise that the default TCP receive window handling is better on the server side. With changes to the way my laptop handles TCP, download speeds would likely be improved significantly. Additionally, if we wanted to push the envelope even further, we might consider using a different transfer protocol to take advantage of the consistent, controlled network environment.

The Importance of Physical Location in Cloud Computing

These real-world test results under controlled conditions demonstrate the significance of data's geographic proximity to its user on the user's perceived network performance. We know that the network latency in a 14-mile trip will be lower than the latency in a 10,000-mile trip, but we often don't think about the ripple effect latency has on other network performance indicators. And this experiment actually controls a lot of other variables that can exacerbate the performance impact of geographic distance. The tests were run on a 100Mbps connection because that's a pretty common maximum port speed, but if we ran the same tests on a GigE line, the difference would be even more dramatic. Proof: HOU02 @ 1Gbps v. SNG01 @ 1Gbps

Let's apply our experiment to a real-world example: Half of our site's user base is in Paris and the other half is in Singapore. If we chose to host our cloud infrastructure exclusively from Paris, our users would see dramatically different results. Users in Paris would have sub-10ms latency while users in Singapore have about 300ms of latency. Obviously, operating cloud servers in both markets would be the best way to ensure peak performance in both locations, but what if you can only afford to provision your cloud infrastructure in one location? Where would you choose to provision that infrastructure to provide a consistent user experience for your audience in both markets?

Given what we've learned, we should probably choose a location with roughly the same latency to both markets. We can use the SoftLayer Looking Glass to see that San Jose, California (SJC01) would be a logical midpoint ... At this second, the latency between SJC and PAR on the SoftLayer backbone is 149ms, and the latency between SJC and SNG is 162ms, so both would experience very similar performance (all else being equal). Our users in the two markets won't experience mind-blowing speeds, but neither will experience mind-numbing speeds either.

The network performance implications of physical distance apply to all cloud providers, but because of the SoftLayer global network backbone, we're able to control many of the variables that lead to higher (or inconsistent) latency to and from a given data center. The longer a single provider can route traffic, the more efficiently that traffic will move. You might see the same latency speeds to another provider's cloud infrastructure from a given location at a given time across the public Internet, but you certainly won't see the same consistency from all locations at all times. SoftLayer has spent millions of dollars to build, maintain, and grow our global network backbone to transport public and private network traffic, and as a result, we feel pretty good about claiming to provide the best network performance in cloud computing.


October 28, 2014

SoftLayer and AWS: What's the Difference?

People often compare SoftLayer with Amazon Web Services (AWS).

It’s easy to understand why. We’ve both built scalable infrastructure platforms to provide cloud resources to the same broad range of customers—from individual entrepreneurs to the world’s largest enterprises.

But while the desire to compare is understandable, the comparison itself isn’t quite apt. The SoftLayer platform is fundamentally different from AWS.

In fact, AWS could be run on SoftLayer. SoftLayer couldn’t be run on AWS.

AWS provisions in the public cloud.

When AWS started letting customers have virtual machines deployed on the infrastructure that AWS had built for their e-commerce business, AWS accelerated the adoption of virtual server hosting within the existing world of Web hosting.

In an AWS cloud environment, customers order the computing and storage resources they need, and AWS deploys those resources on demand. The mechanics of that deployment are important to note, though.

AWS has data centers full of physical servers that are integrated with each other in a massive public cloud environment. These servers are managed and maintained by AWS, and they collectively make up the available cloud infrastructure in the facility.

AWS installs a virtualization layer (also known as hypervisor) on these physical servers to tie the individual nodes into the environment’s total capacity. When a customer orders a cloud server from AWS, this virtualization layer finds a node with the requested resources available and provisions a server image with the customer’s desired operating system, applications, etc. The entire process is quick and automated, and each customer has complete control over the resources he or she ordered.

That virtualization layer is serving a purpose, and it may seem insignificant, but it highlights a critical difference in their platform and ours:

AWS automates and provisions at the hypervisor level, while SoftLayer automates and provisions at the data center level.

SoftLayer provisions down to bare metal resources.

While many have their sights on beating AWS at its own game, SoftLayer plays a different game.

SoftLayer platform is designed to give customers complete access and control over the actual infrastructure that they need to build a solution in the cloud. Automated and remote ordering, deployment, and management of the very server, storage, and security hardware resources themselves, are hosted in our data centers so that customers don’t have to build their own facilities or purchase their own hardware to get the reliable, high performance computing they need.

Everything in SoftLayer data centers is transparent, automated, integrated, and built on an open API that customers can access directly. Every server is connected to three distinct physical networks so that public, private, and management network traffic are segmented. And our expert technical support is available for all customers, 24x7.

Notice that the automation and integration of our platform happens at the data center level. We don’t need a virtualization layer to deploy our cloud resources. As a result, we can deploy bare metal servers in the same way AWS deploys public cloud servers (though, admittedly, bare metal servers take more time to deploy than virtual servers in the public cloud). By provisioning down to a lower level in the infrastructure stack, we’re able to offer customers more choice and control in their cloud environments:

In addition to the control customers have over infrastructure resources, with our unique network architecture, their servers aren’t isolated inside the four walls of a single data center. Customers can order one server in Dallas and another in Hong Kong, and those two servers can communicate with each other directly and freely across our private network without interfering with customers’ public network traffic. So with every new data center we build, we geographically expand a unified cloud footprint. No regions. No software-defined virtual networks. No isolation.

SoftLayer vs. AWS

Parts of our cloud business certainly compete with AWS. When users compare virtual servers between us, they encounter a number of similarities. But this post isn’t about comparing and contrasting offerings in the areas in which we’re similar … it’s about explaining how we’re different:
  • SoftLayer is able to provision bare metal resources to customers. This allows customers free reign over the raw compute power of a specific server configuration. This saves the customer from the 2–3 percent performance hit from the hypervisor, and it prevents “noisy neighbors” from being provisioned alongside a customer’s virtual server. AWS does not provision bare metal resources.

  • AWS differentiates “availability zones” and “regions” for customers who want to expand their cloud infrastructure into multiple locations. SoftLayer has data centers interconnected on a global private network. Customers can select the specific SoftLayer data center location they want so they can provision servers in the exact location they desire.

  • When AWS customers move data between their AWS servers, they see “Inter-Region Data Transfer Out” and “Intra-Region Data Transfer” on their bills. If you’re moving data from one SoftLayer facility to another SoftLayer facility (anywhere in the world), that transfer is free and unmetered. And it doesn’t fight your public traffic for bandwidth.

  • SoftLayer bare metal servers ordered with monthly billing include 20TB/mo of public outbound bandwidth, and virtual servers ordered with monthly billing include 5TB/mo of public outbound bandwidth. With AWS, customers pay a per-GB charge for bandwidth on every bill.

  • SoftLayer offers a broad range of management, monitoring, and support options to customers at no additional cost. AWS charges for monitoring based on metrics, frequency, and number of alarms per resource. And having access to support requires an additional monthly cost.

Do SoftLayer and AWS both offer Infrastructure as a Service? Yes.

Does that make SoftLayer and AWS the same? No.


June 30, 2014

OpenNebula 4.8: SoftLayer Integration

In the next month, the team of talented developers at C12G Labs will be rolling out OpenNebula 4.8, and in that release, they will be adding integration with SoftLayer! If you aren't familiar with OpenNebula, it's a full-featured open-source platform designed to bring simplicity to managing private and hybrid cloud environments. Using a combination of existing virtualization technologies with advanced features for multi-tenancy, automatic provisioning, and elasticity, OpenNebula is driven to meet the real needs of sysadmins and devops.

In OpenNebula 4.8, users can quickly and seamlessly provision and manage SoftLayer cloud infrastructure through OpenNebula's simple, flexible interface. From a single pane of glass, you can create virtual data center environments, configure and adjust cloud resources, and automatic execution and scaling of multi-tiered applications. If you don't want to leave the command line, you can access the same functionality from a powerful CLI tool or through the OpenNebula API.

When the C12G Labs team approached us with the opportunity to be featured in the next release of their platform, several folks from the office were happy to contribute their time to make the integration as seamless as possible. Some of our largest customers have already begun using OpenNebula to manage their hybrid cloud environments, so official support for the SoftLayer cloud in OpenNebula is a huge benefit to them (and to us). The result of this collaboration will be released under the Apache license, and as such, it will be freely available to the public.

To give you an idea of how easy OpenNebula is to use, they created an animated GIF to show the process of creating and powering down virtual machines, creating a server image, and managing account settings:


We'd like to give a big shout-out to the C12G Labs team for all of the great work they've done on the newest version of OpenNebula, and we look forward to seeing how the platform continues to grow and improve in the future.


February 20, 2014

SoftLayer at IBM Pulse 2014

When you plan your IBM Pulse schedule, you'll want to know where to find SoftLayer in the sea of people, sessions and events in Las Vegas next week. I consolidated some of the SoftLayer-specific highlights into this blog post, but by the time I got to the end of the post, it seemed like a daunting amount of content. To give the blog audience a "tl;dr" ("too long; didn't read") alternative, I convinced a few of my coworkers into sharing a quick overview of our activities via video:

Armed with the information from the video, scan down the rest of this post for details about the specific sessions or events that piqued your interest.

SoftLayer-Led IBM Pulse Sessions

Six different SLayers are presenting IBM Pulse 2014 sessions — five technical overviews, one panel, and one general session. Click on any of the topics below to read the session abstracts and learn more about the presenter with the IBM Pulse agenda preview tool.

IAS-2137A: Compute-as-a-Service: More than a Virtual Affair?
Steven Canale, VP of Global Sales
Monday, February 24 @ 11:15am — Room 119
IAS-2145A: Comparing Cloud Computing Models for Performance and Workload Suitability
Marc Jones, VP of Product Innovation
Monday, February 24 @ 1:00pm — Room 101
IAS-2117A: Cloud Performance is Not a Commodity
Nathan Day, Chief Scientist
Monday, February 24 @ 3:45pm — Room 119
IAS-1943A: Elastic OpenStack Private Clouds on SoftLayer
Marc Jones, VP of Product Innovation (+ Panel)
Tuesday, February 25 @ 11:15am — Room 124
IAS-2158A: High-Performance, Scalable Big Data Solutions in a Bare Metal Cloud
Harold Hannon, Sr. Software Architect
Tuesday, February 25 @ 2:15pm — Room 119
IAS-2167A: Infrastructure at Scale: Best Practices in Scaling Cloud Architectures
Phil Jackson, Developer Advocate Lead
Tuesday, February 25 @ 3:45pm — Room 119
GEN-2539A: General Session Day 3: Inspiring Bold Moves
Lance Crosby, CEO
Wednesday, February 26 @ 9:00am — Grand Garden Arena

Solution EXPO

In addition to those presentations, we'll be making a lot of noise in the Solution EXPO. Visit the IAAS Zone in the Cloud Demo Area to find us at Demo Pad 432-08. Here, you'll get a first-hand look at the ordering, configuration and management tools we use for our bare metal and virtual server cloud resources. Click around in our customer portal, try out our ordering process, and learn more about the automation that drives our cloud platform.

After you learn about SoftLayer in the Demo area, make your way to the Cloud Category Area to compete in the legendary Server Challenge II competition at #332. Your goal will be to repopulate the drives and network cables into a scaled-down version of a SoftLayer server rack, and if you record the best time at the event, you'll walk away with the pride of being the IBM Pulse 2014 Server Challenge champion... and a MacBook Air. To train for your two attempts per day, you might want to watch the current world record: SoftLayer + Supermicro Server Challenge II - World Record.


Happening in parallel with IBM Pulse, Dev@Pulse is a FREE developer-focused event where attendees have access to hands-on labs, lightning talks and a playground of technical toys like the Oculus Rift and Parrot AR Drones. Additionally, IBM subject matter experts will be on-site to answer questions and help developers solve any of the code-related problems they've run into. And yes, as Phil Jackson so humbly explained in the video, he'll be presenting one of those lightning talks.

Pulse Palooza

To relax and unwind a bit after the heavy-hitting sessions on Monday and Tuesday, IBM Pulse is rolling out the red carpet for attendees to party in the MGM Grand Garden Arena from 7:00-10:00pm with live performances by Elvis Costello and Fall Out Boy!

Pulse Palooza

This event is included with all Pulse passes, and as Ryan said in the video, it's guaranteed to be a good time.

I can't even begin to describe the excitement our team has about IBM Pulse 2014, and we hope you feel the same way. Next week will be a great opportunity for you to learn more about SoftLayer, AND it'll give us a chance to learn more about your business and how we help you improve it in the cloud.


January 29, 2014

Get Your Pulse Racing

What will the future bring for SoftLayer and IBM? Over the past six months, you've probably asked that question more than a few times, and the answer you got may have been incomplete. You know that IBM is supercharging SoftLayer expansion and that our platform will be the foundation for IBM's most popular enterprise cloud products and services, but you've really only seen a glimpse of the big picture. At IBM Pulse, you'll get a much better view.

SoftLayer is no stranger to conferences and events. Last year alone, we were involved in around 70 different trade shows, and that number doesn't include the dozens of meetups, events, and parties we participated in without an official booth presence. It's pretty safe to say that Pulse is more important to us than any of the shows we've attended in the past. Why? Because Pulse is the first major conference where SoftLayer will be in the spotlight.

As a major component in IBM's cloud strategy, it's safe to assume that every attendee at IBM's "Premier Cloud Conference" will hear all about SoftLayer's platform and capabilities. We'll have the Server Challenge on the expo hall floor, we're going to play a huge part in connecting with developers at dev@Pulse, a number of SLayers are slated to lead technical sessions, and Wednesday's general session will be presented by our CEO, Lance Crosby.

If you're interested in what's next for IBM in the cloud, join us at Pulse 2014. SoftLayer customers are eligible for a significant discount on registration for the full conference, so if you need details on how to sign up, leave a comment on this blog or contact a SoftLayer sales rep, and we'll make sure you get all the information you need. To make it easier for first-time attendees to experience Pulse, IBM offers a special Pulse Peek pass that will get you into the general sessions and expo hall for free!

If you're a developer, we need to see you at dev@Pulse. Happening in parallel with the main Pulse show, dev@Pulse is focused on helping attendees design, develop, and deploy the next generation of cloud-based systems and applications. In addition to the lightning talks, hands-on labs, free certification testing, and code jam competition, you'll get to try out the Oculus Rift, meet a ton of brilliant people, and party with Elvis Costello and Fall Out Boy. The cost? A whopping $0.

Whether you're chairman of the board or a front-line application developer, you'll get a lot out of IBM Pulse. What happens in Vegas ... could change the way you do business. (Note: The parties, however, will stay in Vegas.)


January 15, 2014

Keep Spending Most Our Lives Livin' in a Gamer's Paradise

With apologies to Coolio, I couldn't resist adapting a line from the chorus of "Gangsta's Paradise" to be the title of this blog post. While I could come up with a full, cringe-worthy cloud computing version of the song (and perform it), I'll save myself the embarrassment and instead focus on why "Gamer's Paradise" came to mind in the first place. We announced some amazing stats about two gaming customers that use SoftLayer's cloud infrastructure to power popular online games, and I thought I'd share an interesting observation about that news.

More than 130 million gamers rely on SoftLayer infrastructure. SoftLayer is virtually invisible to those gamers. And that's why gaming companies love us.

When would a gamer care where a game is hosted? Simple: When gameplay is unavailable, lagging, or otherwise underperforming. Because we deliver peak cloud performance consistently for our gaming customers, we'll continue to live in the shadows of gamers' collective consciousness (while taking center stage in the minds of game producers and developers).

It's easy to get caught up in discussing the technical merits of our cloud hosting platform. Speeds and feeds provide great metrics for explaining our infrastructure, but every now and then, it's worthwhile to step back and look at the forest for the trees. Instead of talking about how bare metal resources consistently outperform their virtual server equivalents, let's take a look at why our gaming customers need as much server horsepower as we can provide:

As you can see, the games we're hosting for our customers are a little more resource-intensive than Tic-tac-toe and Pong. By leveraging SoftLayer bare metal infrastructure, gaming companies such as KUULUU and Multiplay can seamlessly support high definition gameplay in massive online environments for gamers around the world. When KUULUU launched their wildly popular LP Recharge Facebook game, they trusted our platform all the way from beta testing through launch, daily play, and updates. When Multiplay needed to support 25,000 new users in Battlefield 4, they spun up dedicated SoftLayer resources in less than four hours. If gamers expect a flawless user experience, you can imagine how attentive to infrastructure needs gaming companies are.

As more and more users sign on to play games online with Multiplay, KUULUU, and other gaming customers on our platform, we'll celebrate crossing even bigger (and more astounding) milestones like the 130 million mark we're sharing today. In the meantime, I'm going to go "check on our customers' servers" with a few hours of gameplay ... You know, for the good of our customers.


More Info: Multiplay and KUULUU Launch Games with SoftLayer, an IBM Company - Gaming companies flock to SoftLayer’s cloud, adding to 130 million players worldwide

September 30, 2013

The Economics of Cloud Computing: If It Seems Too Good to Be True, It Probably Is

One of the hosts of a popular Sirius XM radio talk show was recently in the market to lease a car, and a few weeks ago, he shared an interesting story. In his research, he came across an offer he came across that seemed "too good to be true": Lease a new Nissan Sentra with no money due at signing on a 24-month lease for $59 per month. The car would as "base" as a base model could be, but a reliable car that can be driven safely from Point A to Point B doesn't need fancy "upgrades" like power windows or an automatic transmission. Is it possible to lease new car for zero down and $59 per month? What's the catch?

After sifting through all of the paperwork, the host admitted the offer was technically legitimate: He could lease a new Nissan Sentra for $0 down and $59 per month for two years. Unfortunately, he also found that "lease" is just about the extent of what he could do with it for $59 per month. The fine print revealed that the yearly mileage allowance was 0 (zero) — he'd pay a significant per-mile rate for every mile he drove the car.

Let's say the mileage on the Sentra was charged at $0.15 per mile and that the car would be driven a very-conservative 5,000 miles per year. At the end of the two-year lease, the 10,000 miles on the car would amount to a $1,500 mileage charge. Breaking that cost out across the 24 months of the lease, the effective monthly payment would be around $121, twice the $59/mo advertised lease price. Even for a car that would be used sparingly, the numbers didn't add up, so the host wound up leasing a nicer car (that included a non-zero mileage allowance) for the same monthly cost.

The "zero-down, $59/mo" Sentra lease would be a fantastic deal for a person who wants the peace of mind of having a car available for emergency situations only, but for drivers who put the national average of 15,000 miles per year, the economic benefit of such a low lease rate is completely nullified by the mileage cost. If you were in the market to lease a new car, would you choose that Sentra deal?

At this point, you might be wondering why this story found its way onto the SoftLayer Blog, and if that's the case, you don't see the connection: Most cloud computing providers sell cloud servers like that car lease.

The "on demand" and "pay for what you use" aspects of cloud computing make it easy for providers to offer cloud servers exclusively as short-term utilities: "Use this cloud server for a couple of days (or hours) and return it to us. We'll just charge you for what you use." From a buyer's perspective, this approach is easy to justify because it limits the possibility of excess capacity — paying for something you're not using. While that structure is effective (and inexpensive) for customers who sporadically spin up virtual server instances and turn them down quickly, for the average customer looking to host a website or application that won't be turned off in a given month, it's a different story.

Instead of discussing the costs in theoretical terms, let's look at a real world example: One of our competitors offers an entry-level Linux cloud server for just over $15 per month (based on a 730-hour month). When you compare that offer to SoftLayer's least expensive monthly virtual server instance (@ $50/mo), you might think, "OMG! SoftLayer is more than three times as expensive!"

But then you remember that you actually want to use your server.

You see, like the "zero down, $59/mo" car lease that doesn't include any mileage, the $15/mo cloud server doesn't include any bandwidth. As soon as you "drive your server off the lot" and start using it, that "fantastic" rate starts becoming less and less fantastic. In this case, outbound bandwidth for this competitor's cloud server starts at $0.12/GB and is applied to the server's first outbound gigabyte (and every subsequent gigabyte in that month). If your server sends 300GB of data outbound every month, you pay $36 in bandwidth charges (for a combined monthly total of $51). If your server uses 1TB of outbound bandwidth in a given month, you end up paying $135 for that "$15/mo" server.

Cloud servers at SoftLayer are designed to be "driven." Every monthly virtual server instance from SoftLayer includes 1TB of outbound bandwidth at no additional cost, so if your cloud server sends 1TB of outbound bandwidth, your total charge for the month is $50. The "$15/mo v. $50/mo" comparison becomes "$135/mo v. $50/mo" when we realize that these cloud servers don't just sit in the garage. This illustration shows how the costs compare between the two offerings with monthly bandwidth usage up to 1.3TB*:

Cloud Cost v Bandwidth

*The graphic extends to 1.3TB to show how SoftLayer's $0.10/GB charge for bandwidth over the initial 1TB allotment compares with the competitor's $0.12/GB charge.

Most cloud hosting providers sell these "zero down, $59/mo car leases" and encourage you to window-shop for the lowest monthly price based on number of cores, RAM and disk space. You find the lowest price and mentally justify the cost-per-GB bandwidth charge you receive at the end of the month because you know that you're getting value from the traffic that used that bandwidth. But you'd be better off getting a more powerful server that includes a bandwidth allotment.

As a buyer, it's important that you make your buying decisions based on your specific use case. Are you going to spin up and spin down instances throughout the month or are you looking for a cloud server that is going to stay online the entire month? From there, you should estimate your bandwidth usage to get an idea of the actual monthly cost you can expect for a given cloud server. If you don't expect to use 300GB of outbound bandwidth in a given month, your usage might be best suited for that competitor's offering. But then again, it's probably worth mentioning that that SoftLayer's base virtual server instance has twice the RAM, more disk space and higher-throughput network connections than the competitor's offering we compared against. Oh yeah, and all those other cloud differentiators.


August 22, 2013

Network Cabling Controversy: Zip Ties v. Hook & Loop Ties

More than 210,000 users have watched a YouTube video of our data center operations team cabling a row of server racks in San Jose. More than 95 percent of the ratings left on the video are positive, and more than 160 comments have been posted in response. To some, those numbers probably seem unbelievable, but to anyone who has ever cabled a data center rack or dealt with a poorly cabled data center rack, the time-lapse video is enthralling, and it seems to have catalyzed a healthy debate: At least a dozen comments on the video question/criticize how we organize and secure the cables on each of our server racks. It's high time we addressed this "zip ties v. hook & loop (Velcro®)" cable bundling controversy.

The most widely recognized standards for network cabling have been published by the Telecommunications Industry Association and Electronics Industries Alliance (TIA/EIA). Unfortunately, those standards don't specify the physical method to secure cables, but it's generally understood that if you tie cables too tight, the cable's geometry will be affected, possibly deforming the copper, modifying the twisted pairs or otherwise physically causing performance degradation. This understanding begs the question of whether zip ties are inherently inferior to hook & loop ties for network cabling applications.

As you might have observed in the "Cabling a Data Center Rack" video, SoftLayer uses nylon zip ties when we bundle and secure the network cables on our data center server racks. The decision to use zip ties rather than hook & loop ties was made during SoftLayer's infancy. Our team had a vision for an automated data center that wouldn't require much server/cable movement after a rack is installed, and zip ties were much stronger and more "permanent" than hook & loop ties. Zip ties allow us to tighten our cable bundles easily so those bundles are more structurally solid (and prettier). In short, zip ties were better for SoftLayer data centers than hook & loop ties.

That conclusion is contrary to the prevailing opinion in the world of networking that zip ties are evil and that hook & loop ties are among only a few acceptable materials for "good" network cabling. We hear audible gasps from some network engineers when they see those little strips of nylon bundling our Ethernet cables. We know exactly what they're thinking: Zip ties negatively impact network performance because they're easily over-tightened, and cables in zip-tied bundles are more difficult to replace. After they pick their jaws up off the floor, we debunk those myths.

The first myth (that zip ties can negatively impact network performance) is entirely valid, but its significance is much greater in theory than it is in practice. While I couldn't track down any scientific experiments that demonstrate the maximum tension a cable tie can exert on a bundle of cables before the traffic through those cables is affected, I have a good amount of empirical evidence to fall back on from SoftLayer data centers. Since 2006, SoftLayer has installed more than 400,000 patch cables in data centers around the world (using zip ties), and we've *never* encountered a fault in a network cable that was the result of a zip tie being over-tightened ... And we're not shy about tightening those ties.

The fact that nylon zip ties are cheaper than most (all?) of the other more "acceptable" options is a fringe benefit. By securing our cable bundles tightly, we keep our server racks clean and uniform:

SoftLayer Cabling

The second myth (that cables in zip-tied bundles are more difficult to replace) is also somewhat flawed when it comes to SoftLayer's use case. Every rack is pre-wired to deliver five Ethernet cables — two public, two private and one out-of-band management — to each "rack U," which provides enough connections to support a full rack of 1U servers. If larger servers are installed in a rack, we won't need all of the network cables wired to the rack, but if those servers are ever replaced with smaller servers, we don't have to re-run network cabling. Network cables aren't exposed to the tension, pressure or environmental changes of being moved around (even when servers are moved), so external forces don't cause much wear. The most common physical "failures" of network cables are typically associated with RJ45 jack crimp issues, and those RJ45 ends are easily replaced.

Let's say a cable does need to be replaced, though. Servers in SoftLayer data centers have redundant public and private network connections, but in this theoretical example, we'll assume network traffic can only travel over one network connection and a data center technician has to physically replace the cable connecting the server to the network switch. With all of those zip ties around those cable bundles, how long do you think it would take to bring that connection back online? (Hint: That's kind of a trick question.) See for yourself:

The answer in practice is "less than one minute" ... The "trick" in that trick question is that the zip ties around the cable bundles are irrelevant when it comes to physically replacing a network connection. Data center technicians use temporary cables to make a direct server-to-switch connection, and they schedule an appropriate time to perform a permanent replacement (which actually involves removing and replacing zip ties). In the video above, we show a temporary cable being installed in about 45 seconds, and we also demonstrate the process of creating, installing and bundling a permanent network cable replacement. Even with all of those villainous zip ties, everything is done in less than 18 minutes.

Many of the comments on YouTube bemoan the idea of having to replace a single cable in one of these zip-tied bundles, but as you can see, the process isn't very laborious, and it doesn't vary significantly from the amount of time it would take to perform the same maintenance with a Velcro®-secured cable bundle.

Zip ties are inferior to hook & loop ties for network cabling? Myth(s): Busted.


P.S. Shout-out to Elijah Fleites at DAL05 for expertly replacing the network cable on an internal server for the purposes of this video!

July 24, 2013

Deconstructing SoftLayer's Three-Tiered Network

When Sun Microsystems VP John Gage coined the phrase, "The network is the computer," the idea was more wishful thinking than it was profound. At the time, personal computers were just starting to show up in homes around the country, and most users were getting used to the notion that "The computer is the computer." In the '80s, the only people talking about networks were the ones selling network-related gear, and the idea of "the network" was a little nebulous and vaguely understood. Fast-forward a few decades, and Gage's assertion has proven to be prophetic ... and it happens to explain one of SoftLayer's biggest differentiators.

SoftLayer's hosting platform features an innovative, three-tier network architecture: Every server in a SoftLayer data center is physically connected to public, private and out-of-band management networks. This "network within a network" topology provides customers the ability to build out and manage their own global infrastructure without overly complex configurations or significant costs, but the benefits of this setup are often overlooked. To best understand why this network architecture is such a game-changer, let's examine each of the network layers individually.

SoftLayer Private Network

Public Network

When someone visits your website, they are accessing content from your server over the public network. This network connection is standard issue from every hosting provider since your content needs to be accessed by your users. When SoftLayer was founded in 2005, we were the first hosting provider to provide multiple network connections by default. At the time, some of our competitors offered one-off private network connections between servers in a rack or a single data center phase, but those competitors built their legacy infrastructures with an all-purpose public network connection. SoftLayer offers public network connection speeds up to 10Gbps, and every bare metal server you order from us includes free inbound bandwidth and 5TB of outbound bandwidth on the public network.

Private Network

When you want to move data from one server to another in any of SoftLayer's data centers, you can do so quickly and easily over the private network. Bandwidth between servers on the private network is unmetered and free, so you don't incur any costs when you transfer files from one server to another. Having a dedicated private network allows you to move content between servers and facilities without fighting against or getting in the way of the users accessing your server over the public network.

It should come as no surprise to learn that all private network traffic stays on SoftLayer's network exclusively when it travels between our facilities. The blue lines in this image show how the private network connects all of our data centers and points of presence:

SoftLayer Private Network

To fully replicate the functionality provided by the SoftLayer private network, competitors with legacy single-network architecture would have to essentially double their networking gear installation and establish safeguards to guarantee that customers can only access information from their own servers via the private network. Because that process is pretty daunting (and expensive), many of our competitors have opted for "virtual" segmentation that logically links servers to each other. The traffic between servers in those "virtual" private networks still travels over the public network, so they usually charge you for "private network" bandwidth at the public bandwidth rate.

Out-of-Band Management Network

When it comes to managing your server, you want an unencumbered network connection that will give you direct, secure access when you need it. Splitting out the public and private networks into distinct physical layers provides significant flexibility when it comes to delivering content where it needs to go, but we saw a need for one more unique network layer. If your server is targeted for a denial of service attack or a particular ISP fails to route traffic to your server correctly, you're effectively locked out of your server if you don't have another way to access it. Our management-specific network layer uses bandwidth providers that aren't included in our public/private bandwidth mix, so you're taking a different route to your server, and you're accessing the server through a dedicated port.

If you've seen pictures or video from a SoftLayer data center (or if you've competed in the Server Challenge), you probably noticed the three different colors of Ethernet cables connected at the back of every server rack, and each of those colors carries one of these types of network traffic exclusively. The pink/red cables carry public network traffic, the blue cables carry private network traffic, and the green cables carry out-of-band management network traffic. All thirteen of our data centers have the same colored cables in the same configuration doing the same jobs, so we're able to train our operations staff consistently between all thirteen of our data centers. That consistency enables us to provide quicker service when you need it, and it lessens the chance of human error on the data center floor.

The most powerful server on the market can be sidelined by a poorly designed, inefficient network. If "the network is the computer," the network should be a primary concern when you select your next hosting provider.


March 8, 2013

Server Challenge II: Strata Conference 2013

If you want to find the Server Challenge II on an exhibit hall floor, just look for a crowd in one of the aisles and listen for cheers. When SoftLayer partnered with Supermicro to build a retro upgrade for our original Server Challenge, we knew the results would be phenomenal, and we haven't been disappointed. Other booths are chatting with one or two attendees while we've got the attention of 20+ as we explain what the Server Challenge II is all about and how it relates to what we do.

Strata Conference

About a dozen Strata Conference attendees asked where the Server Challenge II would show up next, and upon hearing that we'd have it at SXSW next week, one (semi-jokingly) begged us to let him rent the unit so he could practice beforehand. It almost seems like the competition is getting a cult following. And we love it.

Beyond the simple fact that the Server Challenge II affords us to talk about SoftLayer's differentiators as a cloud infrastructure provider, the competition actually brings flocks of attendees to our booth at the *end* of a show when other booths are already starting to packing up to go home. At Strata, the top four times were set in the last two hours of the show, and the very last attempt (which started right when the lights were flashing to signal the end of the show) was less than five seconds for taking the top spot.

In the end, Jonathan Heyne Galli bested the competition to take home bragging rights and a MacBook Air with a speedy time of 1:04.45. To showcase the winning attempt in a unique way, I grabbed my phone and fired up Vine:

If you have twelve more seconds to watch two other attempts, the Second Place and Third Place attempts were also captured with Vine.

In the midst of all of this competition, I've been blown away at the sportsmanship between competitors. I know how cheesy that sounds given the fact that we're talking about a game with a server rack in an expo hall, but it's true. Carson, the third place finisher, actually beat Jonathan's 1:04.45 toward the end of the show, but one of the drive tray arms wasn't clipped closed when he stopped the timer. We explained that we couldn't give him the top spot but that we could wipe that score and give him one more chance to replicate the result (with no errors), and he was quick to agree. He wouldn't want someone else to win with an "incomplete" build if he were in first place, so he didn't want to win that way.

Here was the final leader board from Strata 2013:

Strata Leader Board

Given the floods of traffic to our booth wherever the Server Challenge II turns up, it's only a matter of time until someone makes a documentary on the Server Challenge like The King of Kong: A Fistful of Quarters. I can see it now ... The Server Sultan: Get in Line to Bring Servers Online.


Subscribe to Author Archive: %