Cybernated Complex

Try to keep complex in the cyberspace.


Behind the site #1: Consideration of the Hosting Service

I finally deployed this site, and brought the old articles back online from the archive. Settings up items are always easy, “just read the instructions”. However, it is much more diffiult to choose a set of handy but suitable “technical stack” to implement everything from the ground up.

Here are some core considerations:
The first thing is the budget. A small site with few visitors should never be costly. Most virtual private servers (VPS) with a tiny specification usually cost US$ 5/mo or above. And these servers are overcapacity in some ways for a site blog site: With some specific solutions, a blog site can be just a set of static pages, and a very simple web server can get the job done just right.

The second thing is availability. The concept of “Availability” has two sides: “Accessability” and “Service Availability”.
As we all know, many problems exist when a user from a widely-restricted network accesses the server. For example, some users from CMCC’s network can hardly access servers in the US just because the CMCC contributed little to constructing fibres across the Pacific than the other two carriers: CT and CU.
Moreover, the GFW blocks many widely-used service providers such as WordPress or Google Blogspot. When I create a server and then find out I have no idea of accessing this server just because the GFW had blocked it, damn…

The other thing is service availability, or the SLA. This is much more easier. In some ways, VPS providers may over-allocation some key resources such as CPU and memory. In some common cases, the CPU will be allocated 300% of its physical resource, and the memory will be allocated 1 ~ 1.4 times more than the physical resource. A service with tight resources has a much higher occasion of running into failure.
Keeping service always online requires more effort: monitoring. We need some specific technique to monitor the service, bring it up when something goes wrong, and let the maintainer get notified. For example, we can set up a service prober to continuously check if the service is running, or a server monitor, such as the ServerCat by Baye.

All above, based on my tight budget and effort, the way towards a solution is almost there:

  • I need a budget service provider with less effort on monitoring and maintaining. Therefore, I shall reduce the performance requirements as I can.
  • The service provider should have almost-available connectibility from the world behind restrctions.

First, I choose hugo as the page generator. It will help me generate static pages from a set of template and my articles. Static pages have a much more lower cost when those with a common CMS like WordPress.

Second, the chosen of the service provider, there are many choices:

  1. Github Pages
  2. Some block storage such as Amazon S3 and Azure Blobs
  3. Azure Static Web Apps
  4. A very cheap hosting service

Github Pages is a most-common choice for static pages, also it is compatible with custom domains. However, it has been partically blocked by the GFW. Amazon S3 has a same problem: not accessable from the world behind the GFW, also, setting the site up with Amazon S3 costs much more efforts. I tried Azure Blobs at first, it provides a handy static site service. While I was trying to getting everything done, I saw the Azure was providing a dedicated Static Web Apps service, and it was much more easier than simply using the Blobs.

Plus the consideration of everything above, the final choice is Azure’s Static Web App, it is totally FREE, Lmao.

The next thing is how to bring site online. Please refer to my next article: “Behind the site #2: the Pipeline”.