Reddit DevOps

regularly; this system should allow for the concept of shared and app-specific configuration, particularly for microservice-based architectures
- A pre-built configuration package they can easily include into any codebase that knows how to read the automatically provided config
- Infrastructure that will automatically scale their code up or down based on need, and scale itself up or down based on how much the code needs to be scaled

I'm generalizing and I'm sure there are some additional details I could add, but on the whole, the work I've seen devops teams pour time into has typically been to implement some subset of the above. I have seen teams have varying levels of success doing so with a whole bunch of different tools, some home-grown, some commercial, some open-source, but all of them quite different. And I'm sick of it.

We all want the same thing, and there is, GENERALLY SPEAKING, an "ideal" devops pipeline and infrastructure out there that checks all the boxes, but it requires strong interplay between assumptions made by the infrastructure and codebases fulfilling those assumptions. That brings me to my core thesis:

We need to start viewing devops and infrastructure like compilers, not editable pipelines

When you start writing code, you don't rewrite your compiler or your interpreter to fix your janky code. The compiler/interpreter knows what's right and what's wrong and publishes a clear interface for how you need to be doing things, and if you do them wrong, you fix your code, not the compiler/interpreter. Too many times have I seen teams force changes to a pipeline due to poor coding and software development practices rather than problems in a pipeline. Once those poor practices have been normalized it is incredibly difficult to change them. If you normalize good practices from day 1, everyone gets used to it and no one grumbles.

Our devops pipelines should provide a clear interface for what is considered acceptable code, and code should be modified to fit that interface, not the other way around

If the code fulfills the interface, infrastructure can make SO MANY assumptions that provides that same code a huge number of pre-configured systems and advantages that then don't need to be configured by a dedicated devops team.

A crucial part of accomplishing this successfully is providing a very easy-to-use entrypoint to that interface. Usually, I implement this in the form of "template" repos that act as quickstarts; this is a repo in the target coding language that has a main file with a clear entry point to start writing code and all the observability and config packages pre-configured. This repo will also typically include a compliant Dockerfile and Makefile. Make sure that as few build files have to be configured as possible. The idea here is to create a "pit of success": the easiest path is the correct path. A developer can clone the repo, start writing code, push the new repo, and the pipelines take care of the rest.

The trick is always to balance out maintaining enough customizability that most applications can fit the interface, without making it so generic that making things works requires a lot of app-specific work, but I believe there is a balance that fits MOST applications; not necessarily ALL applications, but MOST.

I've been building out such a system using exclusively open-source tools for the past year and I think it works quite well and is applicable to most of the companies I've worked at. What I like about it is there's no vendor lock-in and can be deployed single- or multi-tenant, so it could be deployed entirely separately or used as a PaaS. I'm having some trouble motivating myself to finish it recently and figured I'd get feedback from the devops community to hear if:

1. They apply these sorts of principles at their own jobs

2. If so, have they found it to be useful, and have they found success in doing so; if not, what technical or non-technical barriers have they encountered

3. If they know of any tools or companies that accomplish this or some subset of this (and

3 views22:32