Before going any further I think it is important to dive a little deeper in to the goals of this series, and, maybe even more importantly, some anti-goals.
Production ready
Throughout this tutorial we’re going to focus on building production ready services. This will be defined better later on, but, for example, deployment, accessability, observability, and SLA’s will all be key considerations throughout. Changes will be driven by made up feature requests, scalability concerns, and org structure changes, but unlike most tutorials, you will start and end each post with an application that is deployed and usable.
Exposure to large swath of the available tools
Before starting the tutorial itself you’ll see a run down of the full tech stack we’re planning on using (not all at once, but by the end on the tutorial). As mentioned in the overview, this tool set was chose for a few different reasons. The primary motivator for selecting such a wide variety of tools is to give an overview of the current landscape that larger than would be possible if a more homongenous tool set was used. If you’re actually building out an application, make sure you’re selecting the right tools for what you’re trying to accomplish and stay consistent.
In reality though, this can be challenging. Tools are selected in almost every real life case with a large number of unknown unknowns. When scaling an actual system, the database you selected when you had 100 users may not be the right choice when you’ve got 10,000, the CI system you selected may have worked well when you had a single monolithic application, but doesn’t work when there are 5 teams working across 10 different applications. This is second motivator behind the tech stack chosen. Early in an application’s life it’s easy to sit at a whiteboard and draw out the ideal application architecture, but as new engineers join with varied backgrounds and new teams emerge it gets harder and harder to maintain consistency. This tutorial attempts to emulate that complexity by changing tooling slightly more than might seem pragmatic.
Deep dives where necessary
The main focus of the tutorial itself is to walk through building and growing an actual application. There will be lots of notes and tips along the way, but in no way would I endorse turning around and using these tools in your production applications without more research. In certain cases, where I think the context would be especially useful or interesting, I’ve broken out deep dive posts that cover tools in much more detail. Note however that these are optional. If a deep dive is broken out from a specific post it will be called out at that point. I would generally recommend finishing the post you’re on before working through the deep dive. If you’re eager to move on to the next topic or just don’t find the deep dive interesting, skip it(!), really, you won’t miss anything necessary for the tutorial. No code written in the deep dives will be used for the main application.
Inject published opinions of industry experts
Throughout this series there are a lot of links out to posts/comments/projects by industry experts. While there’s no right way to do most things, it would be foolhardy for us to reinvent everything we’re doing as we go along. I can’t promise that I will even follow all advised in linked materials as dogmatically as the authors would have intended, but I think that’s OK. In many cases, if a choice made is controvertial or counterintuitive I’ve done my best to provide the rationale for the decision.
Follow industry best practices
This series won’t make you an expert in Go, Kubernetes, Docker, etc., but it hopefully won’t teach you any bad habits. The point of the posts in this series aren’t to teach you the Go programming language or help you become a DevOps Master. Experts in any of the specific toolsets used here will likely disagree with choices that have been made. If you’re one of those experts and something I’ve done is teaching bad habits or is just straight up wrong, open a PR!
Prescribe any individual tool or framework
Nothing used in the tutorial is an endorsement, per se. This series is meant to help navigate the ecosystem of modern day services, not propose a tech stack. While I may have a proclivity for using Go for API’s, and Kubernetes for container orchestration, that doesn’t mean they’ll be write for your use case. Where relevant, I explain why I’ve chosen the tools that I use here, but there are many other tools out there that would have fit the use case equally as well.
Evaluate the efficacy of any one tool as compared to other competing options
This is directly related to the anti goal above. While I may mention other tools available that fit a similar niche, I don’t go in to large amounts of details comparing one tool to its competitors.
Provide enough information to operate any of these tools in a production setting:
This tutorial provides an overview of the tooling and systems used, theres not enough information contained to turn around and use any tooling chosen here the next day. Do your research, pick the right tool for the problem that you are solving and have plans in place for supporting that tooling once it goes live.