1. Diversify your IP space.
2. Add keywords to the <meta> tag on your site.
3. Make sure those keywords also appear in the body of your document.
4. Take 2 & 3 and fill them with references to Pokémon, pop music, and porn.

However, only #3 is a valid tactic in this new, Google-driven world. Let’s analyze them one by one.

Diversifying your IP space. Old search engines gave more credence to sites located in “geographically diverse” areas, where “geographically diverse” was determined by class C addresses. Now, however, with the advent of huge centralized data centers, search engine algorithms recognize that a site with 15 servers in the same datacenter may be just as effective as 15 separate cities. Of course, it’s still a good idea to buy servers in, say, Dallas, Seattle, and Washington DC.

Meta tags. Google and other major search engines don’t really look at meta tags anymore for keywords. They still will use the meta tag for language, encoding, and summary data. However, the processing power of search engines has been increasing exponentially in the last few years, which means they’re capable of analyzing the actual content of the page rather than relying on meta tags. If you still have meta tags, you can keep them, but they’re only really useful for language and summary information.

Document body keywords. This is an area where it still matters. As previously mentioned, search engines now are capable of searching the entire page. In the past, it was only a few search engines that indexed actual page content, and even then it may have been a simple count of how often your meta keywords match page contents. Now, however, Google stores local copies of every page they index (to a certain extent) and uses the entire page contents for search and cached viewing.

Dummy data. When search engines were younger, they could be fooled very easily by simply including the top 1,000 popular search terms in your meta tags and as invisible text inside your document body. I never understood it personally, but the thinking was that if you had enough references to Britney Spears on your page, you would hijack enough people that one of them would forget what he was originally looking for and buy your product instead. Though I guess that’s how spam works now, isn’t it?

So what can you do right now to improve your search engine placement? There are a few easy things to do, broken into the following categories:

1. Page Titles. Your pages should each have a unique, meaningful title. Putting the name of your site on every page doesn’t do anyone any good. Not only will it give your search results more visibility, but it will help people find it again if they bookmark it.
2. Page Content. You want your page content to be meaningful and arranged around a central semantic theme. Don’t put up one huge page featuring thousands of unrelated pieces of information. Keep it concise, unique, and focused. You have an unlimited number of individual pages, make use of that fact.
3. Dynamic Content. The more often your site changes, the higher your Google rank will be. You could take the cheap way out and simply put a box on your site that has random content, but the best way is to actually do updates as often as possible. This ensures not only visibility on the search engines, but makes your site more useful to the people that eventually make it to your pages, which is your main goal anyway.
4. Accessibility. This is a key area that many sites overlook. You need to make heavy use of the title and alt attributes for things like links and images. Not only is it required by the Americans With Disabilities Act, but it helps blind users navigate your site. You know what acts like a blind user? Search engine crawlers. When you do a Google images search, the images that pop up most likely have alt attributes specified. The same goes for link titles, if you put a brief link description in your titles, not only do you get pretty mouseovers on the links, but they add one more point to your eventual page rank.
5. Linking. Google builds its page rank based on links to and from the page in question, as well as the page contents itself. With this in mind, it’s useful to link out to sources on whatever topic you’re attempting to talk about. The higher the page rank of the target, the higher the benefit to you. Also, it’s a good idea to attempt to be useful enough for other people to link to you, either in message boards or as a source of their own. All links eventually increase your page rank. Also, as a small note, make your URLs “search engine friendly” by attempting to include keywords in there as well. Many message boards will include the post title in the URL for just this purpose. Also, for some reason, Google refuses to index any URL with “?id=” in it, so be careful about that.
6. Site Map. Search engines love site maps. Users don’t care for them as much, but a concise HTML or XML site map with links to every page on your site divided into sections with a short description increases links, increases accessibility, and gives the search engines more meta data on the important topics in each page.

So all you have to do to improve your search engine rank is to have dynamic, frequently changing content about a single, concise topic on an easily accessible page that is frequently linked to by other pages. Wikipedia is a perfect example of search engine optimization in action. Each page is titled with the topic it discusses; every image has a title attribute and links out to a full description of the article; each link has a title attribute; many outside sources are mentioned; plenty of sites link to each article as well as the root domain; and the index page changes every single day with completely new and original content.

Unfortunately, there was just one catch—I’m not a .NET programmer. I’ve got 10 years of experience writing drivers, protocol suites, and firmware. In other words, C/C++ with a little bit of assembler thrown in when push comes to shove. Sure I can write a c-sharp application, but I’m pretty green at it and until a month ago if someone had told me they had a problem with their WSDL (pronounced wiz’duhl) I would have wondered why they were telling me instead of their urologist!

That said, what follows is a pretty basic SLAPI example, done in both C# and VB.NET (because I’m ambi-dot-dextrous). Don’t expect anything more than a DOS-style command console for the UI. I’m used to letting the Microsoft’s control panel give the user any feedback and usually consider my code to be ready to ship if it can run for 24 hours without blue-screening the box!

My chops are on display at the SLDN API Wiki. Let me know what you think!

The picture below represents how each API data type relates to each other. The ones with the most lines connecting them to outher types are SoftLayer_Account and SoftLayer_Hardware. Go figure. : ) Here’s an SVG version of the image or click on the image below for a higher resolution version for your viewing pleasure. It looks most impressive when printed out and taped to your cubicle wall. Enjoy! See y’all next time.

In other news, SoftLayer has recently launched a shiny new Facebook group. Sign in and join up to talk with us and get your hands-on exclusive content (which currently is videos of me rambling about the API). As always, we’re here if you have questions, concerns, or just want to chat. See you next time!

- The SoftLayer API now explicitly specifies the data types it uses, making it far easier to write in major programming languages like Java and .NET.
- This go around we’re object-oriented. Anything that you can do in it is modeled by a service and data type. Where API version 1 had one endpoint and about 20 methods, API version 3 has about 50, one per service, and about 390 methods. That leads me to…
- It does everything. Seriously, this API lets you manage every single one of your SoftLayer servers and services. In fact it lets you do everything that our portal lets you do (except purchasing servers, but we’ll get to that). For you guys that have been asking, yes that includes DNS management and OS reloads.

We like this API so much that for the past month we’ve been busting our humps rewriting our customer portal as an API application. I just checked our system statistics. Load on our database is down by 25%, and load on our portal web servers is down about 10%. There’s a noticeable improvement in portal responsiveness since we’ve started this project. A great side effect of rewriting our portal as an API application is that when we bust out new services they go into the API immediately.

If you’ve been developing against API version 1 then take a look at our migration guide and FAQ on our brand-spanking-new SLDN documentation wiki. We’re really looking forward to making (and help you guys make) some cool apps with this. This is a big change for us, so please don’t be shy in letting us know what you think. Our forums and email are waiting!

Where has the time gone? We’ve been busy in the devCave working out some big projects and improving what we’ve got. In the mean time here’s some new API features for ya’ll to try out:

 
Back It Up
 

You can now query the state of your NAS or lockbox accounts through the API via the getNasSummaryDetails(strNasType) method. Pass along the string “N” or “L” if you want to check NAS or lockbox accounts and it’ll return a list of NAS accounts containing your NAS server’s hostname and IP address, connect username and password, capacity, and the server id and name that the NAS account is attached to. If your NAS account isn’t tied to a server then it returns “N/A” for the attached server hostname and IP address. Its another way to keep track of your services through the API.

 
The Port Authority
 

The Port Control features of the Customer Portal are now available in the API to help you manage your ports programmatically. Now you can get the port SPEED of the given server by using the method, getServerPortSpeed(strServerIdentifier). This function also returns the ID, SERVERNAME, PUBLIC IP, and PRIVATE IP. If you would like to broaden your scope of data, use the getServerPortSpeedList() method. This function returns the same data provided by the former but for all of your servers.

With access to this data, you may find that you want to make a few changes. The updateServerPortSpeed(strServerIdentifier, intNewSpeed, strControlInterface) function was created to do just that. Just provide the ID of your server (IP or Hardware ID), the new port speed that you would like configured (values of 0, 10, 100, 1000), and the interface (public or private), and you are on your way. Not only will the ports for the specified server be reconfigured, but the upstream and downstream connected components will be updated as well.

Give it a shot and let us know your thoughts!

We’ve updated the API again! This latest refresh sports:

• fixed: getBandwidthList()’s output now mirrors the estimated and projected bandwidth amounts measured by our management portal.
• fixed: Hostnames and domain names in server names are now separated by a period in getBandwidthList()’s output.
• fixed: The Savvis #2 and Global Grossing links are now properly reported in getBackboneList().
• added: The getServerBandwidthDetails() method has been added to the SoftLayer API. getServerBandwidthDetails() mirrors getBandwidthList()’s output for a single server. It returns an array and requires two paraeters:

  strServerIdentifier: A server ID, public IP addres, or private IP address.
  strBandwidthType: The string “public” or “private” depending on which port you want to retrieve bandwidth data from. This value defaults to “public”.

We really should give a shout out to those that have been keeping us on our toes by reporting issues to us on our forums and in support tickets. Please keep them coming. Your contributions are turning the API into a great product. See ya’ll next time!

I think we on the SLDN development team have it pretty lucky. You can’t beat developing at a datacenter where there are umpteen, wonderful servers to test your code on. Need to reboot a box? Sure! Go for it! After all, it’s just a quick phone call to the datacenter to bring it back online if your test code broke something. In the mean time there are plenty of other boxes to test on. Sure that’s great for us, but it can get hairy if you only have one or two systems to test with. While our sales droids would have you fix that by ordering more servers we on the dev team just implemented a tried and true code test mechanism, the sandbox! Wait, I mean this sandbox!

Our API sandbox is a way for you to safely test sensitive methods without affecting your servers. Method calls from the sandbox will return accurate return data without actually affecting your services or SoftLayer services. Most of our methods are simple get methods; those still work exactly the same. More fun methods like rebootServer() will not reboot your server if called from our sandbox, but will return the same response to your app as if they did.

To use the API sandbox change the API entry point server in your code to api-sandbox.service.softlayer.com. That’s it! Use the same methods and parameters that you’d normally call. The sandbox works on both the XML-RPC and SOAP interfaces. When you’re done testing point your API calls back to api.service.softlayer.com to return to normal functionality.

As always, we welcome your feedback and suggestions. Let us know what you think on our forums. See you next time!