It’s real, Google App Engine has been released. I’ve downloaded the SDK and worked my way though the Getting Started guide, and I’m excited. Very excited. GAE isn’t just a virtual server to deploy your application on, it’s an entire platform. GAE includes a DataStore API that makes SimpleDB look like a hobby project, Users API (Google’s answer to OpenID) and more.

GAE comes complete with auto-app-versioning, your choice of runtime environment (Python only for now, but they say there’s more coming) and automatic scaling. In fact, GAE lets us forget all about scaling and reliability: it just works. And that’s the future: complete platforms, not ad-hoc components. Google has definitely hit the nail on the head with GAE and I can’t wait until it’s out of beta. Stay tuned for more on GAE soon.

• 0 Comments

I’ve used Xen a lot in the past, and I really like it. It’s about as close as you can come to having a pseudo-dedicated server: your own kernel, complete isolation, guaranteed non over-committed resources. And, it’s probably the best choice if you’re running an unmanaged hosting environment full of strangers. At Integral Impressions we evaluated both Xen and OpenVZ for our managed hosting solution. Hands down, OpenVZ made the most sense for us. Here’s a few reasons why:

• Negligible overhead. All OpenVZ virtual servers share the same kernel. This makes for such little overhead that it goes unnoticed.
• Flexible resource allocation. We can share resources among our virtual servers much more flexibly than we could with Xen. For example, our Level 3 hosting plan has 1GB RAM . But we don’t really cap it at 1GB, that’s just what we guarantee. In reality, we’re fine with a customer’s virtual server temporarily using more than that. If it becomes permanent, we’ll just ask them to upgrade. Our servers have a ton of RAM , and there’s always GBs to spare, so no sense in letting them go to waste. If we were using Xen, we’d have to cap the customer at 1GB and they’d need to upgrade to increase that, even if only temporarily. The same deal applies to CPU and disk space.
• Extremely quick upgrades and downgrades. We can upgrade or downgrade a customer’s resources in a matter of seconds and usually with zero downtime. How’s that for cool. Even disk quota’s can be altered in seconds – something that’s usually a painful operation with Xen.
• Stability. OpenVZ is the core of a commercial product, Virtuozzo. Virtuozzo has been through several years of production usage, and it’s rock-solid. We’ve not had a single problem with OpenVZ. What’s more, should we ever need commercial support we can always contact Virtuozzo.
• Performance. I can’t provide you with any benchmarks right now, but compared to some of the Xen solutions we’ve used in the past, OpenVZ seems a lot faster. Read into that what you will, but that’s our experience.

If you’ve also used both OpenVZ and Xen, I’d love to hear your experiences. What made the most sense for you? Why?

• 0 Comments

Some time ago we implemented a basic spam filter for Ticketish. Nevertheless, those pesky spammers continued to push through their mail. No more. We’ve implemented a full-blown bayesian spam filter for all Ticketish accounts. If you’ve never heard of bayesian filtering, a great place to start is Paul Graham’s article A Plan for Spam.

To get the most out of the filter you need to train it. When using Ticketish, you’ll see some new items in the drop-down for managing multiple tickets: Spam and Train Not Spam. Start by selecting a whole group of tickets that aren’t spam, and train them so. Then, make sure you mark all spam tickets as spam instead of just deleting them. Over time, Ticketish will become very accurate at determining what’s spam and what’s ham.

Every Ticketish account is trained separately. This is important because what’s spam for some might be ham for others. All accounts start with a clean slate, so it’s up to you to train appropriately. We’ve developed the spam filter as a RES Tful web service, so expect to see it pop up in our other applications as well.

• 0 Comments