Posts Tagged 'Facts'

November 4, 2011

Top 10 SoftLayer Facts

At conferences and tradeshows, I have the opportunity to meet hundreds of people. While a good number of attendees at technical conferences will come up to our booth and tell me they're already customers, we still come across a few people who glance at our collateral and our graphics with a puzzled look on their face before they say, "What's Soft ... Layer?" This is where I spring into action!

To give some context, I'll usually explain, "SoftLayer is an on-demand data center provider. We host dedicated servers, cloud computing instances and integrated solutions for customers around the world." When that overview sinks in and the attendee understands that we are an infrastructure provider, I get to share some of SoftLayer's biggest differentiators along with some pretty amazing statistics about our business. With a huge sample pool of conversations to pull from, I thought it would be fun to put together a "Top 10" list of the facts that usually impress attendees the most.

The Top 10 SoftLayer Facts

Based on "oohs" and "ahhs" from attendees

  1. No Hidden Fees: Our pricing is listed on our website and is straight-forward.
  2. Huge Product Catalog: SoftLayer offers load balancers, CDN, firewalls, managed services, and storage. If you need something we don't offer, we can usually find a way to make it work.
  3. No Long-Term Contracts: Dedicated servers are offered on a month-to-month basis, and cloud instances are available on a monthly or hourly basis. We have to earn your business every month.
  4. Built By Geeks For Geeks: We offer a fully programmable API that gives you complete control of your server(s) from your own application or system.
  5. Free Private Network Traffic: Every SoftLayer facility is interconnected via our private network. All private network traffic and inbound public network traffic is provided at no charge – We only charge for outbound public network traffic.

The Top 5 are facts that almost always amaze:

  1. Global Network: We have 13 data centers in Dallas, Houston, Seattle, San Jose, Washington, D.C., Amsterdam, and Singapore. We also operate 16 additional network Points of Presence (PoPs) around the world.
  2. Our Business is Strong: SoftLayer has 24,000+ customers in more than 150 countries. We manage more than 100,000 active servers, hosting more than 20 million domains. Oh, and we're doing about $350 million in annual revenue.
  3. Infrastructure On-Demand: Our dedicated servers can be deployed in less than four hours, and cloud instances can be provisioned in less than 15 minutes.
  4. Everything Works Together: Our dedicated servers and cloud instances are fully integrated. You can have a dedicated server in Seattle and a cloud instance in Singapore, and they're both managed by a single industry-leading portal. The fact that they can communicate with each other over SoftLayer's private network is a huge plus there as well.

And the simple fact that impresses people most: *drum roll*

  1. SoftLayer is the largest privately held hosting provider in the world!

Every time I shock attendees with these facts, I can't help but be even more proud of our accomplishments. Let's keep up the good work! We're taking over the world, one data center at a time."

-Natalie

August 5, 2010

Security Myths part 2

Security Myth #4: A hardware firewall will stop the evil hackers from the internet. They also stop viruses and spam emails.

The Facts: A hardware firewall will filter your traffic based on a set of rules. If properly configured, this will certainly harden your system from certain types of attacks. However, if you want to stop intrusion attempts on your server, you probably want to implement brute force protection or intrusion detection (IDS). Most operating systems nowadays include brute force protection in one form or another (although it may not be turned on by default). If you want an IDS, there are several options available. Here at SoftLayer, we offer McAfee Host Intrusion Protection System (or HIPS for short) for Windows systems. This will offer you some additional protection against intrusion attempts, but it is no substitute for a well patched system with strong passwords. This is especially important to know if you contract with an outside agency to configure your firewall for you. It’s easy to delude yourself into a “set it and forget it” attitude toward security. I can’t tell you how many administrators I’ve talked to that have asked “how did I get hacked? I had a firewall!”

The Side Effects:

  • Having a hardware firewall means an additional step to allow access to ports. Can be time consuming.
  • Having a hardware firewall can potentially mean an additional point of failure.
  • Too many rules can mean degraded performance.

Security Myth #5: I run a Unix/Linux based system, so I can’t get hacked.

The Facts: I have seen a fair share of Unix based systems get hacked, simply because the user is unfamiliar with the OS. Running everything from within a control panel is convenient, but make sure you or one of your administrators is familiar with command line access.

The Side Effects:

  • Running a control panel can cause more security holes

Security Myth #6: I have my Wordpress (or other web application) patched to the latest version, so I should be fine.

The Facts: WordPress is a piece of cake to install. You don’t even need to know how to code in HTML. This means you can install it and have it working properly, and still forget to correct your filesystem permissions. You need to make sure that you read the installation documentation and complete all steps. If you just stop reading once the application starts working, you could potentially forget to correct your permissions and someone could gain access as an administrative user. I ran into a situation one time where a user was utilizing a web interface to manage an online marketplace. I was shocked to find out that the link he sent me allowed me in without the use of a password! Make sure that your application doesn’t use the default password or a blank password.

The Side Effects:

  • Having the latest version is great, but make sure you take a 360 degree look around to make sure nothing is out of place

Security Myth #7: I am getting SPAM messages, but I have a firewall.

The Facts: A firewall does not filter SPAM messages. You might look into the free SpamAssassin software that will filter email for potential SPAM. http://spamassassin.apache.org/

July 27, 2010

Security Myths Part 1

The world of IT security is full of partial truths and paranoia - some of which is completely justified. Sometimes, steps are taken that actually are beneficial, but without knowing the reason behind the precautions, many administrators are lulled into a false sense of security. Here are some common misconceptions that I see in action frequently:

Security Myth #1: If I set my password strong enough, my system will be secure.

The Facts: There are many ways to compromise a system. For example: exploitable code on your website, lax filesystem permissions, and publicly accessible services running on your system (such as email or chat). In fact, having a long secure password is often like having a steel security door with retinal scan technology on a grass hut. Don’t get me wrong, having strong passwords is a great thing, but don’t forget to look at the rest of your system!

The Side Effects:

  • Longer passwords take longer to type (obviously).
  • You are more likely to forget a longer password.
  • You are more likely to mistype a longer password (and get locked out).
  • If you force this policy on your end users they are more likely to write the password down (bad).

Security Myth #2: If I replace letters with their corresponding l33t speak numbers (e.g. hello -> h3110), it will make my password more secure.

The Facts: Technically, yes it will make your password more secure, but only marginally. Simple character substitution is a common feature among brute force tools. This will slow down the brute force attack, but your system may still eventually be compromised by a hybrid dictionary attack. You might also consider configuring the brute force protection options on your server.

The Side Effects: There are no side effects - in fact, this is a far greater idea than simply using a dictionary word. However, it is best to also add some additional numbers or letters to throw off brute force tools. Many brute forcers also allow for pre-pending or post-pending a string of numbers (e.g. 123hello or hello123). It is better to place random numbers or characters in the middle of your password so that it is not vulnerable to a dictionary attack (e.g. hagen!23daas). Another alternative to a secure and easy to remember password is make an acronym of a famous phrase or quote. For example: “sticks and stones may break my bones” -> “S&smbMb!$”.

Security Myth #3: If I change the port number for RDP/SSH/Plesk or turn off ping response, my server will be safe.

The Facts: This is the myth of “security through obscurity.” Changing your port number or turning off ping will only reduce attacks from computer worms and extremely lazy hackers. Say for example that you run a website on your server. Anyone who knows the URL of the website can easily find your IP address (by ping or nslookup). Then all they have to do is port scan that IP address (using a port scanning tool such as nmap or SuperScan) to see which ports are open. If your passwords are secure enough, you needn’t worry too much about the brute force attacks from the internet. You should only consider this a secondary safeguard just in case the server happens to have a vulnerable service running on it. Your first priority is making sure your system is properly patched and updated.

The Side Effects:

  • It is very difficult to track or troubleshoot packet loss on servers that have ICMP blocked.
  • Changing ports may confuse your users.
  • You will need to remember to include this port information in any technical support request.
  • Many automated systems or scripts will require custom configuration.
December 7, 2009

Availability with NetScaler VPX and Global Load Balancing

The concept Single Point of Failure refers to the fact that somewhere between your clients and your servers there is a single point that if it fails downtime happens. The SPoF can be the server, the network, or the power grid. The dragon Single Point of Failure is always going to be there stalking you; the idea is to push SPoF far enough out to where you have done the best you can with your ability and budget.

At the server level you could combat SPoF by using redundant power supplies and disks. You can also have redundant servers fronted by a load balancer. One of the benefits when using load balancer technology is that the traffic for an application is spread between multiple app servers. You have the ability to take an app server out of rotation for upgrades and maintenance. When you’re done you bring the server back online, the load balancer notices it UP on the next check and the server is back in service.

Using a NetScaler VPX you can even have two groups of servers—one group which generally answer your queries and another group which usually does something else—with the second group functioning as a backup against all of the primary servers for a service having to be taken down through the Backup Virtual Server function.

Result: no Single Point of Failure for the app servers.

What happens if you are load balancing and have to take the load balancer out of service for upgrades or maintenance? Right, now we’ve moved SPoF up a level. One way to handle this is by using the NetScaler VPX product we have at SoftLayer. A pair of VPX instances (NodeA/NodeB) can be teamed in a failover cluster so that if the primary VPX is taken down (either by human action or because the hardware failed) the secondary VPX will begin answering for the IPs within a few seconds and processing the actions. When you bring NodeA back online it slips into the role of secondary until such time as NodeB fails or is taken down. I will note here that VPX instances do have dependency on certain network resources and that dependency can take both VPX instances down.

Result: Loss of a single VPX is not a Single Point of Failure.

So what’s next? A wide-ranging power failure or general network failure of either the frontend or the backend network could render both of the NetScalers in a city unusable or even the entire facility unusable. This can be worked around by having resources in two cities which are able to process queries for your users and by using the Global Load Balancer product we offer. GLB load balances between the cities using DNS results. A power failure taking down Seattle just means your queries go to Dallas instead. Why not skip the VPX layer and just GLB to the app servers? You could, if you don’t have a need for the other functionalities from the VPX.

Result: no single point of failure at the datacenter level

Having redundant functionality between cities takes planning, it takes work, and it takes funding. You have to consider synchronization of content. The web content is easy. Run something like an rsync from time to time. Synching the database content between machines or across cities is a bit more complicated. I’ve seen some customers use the built-in replication capabilities of their database software while others will do a home-grown process such as having their application servers write to multiple database servers. You also have to consider issues of state for your application. Can your application handle bouncing between cities?

Redundancy planning is not always fun but it is required for serious businesses, even if the answer is ultimately to not do any redundancy. People, hardware and processes will fail. Whether a failure event is a nightmare or just an annoyance depends on your preparation.

December 3, 2009

Hey, I just got an email saying I won a million dollars! *Click* Wait, what just happened to my computer?

This is usually how it starts. Some shady person sends out spam telling people they have one a million dollars or a free laptop or mp3 player with a link a form they need to fill out to claim their prize. Only you don’t win an mp3 player or laptop. You win an infected computer that is now a drone in a much larger botnet. This botnet is either for direct malicious purposes (Denial-of-Service attacks) or indirect malicious purposes (spam, phishing, etc). How do you stop this from happening to you and you becoming “that guy”? Don’t click links in email unless you’re 100% sure who it’s from and what it’s for. That’s the basic rule to remember. Secondly, make sure you have an anti-virus program that’s capable of scanning email and keeping your system protected from malicious browser exploits. Thirdly, (and this should go without being said, but I’m saying it anyways) make sure your computer (and all software) is up-to-date. Sure, there’s the occasional bug and 0-day exploit on up-to-date systems, but there’s a whole slew of exploits and things that can be done to an un-patched system. Keep your systems up-to-date and you reduce the “known” exploits from literally thousands to maybe a few.

Think about this, 80% of the world’s email is considered spam. Of that 80%, the vast majority (more than 75%) is sent using infected computers (drones). If everyone would re-think blindly clicking links in emails and on webpages (social networking sites have a history of people trying to fool users into clicking bad links) then the spammers wouldn’t have drones available to them to send spam. Interesting thought, isn’t it? Let’s stop spam by being smart internet users and denying the “bad guys” the resources they need to send out the spam.

October 7, 2009

GAHAP Revisited. Otherwise titled “Credit Analysts, Statistics, and Common Sense”

From time to time, I have posted about my frustration with GAAP accounting and traditional credit analysis and how it is not friendly to the hosting business model. For a refresher, click here, here, here, here, and here. By GAHAP, I jokingly mean “generally accepted hosting accounting principles.”

Mike Jones came in my office after a frustrating phone call with a credit analyst. They were trying to talk through collateral possibilities. He told me that the credit analyst has a problem because we carry hardly any accounts receivable. The credit analyst wants something that he can collect in case of default. In GAAP (generally accepted accounting principles), accounts receivable is the total amount that you have billed your customers but have not yet collected from them. Common sense hint: the accounts receivable balance won’t pay your bills – they won’t get paid until you collect the cash.

SoftLayer includes this common sense in its business model. Rather than send out invoices and bug people to pay us later, we choose to have our customers pay us in advance of their use of products and services. Many other hosting companies do the same. There are many advantages to this: we save costs that we would incur collecting the cash, we reduce the amount of abusive accounts that would sign up for a few days of malicious activity and never pay us, and it helps facilitate the on-demand billing side of the cloud computing model.
Again, the disadvantage of this practice comes about when trying to educate a set-in-his-ways credit analyst about our business model. Here is the basic gist of a mythical conversation between a credit analyst and a hosting company:

Credit Analyst: “I see you don’t have any accounts receivable to speak of.”

Hosting Company: “I know! Isn’t that great?”

Credit Analyst: “But if you default, what can I collect?”

Hosting Company: “You’d simply continue to bill the customers for their continued business. Because our customer agreement is month-to-month, you just collect for their next month of service over the next 30 days and you’ve essentially done the same as collect receivables. In fact, that is far easier than collecting past due receivables. We’d be happy place the anticipated next month billing to our customers on the balance sheet in an accounts receivable type of account, but GAAP does not allow this.”

Credit Analyst: “Oh my…you don’t have long term contracts? So all of your customers could leave at once? Isn’t that risky?”

Hosting Company: “We have several thousand customers who trust us with mission critical needs. They will not all leave at once. Our statistics show only a very low percentage of customers terminate services each month. Even through the depths of the recession, we had more new customers joining us than we had customers leaving.”

Credit Analyst: “But conceptually, they could all leave at once since they have no contracts.”

Hosting Company: “That is statistically impossible. The odds of that event are so low that it’s immeasurable. As I said, we provide mission critical services to our customers. To think that they will all no longer need these services simultaneously is paranoid. And if they did, would a contract keep them paying us? That’s doubtful. Let me ask you – do you lend to the electric company or the phone company?”

Credit Analyst: “Of course.”

Hosting Company: “Do their customers sign long term contracts?”

Credit Analyst: “Some do for special promotions. But for the most part – no.”

Hosting Company: “So why do you lend to them?”

Credit Analyst: “Why, the customers can’t live without electricity or phones. That’s a no brainer.”

Hosting Company: “It is exactly the same with our business. In this information age economy, our customers cannot live without the hosting services that we provide. You should look at us in a similar way that you look at a utility company.”

Credit Analyst: “But we classify your business as a technology company. Can’t you just have your customers sign contracts?”

Hosting Company: “Well, wouldn’t that conflict with the on-demand, measured billing aspects of cloud computing?”

Credit Analyst: “I guess there’s not much hope of you building up a sizeable accounts receivable balance then.”

Hosting Company: “It really makes no sense for us to do that.”

Credit Analyst: “We may not be able to do business with you. Do you have any real estate?”

Conclusion: Most credit analysts are so wrapped up in GAAP that they’ve forgotten the laws of statistics and many have even lost touch with common sense. Is it any wonder we’ve had a big banking crisis over the past couple of years?

August 26, 2009

Cool Tool: nslookup

If you've been around the Internet awhile you've probably heard of the Domain Name Service. DNS is what takes www.domain.com and turns it into the 1.2.3.4 IP address which your application actually uses to find the server hosting www.domain.com.

Fascinating, Michael, why do I care? Well if you ask that question you've never had DNS fail on you.

When name resolution goes on the blink one of the tools that support uses to see what is going is the command-line utility nslookup. In its most basic form nslookup is going to do an A record query for the string you supply as an argument and it'll send that query to your operating system's configured resolvers.


C:\>nslookup www.softlayer.com
Server: mydns.local
Address: 192.168.0.1

 


Non-authoritative answer:
Name: www.softlayer.com
Address: 66.228.118.51


What is the utility telling us? First off, it asked a resolver at 192.168.0.1 for the information. Non-authoritative answer means that the server which returned the answer (192.168.0.1) is not the nameserver which controls softlayer.com. It then gives the IP address or addresses which were found.



C:\>nslookup -q=mx softlayer.com ns1.softlayer.com
Server: ns1.softlayer.com
Address: 67.228.254.4


softlayer.com MX preference = 20, mail exchanger = mx02.softlayer.com
softlayer.com MX preference = 30, mail exchanger = mx03.softlayer.com
softlayer.com MX preference = 10, mail exchanger = mx01.softlayer.com
softlayer.com nameserver = ns2.softlayer.net
softlayer.com nameserver = ns1.softlayer.net

 


This is a slightly different query. Rather than asking my local resolver to do an A record query for www.softlayer.com I've sent an MX (mail exchanger) query for softlayer.com directly to the nameserver ns1.softlayer.com. Notice that the response does not have the non-authoritative tag. The server ns1.softlayer.com is one of the nameservers which is configured to respond with a definite answer to a question rather than just saying "well, this other guy said...".

One thing that both of these queries fail to do is show the TTL for the answer they give. Time to Live (TTL) is what generally controls how long a resolver will keep an answer in cache. While the TTL is valid the resolver will use that answer. Once the TTL expires, the resolver goes looking for a fresh answer. This is great for performance but it does have a dark side to it: because of TTL, changes to DNS records are not seen instantly by all clients. If ClientA hits your website often his resolver is going to have the query result cached (say www.domain.com -> 1.2.3.4). You change the record to www.domain.com -> 5.6.7.8 but ClientA's resolver is going to continue to respond with 1.2.3.4 until the TTL runs out. If ClientA controls their resolver they can flush its cache. Generally though it is controlled by their ISP and you just have to wait.

To see the TTL for an answer you can use the nslookup form below:



C:\>nslookup
Default Server: mydns.local
Address: 192.168.5.1

 


> set debug
> www.softlayer.com.
Server: mydns.local
Address: 192.168.5.1


------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 2, additional = 0


QUESTIONS:
www.softlayer.com, type = A, class = IN
ANSWERS:
-> www.softlayer.com
internet address = 66.228.118.51
ttl = 86400 (1 day)
AUTHORITY RECORDS:
-> softlayer.com
nameserver = ns1.softlayer.net
ttl = 86400 (1 day)
-> softlayer.com
nameserver = ns2.softlayer.net
ttl = 86400 (1 day)


------------
Non-authoritative answer:
Name: www.softlayer.com
Address: 66.228.118.51


The key to this spew is 'set debug' which causes nslookup to display additional information about the response, including the TTL value of the answer. You'll notice that the TTL in the ANSWERS section is 86400 seconds, which is the number of seconds in one day. This is a common TTL value. If I run the query again though, I have the following answers section:



ANSWERS:
-> www.softlayer.com
internet address = 66.228.118.51
ttl = 85802 (23 hours 50 mins 2

 


Notice how the TTL is counting down. The resolver is going to continue responding with the answer 66.228.118.51 until that TTL hits zero. At zero, the resolver will go looking for a new answer. What this means for you as a domain operator is that if you know you're going to be changing a record you should adjust down the TTL for that record a couple of days in advance. For example when some friends and I moved our colo server from one provider to another we dropped the TTLs for our DNS records down to 30 minutes two days prior to the move. Once the move was complete we were able to put them back to prior values.

 

If you spend any time at all messing with DNS you should play around with nslookup.

If you're on a Unix system take a look at the command 'dig' as well.

Happy resolving.

April 2, 2009

We Need New Small Businesses

It is often said that small business is the backbone of our economy. According to the U.S. Small Business Administration, small business employs half of all private sector employees. Over the past decade, small business has produced between 60 and 80 percent of net new jobs. We need small businesses to prosper and lead us out of the economic mess in which we find ourselves.

I track growth in domain names every week. I think it indicates how quickly new small businesses are being formed. After all, what business can you think of today (large or small) that does not have some sort of web site? I can’t think of any. One of the things on any small business start up checklist today is the web site. Hence, most all of them register a domain name.

So what’s been happening with growth in domain names? Lately, it’s not too pretty.

Chart

With all the talk lately about stimulating the economy, one of the best ways to do this would be to encourage the formation of new businesses.

Some would argue that we need to fix the credit market mess to help banks be able to lend to small business startups. This couldn’t be further from the truth. How many small businesses do you know that started with a commercial loan from a bank? I cynically say that banks do not want to loan to businesses until the business can survive without need of a bank, and that was true even before the credit crisis. This was certainly true in SoftLayer’s case – when the founders were preparing for launch in late 2005, there wasn’t a bank anywhere that would touch the SoftLayer business plan. What I’m saying is that the credit crisis isn’t that much of a barrier to small business startups. Passionate entrepreneurs will find a way to get going.

But all the passion to start one’s own business doesn’t go very far in the face of the real barriers to starting a business. One of the real barriers that an entrepreneur must overcome is tax issues. Do they begin as a sole proprietor? A partnership? An LLC? An “S” Corp? Should they incorporate? All of them have different tax implications. All of them have to deal with either income taxes at the personal level or corporate level. Some have to deal with self-employment taxes. Others must deal with 941 taxes. Then there are state and local tax issues, such as the margin tax if you’re in Texas. And don’t forget sales taxes and property taxes either.

One of the strategies that allowed the Internet to cement itself in our society during the 1990’s was this: just let it develop without taxing it. Without that burden, the Internet took off like wildfire.

Ergo, if we’d like a bunch of new small businesses to get going, let’s ease up on the tax burden on new startups. This would cost the government hardly any money at all. Think about it – businesses that don’t yet exist do not pay any taxes. Workers that are not yet employed do not pay any taxes. Currently unemployed workers do not pay income taxes, except for a pittance on unemployment benefits. So allowing new businesses to form and employ workers and transact business “tax-free” for a defined start-up period would produce an EXPLOSION of small business startups.

How long should this tax free period be? Per the SBA, if a new business survives 4 years, they have a great shot at surviving long term. So why not give all new business startups a tax holiday for four years as they establish themselves? Can you imagine how big the tax base would grow as these healthy, strong 4-year- old businesses begin paying taxes?

It seems that the biggest issue facing our new President and his administration is how to pay for all the things they’d like to do. Let me suggest that expanding the tax base is the best way to grow government revenues, as opposed to increasing the rates on the current tax base. Allowing a flood of new businesses to take root and grow our tax base may be the best way to fund our growing public budgets.

Naturally, SoftLayer would be more than happy to assist these new businesses with our enterprise class data center outsourcing services so that the new businesses focus on their business plan – not their IT overhead.

Subscribe to facts