Blog and Host Like it is 2018
Here are the short problem statement and solution for very impatient. If you interested in details and motivation read further.
Host a personal blog. It should be easy to deploy, update, manage and be cheap.
Host static webpage files in AWS S3 and serve them as a static website using Route53 DNS. Robust, reliable, high-performance system for
Blog or another not-so-frequently-updated product in its nature has from little to no back-end dependency because it is read-only. Usually, user’s cant writes new posts on your blog, aren’t they?
Using this information static site generator like Hugo, Jekyll, or whatever else might be a good solution. By the way, if you have no idea what to choose, here is a great List of Static Site Generators.
Indeed, a static site is the easiest thing to deploy and manage. It is also easy to write and update content.
If you aren’t familiar with the conception of static site generators, basically it works like following. First, you write your post in a text file, most likely with markdown syntax. Next, you generate a static web page using static site generator. This generator is basically a pipeline which can be rawly represented by this scheme:
.mdfile -> static site generator ->
Basically, the same process which is done by web frameworks but once and result is stored on file system.
Also, there are many ready-made options such as Ghost or other blogging platforms. However, these platforms require certain server infrastructure. This is a good solution if your blog updated multiple times on a daily basis or you need some admin panel, multiple users, etc.
That being said we may say that static site generator is a way to go. But what about non-trivial question: server side?
Deployment and Hosting
Previously I used to host things like this: just spin another Virtual Private Server instance and setup all the things in there. The bill was about
$10 month. However, it feels so wrong to host static pages on a separate server, running it 24⁄7. What software engineer can run a computation process while there is nothing to compute? Even if your blog is read by 10,000 people monthly most of the time your server simply idle.
Say you are running some web framework which serves your static content (yes, runtime generation of a static content is still a static content and your average computational latency is 65ms from request dispatching by some server like NGINX to sending a response.
You did something truly amazing so that 100,000 people decided to read about it. It will yield 6,500 seconds of computation time, if computed sequentially, not in parallel. The average month is 30.41 days long, or 2,627,424 seconds. 6,500 seconds from 2,627,424 is 0.247%.
If your dymanically generated blog will visit 100,000 people in on month your server idle time will be 99.752%
Doesn’t it feel quite wrong?
AWS has superb Simple Storage Service or S3 for short. You can store your site on S3 as a static site and configure Route53 routing. Works like a charm and easy to setup.
Here is a common misunderstanding: “But doesn’t AWS expensive?”. No, it is not.
Storage pricing works like this:
total = storage + requests + data transfer
Storage pricing is
$0.023 per GB, request pricing is
$0.004 for 10,000 GET requests,
data transfer is free for 1 GB, next $0.09 per GB.
Route53 (DNS) pricing is
$0.5 per zone and
$0.4 per million queries.
Practically you have to maintain quite a popular blog to make your bill go over
While using VSP user is billed monthly, no matter how much actual computing time was used S3 billed as much as used. No use - no bill.
No matter how your page is popular it will be served equally well. Your site is “computed” only on demand with very little inner latency. Outer latency depends, as always, on how far client from the server plus client’s network quality.
No scaling issues concerns whatsoever.
A static site is superior or equal to dynamically generated blog for certain use cases. A static site can be hosted on AWS S3 which is strictly superior to Virtual Private Server, great availability and no infrastructure to manage.
Reading Further and Useful Links