Posts Tagged ‘API’

Well, we’ve done it again! Last week we had a record SLales day and a monumental achievement for Team Softlayer. We sold and fully delivered 208 servers last Monday breaking our previous record of 117 in a single day. There will be no official press releases about this or anything like that other than this blog, this is normal day to day operations here at Softlayer, or as I like to call it – Monday.

We are indeed making quite a dent in the hosting industry, who else out there can claim that they can accomplish this colossal achievement? We are growing at a massive rate here and all the while keeping the same high level of service that we have worked extraordinarily hard to earn and maintain.

We’ve come a long way since the opening of our doors 2 years ago. However we still have a long way to go. We have our Washington DC datacenter coming online in May to offer better service to our East Coast and European clients and we have integrated our new API 3.0 for our clients to have even more control over there servers and our services never before seen in the industry today. 2008 is going to be an astounding year for our clients as well as Softlayer.

We’ve come a long way, and we still have a long road ahead of us but in closing, our better is better than the competitions better.

-Michael

Mike Jones and I recently attended a conference, and one of the keynote speakers was Vijay Govindarajan from the Tuck School of Business at Dartmouth. His presentation on business strategy encouraged us to 1) Manage the present, 2) Selectively forget the past, and 3) Create the future.

His main point of emphasis was to be sure that we did not focus so much on the present that we lose touch or else when the future arrives, we’re left behind. Along those lines, he mentioned that there may be some “dead horses” at present in your business. By a dead horse, he means a line of business that at present is declining. So what do you do about these dead horses? A la David Letterman, he gave us a Top 10 List that I’ll pass along to you.

10. Whip the horse a little harder
9. Change the rider
8. Harness several dead horses together for increased speed
7. Emulate the best practices of companies riding dead horses
6. Proclaim that it’s cheaper to feed a dead horse
5. Affirm that “This is the way we have always ridden this horse.”
4. Declare that “This horse is not dead.”
3. Have the lawyers bring suit against the horse manufacturer
2. Engage a consultant to study the dead horse

And number 1, Promote the dead horse to a senior management position.

At SoftLayer, we try to be all about creating the future. Whether it’s opening up our API’s or adding new features to our portal or opening new geographically diverse data centers or leveraging our geographic diversity to roll out new products and services, we have the future in mind. Yes, you’ll see some new wrinkles once our Virginia data center goes live in a few short weeks. We promise to keep any dead horses from stinking up the place.

-Gary

Recently, as you know, SoftLayer released the new API version 3. We have all been working very hard on it, and we’ve been completely immersed in it for weeks (months, for some of us). This means that, for the developers, we’ve been living and breathing API code for quite some time now. The time came to release the API, and as many of you know, it was a smashing success. However, we were lacking in examples for its use. Sure, we all had examples coming out our ears since the customer portal itself uses the API, but those were written by the same developers that developed the API itself, and therefore were still written from an insider’s perspective.

So a call went out for examples. Many people jumped on the list, offering to write examples in a variety of languages. I thought I would tackle writing an API usage example in Perl. Perl, for those of you unfamiliar, is an infamous programming language. Flexible, confusing, fantastic and horrifying, it is the very embodiment of both “quick and dirty” and “elegance.” It is well loved and well loathed in equal measure by the programming community. Nevertheless, I have some experience with Perl, and I decided to give it a try.

I will attempt to describe my thought process as I developed the small applications (which you should be able to locate shortly in the SLDN documentation wiki) throughout the work day.

9am: “Wow, I really don’t remember as much Perl as I thought. This may be difficult.”
10am: “I need to install SOAP::Lite, that shouldn’t be hard.”
11am: “Where the heck are they hiding SOAP::Lite? There are articles about it everywhere, but I can’t actually find it or get it installed!”
12pm: “Ok, got SOAP::Lite installed, and my first test application works perfectly! Things are going to be ok! Wait…what’s all this about authentication headers?”
1pm: “What have I done to deserve this? Why can’t I pass my user information through to the API?”
2pm: “Aha! Another developer just wandered by and pointed out that I’ve been misspelling ‘authentication’ for 2 hours! Back on track, baby!” (Side note: another “feature” of Perl is how it never complains when you use variables that don’t exist, it just assumes you never meant to type that. Of course, you could tell it to complain, but I forgot about that feature because I haven’t used Perl in 4 years.)
3pm: I finally get example #1 working. It queries the API and shows a list of the hardware on your account.
3:30pm: Example #2 working, this shows the details for a single server, including datacenter and operating system
4pm: Combining examples #1 and #2, the third example shows all hardware on your account, plus the installed OS and datacenter, in a handy grid right on the command line. Success! I put Perl away, hopefully for another 4 years.

The whole experience, though, really gave me an insight into how fantastically awesome the API is. I was looking at it from an outsider’s perspective. I was confused as to how everything worked, I was working with an unfamiliar language, and I was browsing through the API looking for anything that looked “cool and/or useful.” Getting a list of all my account’s hardware to show up in a custom built application that I wrote as if I knew nothing about the API was a great feeling. It showed that not only was the API perfectly suited to the tasks we expected of it, but even a novice developer could, with a little effort, make an API application like mine. Expanding on it to show more and more information, and all the possibilities that it opened up in my mind made me realize how useful this API is that we made. It’s not just something that a small percentage of our customers will be using. It’s something that is truly revolutionary, and that all clients can take advantage of. I’m assuming, of course, that all clients have at least rudimentary skill in at least one programming language, but given the level of success everyone has had with our other offerings, I can assume that assumption is accurate.

If you have been thinking recently “look at all the noise they’ve been making about this ‘API’ nonsense,” I highly recommend dusting off an old programming book and at least looking at it once. Think of all the possibilities, all the custom reports that you can make for yourself, all the data that we have provided right at your fingertips to assemble in any way you wish. We try our best to make the portal useful to every customer, but we know that you can’t please all the people all the time. But with the API, we may do just that. If you’re the kind of customer that is only interested in outbound bandwidth by domain, write an API script that displays just that! If you want to know the current number of connections and CPU temperature of your load balanced servers, get that data and show it! The possibilities are endless, and we’re improving the API all the time.

-Daniel

In most project management and system development circles, collocation refers to the centralization of resources, human and otherwise, for the purpose of creating greater efficiencies in a development cycle. In most cases, this involves pulling a developer from here, an analyst from there, and so on, for the life of the effort that they have been designated to participate in. In this day and age, with stakeholders spanning the globe, collocating for the sake of one project is not quite feasible. Now, imagine collocating for every project. Some might say, “That’s crazy!” Here at SoftLayer, we are just that… collocated that is. Sales, Finance, Development, and Support all share the same roof, breathe the same air, and drink the same coffee!

Outside of the obvious efficiencies gained from being in each other’s reach, such as information sharing and truly real-time communication, we reap other benefits that quickly cascade out to you, our customers. A major benefit that we have realized is the speed of going from suggestion or conception, to the delivery of a valued and usable solution. A good example of this resulted in one of the latest API method releases that I was recently involved in.

While working on a solution to parallel the monitoring feature of the Customer Portal, one of our forum moderators noticed a request from a customer that involved exposing the monitoring data to the API as well as including a few other bells and whistles. By the end of the day, the new API monitoring method, along with the customer’s requested additions, was approved, designed, developed, and tested! How crazy is that? Let me run that by you again, the customer made a request, the company responded… quickly. No web conferences, conference calls, misinterpreted emails or IMs, just a quick and correct response.

Another benefit of being collocated is visibility. Good ideas are never overlooked. While we like to think of ourselves as innovators that are constantly ahead of the curve, we are always looking for ways of serving our customers better. Whether you are engaged in a phone call or chat with one of our Sales Representatives, touching bases with Support, or volleying an idea through the SoftLayer Forum, your input is channeled directly to the hub where a dedicated and connected team is staged for top performance. Our disposition affords us the ability to nimbly address your position, resulting in gains that can reach crazy proportions!

-DJ

The term “Digital Super-Highway” seems to be quite prophetic as the monetization of the internet seems to be exploding from all angles. Monetization of the internet is something that we are always focusing on here since a good portion of our customer base turns our underlying infrastructure into a revenue-generating engine for them, be it through Value Added Services, enablement of SaaS business models, e-commerce activities or whatever focus our customers have (which are too many to list).

I always knew the monies on the web were staggering, but I was caught off guard the other day when I came across an article in Business 2.0, “The Man Who Owns the Internet“. The article is about Kevin Ham, who has built a $300 Million Dollar portfolio of domain names. $100,000 for Greeting.com, and $31,000 for Christianrock.com and so on. He’s a domain name mogul.

In a technology world, this seems to be the “day-trading” of the internet. The other portion of this article that struck me is the monetization of the typographical errors in domains, referred to as “Typo Squatting”. We have all accidentally fat-fingered a key here or there and after closing the 85 pop-ups, the monies are moving like a slot machine with triple 7’s across the board. In an article referring to the monetization of Typo Squatting, companies have built multi-million dollar producing firms on capitalizing on a misspelling here, a lack of dash there, etc. Just for reference, it seems that www.softlater.com is already taken, which means my dream of typo squatting my way to retirement has taken a drastic turn.

With the tools we have put in place through the API and the private network we have really streamlined the enablement of the monetization of the internet, which when we talk to our customers it’s at the forefront of both of our minds. The successes of our customers ensure our success, so putting these tools in place are essential. Not to give away the secrets of others, but I have peeked into the private back-end network and seen things like credit card processing gateways, server to server data transfers, licensing gateways and numerous other activities that are surely streamlining the money making processes for our customers.

So I am not sure that when the term “Digital Super Highway” was coined that we ever thought there would be toll-booths along the way, but its clear that these are here to stay.

As a side note, if anyone is interested in sharing their monetization stories, feel free to drop me a line at bizdev@softlayer.com

-Sean