Posts Tagged 'Interface'

September 28, 2011

A Whole New World: SoftLayer on Windows Phone 7

As SLayers, our goal is always to bring creativity in every aspect of work we do at SoftLayer. It was not too long ago when the Interface Development team was presented with a new and exciting challenge: To develop a Windows Phone 7 Series app. Like me, many questioned whether we should tap into the market of Windows Phone OS ... What was the scope of this OS? What is the future of Windows Phone OS smartphones? The business relationship that NOKIA and Microsoft signed to produce smartphones with Windows Phone 7 OS will provide consumers with a new interface and unique features, so smartphone users are paying attention ... And we are too.

The SoftLayer Mobile world had already made huge strides with iPhone and Android based apps, so our work was cut out for us as we entered the Windows Phone 7 world. We put together a small, energetic and skilled group of SLayers who wanted to make SoftLayer proud, and I am proud to be a member of that team!

Our focus was to design and develop an application that would not only provide the portal functionality on mobile phone but also incorporate the awesome features of Windows Phone 7. Keeping all that in consideration, the choice of using an enterprise quality framework was essential. After a lot of research, we put our finger on the Microsoft's Patterns and Practices-backed Prism Framework for Windows Phone 7. The Prism Framework is a well-known and recognized name among Silverlight and Windows Presentation Framework developers, and since Windows Phone 7 is built upon the Silverlight and XNA Framework, our choice was clearly justified.

After selecting the framework, we wanted to make the whole asynchronous experience smooth while talking to SoftLayer's mobile API. That' where we met the cool kid on the block: Reactive Extensions for .NET (also known as Rx). The Rx is a library used to compose asynchronous and event-based programs. The learning curve was pretty intense for the team, but we operate under the mantra of CBNO (Challenging-But-Not-Overwhelming), so it was learning we knew would bear fruits.

The team's plan was to create an app that had the most frequently used features from the portal. The features to be showcased in the first release were to be basic but at the same time essential. The features we pinpointed were ticket management, hardware management, bandwidth and account management. Bringing these features to the phone posed a challenge, though ... How do we add a little more spice to what cold be a rather plain and basic app?

Windows Phone 7 controls came to our rescue and we utilized the Pivot and Panorama controls to design the Ticket Lists and Ticket Details. The pivot control works like a tabbed-style control that is viewable by sliding left or right. This lets us put the ticket-based-categories in a single view so users don't have to navigate back-and-forth to see different types of tickets. It also provides context-menu style navigation by holding onto the ticket item, giving an option to view or edit ticket with one tap. Here is a screen shot of pivot control in use to view tickets by categories and device list:

Win7 Phone Screen

Another achievement was made by using the panorama control. The control works like a long page with different relevant sections of similar content. This control was used to show a snap shot of a ticket, and the view displays basic ticket details, updates, attachments and any hardware attached to a ticket. This makes editing a ticket as easy as a tap! This is a screenshot of panorama control in use to view ticket detail:

Win7 Phone Screen

The device list view will help people see the dedicated and virtual devices in a pivot control giving a visual distinction. The list can be searched by tapping on the filter icon at the application bar. The filtering is search-as-you-type style and can be turned off by tapping the icon again. This screenshot shows the device list with a filtering option:

Win7 Phone Screen

To perform further hardware operations like pinging, rebooting and power cycling the server, you can use the hardware detail view as well. The bandwidth view may not be as flashy, but it's a very useful representation of a server's bandwidth information. Charting is not available with this release but will be available in the upcoming releases.

If you own a Windows Phone 7 device, go ahead and download "SoftLayer Mobile" and send us the feedback on what features you would like to see next and most importantly whether you love this app or not. We have and will always strive for excellence, and we know there's always room to improve!

-Imran

August 25, 2011

The Beauty of IPMI

Nowadays, it would be extremely difficult to find a household that does not store some form of media – whether it be movies, music, photos or documents – on their home computer. Understanding that, I can say with confidence that many of you have been away from home and suddenly had the desire (or need) to access the media for one reason or another.

Because the Internet has made content so much more accessible, it's usually easy to log in remotely to your home PC using something like Remote Desktop, but what if your home computer is not powered on? You hope a family member is at home to turn on the computer when you call, but what if everyone is out of the house? Most people like me in the past would have just given up altogether since there would be no clear and immediate solution. Leaving your computer on all day could work, but what if you're on an extended trip and you don't want to run up your electricity bill? I'd probably start traveling with some portable storage device like a flash drive or portable hard drive to avoid the problem. This inelegant solution requires that I not forget the device, and the storage media would have to be large enough to contain all necessary files (and I'd also have to know ahead of time which ones I might need).

Given these alternatives, I usually found myself hoping for the best with the portable device, and as anticipated, there would still be some occasions where I didn't happen to have the right files with me on that drive. When I started working for SoftLayer, I was introduced to a mind-blowing technology called IPMI, and my digital life has never been the same.

IPMI – Intelligent Platform Management Interface – is a standardized system interface that allows system administrators to manage and monitor a computer. Though this may be more than what the common person needs, I immediately found IPMI to be incredible because it allows a person to remotely power on any computer with that interface. I was ecstatic to realize that for my next computer build, I could pick a motherboard that has this feature to achieve total control over my home computer for whatever I needed. IPMI may be standard for all servers at SoftLayer, but that doesn't mean it's not a luxury feature.

If you've ever had the need to power on your computers and/or access the computer's BIOS remotely, I highly suggest you look into IPMI. As I learned more and more about the IPMI technology, I've seen how it can be a critical feature for business purposes, so the fact that it's a standard at SoftLayer would suggest that we've got our eye out for state-of-the art technologies that make life easier for our customers.

Now I don't have to remember where I put that flash drive!

-Danny

August 23, 2011

SOAP API Application Development 101

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.

Authentication
Before you start playing with the SoftLayer SOAP API, you will need to find your API authentication token. Go into your portal account, and click the "Manage API Access" link from the API page under the Support tab. At the bottom of the page you'll see a drop down menu for you to "Generate a new API access key" for a user. After you select a user and click the "Generate API Key" button, you will see your username and your API key. Copy this API key, as you'll need it to send commands to SoftLayer's API.

PHP
In PHP 5.0+ there are built in classes to deal with SOAP calls. This allows us to quickly create an object oriented, server side application for handling SOAP requests to SoftLayer's API. This tutorial is going to focus on PHP 5.1+ as the server side language for making SOAP function calls. If you haven’t already, you will need to install the soap client for php, here is a link with directions.

Model View Controller

Model-View-Controller or MVC is a software architecture commonly used in web development. This architecture simply provides separation between a data abstraction layer (model), the business logic (controller), and the resulting output and user interface (view). Below, I will describe each part of our MVC "hello world" web application and dissect the code so that you can understand each line.

To keep this entry a little smaller, the code snippits I reference will be posted on their own page: SOAP API Code Examples. Protip: Open the code snippit page in another window so you can seamlessly jump between this page and the code it's referencing.

Model
The first entry on the API Code Examples page is "The Call Class," a custom class for making basic SOAP calls to SoftLayer's API. This class represents our model: The SOAP API Call. When building a model, you need to think about what properties that model has, for instance, a model of a person might have the properties: first name, height, weight, etc. Once you have properties, you need to create methods that use those properties.

Methods are verbs; they describe what a model can do. Our "person" model might have the methods: run, walk, stand, etc. Models need to be self-sustaining, that means we need to be able to set and get a property from multiple places without them getting jumbled up, so each model will have a "set" and "get" method for each of its properties. A model is a template for an object, and when you store a model in a variable you are instantiating an instance of that model, and the variable is the instantiated object.

  • Properties and Permissions
    Our model has these properties: username, password (apiKey), service, method, initialization parameters, the service's WSDL, SoftLayer's type namespace, the SOAP API client object, options for instantiating that client, and a response value. The SOAP API client object is built into php 5.1+ (take a look at the “PHP” section above), as such, our model will instantiate a SOAP API object and use it to communicate to SoftLayer's SOAP API.

    Each of our methods and properties are declared with certain permissions (protected, private, or public), these set whether or not outside functions or extended classes can have access to these properties or methods. I "set" things using the "$this" variable, $this represents the immediate class that the method belongs to. I also use the arrow operator (->), which accesses a property or method (to the right of the arrow) that belongs to $this (or anything to the left of the arrow). I gave as many of the properties default values as I could, this way when we instantiate our model we have a fully fleshed out object without much work, this comes in handy if you are instantiating many different objects at once.

  • Methods
    I like to separate my methods into 4 different groups: Constructors, Actions, Sets, and Gets:
    • Sets and Gets
      Sets and Gets simply provide a place within the model to set and get properties of that model. This is a standard of object oriented programing and provides the model with a good bit of scalability. Rather than accessing the property itself, always refer to the function that gets or sets the property. This can prevent you from accidentally changing value of the property when you are trying to access it. Lines 99 to the end of our call are where the sets and gets are located.

    • Constructors
      Constructors are methods dedicated to setting options in the model, lines 23-62 of the call model are our constructors. The beauty of these three functions is that they can be copied into any model to perform the same function, just make sure you keep to the Zend coding standards.

      First, let’s take a look at the __construct method on line 24. This is a special magic php method that always runs immediately when the model is instantiated. We don’t want to actually process anything in this method because if we want to use the default object we will not be passing any options to it, and unnecessary processing will slow response times. We pass the options in an array called Setup, notice that I am using type hinting and default parameters when declaring the function, this way I don’t have to pass anything to model when instantiating. If values were passed in the $Setup variable (which must be an array), then we will run the “setOptions” method.

      Now take a look at the setOptions method on line 31. This method will search the model for a set method which matches the option passed in the $setup variable using the built in get_class_methods function. It then passes the value and name of that option to another magic method, the __set method.

      Finally, let’s take a look at the __set and __get methods on lines 45 and 54. These methods are used to create a kind of shorthand access to properties within the model, this is called overloading. Overloading allows the controller to access properties quicker and more efficiently.

    • Actions
      Actions are the traditional verbs that I mentioned earlier; they are the “run”, “walk”, “jump”, and “climb” of our person model. We have 2 actions in our model, the response action and the createHeaders action.

      The createHeaders action creates the SOAP headers that we will pass to the SoftLayer API; this is the most complicated method in the model. Understanding how SOAP is formed and how to get the correct output from php is the key to access SoftLayer’s API. On line 77, you will see an array called Headers, this will store the headers that we are about to make so that we can easily pass them along to the API Client.

      First we will need to create the initial headers to communicate with SoftLayer’s API. This is what they should look like:

      <authenticate xsi:type="slt:authenticate" xmlns:slt="http://api.service.softlayer.com/soap/v3/SLTypes/">
          <username xsi:type="xsd:string">MY_USERNAME</username>
          <apiKey xsi:type="xsd:string">MY_API_ACCESS_KEY</apiKey>
      </authenticate>
      <SoftLayer_API_METHODInitParameters xsi:type="v3:SoftLayer_API_METHODInitParameters" >
          <id xsi:type="xsd:int">INIT_PERAMETER</id>
      </SoftLayer_API_METHODInitParameters>

      In order to build this we will need a few saved properties from our instantiated object: our api username, api key, the service, initialization parameters, and the SoftLayer API type namespace. The api username and key will need to be set by the controller, or you can add in yours to the model to use as a default. I will store mine in a separate file and include it in the controller, but on a production server you might want to store this info in a database and create a "user" model.

      First, we instantiate SoapVar objects for each authentication node that we need. Then we store the SoapVar objects in an array and create a new SoapVar object for the "authenticate" node. The data for the "authenticate" node is the array, and the encoding is type SOAP_ENC_OBJECT. Understanding how to nest SoapVar objects is the key to creating well formed SOAP in PHP. Finally, we instantiate a new SoapHeader object and append that to the Headers array. The second header we create and add to the Headers array is for initialization parameters. These are needed to run certain methods within SoftLayer’s API; they essentially identify objects within your account. The final command in this method (__setSoapHeaders) is the magical PHP method that saves the headers into our SoapClient object. Now take a look at how I access the method; because I have stored the SoapClient object as a property of the current class I can use the arrow operator to access methods of that class through the $_client property of our class, or the getClient() method of our class which returns the client.

      The Response method is the action which actually contacts SoftLayer’s API and sends our SOAP request. Take a look at how I tell PHP that the string stored in our $_method property is actually a method of our $_client property by adding parenthesis to the end of the $Method variable on line 71.

View
The view is what the user interprets, this is where we present our information and create a basic layout for the web page. Take a look at "The View" section on SOAP API Code Examples. Here I create a basic webpage layout, display output information from the controller, and create a form for sending requests to the controller. Notice that the View is a mixture of HTML and PHP, so make sure to name it view.php that way the server knows to process the php before sending it to the client.

Controller
The controller separates user interaction from business logic. It accepts information from the user and formats it for the model. It also receives information from the model and sends it to the view. Take a look at "The Controller" section on SOAP API Code Examples. I accept variables posted from the view and store them in an array to send to the model on lines 6-11. I then instantiate the $Call object with the parameters specified in the $Setup array, and store the response from the Response method as $Result in line 17 for use by the view.

Have Fun!
Although this tutorial seems to cover many different things, this just opens up the basic utilities of SoftLayer's API. You should now have a working View to enter information and see what kind of data you will receive. The first service and method you should try is the SoftLayer_Account service and the getObject method. This will return your account information. Then try the SoftLayer_Account service and the getHardware method; it will return all of the information for all of your servers. Take the IDs from those servers and try out the SoftLayer_Hardware_Server service and the getObject method with that id as the Init property.

More examples to try: SoftLayer Account, SoftLayer DNS Domain, SoftLayer Hardware Server. Once you get the hang of it, try adding Object Masks and Result Limits to your model.

Have Fun!

-Kevin

June 21, 2011

Ghostin' the Machine - SoftLayer Customer Portal

The hosting business is a really great place to be these days. It may morph rapidly, but some things ring consistently clear. The dedicated server is one of those things. In the brief 10 years or so of my Internet hosting career, the way dedicated servers are delivered to customers and the way they are managed has gone from prop-jet to auto-pilot.

I got started in the dedicated hosting business under Lance Crosby (our current CEO) in October of 2003. At that time we had less than 100 employees, and it may have been less than 50. "Auto-provisioning" consisted of Lance offering pizza and cash bonuses for each white-box PC that we'd 'ghost' with a boot floppy using a networked imaging server (in between our support tasks of answering calls and responding to tickets). We used a popular product made by Norton* in those days to deliver servers as quickly as possible to feed what seemed like an endless demand. As time has gone by, our systems have vastly improved, and true automation is the rule now; Manual intervention, the exception.

Today, SoftLayer has 600+ employees, 80,000+ dedicated servers, 26,000+ customers and is on the verge of launching our international presence. One of the biggest reasons SoftLayer has been so successful is because we offer customers maximum control.

When you need online computing power these days, you have hundreds of choices. Most of your options are still centered on the general idea of the dedicated server, but there are variations depending on what needs are being targeted. Physical dedicated servers are now complimented by Cloud Compute Instances and Virtualized Instances to provide a more flexible platform to tailor to specific use cases. Some providers do better than others at integrating those platforms, and when we began incoporating cloud and dedicated in an integrated environment, our goal was to enable customers to control all aspects of their environment via a single 'pane of glass,' our customer portal.

If you've heard us talk about the features and functionality in the customer portal but have never seen how easy it is to actually navigate the interface, today's your lucky day:

In a nutshell, you get the kind of server control that used to require driving down to the data center, popping on your parka and performing some troubleshooting in the freezing cold cage. You may have been troubleshooting hardware cooling, wiring or other hardware issues, and you'd usually need direct console access to all the different types of servers and devices loaded on your rack.

Thankfully, those days are gone.

Now you can order a dedicated server and have it online in 2-4 hours (or a Cloud Computing Instance which can be online in 15 minutes). You can configure their private network so that they can talk to each other seamlessly; you can add firewalls, load balancing, backup services, monitoring instantly. For maintenance issues, you have the convenience of BIOS-level access via the standard KVM over IP card included in every server so you can see low-level hardware indicators like fan speeds and core temperatures and perform soft IPMI reboots. Firmware upgrades for your hard drive, motherboard, or RAID card that once required the ever-hated floppy disk can now be done with a few button clicks, and speaking of RAID cards, our systems will report back on any change to an ideal status for your disk subsystem. If that weren't enough, you've got monitoring alerts and bandwidth graphs to give you plenty of easy to reference eye-candy.

No more messy wiring, no more beeping UPS units, no more driving, no more parkas.

-Chris

*As a rather humorous aside: My former manager, Tim, got a call one night from one of the newer NOC staff. He was a systems guy, many of the internal systems were under his SysAdmin wing. He was awakened by a tech with broken English who informed him that his name was on the escalation procedures to be called whenever this server went down:

Tim: (groggily) "What is the server name?"
Tech: "G - Host - Me"
Tim: "Huh? Why did you wake me up? ... Why don't you call that hosting company? ... I don't think that's one of my boxes!"
Tech: "No, no sir, so sorry, but your name is on the escalation. Server Label is 'G' ... um 'HOSTME.'"
Tim: "Whaa? — Wait, do you mean Ghost Me?" (GHOSTME was the actual hostname for the Norton imaging server that we used for a while as our 'provisioning' platform)

Laughter ensued and this story was told many times over beers at the High Tech pub.

Subscribe to interface