50 Projects | Infrastructure
TL;DR The beginning of every journey is hard, that’s doubly true for 50 journeys. So I needed a good kit to turn every week into an efficient journey.
In case you missed why I am even doing this, check out my inspirational post.
My first project
My KPI for creating any project this year is that I would gladly pay for the product. Being an engineer I understand that focus is equally hard as it is important. In the context of all subsequent weeks that means that I need to be able to focus on the aspects that are actually adding value instead of, say, figure out development, deployment, billing etc. every week again. So my first project is actually setting up an infrastructure and process that I would pay for.
You may consider this partly cheating, since I am already paying for my servers, but bear with me for a moment ;-)
When thinking about the workflow I would like to have, I saw basically those options:
- A unique environment tailored to every project’s specific needs on my own servers,
- A single environment allowing only a very specific stack (e.g. full stack javascript plus mongodb), which then is used by all projects on my own servers,
- Allowing a great variety of environments, contained in docker containers, with some forwarding by nginx on my own servers,
- Allowing a great variety of environments, utilizing docker swarm or kubernetes, figuring out binding of (sub)-domains when necessary on my own servers,
- Disregarding my servers and using AWS clusters for all intents and purposes,
- Disregarding my servers and using services like heroku for all projects
All of those have obvious advantages and drawbacks.
Some facilitate broad and/or deep lessons, there’s also cost to be considered, but the biggest factor is probably time. Time, that I need to set things up and time that I need every week.
The very simplest option would probably have been using heroku, especially given the great experience with their toolkit and mangement options. However I also wanted to utilize my own servers.
From a learning perspective I would have preferred using kubernetes on my own servers or on AWS. Following one of the most recommended tutorials for professionals, [Kubernetes, the hard way]https://github.com/kelseyhightower/kubernetes-the-hard-way), I quickly realised that without focussing more time on this than I actually have available, this was the easiest way to blow my pledge from the start. Don’t get me wrong, Kubernetes is exciting and that tutorial shows a lot of the potential, but I would have had to focus more on the infrastructure than on the actual projects. So I needed to look for alternatives.
So then a friend and colleague recommended dokku and I immediately saw that this was what I was looking for. Dokku is a docker-powered PaaS that helps you build and manage the lifecycle of applications.
Fast forward a couple of hours and I have my own servers set up as a Platform running applications either heroku style using buildpacks (featured by the awesome herokuish project) or as docker containers. So whatever fits my development style in a specific project better, I can use it.
When I say platform, what services do I have available so far?
- An open source github clone called Gogs,
- My blog running Ghost,
- Tracking running Piwik,
- Dokku itself with all its perks,
- Databases, should I need them (currently for the blog, gogs and piwik),
- Https for my services using Letsencrypt,
- Notifcations on deployments and changes to my Telegram.
While in the future I might be taking a second look at kubernetes, specifically at Workflow by the Deis project, this is as good as I need it for now. Which is good enough!
Metrics
I spent
- 15 hours on the actual platform (probably 10 on the actual setup, the rest on possible alternatives),
- 6 hours on writing and planning,
- 17 hours on quality time (me, family, kids or with my wife)
While I intended to spend much less time on the actual project, I do hope the additional hours pay off when I don’t have to rethink deployment and pipelines.
Again, my most important KPI was that I create something I would gladly pay for and this week I have done so!
Last thoughts
I will also likely look at options for logging or tracing, monitoring and backup options, secret management and maybe more sophisticated deployment pipelines.
I’m interested in your thoughts on deployments on your bare metal hardware. Let me know in the comments or drop me a message. Also if you are interested, let me know whether you want to know more about working with dokku.
Originally published at blog.50projects.de on January 7, 2018.
