Here’s my history of hosting on the Internet. Before 1994 I built software for everything from supercomputers to home computers (I’ll tell you more about DesignWare some day).

• 1994- Virtual hosts on Best.com; 1999- Virtual hosts on Verio (bought Best.com)
• 2003-2005: New X-Serves on Maccius (Mac-only host in San Jose)
• 2009: Slicehost, and then Rackspace cheap virtual hosts- “slices” in the cloud
• 2012: WPEngine — specializing in WordPress, with caveats

Why this particular migration and what would I recommend that you do today?1994-2003: Virtual hosts were the way to go when the Web was first ramping up. They’re easy to start up (click a few buttons) and you can use FTP to upload, and most of the provide root access so you can load any software you want to. But they were relatively expensive, given that they are on shared computers and you’re at the mercy of the other users who’re on that same computer – if someone runs away with the CPU you end up with a very slow site. (And I’ve been guilty of messing up the other users too…)^[1]

2003-2008: Later on, I tired of paying $95 a month for a slice of a larger computer and bought my own Apple servers. These machines really rock. Lots of power, and dedicated to me alone. No need to worry about other users getting in my way. For $125 a month I get a space in a rack and I can run my server at 100% CPU if I want to. Cranks out sites really quickly.

2009: Virtual servers have come down in price. I looked around early in the year and chose Slicehost, which has a simple $25/month server with 256MB of “RAM” and 10GB of RAID storage, and they give me 100GB of data transfer per slice per month. I wouldn’t have gone back to virtual hosting except for the low price. Slicehost was acquired by Rackspace, and made a part of their cloud late this year, and I also had a few virtual servers on Rackspace. So they’re all consolidated under Rackspace now.

2012: WordPress specialists, such as WPEngine, have come along, providing service for those who use WP but don’t care to do the security and system upgrading.

Only for the brave: The pros and cons of slicing up a big server: Well, 256MB of RAM is pretty small, and that’s what Slicehost allowed you to start with. Rackspace starts at 512MB now. You gotta install a lean operating system (Ubuntu 8.04 was my choice — but now Ubuntu 12.04 LTS), and you gotta really tune it up so it functions well in tight places. The nicest thing about the old Rackspace slices is the 4 powerful CPUs, which give you lots of headroom if you have to crank out a page. If you buy a new Rackspace VPS now (December, 2012) you’ll get a single CPU allocated, with 512MB of RAM as the minimum.

Yup, if you like getting your hands really dirty, then a slice might be for you. Ubuntu has gotten pretty easy to install – and on Rackspace you just click a button and a few minutes later they send you a hostname and IP address and it’s running. And adding new features is about as simple as running “apt-get install foo” and then you do a few configuration changes. Well, almost that easy. Every once in a while I run into something that I think is going to take an hour and it takes two days. But I can configure a new host from scratch in about 25 minutes (Apache, PHP, MySQL) and bring up new web sites in about 20 minutes each.

WordPress specialists: I’ve got to say something about WPEngine here because it’s a love/hate relationship. First, WPE provides a great service because they give you a functioning WP engine in one click, for as little as USD $25 a month. They provide a one-click staging version of your site where you can test new plugins and do your own PHP coding without upsetting your live site. They host under your own domain name or theirs — you pick. They “curate” common plugins, taking care of any problems and updating them so you’re always up to date. The one caveat is that you can’t use certain banned plugins (mostly those that are database intensive), and they sometimes push upgrades without warning you, which might break your non-curated plugins! I recommend them if you have plain vanilla WordPress needs, but my jury is still out in terms of whether more sophisticated sites should use them or not.[2]

[1] A Virtual Server or Virtual Host or Virtual Private Server [VPS] is a piece of software that subdivides a big server into smaller “servers” that from a user’s viewpoint look like independent machines, but in real life are just logical (thus “virtual”) subdivisions of the larger computer.

[2] I’ve brought up several sites that needed large bursts of speed and high reliability. WPE is great for the bursts, which would have bogged down a VPS. However, we’ve been surprised several times when our sites just stopped working due to unexpected WPE upgrades. They do not tell you in advance when they’re going to change some plugin out in the middle of the night, so you have to be on call 24/7 watching for such things. You just don’t have the same degree of control here in terms of staging your upgrades and improvements and then rolling them on particular days because they might do one suddenly that you didn’t expect.

The post Hosting- Rackspace on steroids and on to WPEngine (for some) appeared first on Sky's Blog.

Cloudkick runs a slick service that lets you manage your Slicehost and Rackspace/Mosso cloud servers (both brands are owned by and housed in Rackspace facilities), providing some data visualization in addition. Of course you could manage your servers using the control panels provided by Slicehost and Rackspace, but Cloudkick’s one-layer-removed management adds some unique extras. And they can “automatically” migrate your Amazon EC2 servers over to Rackspace if you’re interested in that. I have nine virtual servers on S&R (as I’ll call the two services) and signed up for the free Cloudkick services almost three months ago. They were voted Best in Show at Under the Radar (see Cloudkick writeup and video). The company is a little under a year old. It was kick-started by a seed investment by Y-Combinator, and recently obtained an angel round of investment.

They start by giving you a nice little control panel that shows the status of all of your servers (you have to “register” each service with Cloudkick – giving them your API information from Rackspace or Slicehost). They determine the status by pinging a handful of services on each virtual host.

It seems to me that ultimately they’d like to take over the complete management interface so you don’t ever have to go down to Slicehost or Rackspace interfaces. Currently you can fire up a Rackspace virtual server directly from Cloudkick, without ever touching the Rackspace Cloud control panel.

I separately monitor my own servers to be sure they’ve not been hacked, but the Cloudkick service adds a dimension I like, by integrating the control together in one place. And today they described some future services that I know I’ll be able to utilize. I particularly like the idea of additional data visualization, and that’s on its way. Here’s the kind of graphing they provide right now… this shows web page load times for two Slicehosted sites:

And here’s the UStream video of Alex describing CloudKick.

[swfobj width=”480″ height=”386″ flashvars=”autoplay=false” allowfullscreen=”true” allowscriptaccess=”always” src=”http://www.ustream.tv/flash/video/1426508″]

The post How will I manage? (the cloud) appeared first on Sky's Blog.

Geek alert! This article is for Slicehost geeks only.

Talk about playing on the edge, I almost fell off this time. I have eight slices (virtual servers, that is) on Slicehost (which is now owned by Rackspace) and believe me they are tiny!^[1] But they can serve low-volume to medium-volume web sites pretty well. For instance, Shaping Youth (several thousand visitors a day) and GirlsHorseClub are on these little servers and they serve up pretty rapidly.^[2] Nice thing about Slicehost is that any host can be scaled up from the tiny size to 16x that size, and because it’s cloud computing, you can also bring up multiple instances of any server and have them share load. This allows me to implement the traditional three-tiered architecture (web/application/database) quite well without having to worry about whether my servers will be able to handle the load because I can scale ’em up whenever I need to.

But, the catch is that when you start with the tiniest slice (256MB RAM) you really have to fine-tune your operating system and applications in order to get good performance out of them.

This has led me to some fun discoveries about 1) how to make Apache work in a really tight space; 2) how to add additional web serving using NGINX (engine-X); 3) how to run MySQL in less space; and finally 4) how to use Java and Tomcat wedged into a non-existent memory slice.

Today’s lesson for me was installing Tomcat 5.5 on Slicehost. I started by reading How to Install Tomcat on Ubuntu in the mkyong blog. Not bad at all. The essence is to first find out what version of Tomcat is available on your slice:

sudo apt–cache search tomcat

Then install that version and the admin app for it:

apt–get ––fix–missing install tomcat5.5
apt–get ––fix–missing install tomcat5.5-webapps
apt–get ––fix–missing install tomcat5.5-admin

Then I like to have /usr/local/tomcat defined (like on all my other servers):

ln –s /usr/share/tomcat5.5/server/ /usr/local/tomcat

That was about all it took. It serves by default on port 8180 – and the admin app was there and ready to go. My next step was to port a Java app that I have been running on bigger servers over to this little server. That actually worked quite well, requiring about 6 hours to port, recompile (to eliminate a few warnings) and test.

[2] These two slices actually had to be boosted to 512MB recently in order to handle anticipated high traffic. But I can reduce their size after the stress-out period passes.

The post Slicehost- Tomcat installation on a tiny virtual server appeared first on Sky's Blog.

Zend’s CEO, Andi Gutmans, claims that PHP is disrupting Java. Meaning that PHP has gotten a significant toehold and is dislodging Java from its position as the granddaddy of server-side web applications frameworks[1]. I take the word disrupting in its modern sense of disruptive technology – a technology that significantly differs from the standard paradigm and whose effect would have been hard to predict, based on the “rules” of the standard paradigm.

I am a long-time Java-user (9 years) and I agree that PHP is a real contender in the web applications sphere… and would like to make some additional observations.

I suppose that if you don’t know what PHP and Java are, you might consider this article total gibberish. So let’s fix that. If you’d like to read up and learn about PHP and Java, try Wikipedia [PHP] and [Java] articles for starters.

Here’s additional elucidation…

PHP: … is a programming language that is embedded within web pages (on the server) whose purpose is to embody the “logic” of the web application and ultimately emit HTML pages. When PHP statements are executed they do things like connect to databases, make computations, and modify and format the information for display on the web page. Ultimately the output is HTML (and javascript) like any other page. PHP developed as a scripting language, and one characteristic of scripting is that the server “interprets” (or compiles) each PHP page from scratch each time the page is requested by a web browser. That’s each time a page is requested. That makes for quick development and modification of PHP pages, but it’s not very efficient from the standpoint of server efficiency.

Java: Similarly, Java language statements can be embedded in web pages (on the server) to connect to databases, read files, and modify and format information for display.  Java provides (runs within) a framework^[1] that precompiles its programming language statements to a compact form which can be very quickly executed by the server. One common framework is Java Server Pages [JSP] running under the control of systems like JBoss or Tomcat. The other big difference, compared to PHP, is that Java pages (JSP pages in my case) are “persistent” and once a page is compiled and then loaded, it stays in memory and can be executed super-quickly for thousands of viewers without recompilation or reloading – while PHP pages have to be compiled for each of the thousands of viewers.

And the bottom line is that Zend, the company, provides an “optimizer” and its own framework that vastly improves the performance of PHP pages, thus making PHP much more competitive with Java. So Andi is right. PHP is really disrupting Java’s hold on the web application market.

Working in the cloud^[2], as I do now, I have found it’s easier to find a cloud supplier who provides a PHP right-out-of-the-box solution than a Java solution. Or maybe it’s just easier to configure PHP (like on the Ubuntu Linux servers I use at Slicehost). But Slicehost is promising us a Java solution soon. Probably more important, Google has announced they’re workin’ on a Java solution to be positioned within their App Engine and I see more and more clients using Google Apps every day.

So what’s the bottom line? PHP has really come up the curve, especially with the Zend Framework and Zend Server in the picture. I’d say that development progresses a little faster in PHP than in Java – while you’re developing the database and other support – but when you’re developing the PHP or JSP pages themselves, the two approaches get pretty similar traction. During development and debugging, you can make a change to a page and instantly view the result of your change. Once you’ve deployed the solution and there are thousands of users, then the Java-based app is probably a bit easier on the server and has greater capacity.

[1] A framework is a set of cooperating programs that together provide underlying support services for a computer application (“application” in the sense of a computer program that gets some big task done). I’m talking about web applications here – meaning applications running on big servers in the cloud and used by people through web browsers.

[2] Cloud computing is “computing as a service” without the customer having to worry about servers or other hardware – you just purchase as much computing as you need.

The post Did PHP kill the Java radio star? appeared first on Sky's Blog.

I’ve mentioned before that I’m bringing up web sites on Slicehost. It’s a cloud computing environment and that means I don’t know and don’t care exactly what or where the server is, and I only buy as much as I need.

It’s an interesting experience because in the rest of my life I’m constantly expanding my (personal) computers by adding storage and processor power so they can run faster and faster, but in the case of cloud computing, instead, I’m scaling down the pieces of software so they can run more efficiently in a small “computer” instead.I was wondering a few days ago why one of my slices was running so “hot” – it was using up all of its memory and it was swapping to disk like crazy. I thought that Apache (web server) and MySQL (database) would be smart enough to make good use of whatever memory was available, whether it be large or small.

So in the interest of geekiness I took a look at what I could do to save the situation.

Turns out that my reducing the number of processes that Apache is allowed to run, and my using an example configuration file that MySQL provides for small installations, I was able to tune my slice so that it hardly ever swaps (which reduces disk utilization to minimum) and just barely fills up the available RAM in the virtual computer.

Here are the references that were most useful to me in this process. It probably took me 30 minutes to get it all tuned up. And wow it runs great now!

• Lowering Apache memory usage (just read the Apache part, not the MySQL part)
• Finding and using the my-small.cfg MySQL configuration file (this is specifically designed for Slicehost, which I use)

The post Small slices of computing (Slicehost) require small MySQL and Apache appeared first on Sky's Blog.

Cloud Computing– it’s a relatively new term for a relatively old concept. For at least six months now I’ve been thinking about two inevitabilities: 1) that my servers will fail some day soon; and 2) that I may have to rapidly scale (up) some customer’s site because it will suddenly have traffic needs well beyond the capacity of my servers.

The answer is pretty obvious to me – I’ll soon be eliminating my own serves in favor of purchasing computing power in whatever quantities I need at the time. Scalable on demand. From one of the cloud service providers that are coming online now.

Buying cloud computing essentially means buying computing power without knowing or caring exactly where it is physically located or what type of equipment it’s on. Someone else buys the servers, puts them in racks, powers them, cools them, and connects them to the Internet. And they stand there ready to go into service whenever they’re needed.

I looked at Amazon EC2 first, because it’s been getting a lot of publicity. Amazon has built server farms that could scale up and down rapidly, and has been supporting its own services on those computers, for years. It’s was logical that they’d be in a position to sell “time” on servers to anyone who wants it…as long as they had the spare capacity. But Amazon charges $0.10 per hour for a basic “server” instance, which means $2.40 a day or over $72 a month for even one server. That’s pretty close to what I was paying Verio for a virtual private server in the late 1990s, and it’s probably 50% of what it costs me to have my own server with several times the capacity.

Then I ran across a company called Slicehost – recently acquired by Rackspace. These guys offer raw server instances (virtual private servers) starting at $20 a month. These $20 “slices” are small, but they get the job done and they’re ideal for hosting web sites that are simple, have low traffic requirements, and yet might have to be scaled up at a future date. To scale, you access the Slicehost online control panel, and within minutes you can have a much larger slice of a server – still “private” – with literally the click of a button.

Oh, and the “private” is important. My clients need pretty tight security, and running a web site on a virtual private server means they don’t have to worry about some other user of the same server having a weak password and getting hacked, consequently opening up a window to my client also getting hacked. With a virtual private server, there’s only one user, and you’re responsible for your own problems.

So the site you’re looking at right now is on Slicehost. On their smallest and cheapest offering. And yet handling the traffic pretty well. And on top of that, I have several sites all on the same slice. This isn’t for the faint of heart – I had a Ubuntu 8.04 server instance installed and from there I installed all of the services I needed, but this really requires some middling sysadmin expertise. (Takes me under an hour to provision one slice and bring up a WordPress instance. Then about 30 minutes for additional WordPress instances or web sites.)

This is the future and it’s slick.

Oh, by the way, the new look of the web site is not related to the switch to Slicehost. I just got tired of the old look, and loved this new theme, and switched over during the migration to Slicehost.

The post Slicing up the Cloud appeared first on Sky's Blog.