Aspiring To Be A Network Of Loosely Coupled Gitnodes Over Being An Organization of Github Repos

This is some of my thoughts around a new design of a Docker driven micro-service that I'm contemlating deploying as part of my infrastructure. I depend on Github, in a big, big way. It runs all of my sites, web apps, and stores much of my super top secret code and algorithms—Github plays a pretty central role in overall API Evangelist operations.

When it comes to Git, Github, and the Github API I use less than 25% of the functionality available to me on the platform. I depend on the version and user control, pages hosting, and read, write, and delete pages through the API, as well as the Git interface. As I ponder my plan B, and plan C option for my network, I’m thinking about a design for a modular version of how I use Github, as a micro-service running in a Docker container.

This containerized version of how I use Github, would utilize Git, have a basic file system API, and use Jekyll as a CMS, all the goodness I would require in an independent node. Don’t get me wrong, I love Github, but ever since hearing Mike Amundsen's (@mamund) talk in Sydney Australia, a couple weeks ago, I’ve been thinking about how I can evolve my platform to be series of nodes vs a hub.

I will call my new API driven, Git-centric, dockerized micro-service, Gitnode. When ready, i should be able to run my Gitnode anywhere I want. On my AWS, Google, or any other infrastructure I use to host my Docker containers. I predict I will still heavily use Github for many of my sites, but for some elements of my infrastructure, using a Githnode might make more sense.

I will design Gitnode as a standalone micro-service, that runs in Docker, as I'm doing with the rest of my stack. I anticipate I will eventually have several variations of Gitnode, but for now, I just want to mimic the website hosting I achieve through Github, and from there I'll branch out.