Smashing goals and productionizing software!
Added 2018-11-06 02:17:56 +0000 UTC!!! !!! !!!
LADIES AND GENTS, we are at $ 4 DIGITS $. I am consistently floored by the excitement for LegendKeeper, and it continually fuels my obsession with the project. Thank you so much for everything! I have already opened up lines of communication with a few map makers to commission general purpose maps, so that when you log in to LegendKeeper on Day One, you'll have some awesome maps ready to be used with your world.
In my last public post, I enumerated a brief roadmap for the near-future of LegendKeeper as it makes its way to release. Specifically, in step 5 I discussed that LegendKeeper needed to be prepared for production deployment. This weekend, I decided to step away from feature implementation and focus solely on that productionization, or more succinctly, preparing LegendKeeper to support people other than me using it.
LegendKeeper was prototyped and deployed on Heroku, which is a cloud services provider. In a nutshell, they give you one-click provisioning of computers, databases, search engines, etc. to serve your app with. Heroku is probably the fastest way to get an app off the ground, but there's an issue for small li'l software startups like me: It's EXPENSIVE. The hobby/development tiers are cheap/free enough, but the moment you scale up to a level that needs to handle some traffic, it gets pricy.
Additionally, some of my technical dependencies didn't play nice with Heroku, and required some hacky workarounds that would make scaling hard when I needed it. While I'm a big proponent of not prematurely optimizing, you should still have in your mind a clear path to scaling, and I don't think being completely blocked from the start is a good strategy, especially if it would take only a couple days work to restructure things so that you are a little more future-proof. Plus, it's a good learning opportunity for me.
I've successfully migrated all of LegendKeeper's infrastructure from Heroku over to the Google Cloud Platform, deployed on a mix of Google's App Engine and Kubernetes Engine. App Engine is a lot like Heroku, with considerably more flexibility, and you can think of Kubernetes as a way of building your own Heroku, specialized to the exact needs of your application. Kubernetes is a massive topic on its own and is fairly complex, even to us software engineer folk who are used to rolling around in bits and bytes. Put simply, it allows me to requisition and manage the exact resources I need, while having the capacity for auto-repairing and scaling all of my infrastructure if it ever needs it--No hacky workarounds. Additionally, it ends up being considerably cheaper. This flexibility does come at a another price: Complexity. You pay Heroku to deal with a lot of problems for you; doing things on your own means needing to hop in and get your hands dirty when things go wrong.
All that being said, the whole process went pretty smoothly and I learned a ton! I've barely scratched the surface of Kubernetes, but from an engineering perspective, LegendKeeper now has both a development and production deployment pipeline, as well as a scalable infrastructure to support it on Day One. If you're an engineer, you might be thinking "Why the hell does an app like LegendKeeper need Kubernetes?" You'd be right in that there are tons of ways to build an app like LK, but I really like the flexibility Kubernetes gives me, and it makes deployment a breeze. I just need to add some data caching in a few places on the API server, and fix a bug I found in the search engine code, and Roadmap Step #5 will be diggity done.
Thanks for reading!
Braden