Posts Tagged 'Customer'

October 28, 2014

SoftLayer and AWS: What's the Difference?

People often compare SoftLayer with Amazon Web Services (AWS).

It’s easy to understand why. We’ve both built scalable infrastructure platforms to provide cloud resources to the same broad range of customers—from individual entrepreneurs to the world’s largest enterprises.

But while the desire to compare is understandable, the comparison itself isn’t quite apt. The SoftLayer platform is fundamentally different from AWS.

In fact, AWS could be run on SoftLayer. SoftLayer couldn’t be run on AWS.

AWS provisions in the public cloud.

When AWS started letting customers have virtual machines deployed on the infrastructure that AWS had built for their e-commerce business, AWS accelerated the adoption of virtual server hosting within the existing world of Web hosting.

In an AWS cloud environment, customers order the computing and storage resources they need, and AWS deploys those resources on demand. The mechanics of that deployment are important to note, though.

AWS has data centers full of physical servers that are integrated with each other in a massive public cloud environment. These servers are managed and maintained by AWS, and they collectively make up the available cloud infrastructure in the facility.

AWS installs a virtualization layer (also known as hypervisor) on these physical servers to tie the individual nodes into the environment’s total capacity. When a customer orders a cloud server from AWS, this virtualization layer finds a node with the requested resources available and provisions a server image with the customer’s desired operating system, applications, etc. The entire process is quick and automated, and each customer has complete control over the resources he or she ordered.

That virtualization layer is serving a purpose, and it may seem insignificant, but it highlights a critical difference in their platform and ours:

AWS automates and provisions at the hypervisor level, while SoftLayer automates and provisions at the data center level.

SoftLayer provisions down to bare metal resources.

While many have their sights on beating AWS at its own game, SoftLayer plays a different game.

SoftLayer platform is designed to give customers complete access and control over the actual infrastructure that they need to build a solution in the cloud. Automated and remote ordering, deployment, and management of the very server, storage, and security hardware resources themselves, are hosted in our data centers so that customers don’t have to build their own facilities or purchase their own hardware to get the reliable, high performance computing they need.

Everything in SoftLayer data centers is transparent, automated, integrated, and built on an open API that customers can access directly. Every server is connected to three distinct physical networks so that public, private, and management network traffic are segmented. And our expert technical support is available for all customers, 24x7.

Notice that the automation and integration of our platform happens at the data center level. We don’t need a virtualization layer to deploy our cloud resources. As a result, we can deploy bare metal servers in the same way AWS deploys public cloud servers (though, admittedly, bare metal servers take more time to deploy than virtual servers in the public cloud). By provisioning down to a lower level in the infrastructure stack, we’re able to offer customers more choice and control in their cloud environments:

In addition to the control customers have over infrastructure resources, with our unique network architecture, their servers aren’t isolated inside the four walls of a single data center. Customers can order one server in Dallas and another in Hong Kong, and those two servers can communicate with each other directly and freely across our private network without interfering with customers’ public network traffic. So with every new data center we build, we geographically expand a unified cloud footprint. No regions. No software-defined virtual networks. No isolation.

SoftLayer vs. AWS

Parts of our cloud business certainly compete with AWS. When users compare virtual servers between us, they encounter a number of similarities. But this post isn’t about comparing and contrasting offerings in the areas in which we’re similar … it’s about explaining how we’re different:
  • SoftLayer is able to provision bare metal resources to customers. This allows customers free reign over the raw compute power of a specific server configuration. This saves the customer from the 2–3 percent performance hit from the hypervisor, and it prevents “noisy neighbors” from being provisioned alongside a customer’s virtual server. AWS does not provision bare metal resources.

  • AWS differentiates “availability zones” and “regions” for customers who want to expand their cloud infrastructure into multiple locations. SoftLayer has data centers interconnected on a global private network. Customers can select the specific SoftLayer data center location they want so they can provision servers in the exact location they desire.

  • When AWS customers move data between their AWS servers, they see “Inter-Region Data Transfer Out” and “Intra-Region Data Transfer” on their bills. If you’re moving data from one SoftLayer facility to another SoftLayer facility (anywhere in the world), that transfer is free and unmetered. And it doesn’t fight your public traffic for bandwidth.

  • SoftLayer bare metal servers ordered with monthly billing include 20TB/mo of public outbound bandwidth, and virtual servers ordered with monthly billing include 5TB/mo of public outbound bandwidth. With AWS, customers pay a per-GB charge for bandwidth on every bill.

  • SoftLayer offers a broad range of management, monitoring, and support options to customers at no additional cost. AWS charges for monitoring based on metrics, frequency, and number of alarms per resource. And having access to support requires an additional monthly cost.

Do SoftLayer and AWS both offer Infrastructure as a Service? Yes.

Does that make SoftLayer and AWS the same? No.

-@khazard

June 30, 2014

OpenNebula 4.8: SoftLayer Integration

In the next month, the team of talented developers at C12G Labs will be rolling out OpenNebula 4.8, and in that release, they will be adding integration with SoftLayer! If you aren't familiar with OpenNebula, it's a full-featured open-source platform designed to bring simplicity to managing private and hybrid cloud environments. Using a combination of existing virtualization technologies with advanced features for multi-tenancy, automatic provisioning, and elasticity, OpenNebula is driven to meet the real needs of sysadmins and devops.

In OpenNebula 4.8, users can quickly and seamlessly provision and manage SoftLayer cloud infrastructure through OpenNebula's simple, flexible interface. From a single pane of glass, you can create virtual data center environments, configure and adjust cloud resources, and automatic execution and scaling of multi-tiered applications. If you don't want to leave the command line, you can access the same functionality from a powerful CLI tool or through the OpenNebula API.

When the C12G Labs team approached us with the opportunity to be featured in the next release of their platform, several folks from the office were happy to contribute their time to make the integration as seamless as possible. Some of our largest customers have already begun using OpenNebula to manage their hybrid cloud environments, so official support for the SoftLayer cloud in OpenNebula is a huge benefit to them (and to us). The result of this collaboration will be released under the Apache license, and as such, it will be freely available to the public.

To give you an idea of how easy OpenNebula is to use, they created an animated GIF to show the process of creating and powering down virtual machines, creating a server image, and managing account settings:

OpenNebula

We'd like to give a big shout-out to the C12G Labs team for all of the great work they've done on the newest version of OpenNebula, and we look forward to seeing how the platform continues to grow and improve in the future.

-@khazard

Categories: 
August 19, 2013

The 5 Mortal Sins of Launching a Social Game

Social network games have revolutionized the gaming industry and created an impressive footprint on the Web as a whole. 235 million people play games on Facebook every month, and some estimates say that by 2014, more than one third of Internet population will be playing social games. Given that market, it's no wonder that the vast majority of game studios, small or big, have prioritized games to be played on Facebook, Orkut, StudiVZ, VK and other social networks.

Developing and launching a game in general is not an easy task. It takes a lot of time, a lot of people, a lot of planning and a lot of assumptions. On top of those operational challenges, the social gaming market is a jungle where "survival of the fittest" is a very, VERY visible reality: One day everyone is growing tomatoes, the next they are bad guys taking over a city, and the next they are crushing candies. An army of genius developers with the most stunning designs and super-engaging game ideas can find it difficult to navigate the fickle social waters, but in the midst of all of that uncertainty, the most successful gaming studios have all avoided five of the most common mortal sins gaming companies commit when launching a social game.

SoftLayer isn't gaming studio, and we don't have any blockbuster games of our own, but we support some of the most creative and successful gaming companies in the world, so we have a ton of indirect experience and perspective on the market. In fact, leading up to GDC Europe, I was speaking with a few of the brilliant people from KUULUU — an interactive entertainment company that creates social games for leading artists, celebrities and communities — about a new Facebook game they've been working on called LINKIN PARK RECHARGE:

After learning a more about how Kuuluu streamlines the process of developing and launching a new title, I started thinking about the market in general and the common mistakes most game developers make when they release a social game. So without further ado...

The 5 Mortal Sins of Launching a Social Game

1. Infinite Focus

Treat focus as limited resource. If it helps, look at your team's cumulative capacity to focus as though it's a single cube. To dedicate focus to different parts of the game or application, you'll need to slice the cube. The more pieces you create, the thinner the slices will be, and you'll be devoting less focus to the most important pieces (which often results in worse quality). If you're diverting a significant amount of attention from building out the game's story line to perfecting the textures of a character's hair or the grass on the ground, you'll wind up with an aesthetically beautiful game that no one wants to play. Of course that example is an extreme, but it's not uncommon for game developers to fall into a less blatant trap like spending time building and managing hosting infrastructure that could better be spent tweaking and improving in-game performance.

2. Eeny, Meeny, Miny, Moe – Geographic Targeting

Don't underestimate the power of the Internet and its social and viral drivers. You might believe your game will take off in Germany, but when you're publishing to a global social network, you need to be able to respond if your game becomes hugely popular in Seoul. A few enthusiastic Tweets or wall post from the alpha-players in Korea might be the catalyst that takes your user base in the region from 1000 to 80,000 overnight to 2,000,000 in a week. With that boom in demand, you need to have the flexibility to supply that new market with the best quality service ... And having your entire infrastructure in a single facility in Europe won't make for the best user experience in Asia. Keep an eye on the traction your game has in various regions and geolocate your content closer to the markets where you're seeing the most success.

3. They Love Us, so They'll Forgive Us.

Often, a game's success can lure gaming companies into a false sense of security. Think about it in terms of the point above: 2,000,000 Koreans are trying to play your game a week after a great article is published about you, but you don't make any changes to serve that unexpected audience. What happens? Players time out, latency drags the performance of your game to a crawl, and 2,000,000 users are clicking away to play one of the other 10,000 games on Facebook or 160,000 games in a mobile appstore. Gamers are fickle, and they demand high performance. If they experience anything less than a seamless experience, they're likely to spend their time and money elsewhere. Obviously, there's a unique balance for every game: A handful of players will be understanding to the fact that you underestimated the amount of incoming requests, that you need time to add extra infrastructure or move it elsewhere to decrease latency, but even those players will get impatient when they experience lag and downtime.

KUULUU took on this challenge in an innovative, automated way. They monitor the performance of all of their games and immediately ramp up infrastructure resources to accommodate growth in demand in specific areas. When demand shifts from one of their games to another, they're able to balance their infrastructure accordingly to deliver the best end-user experience at all times.

4. We Will Be Thiiiiiiiiiiis Successful.

Don't count your chickens before the eggs hatch. You never really, REALLY know how a social game will perform when the viral factor influences a game's popularity so dramatically. Your finite plans and expectations wind up being a list of guestimations and wishes. It's great to be optimistic and have faith in your game, but you should never have to over-commit resources "just in case." If your game takes two months to get the significant traction you expect, the infrastructure you built to meet those expectations will be underutilized for two months. On the other hand, if your game attracts four times as many players as you expected, you risk overburdening your resources as you scramble to build out servers. This uncertainty is one of the biggest drivers to cloud computing, and it leads us to the last mortal sin of launching a social game ...

5. Public Cloud Is the Answer to Everything.

To all those bravados who feel they are the master of cloud and see it as an answer to all their problems please, for your fans sake, remember the cloud has more than one flavor. Virtual instances in a public cloud environment can be provisioned within minutes are awesome for your webservers, but they may not perform well for your databases or processor-intensive requirements. KUULUU chose to incorporate bare metal cloud into a hybrid environment where a combination of virtual and dedicated resources work together to provide incredible results:

LP RECHARGE

Avoiding these five mortal sins doesn't guarantee success for your social game, but at the very least, you'll sidestep a few common landmines. For more information on KUULUU's success with SoftLayer, check out this case study.

-Michalina

May 7, 2013

Tips from the Abuse Department: DMCA Takedown Notices

If you are in the web hosting business or you provide users with access to store content on your servers, chances are that you're familiar with the Digital Millennium Copyright Act (DMCA). If you aren't familiar with it, you certainly should be. All it takes is one client plagiarizing an article or using a filesharing program unscrupulously, and you could find yourself the recipient of a scary DMCA notice from a copyright holder. We've talked before about how to file a DMCA complaint with SoftLayer, but we haven't talked in detail about SoftLayer's role in processing DMCA complaints or what you should do if you find yourself on the receiving end of a copyright infringement notification.

The most important thing to understand when it comes to the way the abuse team handles DMCA complaints is that our procedures aren't just SoftLayer policy — they are the law. Our role in processing copyright complaints is essentially that of a middleman. In order to protect our Safe Harbor status under the Online Copyright Infringement Liability Limitation Act (OCILLA), we must enforce any complaint that meets the legal requirements of a takedown notice. That DMCA complaint must contain specific elements and be properly formatted in order to be considered valid.

Responding to a DMCA Complaint

When we receive a complaint that meets the legal requirements of a DMCA takedown notice, we must relay the complaint to our direct customer and enforce a deadline for removal of the violating material. We are obligated to remove access to infringing content when we are notified about it, and we aren't able to make a determination about the validity of a claim beyond confirming that all DMCA requirements are met.

The law states that SoftLayer must act expeditiously, so if you receive notification of a DMCA complaint, it's important that you acknowledge the ticket that the abuse department opened on your account and let us know your intended course of action. Sometimes that action is as simple as removing an infringing URL. Sometimes you may need to contact your client and instruct them to take the material down. Whatever the case may be, it's important to be responsive and to expressly confirm when you have complied and removed the material. Failure to acknowledge an abuse ticket can result in disconnection of service, and in the case of copyright infringement, SoftLayer has a legal obligation to remove access to the material or we face serious liability.

DMCA Counter Notifications

Most DMCA complaints are resolved without issue, but what happens if you disagree with the complaint? What if you own the material and a disgruntled former business partner is trying to get revenge? What if you wrote the content and the complaining party is copying your website? Thankfully there are penalties for filing a false DMCA complaint, but you also have recourse in the form of a counter notification. Keep in mind that while it may be tempting to plead your case to the abuse department, our role is not to play judge or jury but to allow the process to work as it was designed.

In some cases, you may be able to work out a resolution with the complaining party directly (misunderstandings happen, licenses lapse, etc.) and have them send a retraction, but most of the time your best course of action is to submit a counter notification.

Just as a takedown notice must be crafted in a specific way, counter notifications have their own set of requirements. Once you have disabled the material identified in the original complaint, we can provide your valid, properly formatted counter notification to the complaining party. Unless we receive a court order from the complaining party within the legally mandated time frame the material can be re-enabled and the case is closed for the time being.

While it might sound complicated, it's actually pretty straightforward, but we urge you to do your research and make sure you know what to do in the event a client of yours is hit with a DMCA takedown notice. Just as we are unable to make judgment calls when it comes to takedown notices or counter notifications, we are also unable to offer any legal advice for you if you need help. Hopefully this post cleared up a few questions and misconceptions about how the abuse department handles copyright complaints. In short:

Do take DMCA notifications seriously. You are at risk for service interruption and possible legal liability.
Do respond to the abuse department letting them know the material has been disabled and, if applicable, if you plan to file a counter notification.
Don't refuse to disable the material. Even if you believe the claim is false and you wish to file a counter notification, the material must be disabled within the time period allotted by the abuse department or we have to block access to it.
Don't expect the abuse department to take sides.

As with any abuse issue, communication and responsiveness is important. Disconnecting your server is a last resort, but we have ethical and legal obligations to uphold. The DMCA process certainly has its weaknesses and it leaves a bit to be desired, but at the end of the day, it's the law, and we have to operate inside of our legal obligation to it.

-Jennifer

February 27, 2013

The Three Most Common Hosting-Related Phobias

As a member of the illustrious the SoftLayer sales (SLales) team, I have the daily pleasure of talking with any number of potential, prospective, new and current customers, and in many of those conversations, I've picked up on a fairly common theme: FEAR. Now we're not talking about lachanophobia (fear of vegetables) or nomophobia (fear of losing cell phone contact) here ... We're talking about fear that paralyzes users and holds them captive — effectively preventing their growth and limiting their business's potential. Fear is a disease.

I've created my own little naming convention for the top three most common phobias I hear from users as they consider making changes to their hosting environments:

1. Pessimisobia
This phobia is best summarized by the saying, "Better the devil you know than the devil you don't." Users with this phobia could suffer from frequent downtime, a lack of responsive support and long term commitment contracts, but their service is a known quantity. What if a different provider is even worse? If you don't suffer from pessimisobia, this phobia probably seems silly, but it's very evident in many of the conversations I have.

2. Whizkiditus
This affliction is particularly prevalent in established companies. Symptoms of this phobia include recurring discomfort associated with the thought of learning a new management system or deviating from a platform where users have become experts. There's an efficiency to being comfortable with how a particular platform works, but the ceiling to that efficiency is the platform itself. Users with whizkiditus might not admit it, but the biggest reason they shy away from change is that they are afraid of losing the familiarity they've built with their old systems over the years ... even if that means staying on a platform that prohibits scale and growth.

3. Everythingluenza
In order to illustrate this phobia of compartmentalizing projects to phase in changes, let's look at a little scenario:

I host all of my applications at Company 1. I want to move Application A to the more-qualified Company 2, but if I do that, I'll have to move Applications B through Z to Company 2 also. All of that work would be too time-consuming and cumbersome, so I won't change anything.

It's easy to get overwhelmed when considering a change of cloud hosting for any piece of your business, and it's even more intimidating when you feel like it has to be an "all or nothing" decision.

Unless you are afflicted with euphobia (the fear of hearing good news), you'll be happy to hear that these common fears, once properly diagnosed, are quickly and easily curable on the SoftLayer platform. There are no known side effects from treatment, and patients experience immediate symptom relief with a full recovery in between 1-3 months.

This might be a lighthearted look at some quirky fears, but I don't want to downplay how significant these phobias are to the developers and entrepreneurs that suffer from them. If any of these fears strike a chord with you, reach out to the SLales team (by phone, chat or email), and we'll help you create a treatment plan. Once you address and conquer these fears, you can devote all of your energy back to getting over your selenophobia (fear of the moon).

-Arielle

Categories: 
January 31, 2013

ActiveCampaign: Tech Partner Spotlight

We invite each of our featured SoftLayer Tech Marketplace Partners to contribute a guest post to the SoftLayer Blog, and this week, we're happy to welcome Peter Evans from ActiveCampaign. ActiveCampaign is a complete email marketing and marketing automation platform designed to help small businesses grow.

The Challenge of Sending Email Simply

You need to send email. Usually, that's a pretty simple task, so it's not uncommon to find users who think that sending a monthly newsletter is more or less the same task as sending a quick note to a friend about going to see a movie. In fact, those two email use-cases are completely different animals. With all of the nuances inherent in sending and managing large volumes of email, a plethora of email marketing services are positioned to help users better navigate the email marketing waters. It's tough to differentiate which features you might need and which features are just there to be a "Check" in a comparison checklist. ActiveCampaign set out to make the decision-making process simpler ... We knew that we needed the standard features like auto-responder campaigns, metrics reports and email templates, but we also knew we had to differentiate our service in a meaningful way. So we focused on automation.

Too often, the "automation" provided by a platform can be very cumbersome to set up (if it's available at all), and when it's actually working, there's little confirmation that actions are being performed as expected. In response, we were intentional about ActiveCampaign's automation features being easy to set up and manage ... If automation saves time and money, it shouldn't be intimidatingly difficult to incorporate into your campaigns. Here is a screenshot of what it takes to incorporate automation in your email campaigns with ActiveCampaign:

ActiveCampaign Screenshot

No complicated logic. No unnecessary options. With a only a few clicks, you can select an action to spark a meaningful response in your system. If a subscriber in your Newsletter list clicks on a link, you might want to move that subscriber to a different list. Because you might want to send a different campaign to that user as well, we provide the ability to add multiple automated actions for each subscriber action, and it's all very clear.

One of the subscriber actions that might stand out to you if you've used other email service providers (or ESPs) is the "When subscriber replies to a campaign" bullet. ActiveCampaign is the first ESP (that we're aware of) to provide users the option to send a series of follow-up campaigns (or to restrict the sending of future campaigns) to subscribers who reply to a campaign email. Replies are tracked in your campaign reports, and you have deep visibility into how many people replied, who replied, and how many times they replied. With that information, you can segment those subscribers and create automated actions for them, and the end result is that you're connecting with your subscriber base much more effectively because you're able to target them better ... And you don't have to break your back to do it.

SoftLayer customers know how valuable automation can be in terms of infrastructure, so it should be no surprise that email marketing campaigns can benefit so much from automation as well. Lots of ESPs provide stats, and it's up to you to figure out meaningful ways to use that information. ActiveCampaign goes a step beyond those other providers by helping you very simply engage your subscribers with relevant and intentional actions. If you're interested in learning more, check us out at http://www.activecampaign.com.

-Peter Evans, ActiveCampaign

This guest blog series highlights companies in SoftLayer's Technology Partners Marketplace.
These Partners have built their businesses on the SoftLayer Platform, and we're excited for them to tell their stories. New Partners will be added to the Marketplace each month, so stay tuned for many more come.
August 15, 2012

Managing Support Tickets: Email Subscriptions

This week, the development team rolled out some behind-the-scenes support functionality that I think a lot of our customers will want to take advantage of, so I put together this quick blog post to spread the word about it. With the new release, the support department is able to create "Ticket Email Subscriptions" for different ticket groups on every customer account. As a customer, you might not be jumping up and down with joy after reading that one-sentence description, but after you hear a little more about the functionality, if you're not clapping, I hope you'll at least give us a thumbs-up.

To understand the utility of the new ticket email subscription functionality, let's look at how normal tickets work in the SoftLayer portal without email subscriptions:

User Creates Ticket

  1. User A creates a ticket.
  2. User A becomes the owner of that ticket.
  3. When SoftLayer responds to the ticket, an email notification is sent to User A to let him/her know that the ticket has been updated.

SoftLayer Creates Ticket

  1. SoftLayer team creates a ticket on a customer's account.
  2. The primary customer contact on the account is notified of the new ticket.
  3. Customer logs into the portal and responds to ticket.
  4. Customer gets notifications of updates (as described above).

There's nothing wrong with the existing support notification process, but that doesn't mean there aren't ways to make the process better. What if User A creates an urgent ticket on his/her way out the door to go on vacation? User B and User C aren't notified when an update is posted on User A's ticket, so the other users aren't able to get to the ticket and respond as quickly as they would have if they received the notification. What if the primary customer contact on the account isn't the best person to receive a monitoring alert? The administrator who will investigate the monitoring alert has to see the new ticket on the account or hear about it from the primary contact (who got the notification).

Ticket email subscriptions allow for customers to set contact addresses to be notified when a ticket is created, edited or moved in a particular ticket group. Here are the ticket groups differentiated in our initial release:

  • Billing - Any ticket in our Billing department
  • Maintenance - Scheduled maintenance notifications for specific servers
  • Network Protection - DDoS mitigation and Null Routes
  • Monitoring - Host Down Alerts
  • CST, SysAdmin and Hardware - Any ticket in our support and data center departments
  • Managed Services - Tickets that relate to any managed services
  • Network Maintenance - Scheduled network maintenance

You'll notice that Abuse isn't included in this list, and the only reason it's omitted is because you've always been able to designate a contact on your account for abuse-related tickets ... Ticket subscriptions extend that functionality to other ticket groups.

Because only one email address can be "subscribed" to notifications in each ticket group, we recommend that customers use their own distribution lists as the email contacts. With a DL as the contact, you can enable multiple users in your organization to receive notifications, and you can add and remove users from each distribution list on your end quickly and easily.

When User A creates a ticket with the data center and goes on vacation, as soon as SoftLayer responds to the ticket, User A will be notified (as usual), and the supportsubscription@yourdomain.com distribution will get notified as well. When a network maintenance is ticket is created by SoftLayer, the netmaintsubscription@yourdomain.com distribution will be notified.

Ticket email subscriptions are additive to the current update notification structure, and they are optional. If you want to set up ticket email subscriptions on your account, create a ticket for the support department and provide us with the email addresses you'd like to subscribe to each of the ticket groups.

We hope this tool helps provide an even better customer experience for you ... If you don't mind, I'm going to head back to the lab to work with the dev team to cook up more ways to add flexibility and improvements into the customer experience.

-Chris

June 25, 2012

Tips from the Abuse Department: Part 2 - Responding to Abuse Reports

If you're a SoftLayer customer, you don't want to hear from the Abuse department. We know that. The unfortunate reality when it comes to hosting a server is that compromises can happen, mistakes can be made, and even the most scrupulous reseller can fall victim to a fraudulent sign-up or sly spammer. If someone reports abusive behavior originating from one of your servers on our network, it's important to be able to communicate effectively with the Abuse department and build a healthy working relationship.

Beyond our responsibility to enforce the law and our Acceptable Use Policy, the Abuse department is designed to be a valuable asset for our customers. We'll notify you of all valid complaints (and possibly highlight security vulnerabilities in the process), we'll assist you with blacklist removal, we can serve as a liaison between you and other providers if there are any problems, and if you operate an email-heavy platform or service, we can help you understand the steps you need to take to avoid activity that may be considered abuse.

At the end of the day, if the Abuse department can maintain a good rapport with our customers, both our jobs can be easier, so I thought this installment in the "Tips from the Abuse Department" series could focus on some best practices for corresponding with Abuse from a customer perspective.

Check Your Tickets

This is the easiest, most obvious recommendation I can give. You'd be surprised at how many service interruptions could be avoided if our customers were more proactive about keeping up with their open tickets. Our portal is a vital tool for your business, so make sure you are familiar with how to access and use it.

Keep Your Contact Information Current

Our ticket system will send notifications to the email address you have on file, so making sure this information is correct and current is absolutely crucial, especially if you aren't in the habit of checking the ticket system on a regular basis. You can even set a specific address for abuse notifications to be sent to, so make use of this option. The quicker you can respond to an abuse report, the quicker the complaint can be resolved, and by getting the complaint resolved quickly, you avoid any potential service interruption.

If we are unable to reach you by ticket, we may need to call you, so keep your current phone numbers on file as well.

Provide Frequent Updates

Stay in constant communication in the midst of responding to an abuse report, and adhere to the allotted timeline in the ticket. If we don't see updates that the abusive behavior is being addressed in the grace period we are able to offer, your server is at risk of disconnection. By keeping us posted about the action you're taking and the time you need to resolve the matter, we're able to be more flexible.

If a customer on your servers created a spamming script or a phishing account, taking immediate steps to mitigate the issue by suspending that customer is another great way to respond to the process while you're performing an investigation of how that activity was started. We'll still want a detailed resolution, but if the abuse is not actively ongoing we can work with you on deadlines.

Be Concise ... But Not Too Concise

One-word responses: bad. Page long responses: also not ideal. If given the option we would opt for the latter, but your goal should be to outline the cause and resolution of any reported abusive activity as clearly and succinctly as possible in order to ease communication and expedite closing of the ticket.

Responding to a ticket with, "Fixed," is not sufficient to for the Abuse department to consider the matter resolved, but we also don't need a dump of your entire log file. Before the Abuse team can close a ticket, we have to see details of how the complaint was resolved, so if you don't provide those details in your first response, you can bet we'll keep following up with you to get them. What details do we need?

Take a Comprehensive Approach

In addition to stopping the abusive activity we want to know:

  1. How/why the issue occurred
  2. What steps are being taken to prevent further issues of that nature

We understand that dealing with abuse issues can often feel like a game of Whack-A-Mole, but if you can show that you're digging a bit deeper and taking steps to avoid recurrence, that additional work is very much appreciated. Having the Abuse department consider you a proactive, ethical and responsible customer is a worthy goal.

Be Courteous

I'm ending on a similar note to my last blog post because it's just that important! We understand getting an abuse ticket is a hassle, but please remember that we're doing our best to protect our network, the Internet community and you.

Unplugging your server is a last resort for us, and we want to make sure everyone is on the same page to prevent us from getting to that last resort. In the unfortunate event that you do experience an abuse issue, please refer back to this blog — it just might save you some headaches and perhaps some unnecessary downtime.

-Jennifer

April 23, 2012

Choosing a Cloud: Which Cloud Chooses You?

It's not easy to choose a cloud hosting provider.

In the first post of this series, we talked about the three key deciding factors every cloud customer has to consider, and we set up a Venn diagram to distinguish the surprisingly broad range of unique priorities customers can have:

Cloud Customer Zones

Because every customer will prioritize a cloud's cost, technology and hosting provider a little differently (for completely valid reasons), we mapped out seven distinct "zones" to differentiate some of the basic market segments, or "personas," of cloud hosting buyers. That post was intended to set the stage for a larger discussion on how customers choose their cloud providers and how cloud providers choose their customers, and we're just scratching the surface. We're tackling a pretty big topic here, so as Bill Cosby famously says, "I told you that story to tell you this one."

As a hosting provider, SoftLayer can't expect to be all things for all people. It's impossible to offer a quad-core hex-proc dedicated server for a price that will appeal to a customer in the market for a $49/mo dedicated server.

To better illustrate SoftLayer's vision in the cloud market, we need to take that generic cost v. technology v. hosting provider diagram and give it the "Three Bars" treatment:

SoftLayer Venn Diagram

We're much more interested in living and breathing the Zone 5 "Technology" space rather than the traditional Zone 2 "Hosting Provider" space. That's why in the past two months, you've seen announcements about our launch of the latest Intel Processors, HPC computing with NVidia GPUs, searchable OpenStack Object Storage, and an innovative "Flex Image" approach to bluring the lines between physical and virtual servers. We choose to pursue the cloud customers who make their buying decisions in Zone 3.

That's a challenging pursuit ... It's expensive to push the envelope in technology, customers primarily interested in technology/performance have demanding needs and expectations, and it's easier to make mistakes when you're breaking new ground. The majority of the hosting industry seems to have an eye on the buyer in Zone 1 because they believe the average hosting customer is only interested in the bottom line ... That hosting is more or less a commodity, so the focus should be on some unverifiable qualitative measure of support or the next big special that'll bring in new orders.

As you may have seen recently, GigaOm posted a lovely article that references several high-profile companies in our 25,000+ customer family. We like to say that SoftLayer builds the platform on which our customers build the future, and that short post speaks volumes about the validity of that statement. Our goal is to provide the most powerful, scalable and seamlessly integrated IT infrastructure for the most innovative companies in the world. Innovate or Die isn't just our company motto ... It's our hope for our customers, as well.

We might miss out on your business if you want a $49/mo dedicated server, but if you're looking to change the world, we've got you covered. :-)

-@khazard

April 20, 2012

Choosing a Cloud: Cost v. Technology v. Hosting Provider

If you had to order a new cloud server right now, how would choose it?

I've worked in the hosting industry for the better part of a decade, and I can safely say that I've either observed or been a part of the buying decision for a few thousand hosting customers — from small business owners getting a website online for the first time to established platforms that are now getting tens of millions of visits every day. While each of those purchasers had different requirements and priorities, I've noticed a few key deciding factors that are consistent in a all of those decisions:

The Hosting Decision

How much will the dedicated server or cloud computing instance cost? What configuration/technology do I need (or want)? Which hosting provider should I trust with my business?

Every website administrator of every site on the Internet has had to answer those three questions, and while they seem pretty straightforward, they end up overlapping, and the buying decision starts to get a little more complicated:

The Hosting Decision

The natural assumption is that everyone will choose a dedicated server or cloud computing instance that falls in the "sweet spot" where the three circles overlap, right? While that makes sense on paper, hosting decisions are not made in a vacuum, so you'll actually see completely valid hosting decisions targeting every spot on that graph.

Why would anyone choose an option that wouldn't fit in the sweet spot?

That's a great question, and it's a tough one to answer in broad strokes. Let's break the chart down into a few distinct zones to look at why a user would choose a server in each area:

The Hosting Decision

Zone 1

Buyers choosing a server in Zone 1 are easiest to understand: Their budget takes priority over everything else. They might want to host with a specific provider or have a certain kind of hardware, but their budget doesn't allow for either. Maybe they don't need their site to use the latest and greatest hardware or have it hosted anywhere in particular. Either way, they choose a cloud solely based on whether it fits their budget. After the initial buying decision, if another server needs to be ordered, they might become a Zone 4 buyer.

Zone 2

Just like Zone 1 buyers, Zone 2 buyers are a pretty simple bunch as well. If you're an IT administrator at a huge enterprise that does all of your hosting in-house, your buying decision is more or less made for you. It doesn't matter how much the solution costs, you have to choose an option in your data center, and while you might like a certain technology, you're going to get what's available. Enterprise users aren't the only people deciding to order a server in Zone 2, though ... It's where you see a lot of loyal customers who have the ability to move to another provider but prefer not to — whether it's because they want their next server to be in the same place as their current servers, they value the capabilities of a specific hosting provider (or they just like the witty, interesting blogs that hosting provider writes).

Zone 3

As with Zone 1 and Zone 2, when a zone doesn't have any overlapping areas, the explanation is pretty easy. In Zone 3, the buying decision is being made with a priority on technology. Buyers in this area don't care what it costs or where it's hosted ... They need the fastest, most powerful, most scalable infrastructure on the market. Similar to Zone 1 buyers, once Zone 3 buyers make their initial buying decision, they might shift to Zone 5 for their next server or cloud instance, but we'll get to that in a minute.

Zone 4

Now we're starting to overlap. In Zone 4, a customer will be loyal to a hosting provider as long as that loyalty doesn't take them out of their budget. This is a relatively common customer ... They'll try to compare options apples-to-apples, and they'll make their decision based on which hosting provider they like/trust most. As we mentioned above, if a Zone 1 buyer is adding another server to their initial server order, they'll likely look to add to their environment in one place to make it easier to manage and to get the best performance between the two servers.

Zone 5

Just like the transitional Zone 1 buyers, when Zone 3 buyers look to build on their environment, they'll probably become Zone 5 buyers. When your initial buying decision is based entirely on technology, it's unusual to reinvent the wheel when it comes to your next buying decision. While there are customers that will reevaluate their environment and choose a Zone 3 option irrespective of where their current infrastructure is hosted, it's less common. Zone 5 users love having he latest and greatest technology, and they value being able to manage it through one provider.

Zone 6

A Zone 6 buyer is usually a Zone 1 buyer that has specific technology needs. With all the options on the table, a Zone 6 buyer will choose the cloud environment that provides the latest technology or best performance for their budget, regardless of the hosting provider. As with Zone 1 and Zone 3 buyers, a Zone 6 buyer will probably become a Zone 7 buyer if they need to order another server.

Zone 7

Zone 7 buyers are in the sweet spot. They know the technology they want, they know the price they want to pay, and they know the host they want to use. They're able to value all three of their priorities equally, and they can choose an environment that meets all of their needs. After Zone 6 buyers order their first server(s), they're going to probably become Zone 7 buyers when it comes time for them to place their next order.

As you probably noticed, a lot of transitioning happens between an initial buying decision and a follow-up buying decision, so let's look at that quickly:

The Hosting Decision

Regardless of how you make your initial buying decision, when it's time for your next server or cloud computing instance, you have a new factor to take into account: You already have a cloud infrastructure at a hosting provider, so when it comes time to grow, you'll probably want to grow in the same place. Why? Moving between providers can be a pain, managing environments between several providers is more difficult, and if your servers have to work together, they're generally doing so across the public Internet, so you're not getting the best performance.

Where does SoftLayer fit in all of this? Well beyond being a hosting provider that buyers are choosing, we have to understand buyers are making their buying decisions, and we have to position our business to appeal to the right people with the right priorities. It's impossible to be all things for all people, so we have to choose where to invest our attention ... I'll leave that post for another day, though.

If you had to choose a zone that best describes how you made (or are currently making) your buying decision, which one would it be?

-@khazard

Subscribe to customer