news

September 24, 2012

Cloud Computing is not a 'Thing' ... It's a way of Doing Things.

I like to think that we are beyond 'defining' cloud, but what I find in reality is that we still argue over basics. I have conversations in which people still delineate things like "hosting" from "cloud computing" based degrees of single-tenancy. Now I'm a stickler for definitions just like the next pedantic software-religious guy, but when it comes to arguing minutiae about cloud computing, it's easy to lose the forest for the trees. Instead of discussing underlying infrastructure and comparing hypervisors, we'll look at two well-cited definitions of cloud computing that may help us unify our understanding of the model.

I use the word "model" intentionally there because it's important to note that cloud computing is not a "thing" or a "product." It's a way of doing business. It's an operations model that is changing the fundamental economics of writing and deploying software applications. It's not about a strict definition of some underlying service provider architecture or whether multi-tenancy is at the data center edge, the server or the core. It's about enabling new technology to be tested and fail or succeed in blazing calendar time and being able to support super-fast growth and scale with little planning. Let's try to keep that in mind as we look at how NIST and Gartner define cloud computing.

The National Institute of Standards and Technology (NIST) is a government organization that develops standards, guidelines and minimum requirements as needed by industry or government programs. Given the confusion in the marketplace, there's a huge "need" for a simple, consistent definition of cloud computing, so NIST had a pretty high profile topic on its hands. Their resulting Cloud Computing Definition describes five essential characteristics of cloud computing, three service models, and four deployment models. Let's table the service models and deployment models for now and look at the five essential characteristics of cloud computing. I'll summarize them here; follow the link if you want more context or detail on these points:

  • On-Demand Self Service: A user can automatically provision compute without human interaction.
  • Broad Network Access: Capabilities are available over the network.
  • Resource Pooling: Computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned.
  • Rapid Elasticity: Capabilities can be elastically provisioned and released.
  • Measured Service: Resource usage can be monitored, controlled and reported.

The characteristics NIST uses to define cloud computing are pretty straightforward, but they are still a little ambiguous: How quickly does an environment have to be provisioned for it to be considered "on-demand?" If "broad network access" could just mean "connected to the Internet," why include that as a characteristic? When it comes to "measured service," how granular does the resource monitoring and control need to be for something to be considered "cloud computing?" A year? A minute? These characteristics cast a broad net, and we can build on that foundation as we set out to create a more focused definition.

For our next stop, let's look at Gartner's view: "A style of computing in which scalable and elastic IT-enabled capabilities are delivered as a service using Internet infrastructure." From a philosophical perspective, I love their use of "style" when talking about cloud computing. Little differentiates the underlying IT capabilities of cloud computing from other types of computing, so when looking at cloud computing, we really just see a variation on how those capabilities are being leveraged. It's important to note that Gartner's definition includes "elastic" alongside "scalable" ... Cloud computing gets the most press for being able to scale remarkably, but the flip-side of that expansion is that it also needs to contract on-demand.

All of this describes a way of deploying compute power that is completely different than the way we did this in the decades that we've been writing software. It used to take months to get funding and order the hardware to deploy an application. That's a lot of time and risk that startups and enterprises alike can erase from their business plans.

How do we wrap all of those characteristics up into unified of definition of cloud computing? The way I look at it, cloud computing is as an operations model that yields seemingly unlimited compute power when you need it. It enables (scalable and elastic) capacity as you need it, and that capacity's pricing is based on consumption. That doesn't mean a provider should charge by the compute cycle, generator fan RPM or some other arcane measurement of usage ... It means that a customer should understand the resources that are being invoiced, and he/she should have the power to change those resources as needed. A cloud computing environment has to have self-service provisioning that doesn't require manual intervention from the provider, and I'd even push that requirement a little further: A cloud computing environment should have API accessibility so a customer doesn't even have to manually intervene in the provisioning process (The customer's app could use automated logic and API calls to scale infrastructure up or down based on resource usage).

I had the opportunity to speak at Cloud Connect Chicago, and I shared SoftLayer's approach to cloud computing and how it has evolved into a few distinct products that speak directly to our customers' needs:

The session was about 45 minutes, so the video above has been slimmed down a bit for easier consumption. If you're interested in seeing the full session and getting into a little more detail, we've uploaded an un-cut version here.

-Duke

September 21, 2012

Powering Cloud Automation Through Partnerships

When SoftLayer began back in 2005, the term “cloud computing” was rarely used if at all. The founders of SoftLayer had an ambitious vision and plan to build a service platform that could easily automate, scale and meet the demands of the most sophisticated IT users. They were obviously onto something. Since then, we’ve emerged as the world’s largest privately held Infrastructure-as-a-Service (IaaS) provider, helping the next generation of web savvy entrepreneurs realize their dreams. But we didn’t do it alone. We had partnerships in place—including working with Parallels.

Today everyone is trying to scramble and figure out how this “new” IT shift will work itself out. Our friends over at Parallels had a similar ambitious undertaking—trying to automate and enable a complete gamut of hosting and cloud services. This created a framework for our partnership. We worked with their engineering and sales teams, starting back in 2005, which resulted in Parallels Plesk Panel being offered as an option on every SoftLayer server. That was just the beginning. We are now deploying Parallels Automation for hosting partners and have plans to integrate with their Application Packaging Standard offering. Plans to integrate with other products like Parallels Cloud Server are also on the horizon. It all comes down to helping hosting companies and other joint customers thrive and succeed.

To find out more about our partnership and how it can help streamline your entry into cloud computing click here. We are also the only “Diamond” sponsor at the Parallels Summit 2012 APAC in Singapore this year. We share a heritage and understanding with Parallels borne from a need to simplify and solve IT problems on a broad scale. Now that’s what I call a likeminded partnership.

-@gkdog

September 20, 2012

Conferences, Culture and the SoftLayer Server Challenge

I can't begin to tell you how much fun I have when I get to represent SoftLayer at conferences. The days may be long, and my feet may go numb by the end of the day from so much standing, but the time seems to fly as I get to meet new people, give out SoftLayer swag and introduce/explain the (in)famous SoftLayer Server Challenge.

I've observed that at most tech conferences, attendees will wander up and down the aisles, avoiding eye contact and looking preoccupied with emails or Angry Birds on their phones. When they walk by the SoftLayer booth, something changes. They stop. They pay attention. They get engaged. It's hard to passively navigate around a crowd of people cheering on a Server Challenge competitor, and if you see another attendee your peripheral vision "wowing" us with his/her three-switch-ball juggling skills, you're going to get distracted from your Angry Birds game. The SoftLayer booth is a snapshot of SoftLayer's culture, and SoftLayer's culture is magnetic.

When we catch the eye of that previously disinterested attendee, we get to tell the SoftLayer story: "Oh this? It's a small version of a SoftLayer server rack with five SuperMicro servers in it. We've got more than 100,000 servers like these in 13 data centers around the world. Want to try and race to put it back together?" "This is called a switch-ball ... SoftLayer is an infrastructure as a service provider, so it doesn't really have a direct tie-in with SoftLayer's business, but it's the coolest giveaway you'll see at the conference." Whether the attendee is interested in the competition, hosting, servers or cool swag, we've started a conversation that we might not have had if we were just shaking hands and passing out brochures.

As the conference goes on, most booths see traffic decline. That's when the Server Challenge is usually getting the most competitive. Several of our competitions have been decided by tenths or even hundredths of seconds, and a few have been won by the last competitor on the last day as the PA announcement notifies attendees that the expo hall is closing. At Cloud Connect Chicago, I recorded three competitors who each had the potential to walk away victorious:

All three of those competitors had fun in the SoftLayer booth. The other attendees who stepped up to the Server Challenge enjoyed themselves, too. That's huge. That's extremely rare. That's why I love being a part of the rag-tag group SLayers who have the opportunity to spread the word about SoftLayer.

As I put together the quick video to show the competition from Cloud Connect Chicago, I wondered how the times compared with the other shows that have featured the Server Challenge this year. My "wondering" wound up becoming "researching," and this is what I found:

NAME SHOW TIME
Roger Weber GDC Europe 0:57.62
Rany Grinberg ad:tech San Franscisco 0:58.34
Dejian Fang Cloud Expo East 0:59.08
Darin Goldman HostingCon 0:59.28
Joseph Waite Internet World London 1:03.68
Scott Fossen Cloud Connect Chicago 1:05.51
EJ Fernald GDC San Francisco 1:06.06
Kenny Liao Web 2.0 Expo 1:06.41
Matthew Downing Cloud Expo Europe 1:08.16
Gary Barclay TFM&A 1:10.08

Every conference seems to be competitive, and it's amazing to see how close the times are between all of the conference winners in 2012. Server Challenge World Championship? While I start drawing up plans to try and make that a reality, I recommend you all print out blueprints and start training for the next time you come across a SoftLayer booth at an event.

-@khazard

Categories: 
September 17, 2012

Joining the Internet Infrastructure Coalition

In January, we posted a series of blogs about legislation in the U.S. House of Representatives and Senate that would have had a serious impact on the hosting industry. We talked about SOPA and PIPA, and how those proposed laws would "break the Internet" as we know it. The hosting industry rallied together to oppose the passage of those bills, and in doing so, we proved to be a powerful collective force.

In the months that followed the shelving of SOPA and PIPA, many of the hosting companies that were active in the fight were invited to join a new coalition that would focus on proposed legislation that affects Internet infrastructure providers ... The Internet Infrastructure Coalition (or "i2Coalition") was born. i2Coalition co-founder and Board Chair Christian Dawson explains the basics:

SoftLayer is proud to be a Charter Member of i2Coalition, and we're excited to see how many vendors, partners, peers and competitors have joined us. Scrolling the ranks of founding members is a veritable "Who's who?" of the companies that make up the "nuts and bolts" of the Internet.

The goal of i2Coalition is to facilitate public policy education and advocacy, develop market-driven standards formed by consensus and give the industry a unified voice. On the i2Coalition's Public Policy page, that larger goal is broken down into focused priorities, with the first being

"In all public policy initiatives of the i2Coalition will be to encourage the growth and development of the Internet infrastructure industry and to protect the interests of members of the Coalition consistent with this development."

Another huge priority worth noting is the focus on enabling and promoting the free exercise of human rights — including freedom of speech, freedom of assembly and the protection of personal privacy. Those rights are essential to fostering effective Internet advancement and to maintain a free and open Internet, and SoftLayer is a strong supporter of that platform.

If you operate in the hosting or Internet infrastructure space and you want to be part of the i2Coalition, we encourage you to become a member and join the conversation. When policymakers are talking about getting "an Internet" from their staff members, we know that there are plenty of opportunities to educate and provide context on the technical requirements and challenges that would result from proposed legislation, and the Internet Infrastructure Coalition is well equipped to capitalize on those opportunities.

-@toddmitchell

September 12, 2012

How Can I Use SoftLayer Message Queue?

One of the biggest challenges developers run into when coding large, scalable systems is automating batch processes and distributing workloads to optimize compute resource usage. More simply, intra-application and inter-system communications tend to become a bottleneck that affect the user experience, and there is no easy way to get around it. Well ... There *was* no easy way around it.

Meet SoftLayer Message Queue.

As the name would suggest, Message Queue allows you to create one or more "queues" or containers which contain "messages" — strings of text that you can assign attributes to. The queues pass along messages in first-in-first-out order, and in doing so, they allow for parallel processing of high-volume workflows.

That all sounds pretty complex and "out there," but you might be surprised to learn that you're probably using a form of message queuing right now. Message queuing allows for discrete threads or applications to share information with one another without needing to be directly integrated or even operating concurrently. That functionality is at the heart of many of the most common operating systems and applications on the market.

What does it mean in a cloud computing context? Well, Message Queue facilitates more efficient interaction between different pieces of your application or independent software systems. The easiest way demonstrate how that happens is by sharing a quick example:

Creating a Video-Sharing Site

Let's say we have a mobile application providing the ability to upload video content to your website: sharevideoswith.phil. The problem we have is that our webserver and CMS can only share videos in a specific format from a specific location on a CDN. Transcoding the videos on the mobile device before it uploads proves to be far too taxing, what with all of the games left to complete from the last Humble Bundle release. Having the videos transcoded on our webserver would require a lot of time/funds/patience/knowledge, and we don't want to add infrastructure to our deployment for transcoding app servers, so we're faced with a conundrum. A conundrum that's pretty easily answered with Message Queue and SoftLayer's (free) video transcoding service.

What We Need

  • Our Video Site
  • The SoftLayer API Transcoding Service
  • SoftLayer Object Storage
    • A "New Videos" Container
    • A "Transcoded Videos" Container with CDN Enabled
  • SoftLayer Message Queue
    • "New Videos" Queue
    • "Transcoding Jobs" Queue

The Process

  1. Your user uploads the video to sharevideoswith.phil. Your web app creates a page for the video and populates the content with a "processing" message.
  2. The web application saves the video file into the "New Vidoes" container on object storage.
  3. When the video is saved into that container, it creates a new message in the "New Videos" message queue with the video file name as the body.
  4. From here, we have two worker functions. These workers work independently of each other and can be run at any comfortable interval via cron or any scheduling agent:
Worker One: Looks for messages in the "New Videos" message queue. If a message is found, Worker One transfers the video file to the SoftLayer Transcoding Service, starts the transcoding process and creates a message in the "Transcoding Jobs" message queue with the Job ID of the newly created transcoding job. Worker One then deletes the originating message from the "New Videos" message queue to prevent the process from happening again the next time Worker One runs.

Worker Two: Looks for messages in the "Transcoding Jobs" queue. If a message is found, Worker Two checks if the transcoding job is complete. If not, it does nothing with the message, and that message is be placed back into the queue for the next Worker Two to pick up and check. When Worker Two finds a completed job, the newly-transcoded video is pushed to the "Transcoded Videos" container on object storage, and Worker Two updates the page our web app created for the video to display an embedded media player using the CDN location for our transcoded video on object storage.

Each step in the process is handled by an independent component. This allows us to scale or substitute each piece as necessary without needing to refactor the other portions. As long as each piece receives and sends the expected message, its colleague components will keep doing their jobs.

Video transcoding is a simple use-case that shows some of the capabilities of Message Queue. If you check out the Message Queue page on our website, you can see a few other examples — from online banking to real-time stock, score and weather services.

Message Queue leverages Cloudant as the highly scalable low latency data layer for storing and distributing messages, and SoftLayer customers get their first 100,000 messages free every month (with additional messages priced at $0.01 for every 10,000).

What are you waiting for? Go get started with Message Queue!

-Phil (@SoftLayerDevs)

September 10, 2012

Creating a Usable, Memorable and Secure Password

When I was young, I vividly remember a wise man sharing a proverb with me: "Locks are for honest people." The memory is so vivid because it completely confused me ... "If everyone was honest, there would be no need for locks," I thought, naively. As it turns out, everyone isn't honest, and if "locks keep honest people honest," they don't do anything to/for dishonest people. That paradox lingered in the back of my mind, and a few years later, I found myself using some sideways logic to justify learning the mechanics of lock picking.

I ordered my first set of lock picks (with instruction booklet) for around $10 online. When the package arrived, I scrambled to unwrap it like Ralphie unwrapped the "Red Ryder" BB gun in "A Christmas Story," and I set out to find my first lock to pick. After a few unsuccessful attempts, I turned to the previously discarded instruction booklet, and I sat down to actually learn what I was supposed to be doing. That bit of study wound up being useful; with that knowledge, I managed to pick my first lock.

I tend to collect hobbies. I also tend to shift every spare thought towards my newest obsession until whatever goal I set is accomplished. To this end, I put together a mobile lock-picking training device — the cylinder/tumbler from a dead bolt, my torq wrench wrapped with electrical tape to prevent the recurrence of blisters, and my favorite snake rake. I took this device with me everywhere, unconsciously unlocking and resetting the lock as I went about my shopping, sat in a doctor's office or walked around the block. In my mind, I was honing my skills on a mechanical challenge, but as one of my friends let me know, people who saw me playing with the lock in public would stare at me like I was a budding burglar audaciously flaunting his trade.

I spent less money on a lock picking set than I would have on a lock, and I felt like had a key to open any door. The only thing between me and the other side of a locked door in front of me was my honesty. What about the dishonest people in the world, though? They have the same access to cheap tools, and while they probably don't practice their burgling in public, can spend just as much time sharpening their skills in private. From then on, I was much more aware of the kinds of locks I bought and used to secure my valuables.

When I started getting involved in technology, I immediately noticed the similarities between physical security and digital security. When I was growing up, NBC public service announcements taught me, "Knowledge is Power," and that's even truer now than it was then. We trust technology with our information, and if someone else gets access to that information, the results can be catastrophic.

Online, the most common "hacks" and security exploits are usually easily avoidable. They're the IRL equivalent of leaving valuables on a table by an unlocked window with the thought, "The window is closed ... My stuff is secure." Some of those windows may be hard to reach, but some of them are street-level in high-traffic pedestrian areas. The most vulnerable and visible of access points: Passwords.

You've heard people tell you not to do silly things like making "1 2 3 4 5" your combination lock, and your IT team has probably gotten onto you about using "password" to log onto your company's domain, but our tendency to create simpler passwords is a response to the inherent problem that a secure password is, by its nature, hard to remember. The average Internet user probably isn't going to use pwgen or a password lockbox ... If you had a list of passwords from a given site, my guess is that you'd wind up seeing a lot more pets' names and birth years than passwords like S0L@Y#Rpr!Vcl0udN)3mblyR#Q. What people need to understand is that the "secure" password can be just as easy to remember as "Fluffy1982."

Making a *Usable* Secure Password

The process of creating a unique, usable and secure password is pretty straightforward:

  1. Start with a series of words or phrases which have a meaning to you: A quote in a movie, song lyric, title of your favorite book series, etc. For our example, let's use "SoftLayer Private Clouds, no assembly required."
  2. l33t up your phrase. To do this, you'd remove punctuation and spaces, and you'd replace a letter in the phrase with a special character. You predetermining these conversions to create a template of alterations to any string which only take minimal thought from you. In the simplest of cyphers, letters become a numbers or characters that resemble the letter: An "o" becomes a "0," "e" becomes a "3," an "a" becomes an "@," etc. In more complicated structures, a character can be different based on where it lies in the string or what less-commmon substitutions you choose to use. Our example at this point would look like this: "S0ftL@y3rPr1v@t3Cl0udsn0@ss3mblyr3qu1r3d"
  3. Right now, we have a password that would make any brute-forcing script-kiddie yearn for the Schwarts, but we're not done yet. If someone were to find our cypher and personal phrase, they may be able to figure out our password. Also, this password is too long for use in many sites with password restrictions that cap you a 16 characters. Our goal is to create a password between 15-25 characters and be prepared to make cuts when necessary.
  4. A good practice is to cut out the beginning or ending of a word. In our example (taking out the l33t substitutions for simplicity here), our phrase might look like this: "so-layer-priv-cloud-no-embly-req"
  5. When we combine the shortened password with l33t substitutions, the last trick we want to incorporate is using our Shift key. An "e" might be a "3" in a simple l33t cypher, but if we use the Shift key, the "e" becomes a "#" (Shift+"3"): "S0L@Y#Rpr!Vcl0udN)#mblyR#Q"

The main idea is that when you're "locking" your accounts with a password, you don't need the most complicated lock ever created ... You just need one that can't be picked easily. Establish a pattern of uncommon substitutions that you can use consistently across all of your sites, and you'll be able to use seemingly common phrases like "Fluffy is my dog's name" or "Neil Armstrong was an astronaut" without worrying about anyone being able to "open your window."

-Phil (@SoftLayerDevs)

September 6, 2012

Tips and Tricks - jQuery equalHeights Plugin

Last month, I posted a blog about dynamically resizing divs with jQuery, and we received a lot of positive feedback about it. My quest to avoid iframes proved to be helpful, so I thought I'd share a few more esoteric jQuery tips and tricks that may be of use to the developers and designers in the audience. As I thought back about other challenges I've faced as a coder, a great example came to mind: Making divs equal height, regardless of the amount of content inside.

I haven't seen many elegant div-based solutions for that relatively simple (and common) task, so I've noticed that many people struggle with it. Often, developers will turn back to the "Dark Side" of using tables to format the content since all columns would have the same height as the tallest column by default:

JQuery Tutorial

It was easy theme table columns and to achieve the coveted 100% height that many designers seek, but emulating that functionality with divs proves to be much more difficult. A div is like the Superman of HTML elements (faster-loading, more flexible, more dynamic, etc.), and while it has super powers, it also has its own Kryptonite-like weaknesses ... The one relevant to this blog post being that floating three div elements next to each other isn't going to give you the look of a table:

JQuery Tutorial

Each of the three divs has its own height, so if you're doing something as simple as applying background colors, you're going to wind up with an aesthetically unpleasing result: It's going to look funky.

You could get into some nifty HTML/CSS workarounds, but many frustrated theme creators and designers will tell you that if your parent elements don't have a height of a 100%, you're just wasting coding lines. Some complex solutions create the illusion of all three divs being the same height (which is arguably better than setting fixed heights), but that complexity can be difficult to scale and repeat if you need to perform similar tasks throughout your site or your application. The easiest way to get the functionality you want and the simplicity you need: The jQuery equalHeights plugin!

With a few class declarations in your existing HTML, you get the results you want, and with equalHeights, you can also specify the minimum and maximum parameters so it will create scrollable divs if the tallest element happens to be higher than your specified maximum.

How to Use jQuery equalHeights

First and foremost, include your JQuery lirbraries in the <HEAD> of your document:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.0/jquery.min.js"></script>
<script language="javascript" type="text/javascript" src="jquery.equalheights.js"></script>

The equalHeights plugin is not a hosted library, so you have to host the file on your server (here's the link again).

With the required libraries called in our document, it's time to make the magic happen in your HTML.

Create Your Divs

<div class="divHeight">This DIV is medium sized, not too big and not too small, but just right.</div>
<div class="divHeight">This DIV has a lot of useful content and media that the user can interact with, thus it's very tall.</div>
<div class="divHeight">This DIV is tiny. Period.</div>

To have them line up next to each other, you'd have them float:left; in your CSS, and now you need to apply the equalHeights function.

Call the equalHeights Plugin
In order for the script to recognize the height of the tallest element, you'd need to call $(document).ready just before the </body> tag on your page. This will ensure that the page loads before the function runs.

The call looks like this:

<script type="text/javascript">$(document).ready(function() {
$(".divHeight").equalHeights();
});</script>

If you want to specify a minimum and maximum (i.e. The div should be at least this tall and should be no taller than [adds scrollbar if the div size exceeds] the maximum), just add the parameters:

<script type="text/javascript">$(document).ready(function() {
$(".divHeight").equalHeights(300, 600);
});</script>

The initial call does not change the appearance of the divs, but the time it takes to do the resizing is so miniscule that users will never notice. After that call is made and the height is returned, each div with the class of divHeight will inherit the the same height, and your divs will be nice and pretty:

JQuery Tutorial

This trick saved me a lot of headache and frustration, so hopefully it will do the same for you too!

-Cassandra

August 31, 2012

The Dragon SLayers

It's been a couple weeks since we last posted blog post featuring what SLayers are doing outside the office, so I thought I'd share my experience from a couple months ago when SoftLayer competed in the 2012 Annual DFW Dragon Boat Festival. As you may remember, Cassandra posted about SoftLayer's participation in the Houston-area Dragon Boat Festival, so I'm taking it upon myself to share the Dallas experience.

Let me start off by admitting to you that I'm no expert when it comes to dragon boat racing. In fact, when I was asked to join the team, I was reluctant ... I'd never done anything like a dragon boat competition before, and I didn't want to make a fool of myself. It took a bit of convincing from my coworkers, but I ended up signing on to represent SoftLayer as one of the twenty people in our boat.

As it turns out, I wasn't the only rookie. In fact, this was the first year we've had a boat full of newbies, so we all learned the ropes (or oars) of dragon boat racing together. We had practice on Home Depot buckets in the hallway for about two weeks before we actually hit the water, and by the time our on-the-water practice came, we already had a good feel for the basics of the race. Until then, I had no idea how small the boat was and how soaked we'd get while we were paddling. What had I gotten myself into?

My son was home from college over the race weekend, so I managed to get him signed him up as a backup rower. When we got to the lake, the SLayers were all very noticeable ... Our team was sporting the "Dragon SLayer" shirts, and the SoftLayer tent was abuzz with activity. There were other big companies there like AT&T, Sprint, the Dallas SWAT team, Penny's and Samsung, but we weren't intimidated — even when the other teams started talking smack when we broke out our Home Depot buckets to get some last-minute practice.

When we set sail — er... paddle — we were nervous. The gun sounded, and in a flurry of synchronized rowing, we found ourselves at the finish before everyone else in our heat. First race, first place. Obviously, we were excited by that outcome, so we were probably even more antsy when it came time to run the second race. We piled into the boat, made our way to the starting line, and after another flurry of activity, we won the second race! We were in the finals.

You can probably guess what happened next:

We won it all!

In the video, you can see that we started out slow but came from behind to take the victory (The video gets better at the end of the race). The eagle eyes in the audience will probably also notice that we rowed so hard that the dragon head came off of the boat.

Our practice on the Home Depot cans turned out to be pretty effective. My son Jeremy wound up playing a key role on the boat — the drummer — and he headed back to college with quite a story to tell his friends. All of the SLayers stuck around to accept our trophy, and we made sure to snap a few pictures:

I am proud to call myself a SLayer (and a Dragon SLayer)!

-Fabrienne

Categories: 
August 29, 2012

Demystifying Social Media: Get Involved

A few weeks back, Kevin handed me The Thank You Economy by Gary Vaynerchuk and said we should give it a read. I'm only halfway through it, but I thought I should share some of Vaynerchuk's insights on social media with the SoftLayer blog audience while they are still fresh in my mind.

The best summary of The Thank You Economy comes straight from its pages:

"The Thank You Economy explains how businesses must learn to adapt their marketing strategies to take advantage of platforms that have completely transformed consumer culture and society as a whole."

The book looks at how human nature hasn't changed, but everything else has. The rise of social media is as game-changing as the radio and the television were, and that presents a combination of challenge and opportunity for businesses. In Vaynerchuk's words, "What we call social media is not media, nor is it even a platform. It is a massive cultural shift that has profoundly affected the way society uses the greatest platform ever invented, the Internet."

I've been "in the trenches" with SoftLayer's social media presences for over a year now, and I realized that I take advantage of the fundamental openness of the company. Vaynerchuk urges businesses to dive into social media, and he shares some of most common reasons companies aren't getting involved — I could list all eleven reasons here, but you'd probably recognize them all as excuses you've heard.* The common theme: People (and companies) fear uncertainty, and while that fear is understandable, it shouldn't be paralyzing. The opportunity and necessity of engagement outweigh the excuses.

When you clear all the hurdles preventing your entrance to the world of social media, you need to execute. Vaynerchuk explains how "Cultural Building Blocks" of a company dictate that company's success in social media, and while they aren't exactly an Easy Bake Oven recipe to viral success, they are profound in their simplicity:

  1. Begin with Yourself
  2. Commit Whole Hog
  3. Set the Tone
  4. Invest in Employees
  5. Trust Your People
  6. Be Authentic

The "trust your people" and "be authentic" building blocks resonated the most when I thought of how SoftLayer's social media is managed. The level of trust my boss has in me is both refreshing and challenging, and I find myself working harder to prove I deserve it. A cynic might read that sentence and scoff at its over-the-top positivity, but I'm as honest as I can be ... And that's an example of the challenge of being authentic. SoftLayer employees are passionate about their responsibilities and the company culture, and that kind of enthusiasm is so rare that there's a tendency to assume that it's manufactured.

If I see someone talking to us via social media about a bad experience at SoftLayer, I'm more concerned about changing their experience than I am about what they share with their social network. Often, when I follow up with those customers, when the problem is resolved, it's amazing how surprised people are that someone actually took the time to make things right. I want to hear if someone has a bad experience because I take pride in turning it around. Are we "in control" of what people say about SoftLayer on social media? No. We are in control of how SoftLayer responds to what people are saying about us, though.

Your business needs to be active in social media.

You don't need a "social media team" or a budget or a strategy ... You need to be passionate about your employees, customers and products, and you need to make time to reach out to your community — wherever they are.

What roadblocks have you run into when it comes to your business's social media engagement? If you've been successful, what tips could you share with me (and the rest of the SoftLayer audience)?

-Rachel

*If you're toying with the idea of social media engagement or you're working for a company that hasn't embraced it yet, it's worth it for you to buy The Thank You Economy to read how @garyvee dismantles those excuses.

August 27, 2012

IPv4 v. IPv6 - What's the Difference?

About a year ago, Phil Jackson and I recorded a podcast-esque click-through of a presentation that explained the difference between IPv4 and IPv6 address space, and as a testament to the long-tail nature of blog posts, Internet Society's Deploy360 Blog shared the video. With a hint of nostalgia, I clicked "play" on the video.

I laughed. I cried. I found it informative. I noticed a few places where it could have been better.

We recorded the video in response to a tweet from one of our Twitter followers, and the off-the-cuff dialog wound up being somewhere in between "accessible, informative and funny" and "overly detailed, too long and obviously improvised." Because there aren't many people who want to listen to two guys give a 15-minute presentation on IP addresses when they could be watching a Songified review of Five Guys Burgers and Fries or an epic data center tour, I thought I'd dilute the information from the video into a quick blog post that spells out some of the major distinctions between IPv4 and IPv6 so you can scan it, interject your own "witty" banter and have your favorite YouTube viral video playing in the background.

IP Address Overview

An IP address is like a telephone number or a street address. When you connect to the Internet, your device (computer, smartphone, tablet) is assigned an IP address, and any site you visit has an IP address. The IP addressing system we've been using since the birth of the Internet is called IPv4, and the new addressing system is called IPv6. The reason we have to supplement the IPv4 address system (and ultimately eclipse it) with IPv6 is because the Internet is running out of available IPv4 address space, and IPv6 provides is an exponentially larger pool of IP addresses ... Let's look at the numbers:

  • Total IPv4 Space: 4,294,967,296 addresses
  • Total IPv6 Space: 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses

Even saying the IPv6 space is "exponentially larger" doesn't really paint the picture of the difference in size.

IPv4 Addresses

To understand why the IPv4 address space is limited to four billion addresses, we can break down an IPv4 address. An IPv4 address is a 32-bit number made up of four octets (8-bit numbers) in decimal notation, separated by periods. A bit can either be a 1 or a 0 (2 possibilities), so the decimal notation of an octet would have 28 distinct possibilities — 256 of them, to be exact. Because we start numbering at 0, the possible values of one an octet in an IPv4 address go from 0 to 255.

Examples of IPv4 Addresses: 192.168.0.1, 66.228.118.51, 173.194.33.16

If an IPv4 address is made up of four sections with 256 possibilities in each section, to find the total number of possibilities in the entire IPv4 pool, you'd just multiply 256*256*256*256 to get to the 4,294,967,296 number. To look at it another way, you've got 32 bits, so 232 will get you to the same total.

IPv6 Addresses

IPv6 addresses are based on 128 bits. Using the same math as above, we can take 2128 and find the total IPv6 address pool (which I won't copy again here because it takes up too much space). Because the IPv6 pool is so much larger than the IPv4 pool, it'd be much more difficult to define the space in the same decimal notation ... you'd have 232 possibilities in each section.

To allow for that massive IPv6 pool to be used a little more easily, IPv6 addresses are broken down into eight 16-bit sections, separated by colons. Because each section is 16 bits, it can have 216 variations (65,536 distinct possibilities). Using decimal numbers between 0 and 65,535 would still be pretty long-winded, so IPv6 addresses are expressed with hexadecimal notation (16 different characters: 0-9 and a-f).

Example of an IPv6 Addresses: 2607:f0d0:4545:3:200:f8ff:fe21:67cf

That's still a mouthful, but it's a little more manageable than the decimal alternatives.

CIDR Slash (/) Notation

When people talk about blocks of IP addresses, they generally use CIDR Slash (/) Notation where the block might look like this: 192.0.2.0/24 ... When you glance at that number, you might assume, "Okay, so you have 192.0.2.0 through 192.0.2.24," but CIDR notation is not showing you the range of addresses, it's telling you the size of the "network" part of the allocation.

IP addresses are made up two parts — the network and the host. The "network" part of the address tells us the number of bits that stay the same at the beginning of the block of IPs, while the "host" part of the address are the bits that define the different possibilities of IP addresses in the block. In CIDR notation, a /24 is telling us that the first 24 bits of the address are defined by the network, so we have 8 bits (32 total bits minus 24 network bits) in the host — 28 is 256 distinct addresses. The 192.0.2.0/24 IPv4 address block includes 192.0.2.0 to 192.0.2.255.

IPv4 address blocks can be as large as a /8 (given to regional registries like ARIN and APNIC), and they can be as small as a /32 (which is a single IP address).

Why Provision So Many IPv6 Addresses?

When SoftLayer provisions an IPv6 address block on a server, we give a /64 block of IPv6 addresses ... Or 18,446,744,073,709,551,616 IPv6 addresses to each server. That number seems excessive, but the /64 block size is the "smallest" IPv6 allocation block.

Providers like SoftLayer are allocated /32 blocks of IPv6 addresses. The difference between a /32 and a /64 is 32 bits (232) ... Bonus points if you can remember where you've seen that number before. What that means is that SoftLayer is given a block of IP addresses so large that we could provision 4,294,967,296 /64 blocks of IPv6 addresses ... Or put more remarkably: In one /32 block of IPv6 space, there are the same number of /64 blocks of IPv6 addresses as there are TOTAL IPv4 addresses.

So while it's pretty impossible to use a full /64 of IPv6 addresses on a server, it's equally difficult for SoftLayer to burn through its /32 block.

So Now What?

IPv4 space is running out quickly. If your site isn't running a dual-stack IPv6 configuration yet, it's possible that you're going to start missing traffic from users who are only able to access the Internet over IPv6 (which is not backwards compatible with IPv4). If your Internet Service Provider (ISP) doesn't support IPv6 yet, you won't be able to access websites that are broadcast only with IPv6 addresses.

The percentage of instances of each of those cases is relatively small, but it's only going to get larger ... And it only takes one missed customer to make you regret not taking the steps to incorporate IPv6 into your infrastructure.

-@khazard

Pages

Subscribe to news