Beyond my closet-full of black and red shirts (many of which are visible in Tech Partner Spotlight video interviews on YouTube), even when I’m out of the office I find myself “checking on customers’ servers” quite a bit … I use quotes in there because that the justification I give myself for spending time (that I’d probably spend anyway) on platforms that leverage SoftLayer’s infrastructure.

Because SoftLayer operates with an “Innovate or Die” mentality, we tend to attract customers that innovate in their own businesses. Whether that trend is intentional or not, it makes sense: Why would a fast-moving platform or application with massive growth and scaling needs be hosted with a provider taking “enterprise” time to provision a solution that ends up being “enterprise” only in name? “Enterprise Class” is not the same as “Internet Scale,” and that distinction is pretty significant when a business might have one visitor on Monday and a million visitors on Tuesday. Platforms and applications that grow like that usually operate with a high level of what I like to call “awesomeness,” so when they choose SoftLayer as a hosting provider, I feel like I need to investigate their awesomeness personally … And that’s how I’ve become a die-hard user of many of SoftLayer’s customers.

One of my favorite customers to “check on” is Tumblr. If you aren’t familiar with Tumblr, I recommend that you go to their site right now and immerse yourself in their community. I actually remember the day Tumblr signed on as a customer; I was genuinely excited that they’d be hosting on our platform. Even if that excitement was because I could justify having my Tumblr dashboard open in the background at work. I don’t think anyone could have expected the platform to grow so phenomenally in a few years, but Tumblr’s numbers are pretty staggering these days: 16.7 billion (yes, with a “B”) monthly pageviews of 55.7 million blogs with 23.1 billion posts. I wasn’t one of the first accounts on Tumblr, but I tell myself I have some kind of Tumblr cred … And I use my “limited-edition” black background and Japanese dashboard logo to prove it:

Another SoftLayer customer who’s gotten a lot of press over the past month or two is OMGPOP. OMGPOP scaled “Draw Something” to tens of millions of users on SoftLayer’s infrastructure (which you probably know), but what you probably didn’t know is that as “Draw Something” started growing in the market, it was also spreading virally in our office. You’d be amazed at how many SLayers caught the bug. Here’s one of Steve Kinman‘s works of art from a recent game:

While Tumblr and OMGPOP manage to snag a good amount of my free time, my most recent obsession has been playing NomNom Combo from Eastside Game Studios. I had a chance to meet a few of the guys from Eastside Games at GDC this year, and George Karidis told me that I should download NomNom Combo to check it out before I went to the launch party we sponsored for them in San Francisco. As it turns out, he created a monster … By the time the party rolled around, I had to tear myself away from strategizing the best way to move up the game’s all-time “Top Score” leader board. Two months later, I can say that all of my efforts have been validated:

I guess if I had to make a long story short, if you have an addictive app or game that you want to move to the SoftLayer platform, it would be brilliant move from a growth and scaling perspective. One request I’d have is that you warn me, though. I want to have time to bury my head in the sand so I don’t get hooked on more SoftLayer-powered goodness … I’m running out of “free time.”

-@khazard

Cutting out the Middleman with Nexmo

These days, optimizing mobile messaging deliverability comes at a price. Businesses must connect to multiple carriers, operate heavy infrastructure, and build their own data analytics. On top of that, many third-party SMS solutions require contracts, price negotiations and significant up-front costs.

Nexmo was created to eliminate the need for a business to connect to carriers or complex third party protocols through simple, powerful RESTful and SMPP APIs. Our scalable infrastructure allows you to send and receive SMS in high volumes to over 5 billion users around the world. This is a market need that hasn’t been addressed, and we approached it with a few ideas in mind. If you were going to replicate the functionality of Nexmo on your own, these are the key areas you’d have to look at:

Direct to Carrier Model

With every hop, the quality of a connection has the potential to degrade, and cost inflates. Adding intermediaries in the chain also impact the granularity of collected data, such as delivery reports and reasons of failure. By reducing the number of hops to the final subscriber you’ll see:

• An improved delivery ratio and lower latency
• Enhanced security
• Fewer single points of failure
• Reduced cost, less fat in the chain

With a closer position to the final carrier, a business can access more “Telco” data like phone status, whether it is ported to another network, or if it’s roaming abroad. With that information, you can also make better routing decisions and ultimately see higher delivery ratios.

Get Your own SMS-Enabled Phone Numbers

We’ve seen in the last two years the emergence of “Over the Top” (OTT) messaging apps such as Google Voice and TextPlus. Those apps provide a virtual phone number to each user, and Nexmo behaves similarly by enabling apps to behave like a “super virtual carrier” without the need for heavy Telco infrastructure. North America is the most mature market with OTT players generating significant SMS traffic, and now these models are going abroad. We pinpointed a unique need in the value chain:

• Source virtual phone numbers from global carriers
• Build the business models that protect carriers’ interests without eliminating the opportunity for innovative apps
• Provide the elastic and scalable cloud infrastructure for high volume two-way transactions

Nexmo approached those needs with APIs that enabled app developers to search for available phone numbers, provision new numbers and cancel numbers they weren’t using any more. It doesn’t take days or weeks to launch in a new market … Apps can launch in a new market in a matter of hours with minimal upfront investment!

Improve and Track Deliverability

Enterprises and developers have shifted the focus in the buying process. They are looking for more transparency and accountability, so tracking and monitoring hundreds, thousands or even millions of messages can be of utmost importance.

For every SMS sent, the Nexmo API provides a detailed report of delivery. We push this data into the cloud in real time, displayed in two ratios:

• The Success Ratio: The percentage of message received by the phone. This ratio measures how well traffic is performing.
• The DLR Ratio: The percentage of messages with a delivery receipt. This ratio tracks infrastructure and route performance.

Follow the Life of a Message from the Cloud

Most B2C services and resellers that send millions of SMS for things like alerts, phone verifications and access codes can get swarmed when it comes to user support. We know that’s an intimidating prospect for any business looking to add SMS functionality to their app or platform, so we let our customers follow the life of a message from the cloud and gather more information about it. Some of the information we’ve found most helpful to track:

• How fast was the message was delivered?
• Was the phone available for receiving SMS?
• Did the user enter the correct phone number?

Keeping an eye on these basic kinds of stats reduces the pain of supporting a large user base and enables your support staff to answer questions quickly because they have a good foundation of information.

Receive Outstanding Support

Building a customer centric culture is a sustainable competitive advantage. It is even more meaningful in a commoditized, price-driven industry like wholesale telecom. If you’re going to approach the world of SMS messaging and deliverability, the need for outstanding support is even more urgent because, given the nature of SMS messaging, results are expected immediately.

When we started Nexmo, we knew that, and I’m proud to report that we constantly score over 95% in customer satisfaction, and we’ve noticed a few tricks that have helped us maintain that level of support:

• Hire the right people: Empathy and service mindset are more important than technical skills
• Provide self-help tools and open knowledge bases: Customers appreciate finding solutions by themselves
• Measure help-desk performance and constantly improve: KPI includes first meaningful reply time, resolution time and satisfaction ratio.

We hope these tips can help you build on your existing support or give you a jumping-off point if you’re just getting started.

There is so much more I could tell you about our experience in building Nexmo into the platform it is today, but it’s a lot easier for you to just see for yourself. If you’re interested in learning more about Nexmo, visit http://nexmo.com, sign up, and be ready to go live with us in a matter of minutes … And to make it even easier, you can use the free credits we provide to give the platform a test drive.

If you’ve been intimidated by the daunting task of knocking on the doors of telcos and carriers to get easy-to-use and easy-to-track SMS functionality in your app, Nexmo can save you a lot of headaches.

-Tony Jamous, Nexmo

A recent article talks about the impact of latency on web site viewers. It sounds like common sense that the slower a site is, the more viewers you lose, but what is amazing is that even a latency measured in milliseconds can cost a web site viewers.

The article focuses mainly on application specific solutions to latency, and briefly mentions how to deliver static content like images, videos, documents, etc. There are a couple ways to solve the static content delivery problem such as making your web server as efficient as you can. But that can only help so much. Physics – the speed of light – starts to be your enemy. If you are truly worried about shaving milliseconds off your content delivery time, you have to get your content closer to your viewers.

You can do this yourself by getting servers in datacenters in multiple sites in different geographic locations. This isn’t the easiest solution for everyone but does have its advantages such as keeping you in absolute control of your content. The much easier option is to use a CDN (Content Delivery Network).

CDNs are getting more popular and the price is dropping rapidly. Akamai isn’t the only game in town anymore and you don’t have to pay dollars per GB of traffic or sign a contract with a large commit for a multi-year time frame. CDN traffic costs can be very competitive costing only a few pennies more per Gb compared with traffic costs from a shared or dedicated server. Plus, CDNs optimize their servers for delivering content quickly.

Just to throw some math into the discussion let’s see how long it would take an electron to go from New York to San Francisco (4,125,910 meters / 299,792,458 meters per second = 13.7 milliseconds). 13.7 millisconds one way, now double that for the request to go there and the response to return. Now we are up to 27.4 milliseconds. And that is assuming a straight shot with no routers slowing things down. Let’s look at Melbourne to London. (16,891,360 meters / 299,792,458 meters per second = 56.3 milliseconds). Now double that, throw in some router overhead and you can see that the delays are starting to be noticeable.

The moral of the story is that for most everybody, distributing static content geographically using a CDN is the right thing to do. That problem has been solved. The harder problem is how to get your application running as efficiently as possible. I’ll leave that topic for another time.

-@nday91

First let me say that I am not comparing Software Development to War. I do appreciate the difference between losing one’s job and losing one’s life. But as I was reading the book, the parallels between the job of a project manager preparing for, managing, and executing a large project are not unlike that of the job of a General’s planning staff preparing for a major offensive.

Operation Market-Garden was a combined ground and paratrooper attack into The Netherlands by the Allies a few months after the invasion of Normandy. Things seemed to be going well for the Allies in the months after D-Day and the Allied Generals became confident that they could launch a lightening strike that would end the war sooner rather than later. The operation seemed simple, Airborne paratroopers would be dropped deep in Nazi territory and would capture key bridges along a route into The Netherlands. A ground offensive would quickly follow using the bridges that were captured by the paratroopers to get almost all the way to Germany’s borders. The short version of the story is that the ground offensive never caught up to the paratroopers and the offensive didn’t succeed.

Reading the historical account, with the benefit of hindsight, it became obvious that the Allied Generals underestimated the difficulty of the task. The offensive scope was too big for the resources on hand and perfect execution of all the individual engagements was required. The schedule the Generals developed was impossible to keep and schedule slips meant death for many of the soldiers. Communications between elements of the units involved was critical but did not occur. However, because of heroic actions of some individuals and personal sacrifice of many, the offensive almost succeeded.

In the early stages of a project, setting realistic goals, and not putting on blinders as to the quantity and quality of your resources are key to a projects success. Going on the assumptions that the ‘development weather’ will always be perfect, communications will always work, and that all tasks will be completed on schedule is a recipe for disaster. And you can’t always plan on individual heroics to save a project.

I usually try to inject some levity into my posts, but not this one. 17,000 Allied soldiers, 13,000 German soldiers, and 10,000 civilians were killed, missing, or wounded as a result of this failed offensive.

-@nday91