Why I migrated my personal projects to Kubernetes
A little while ago I made the decision to containerize my personal projects and migrate them to kubernetes. If you’re not familiar with kubernetes or containerization in general, this comic is a helpful explanation of the basics.
It took a long time, but I’ve migrated most of my personal and company services to kubernetes. Here’s why i did it.
More Time For Development
First and foremost, I wanted more free time. A good portion of my free time was being spent on maintaining, deploying, and looking after infrastructure. When I work on side projects, I want to focus on the code and not be distracted by trying to set up a virtual machine. Kubernetes allows me to simply run docker build and push commands once I’ve finished with my changes, and with the help of CI/CD pipelines, my work is pushed automatically to production without any effort on my part.
Less Time Monitoring
A lot of what I was doing with my previous approaches (virtual machines running different stacks) was monitoring services and responding to outages. Monitoring is incredibly important — it’s the base of all site reliability engineering, but I only want to be alerted to take time out of my day if absolutely necessary. Whereas getting notifications to my personal slack, tunneling into my server from my phone, and running a sudo service apache restart command did make me feel pretty cool for a while — it got old fast.
The benefit of containerization and kubernetes is that I now focus less on pets, and more on cattle. Meaning that if a pod (an app, basically) is crashing, kubernetes notices it, kills it for me, and restarts a new pod before ever notifying me that the site is down. Multiple replicas make this even better, as kubernetes handles load balancing between pods, so my customers never see downtime (unless I’ve really fucked up).
Cost Savings
As an independent maker, I bootstrap almost everything I do. I do have regular income streams to help me maintain my services, but why would I spend the money to run 10 virtual machines, when I can run a 3-node cluster and colocate all my apps and services between them. That’s exactly what I did. My costs are only a bit lower since I made the transition from Digital Ocean to Google Cloud Platform (which is more expensive), but the benefits I get are immense.
Scalability & Response to Traffic Spikes
I’ve had a few of my services hit the front pages of major websites like Hacker News, Reddit and Product Hunt. This kind of exposure sees hundreds of thousands of people visiting your website in a few hours. I’ve had single node, single CPU virtual machines (with swap memory) survive these spikes, but once again, I want my infrastructure to be able to handle anything that’s thrown at it.
Another benefit with the migration to kubernetes is that my sites now have the ability to autoscale, both in terms of pods and nodes. When faced with increased CPU load, my deployments will autoscale, rolling out more pods to support the increased traffic. The best part? It scales down when it’s done to save on costs. For those worried about getting a huge bill in the mail — you can limit how much certain services and clusters will scale, very easily.
Future Proofing
Finally, I strongly believe containerization is the future, and want to set my self up to be able to run my infrastructure anywhere, no matter where I decide to host my sites. Kubernetes is open source, meaning I can run it from pretty much any public cloud, or even my bedroom computer — but for right now, I’m sticking to Google Cloud Platform (GKE).
Thinking About K8?
If you’re an independent maker, I would highly recommend you take a look into kubernetes. The learning curve initially can be a little steep, but once you get going, it’s smooth sailing.
