It’s that time again, when everyone who thinks they’re a pundit (that would be everyone with a blog or Twitter account) has to make predictions for the coming year. But predictions are perilous: Get it right and you look like a mere trend-watcher; get it wrong and you look like a fool. It’s such a hassle! So I’m doing something different this year: I’m going to make predictions for 2009 now that it’s over, and reflect on just how smart I am (not) to have made them. Or something.

What I Would Have Gotten Right

I definitely could have predicted a lot of what happened in 2009. I mean, these were slam dunks!

1. Twitter rocks the world – I wasn’t early to Twitter, but I spent the early part of 2009 evangelizing its benefits to companies and co-workers alike. Considering how common Twitter is today, it’s hard to believe how roundly criticized and misunderstood it was this time last year. Yet here we are, on the verge of 2010, and Twitter has seeped onto our business cards, presentation templates, and web sites. I might not have predicted how stable (!) Twitter got by the end of the year, though.
2. Apple’s Macs and iPhones rule – I switched to the iPhone and the Mac in 2007 and 2008, respectively, but it looks like I wasn’t much of an iconoclast after all: By November, half of the Tech Field Day delegates were using MacBooks, and the Windows and Blackberry holdouts have started vocally defending their operating system choice. Pretty much like Mac folks used to do way back in 2008.
3. The recession is a serious pain – Companies put the brakes on spending and hiring, many even shifting both into reverse in 2009. This came as no surprise to humans capable of thought. The impact on enterprise IT companies was similarly predictable: Although most were able to survive, the impact of 2009 will continue to be felt for years. I might have predicted it would be worse, though I’m glad to say I would have been wrong.
4. EMC, NetApp, HDS, HP, and IBM continue to quibble – Surprise: Big company bloggers spend way too much time criticizing the products and actions of each other and way to little time talking about the true value of their own products.

Non-IT slam-dunk predictions: Obama was reviled by the right; the war in Afghanistan continues; people do stupid stuff in the name of reality shows.

What I Probably Could Have Predicted

Although some details would likely have been missed, I think I would have seen these coming.

1. Cloud compute and storage hits the enterprise – I was a believer in the cloud this time last year, and I bet my future on it by taking a position at enterprise cloud storage provider, Nirvanix, in March. I would have predicted that enterprise buyers would be putting serious thought to buying cloud products, but the scope has surprised me. We’re talking enough petabytes that the non-cloud players felt compelled to strike back with the private cloud pitch. Awesome!
2. Sun and Data Domain were acquired – My money would have been on Dell, IBM, or HP as buyers for this pair, but EMC wouldn’t have been outside my guesses. Still, Oracle buying Sun and vocally committing to keep it going, SPARC and all, would never have come to mind. But I wouldn’t have guessed against it either, so I’ll give myself a point here!
3. Cisco and EMC buddy up – I’ve long thought an outright merger of these two was in the cards, but even the recession couldn’t make the financials work. A partnership would have been on the list, and Acadia came as no surprise to anyone.
4. Cloud outages and data loss – I definitely could have predicted that high-profile cloud services would fall over throughout the year, and that some would lose data. Not all are enterprise-grade, after all. But the outages at Google, Rackspace, and Amazon, and Microsoft’s Danger data loss, surprised me. Don’t those guys have their acts together?
5. IT conferences falter – I spoke at Interop in 2009, but it lacked the 20,000-strong crowd it once had. Storage Decisions and Storage Networking World managed to fill their halls, but the old-school IT conference has lost its luster. Although VMworld remains strong, attendance was definitely off.
6. FCoE and SSD are still starting – I’ve been lukewarm on Fibre Channel over Ethernet and Solid State Drives, but I’m a bit surprised that storage vendors didn’t push them harder in 2009. I might have guessed there would have been more customer uptake to match the buzz.
7. SMB storage is hot – There’s a hole in the storage market between $1,000 and $20,000, and companies like Drobo and Iomega are rushing in to fill it. Now that ESX has solid iSCSI support, I expect a world of innovation here. (Oops, that sounds kind of like a 2010 prediction!)

Also in the predictable category: Goldman Sachs and Bank of America thrived while others fell; Ford is the strongest of the remaining US automakers; Boeing finally got the 787 off the ground.

What I Never Would Have Guessed

I’m not perfect, even in retrospect. Some of the Tech news from 2009 was just completely off the wall.

1. Microsoft Bing: This time for sure! – Seriously, Microsoft should stick to in-house thinking instead of trying to copy its rivals. Yet somehow, miraculously, Bing appeared and did not suck. In fact, I’m hearing regular (non-techie) folks around town talking about using the search engine. I’ve even used it! Could they actually have a winner?
2. Windows 7 rocks – Really? Seriously? Could Microsoft have come up with a solid replacement for Windows XP?
3. Ship it! – It’s not even 2010, and enterprise storage buyers can go out and purchase NetApp’s OnTap 8, EMC’s FAST, EMC Atmos Compute, and unicorn tears. Well, maybe not unicorn tears.
4. Still no GDrive – Seemingly every company has a cloud storage platform, from Amazon to Rackspace, Nirvanix to EMC, so why not Google? Could GDrive join Duke Nukem Forever as the most famous vaporware of the decade?
5. The executive shuffle – Dave Donatelli was supposed to lead EMC, not HP. Alan Atkinson was supposed to launch another startup, not take over Xiotech. At least NetApp was gentle.
6. Mac OS X (still) lacks iSCSI and ZFS – Come on, Cupertino, what’s wrong with you guys? I’ve been hyping ZFS for years, and iSCSI is commonplace. Yet Snow Leopard is stingy with both. Makes me want to hiss like one of those blue folks in Avatar.
7. Gestalt IT is a success – On a personal note, Gestalt IT didn’t even exist this time last year, and now we have a successful IT infrastructure blog and social media event. Amazing!

Other total shockers: Everyone loves Michael Jackson again; digital Beatles tunes are available everywhere but iTunes; Obama’s Nobel Peace Prize arrives 10 years early.

© sfoskett for Stephen Foskett, Pack Rat, 2009. | My 2009 IT Industry Predictions
This post was categorized as Apple, Computer History, Enterprise storage, Everything, Personal, Terabyte home, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

But cloud services are different. Seriously! Cloud services don’t need standards because:

1. Cloud services are still rapidly evolving – No one knows how they will look in a year, let alone a decade, and a premature standard will be worthless. Similarly, it’s not at all clear what use cases will eventually win out, and usage should drive interfaces, not the other way around.
2. Cloud services are many and varied – It’s incredibly hard to come up with a reasonably-complete standard programming API or management platform when each vendor’s offering is radically different. Standards must follow the 80/20 rule, but today’s cloud offerings are only about 20% similar.
3. (Real) cloud systems are open already – The whole point of the public cloud is to leverage existing open standards for access (IP/HTTP) and any worthwhile service already has a freely-usable REST-like API. Cloud services are engineered to be programmable and open, so the only lock-in is in how you use the cloud.

We can’t even agree on terminology at this point. Is data storage as a service DaaS (as SNIA says) or STaaS (as NetApp says)? How do you define public, private, and hybrid cloud? And what is cloud anyway? Cloud computing is not a war, it’s a fantastically exciting race to deliver value!

Open for Business

I’d like to return for a moment to that last point: The key element I’ve seen in most interesting cloudy products is programmability. Service providers publish API documents outlining the inputs, processing, and outputs for their systems and developers and end users create applications that leverage these. The best of these APIs use the concept of REST, delivering services through extremely simple and self-contained HTTP calls. This barely even rises to the level of software coding (and thus isn’t a true API) and is the hallmark of the cloud.

These systems are wide open: You can explore their interfaces, discovering new ways to use the them that were never intended. The same process accompanies all Internet systems, from RSS and Atom to Yahoo Finance. Just as one can rapidly migrate from Yahoo to Google by substituting a few URLs and parameters, so too can one move between cloud platforms.

Note that certain cloud systems lend themselves more to this kind of mobility. Once cannot move virtual machines from Amazon EC2 to Rackspace or Terremark because the underlying hypervisor technology is different. But even here companies like RightScale are stepping in to enable mobility.

When it comes to cloud storage services, the major players’ interfaces are open enough that migrating data in and out is simply a matter of performance: Read from this one, write to that one, and wait until the process is done. I am not a programmer and yet I was able to port an application from S3 to Nirvanix in just a few hours using only the respective API documentation. Interfaces like CloudLoop can also be leveraged to ease the movement of data.

Standards When?

Cloud services will eventually settle down and be standardized. I expect a workable cross-platform API for RESTful cloud storage within 24 months, for example. And one expects that the management of cloud compute instances will pass through a consistent and stable interface in that same timeframe. But these will develop as a natural part of the evolution of the systems themselves, not through some artificial “build it and they will come” standardization process.

There is nothing wrong with big companies sending their representatives to SNIA and DMTF meetings to talk about standardization. In fact, this is a great way to discuss ideas and begin to orient the industry. But the time for standards has not yet come, and users of cloud services have no need to wait for them. In fact, waiting for a standard will just prolong the maturation of cloud services, since real-world applications are the external pressure that forces evolutionary selection. Amazon would never have created their virtual private cloud (VPC) capability without customer input, and they will never perfect this capability if they rely only on pundits, bloggers, and product marketers.

Even when standards do appear, they will not eliminate per-solution APIs. Cloud service providers will continue to explore new concepts, and these will appear first in “proprietary” interfaces. Perhaps they will use entirely unique calls, or perhaps they will leverage reserved or unassigned sections of the standard, but innovation will continue. Witness the radical changes in HTML versions to date, the additions to CSS, and the wide world of browser plugins.

So we don’t need cloud standards yet. They will come, whether artificially pushed by committees or evolving through use, but only useful standards will survive. Isn’t that just how it should be?

Note: I am employed by Nirvanix, a cloud managed storage service provider, providing independent cloud strategy advice as Director of Consulting. Although this article was not created for my employer and is not intended to reflect their views, my perceptions are obviously colored by my daily work.

© sfoskett for Stephen Foskett, Pack Rat, 2009. | We Don’t Need Cloud Standards (Yet)
This post was categorized as Computer History, Enterprise storage, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Check out these detailed posts on cloud storage I wrote for my other blog, Enterprise Storage Strategies:

• Cloud Storage, Storage in the Cloud, and Cloudy Storage Systems
• What Makes Cloud Storage Different from Traditional SAN and NAS?

Eventually, it dawned on me: There’s a big difference between real cloudstuff and plain old stuff in the cloud!

Lots of cloud computing offerings are startlingly conventional. They’re plain-jane IT infrastructure just like we all have today: Virtual servers, storage, and databases. Strip away the management API and self-service model and Amazon EC2 and EBS looks an awful lot like the Xen-based virtual server infrastructure you might find at any old IT shop. The same goes for Rackspace’s Mosso Cloud Servers: They’re extremely similar to Rackspace’s Slicehost virtual private servers!

This isn’t all bad, of course. As I discussed with EMC’s Barry Burke last week, you can theoretically run your ERP application on EC2 without major gyrations. Try that with Microsoft Azure or Google App Engine! And the management layers, especially those from companies like RightScale, turn these run-of-the-mill parts into something really extraordinary! VMware’s vCloud concept really hammers home this evolution-not-revolution mindset.

Real cloudstuff is completely different. Comparing a Xen instance running Linux on some disk (a-la EC2) to a programmable platform like Azure is problematic. Just about the only thing they have in common (apart from the cloud name) is the fact that they’re hosted on multi-tenant servers and offered to the public on a pay-per-usage model. Cloudstuff is the IT revolution that application developers have dreamed of!

Of course, the problem with whole-cloth reinvention is that it’s slow to take hold. Although net-new apps can be built to take advantage of full-on cloud infrastructure today, it will literally be a decade before the corporate IT applications we all rely on will run there. The early adopters will be companies like Microsoft and Google, who have a vested interest in seeing the concept succeed and the development muscle to make it happen.

Then there are the bridges between today’s world and this cloudstuff future. Consider applications like Nirvanix CloudNAS and Jungle Disk: They hide the complexity of API-driven cloud storage behind the familiar face of file server or backup application. Once the data is loaded, cloud-aware applications can access it. This is where the magic happens!

© sfoskett for Stephen Foskett, Pack Rat, 2009. | CloudStuff Versus Stuff in the Cloud
This post was categorized as Computer History, Enterprise storage, Personal, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

I had switched from Dreamhost to Slicehost back in February to improve reliability and performance, but the meagre 256 MB of RAM in my virtual private server (VPS) “slice” proved insufficient. The time had come to completely redo my core hosting infrastructure. After some experimentation, I have settled on a simple two-server configuration based on Ubuntu Linux, MySQL, and lighttpd. I thought it would be a good idea to document this new configuration, as well as my previous experiments, for posterity.

If you’re interested in setting up a web site as outlined here, I recommend Slicehost. They’re not the cheapest, but their VPS servers are fast and reliable.

History

My web hosting environment has transitioned over the past six months. I had relied on shared hosting from Dreamhost for almost a decade, with my servers sharing infrastructure and management with thousands of others. This worked fine until I began to see significant traffic increases since creating this blog. Shared hosting just didn’t cut it once I had more than a few thousand pageviews per day.

I tried Dreamhost’s interesting and very flexible virtual private server capabilities, but could never get them working reliably. Plus, the core networking and storage performance of the Dreamhost infrastructure left something to be desired. After much research I switched to Slicehost, an all-VPS provider that has recently been acquired by Rackspace. Although they are not the cheapest or most flexible, Slicehost is a very professional service with good support and excellent infrastructure and connectivity.

I had been using a single 256 MB slice to host my entire site, and had managed to get everything well with lighttpd and MySQL, but this configuration ran into serious performance issues once traffic built again. Once I passed 10,000 pageviews per day, which happened quicker than I hoped, it was again time to upgrade.

Server Configuration

My core question was whether to go with a single 512MB or two 256 MB slices. Would resource contention in a single server be outweighed by the extra available RAM? After consulting with the experts, I decided that it was time to separate the database and web servers.

A multi-server setup delivers performance, reliability, and future capability.

As illustrated above, the database and web servers communicate via a high-speed private network, a standard Slicehost component. I created extremely restrictive iptables firewall policies to control access to both servers, disabling almost all communication. The database server in particular is inaccessible except from the web server, and even then only allows MySQL and public key ssh. Both servers are running bare-bones versions of Ubuntu 9.04.

MySQL Configuration

MySQL is much happier on its own dedicated server. It makes excellent use of its own query cache and operating system buffers and has very little disk access at all. Query performance immediately jumped, and site performance noticeably improved.

My only change to my.cnf was to enable the query cache. This works great on my 256 MB slice:

# Enable query cache
query_cache_limit       = 2M
query_cache_size        = 32M

I’m not a believer in security through obscurity. Sure, you can use a special high MySQL port, but by then you’ve probably lost anyway. Regardless, set up iptables to only allow access from your web server’s private interface using the -s parameter:

# Allow connections on our MySQL port
-A INPUT -p tcp --dport mysql -s 10.176.x.x -j ACCEPT

It’s a pretty simple configuration, but it works well. MySQL is humming along without much paging at all, using the entirety of the 256 MB available for caching. I haven’t had to resort to any tricks to keep the performance up.

One more configuration suggestion: Use a unique username and password for each database application and grant access only to that user on the private network interface. That way, your risk is segmented to a single database should an intruder use a SQL injection or something similar.

For example, say you were configuring the database “myblog_wp” for the user “me_myblog” with the password “123456abcdef”. You use the web server’s private interface address, 10.176.x.x as well so it is harder to get in even if your firewall is breached.

mysql -u root -p
Enter password:
mysql> grant all on myblog_wp.* to 'me_myblog'@'10.176.x.x' identified by '123456abcdef';

All set!

Basic Lighttpd Configuration

Back on the web server, we configure iptables to only allow connections to lighttpd on port 80 and ssh on whatever port you decide. Again, some suggest using a high port for ssh, but if you’ve configured sshd correctly then using an obscure port number is more likely to be a hassle for you than keep anyone out. Here are some good settings for /etc/ssh/sshd_config:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
X11Forwarding no
UsePAM no
UseDNS no

This forces all logins to use established public/private key pairs rather than passwords. Protect your keys and you’re in good shape. Key passphrases are a very good idea here! You’re also disallowing root in any case, since you’re using sudo for all administrative tasks, right?

Next we need to set up lighttpd. I’m using the basic packaged versions for ease of maintenance rather than building my own. I also loaded the stock versions of php5 and mysql-client which integrate nicely. I used to use eaccelerator but didn’t love having to recompile it myself and had some mysterious lockups with it running. So I went with XCache, which is developed by the same fine folks who created lighttpd.

sudo aptitude install mysql-client lighttpd php5-xcache

Why not use Apache? I actually tested Apache with my site before deciding to use lighttpd. I was able to tweak it to run in 256 MB of RAM by limiting the number of worker processes created to 4, but Apache just couldn’t handle the site load. Connections were stacking up and pageviews dropped as people gave up. Lighttpd with XCache is blindingly fast and fits in my 256 MB RAM envelope nicely.

The only real issue I have with lighttpd is that configuration is entirely different from Apache and remains less well-supported. It doesn’t use with .htaccess files, for example, and rewrites use a unique syntax.

Lighttpd for WordPress

Here’s a basic virtual server for /etc/lighttpd/lighttpd.conf for a WordPress domain:

$HTTP["host"] =~ "^(blog\.)?yourdomain\.com$" {
  server.name = "yourdomain.com"
  server.document-root = basedir + server.name + "/blog"
  url.access-deny = ( "wp-config.php" )
  dir-listing.activate = "disable"
  url.rewrite-final = (
    # Exclude some directories from rewriting
    "^/(wp-admin|wp-includes|wp-content)/(.*)" => "$0",
    # Uncomment to exclude Google FriendConnect files
    # "^/(canvas.html|rpc_relay.html)" => "$0",
    # Exclude .php, robots.txt, favicon.*, and sitemap.xml files at root from rewriting
    "^/(.*.php|sitemap.xml|robots.txt|favicon.*)" => "$0",
    # Handle WordPress permalinks and feeds
    "^/(.*)$" => "/index.php/$1"
  )
  accesslog.filename = basedir + "/" + server.name + "/log/blog.access.log"
}

This configuration accomplishes many of the important tasks of WordPress configuration. Most importantly, it works!

1. Permalinks and feeds are correctly redirected so no ugly index.php is used
2. Critical directories like wp-admin and files like robots.txt still work
3. Your wp-config.php file is explicitly protected
4. Directory listings are disabled
5. A site-specific access log is used (like Apache)

I’d love feedback on this configuration! One weird thing I’ve not yet figured out is how to use a site-specific error log. I haven’t configured pretty MediaWiki links in lighttpd yet, but imagine a similar configuration would work there.

© sfoskett for Stephen Foskett, Pack Rat, 2009. | Setting Up a Multi-Server Web Hosting Environment
This post was categorized as Personal. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.

Sun is getting into the cloud services business, but which market is their target?

While the bulk of Sun-related news this week relates to reported talks of a buyout by IBM, the company took a break from negotiations to introduce their own cloud computing and storage infrastructure, challenging Amazon, Google, Rackspace, and perhaps VMware, Microsoft, and Nirvanix.

Sun is leveraging the assets they acquired from Q-layer earlier this year on top of OpenSolaris, MySQL, ZFS, and just about everything else in their arsenal to offer their own virtual data center (VDC) strategy. The Sun Cloud will be a private (inside the firewall) environment offering mobility of virtual machines. Q-layer had partnerships with both VMware and Microsoft and functioned with Windows, OpenSolaris, and Linux, suggesting that this will be quite a full-featured offering. Suddenly Sun’s free OpenSolaris offering on Amazon EC2 makes a lot more sense – it provides a gateway to take virtual computing business from the Bezos team!

One very nifty angle Sun is taking is enabling VirtualBox system images to be saved to (and presumably run in) their cloud. I wonder about monetization, since VirtualBox is more of a desktop virtualization system than VMware ESX and Microsoft Hyper-V, but the prospect of clicking “Upload to Cloud” is intriguing! OpenOffice will also allow cloud storage, a foil to Google Apps.

The Sun Cloud also includes a managed storage service. Sun apparently has three storage protocols: A proprietary Sun Cloud Storage API, WebDAV, and an object API likely leveraging Amazon’s AWS. The company claims that they are API-compatible with AWS, allowing applications written with Amazon in mind to be easily ported to their cloud storage service.

One key point to consider with all of this cloud talk, however, is how prepared each company is to support enterprise computing needs. Long-term viability depends on paying customers, and only the largest systems can attract enough end-user nickels and dimes to survive. Enterprise solutions are where the real money is, and questions remain about how prepared companies like Amazon, Google, and Rackspace are to support the needs of corporate users.

There are really three cloud markets: Shared clouds for small developers and enterprise customers and private cloud systems. Amazon was strong from the start with the little guys, Web 2.0 startups and end-user services like Jungle Disk, and Rackspace/Mosso and Google are challenging them in this space. Sun’s focus on AWS compatibility and VirtualBox suggests that they plan to play in this sandbox.

But the enterprise cloud is another matter entirely. Nirvanix stands strong in shared managed storage services, racking up win after win with big customers. EMC, VMware, Microsoft and others are positioning themselves as private alternatives in this space. Will Sun try to compete here, too? They are certainly talking about private clouds and the virtual data center, but there is a serious risk that they will lose focus trying to take on too many roles, and enterprise users won’t tolerate poor pre- and post-sales support! 

© sfoskett for Stephen Foskett, Pack Rat, 2009. | Sun Launches Their Own Cloud, But For Which Market?
This post was categorized as Enterprise storage, Gestalt IT, Virtual Storage. Each of my categories has its own feed if you'd like to filter out or focus on posts like this.