Tiny Websites have no Server

A big trend in web services right now is the so-called serverless computing, such as Amazon’s Lambda service. The idea is you don’t have a dedicated server waiting for requests for a specific purpose. Instead, you have one server (such as Amazon’s) listening for lots of requests and on demand, you spin up an environment to process that request. Conceptually, it lets you run a bit of Javascript or some other language “in the cloud” with no dedicated server.  https://itty.bitty.site takes this one step farther. The site creates self-contained websites where the content is encoded in the URL itself.

Probably the best example is to simply go to the site and click on “About itty bitty.” That page is itself encoded in its own URL. If you then click on the App link, you’ll see a calculator, showing that this isn’t just for snippets of text. While this does depend on the itty.bitty.site web host to provide the decoding framework, the decoding is done totally in your browser and the code is open source. What that means is you could host it on your own server, if you wanted to.

At first, this seems like a novelty until you start thinking about it. A small computer with an Internet connection could easily formulate these URLs to create web pages. A bigger computer could even host the itty.bitty server. Then there’s the privacy issue. At first, we were thinking that a page like this would be hard to censor since there is no centralized server with the content. But you still need the decoding framework. However, that wouldn’t stop a sophisticated user from “redirecting” to another — maybe private — decoding website and reading the page regardless of anyone’s disapproval of the content.

Continue reading “Tiny Websites have no Server”

Hackaday-proofing your hackerspace’s server

Last month we posted a tutorial from Hub City Labs on making your own PCBs at home. At the time, Hub City was hosting their hackerspace web site on a tiny vps graciously provided by a member. As you might expect, the throngs of Hackaday readers turned Hub City Labs’ server into a pile of molten slag and made their admin’s hair a little more gray. Their web site is up again, and Hub City provided a tutorial on protecting your server from the ravages of being Slashdotted, Farked, Reddited, and even Hackaday’d.

The solution for the first few hours was to transfer Hub City Labs’ site to an Amazon EC2 instance. Since then, they’ve moved over to a Debian EC2 instance that is able to handle half a million pageviews an hour for a WordPress site.

This amazing capability required a good bit of optimizations. A WordPress installation is set to run cron tasks on every page load; not good if you’re going to see thousands of hits every minute. The guys added define(‘DISABLE_WP_CRON’, true) to their wp-config.php file and set all the background tasks – checking to see if a page should be updated – to a fixed schedule every minute or so. Along with an increase in the WordPress cache, these optimizations increased the number of pageviews an hour from 1500 to 60000.

To get up to half a million pageviews an hour, the EC2 instance was loaded up with Varnish, a front-end cache that really speeds things up.

The result – 375 million pageviews for $15 a month – is more than Hub City Labs will probably ever need. The nature of hackerspace web sites, though – light load until Hackaday, Slashdot, or Reddit figure out you did something cool – means hosting on an expandable EC2 instance is probably the way to go.