Project Sunshine - No More Cloud - Intro
Series intro on self hosting, without cloud infra.
Like many others, the last couple of years have meant a deep dive into cloud development/delivery. For me personally, I’ve been deploying everything I could think of to AWS using terraform. I really like how it enabled me to rely less on others and own not just the code and testing but also the deployment and ‘getting it to production’.
Recently I’ve been looking to see what exists outside of the cloud/hyperscalers. Getting back to the basics is great as it gives you some new perspectives on what options you have when there’s no push towards putting everything in the cloud.
So in this series I’m going to walk you through all the things I had to do to deploy a relatively simple application outside of the cloud. There are a lot of lessons to be learnt here and it does make you appreciate all of the bells and whistles that you get out of the box. However, learning and knowing these skills I think is essential as it gives you options. Sometimes the cloud is the right place, sometimes it isn’t.
What this series covers
Every post tackles one part of what had to happen in order to make this application run. I’ve written out all the parts that I think I will have but I might end up removing/adding things later as things change.
At the time of writing we’re talking about a straightforward API written in .net core, using some persistent storage as well as a relational database. Along with every topic I’ll try to make a cost comparison as well.
Part 0 — The Box
Getting a VPS, basic firewall configuration. The boring foundation everything else sits on.
Part 1 — The Front Door
Nginx as a reverse proxy. Static site hosting and setting up TLS certificates with Let’s Encrypt. Routing traffic through to things that aren’t static sites.
Part 2 — Containers For The Application
Running the application in a container with podman. This removes the need for installing a lot of things on the server itself and should limit the attack surface significantly. Running it this way should also help with scaling out later if need be as well as with portability of systems between machines.
Part 3 — The Database
Running an RDBMS yourself, as a container, with persistence and backups taken care of. As a developer (and not a DBA) this might be the most daunting task to get right.
Part 4 — Persistent Storage
Not all data is relational, so we’ll talk about how we can use object storage within our API.
Part 5 — Deployment
Going from source control to an actual running process. Building a container or publishing static files, how do we perform updates without or with minimal downtime.
Part 6 — Observability/Monitoring
When things inevitably go down, I want to find out myself as opposed to getting an email from a customer. So let’s dive into logging, monitoring and alerting.
Part 7 — Disaster Recovery
A backup strategy and actually testing those backups. How do we survive the loss of the entire server?
Caveats
This series assumes you have a machine that you have root access to via SSH. This might even be in one of the hyperscalers if you really want to.
Currently, I’m going to assume that the API runs on a single box. I’m very aware of the limits that puts on being able to quickly scale up. Almost all machines will be virtual though, so upgrading to a bigger box should be a few clicks.
This does mean upgrades/server reboots involve some down time, if this is truly unacceptable, this series is not for you. Keep in mind though that to get 99.99% uptime, you are allowed to be down just over a minute a week. If you keep your setup lean, a reboot should easily be less than a minute and much less often than weekly.