Posts Tagged ‘SLDN’

When I present about the SoftLayer API at conferences and meetups, I often use an image that shows how many of the different services in the API are interrelated and connected. As I started building the visual piece of my presentation, I noticed a curious “coincidence” about the layout of the visualization:

What does that look like to you?

You might need to squint your eyes and tilt your head or “look beyond the image” like it’s one of those “Magic Eye” pictures, but if you’re a geek like me, you can’t help but notice a striking resemblance to one of the most iconic images from Star Wars:

The SoftLayer API looks like the Death Star.

The similarity is undeniable … The question is whether that resemblance is coincidental or whether it tells us we can extrapolate some kind of fuller meaning as in light of the visible similarities. I can hear KHazzy now … “Phil, While that’s worth a chuckle and all, there is no way you can actually draw a relevant parallel between the SoftLayer API and The Death Star.” While Alderaan may be far too remote for an effective demonstration, this task is no match for the power of the Phil-side.

Challenge Accepted.

The Death Star: A large space station constructed by the Galactic Empire equipped with a super-laser capable of destroying an entire planet.

The SoftLayer API: A robust set of services and methods which provide programmatic access to all portions of the SoftLayer Platform capable of automating any task: administrative, configuration or otherwise.

Each is the incredible result of innovation and design. The construction of the Death Star and creation of the SoftLayer API took years of hard work and a significant investment. Both are massive in scale, and they’re both effective and ruthless when completing their objectives.

The most important distinction: The Death Star was made to destroy while the SoftLayer API was made to create … The Death Star was designed to subjugate a resistance force and destroy anything in the empire’s way. The SoftLayer API was designed to help customers create a unified, automated way of managing infrastructure; though in the process, admittedly that “creation” often involves subjugating redundant, compulsory tasks.

The Death Star and the SoftLayer API can both seem pretty daunting. It can be hard to find exactly what you need to solve all of your problems … Whether that be an exhaust port or your first API call. Fear not, for I will be with you during your journey, and unlike Obi-Wan Kenobi, I’m not your only hope. There is no need for rebel spies to acquire the schematics for the API … We publish them openly at sldn.softlayer.com, and we encourage our customers to break the API down into the pieces of functionality they need.

-Phil (@SoftLayerDevs)

Simple Object Access Protocol (SOAP) is built on server-to-server remote procedure calls over HTTP. The data is formatted as XML; this means secure, well formatted data will be sent and received from SoftLayer’s API. This may take a little more time to set up than the REST API but it can be more scalable as you programmatically interface with it. SOAP’s ability to tunnel through existing protocols such as HTTP and innate ability to work in an object-oriented structure make it an excellent choice for interaction with the SoftLayer API.

This post gets pretty technical and detailed, so it might not appeal to our entire audience. If you’ve always wondered how to get started with SOAP API development, this post might be a good jumping-off point.

Read the full SOAP API Application Development post! »

SoftLayer is in a constant state of change … It’s not that bad change we all fear; it’s the type of change that allows you to stretch the boundaries of your normal experience and run like a penguin … Because I got some strange looks when coworkers read “run like a penguin,” I should explain that I recently visited Moody Gardens in Galveston and saw penguins get crazy excited when they were about to get fed, so that’s the best visual I could come up with. Since I enjoy a challenge (and enjoy running around like a penguin), when I was asked to design the new version of SLDN, I was excited.

The goal was simple: Take our already amazing documentation software infrastructure and make it better. A large part of this was to collapse our multi-site approach down into a single unified user experience. Somewhere along the way, “When is the proposal going to be ready?” became “When is the site going to be ready?”, at this point I realized that all of the hurdles I had been trampling over in my cerebral site building were now still there, standing, waiting for me on my second lap.

I recently had the honor to present our ideas, philosophy and share some insight into the technical details of the site at OSCON 2011, and KHazzy had the forethought to record it for all of you!

It’s a difficult balance to provide details and not bore the audience with tech specs, so I tried to keep the presentation relatively light to encourage attendees (and now viewers) to ask questions about areas they want a little more information about. If you’re looking at a similar project in the future, feel free to bounce ideas off me, and I’ll steer you clear of a few land mines I happened upon.

-Phil

Our API has gone through more than a few changes since the middle of 2006 when it was first released in beta to a few of our customers. Since then, it has grown from a handful of available features to your one stop shop for infrastructure automation needs. Providing all the functionality our customer portal has, plus putting automation in your/the customers’ hands that was only dreamed of a few short years ago. We have a few NEW note worthy features we just released concerning the API that numerous people have asked for. So here goes:

1. Opened the API up to the public network

We now have two ways to access the SoftLayer API. The first is the same method you have been using utilizing our private network. Some developers have asked for a way to bypass the VPN and private network. So we have added a publicly accessible entry point for the API in addition to the private network. This should open up your development to new exciting desktop widgets and consumption of our API for external software projects without requiring the VPN overhead. More information is available in the SLDN wiki.

2. RESTful web services

We added a simple Representational State Transfer (REST) interface to the arsenal of already supported SOAP and XML-RPC protocols. REST is great if you want to perform simple requests that do not require the complexity of SOAP and for simple integration into AJAX related operations on web pages.

3. New documentation

We have just revised our documentation located in the SLDN wiki. We added more examples, updated connection information for public access and usage for our new REST protocol support. We have also been busy working on our growing collection of open source projects.

4. New Code Samples

As you may or may not have heard Softlayer has a github account now. We are uploading projects and examples as fast as we can. You might want to check out Stratos a white label portal example, Client libraries for Python, Perl and PHP, as well as our growing gist examples which outline common tasks requested by customers.

We would love to hear any feature requests you are looking for, so let us hear from you.

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

With the NFL season in full swing and the usual suspects up to their usual tricks, a question was raised as to why some teams opt to run a “no-huddle” or “hurry-up” offense when their backs are against the wall with the clock ticking away, while other teams seem to constantly be in a “hurry-up” mode throughout the game and have a significant degree of success with it. In either case, the objective is to keep the competition off balance and have steady advances to the goal. An obvious example of an undeniably successful team that employs such methods is the reigning NFL Champion Indianapolis Colts.

Before I go further into lumping praise onto the Colts, I feel that I am obligated to state that I am not a die-hard Indy fan. The team that I root for shall remain nameless for this article as I am still traumatized by the hammer that they leveled on my team of choice on the NFL’s opening night (Hint: Rhymes with “The Aints.”).

Okay, so this observation invites the question: how did the Colts become champions by performing in a manner that, to outsiders, may appear to be rushed and distressed? One could say it’s because they have trusted, senior individuals in their skill positions implementing the plan. Another might say that by focusing on rapid incremental results, they are able to execute more efficiently. An additional point might be that the constant communication amongst the players allows them to adapt to the circumstances that are constantly changing so that they may deliver and reach their goals.

To those of you not caught up in the imagery of football, you might recognize that these are some of the same traits that characterize successful adaptations of Agile Software Development. With the goal of delivering continuous and valued improvements to our applications and supporting software, the Softlayer Development team practices many of the Principles behind the Agile Manifesto. While “moving the chains” toward the end-zone alludes to the incremental success of an NFL team’s offense, we speak more in terms of functional and valued releases towards achieving greater customer satisfaction. This is afforded to us by the skilled players on our team, constant communication, and a continued focus on producing measurable results. We are determined to keep “moving the chains” so, stay tuned to the Developer Network, Forums, and all channels Softlayer as we continue to push towards our goal.

-DJ

Microsoft, the Next Softlayer…

I’m only kidding, but with the recent announcement for Microsoft’s Surface, total integration across product platforms has serious backing from within Microsoft, as evidenced by Bill Gates’ support. The idea behind “surface computing” is to capture all tangible applications that are data-driven and integrate them into a portal that allows cross-sharing no matter what the product is (a phone, a camera, a personal computer or whatever). The commonality of this all lies within centralization. As one analyst writes in a recent Business Week article:

“It will be at least a few years before a consumer will be able to buy a Surface Computer and bring it home. To get there, Microsoft will need to create an ecosystem where software developers are motivated to write must-have applications. ‘This thing is only cool if it works seamlessly,’ says Roger Kay, president of market research firm Endpoint Technologies Associates. ‘If it works well, it’s game-changing.’ Should those stars align, Kay says, sales could reach into the low billions of dollars in five years. ‘Individuals are going to want this much faster than Microsoft is going to be able to deliver it to them,’ he adds.”

When the team here at Softlayer started, we all had a very similar view as it pertained to the dedicated hosting and utility computing markets. With a tremendously successful track record behind us building companies spanning most everything internet-related, we looked at these markets with a simple question to answer—”How do we merge the physical layer with the virtual layer?” If we could answer this question, this would be our game-changing moment. After our recent announcement of the world’s first API in the dedicated web hosting environment, we are certain the game has changed. The API has certainly started to answer our simple question of merging the physical and virtual environments and now with the introduction of the SoftLayer Development Network, we have opened doors to what is sure to be some really exciting applications to come in the next few days, weeks, and months. Our Eco-System is now one that resides both internally at SoftLayer and with our customer-base. We feel we’ve just barely touched the “Surface.”

-Sean