Posts Tagged ‘applications’

Chris Gardner (of The Pursuit of Happyness fame) said, “Find something that you love. Something that gets you so excited you can’t wait to get out of bed in the morning. Forget about money. Be happy.” Now I can’t honestly tell you I’m able to “forget about money” or that I’m much of a morning person, but I’m quick to tell people that I love what I do. If you click through a few of the “Culture” posts on this blog, you’ll read that I’m not alone. This week, I realized how many non-work interests SoftLayer plays a role in.

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

This guest blog comes to us from Nexmo, a featured member of the SoftLayer Technology Partners Marketplace. Nexmo is the wholesale messaging API that lets you send and receive high volumes of SMS at a global level. In this video we talk to Nexmo CEO Tony Jamous about the benefits of Nexmo, how it came to be and the problem it solves for you.

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!

Read the rest of Nexmo’s blog about adding SMS functionality to your app…

One of my favorite sites is highscalability.com. As someone with an engineering background, reading about the ways other people solve a variety of problems is really quite interesting.

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

I just finished the best Software Project Management book I have ever read. It covered proper planning, requirements gathering, resource management, inter-organizational communication, and even discussed the immeasurable factor of individual effort. The book’s title is ‘A Bridge too Far’ by Cornelius Ryan. The book is actually a historical account of “Operation Market-Garden” which was an attack by the Allied forces against Nazi Germany in World War II.

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