✶ Simple Is Funner than Complex
About half a decade ago, I distinctly remember wishing I had my own side projects that other people used. These days that's my reality, as I've got some tools and a few living deployed web applications out in the wild. Here are the ones relevent to this post:
- nkantar.com is my personal site
- Starminder reminds you about your starred GitHub projects
- SendOtterLove brings otters and puns to your loved ones
- PyBeach.org is a redirect to the PyBeach 2020 site
- nik.pub is barely a URL shortener
Since I'm v. lazy, these are all currently deployed on Heroku, which is a wonderful, exceedingly painless hosting service. It's also quite expensive for my particular use case.
The above projects cost me a total of $42 per month:
- nkantar.com requires one web dyno to run the Flask app
- Starminder requires two dynos—one for the Flask app, and one for the task runner
- SendOtterLove is a single-dyno Django app
- PyBeach.org is a single-dyno micro-app
- nik.pub is also a single-dyno Django app
Heroku charges $7 per dyno per month for the base paid tier ("Hobby"), which is required for constant uptime (free dynos sleep 6 hours per day) and SSL (https is a hard requirement for some of the above apps, and I'm quite fond of it anyway). I find this to be a very reasonable pricing model, if you want to deploy things that, uhh, get used.
But my projects don't really get all that much attention. Traffic on all of the above is nearly nonexistent, averaging less than one request per second:
But I like them all, and don't want them to go away. I'm also unwilling to compromise uptime or SSL to drop down to the free dyno tier.
Given that the performance requirements for all of the above are also nearly nonexistent, I've always thought something as minimal as AWS Lambda would make for a perfect hosting platform. Now that I use Lambda at work a fair bit, that belief has only been reinforced. Relatedly, I have some AWS credit I'd like to use, especially as I'd wager that everything I have would fit into the free tier for most services I'd harness, giving me oodles of free hosting.
So why, then, have I struggled so much to carve out the reasonably small amount of time and energy required to migrate these—or even just one of them—over?
I think the answer is a bit deeper than the reflexive and superficial guess of "well, I am lazy" or "if it ain't broke, don't fix it".
Side Projects vs. Day Job
Software I write on my own time generally doesn't serve any work related purpose and isn't expected or even meant to get me paid directly. Most of it is open source, and it's a mix of web apps, libraries, and other miscellaneous stuff. It's all at least somewhat important to me.
A side project is by necessity of lower priority than the work I do at my day job. I quite like said job and find the work itself very rewarding. While I'm unwilling to compromise my ability to write software on my own time, I don't subject my job to any negative effects that could have. In short, work always comes first.
sweetgreen lives on AWS, so my work involves thinking through a lot of cloud related things. I'm no longer contributing to monoliths deployed on servers, but orchestrating services running on some combination of Lambda, containers, and managed services. Much of my job now is understanding the landscape of available tools and how to best glue them together to get the built-in advantages. I spend less time than ever actually writing application code.
This isn't necessarily a bad thing at all. I enjoy systems design and architecture—it's very challenging and rewarding work. The benefits of the cloud approach are pretty stellar much of the time as well—AWS really provides an awful lot services I don't have to manage at all, and that's great. But it doesn't feel playful or simple just about ever. And I miss that.
Work vs. Play
Many moons ago, when I still very much called myself a web developer, I generally thought of myself as "full-stack". Even though I'd done enough SysAdmin work to get things up and running, this mostly referred to my ability and desire to write code for both the server and the client in the context of web apps. Depending on which one I was working with for the most part at my day job at any given time, I tended to play with the other after hours. This kept me engaged and fulfilled without feeling negatively about work, which may have slanted heavily on occasion.
It's now been some time since I've thought of myself as a web dev, and much longer since I last used the phrase "full-stack" to describe what I do—or want to do. Lately I've invested energy into organizing events instead of writing software, which has left work as the only place where the engineering parts of my mind get a workout. I haven't felt like that in and of itself is a problem, but I do think that a different kind of separation is something I miss.
With the complexity I already tackle daily, I think I may be craving simplicity.
Now What?
I bet this explains why I've been so reluctant to dive into migrating my projects to
AWS: I don't really want to deal with the complexity of rearchitecting everything and
then managing that over time.
I just want to write some Python and share the results with other people.
To paraphrase the third line of my favorite PEP, simple is better funner than complex.
In light of this, I think I'm going to adopt an anti-cloud approach for these apps. I can probably rearchitect them all as fairly simple Django projects and deploy them on Lambda or ECS (if it turns out to be simple enough), or even EC2s (if it doesn't). Not flashy, cool, or full of new things to learn, no. But likely to be simple, enjoyable, and easy to maintain. Given that these are products that cost me time while netting very little in return, this feels like the correct trade-off.
We'll see if I'm right soon enough.
"Black Cat Holding Persons Arm" by Ruca Souza on Pexels
Thanks for reading! You can keep up with my writing via the feed or newsletter, or you can get in touch via email or Mastodon.
Keynotes to Watch
Goals for 2019 in Review