The superset of 12factor is platform engineering, especially managing stateful backend components. I worked at a MAANG where both manual discovery (documentati

The superset of 12factor is platform engineering, especially managing stateful backend components. I worked at a MAANG where both manual discovery (documentation) AND automated discoverability were completely haphazard and often missing because everything was home-grown. Important takeaways should be: - Don't reinvent everything without a specific problem that cannot be solved with reasonable scaling of what already exists. - Theory of least surprise. - Churn is bad. Don't change APIs or functionality for "refactoring" reasons. Replacing something with Rust is no excuse for leaving it broken for a month. - Don't duplicate functionality without differentiated purposes. - Make the purpose of a service and it's use-cases crystal clear. - Name things sensibly rather than giving them cute names. - Standardize stateful storage into a common API that allows for interchangeable and migratable backends. - Document everything into a wiki that's consistent, organized, and is maintained by dedicated, effective technical writers. Don't brain spew text into massive documents! - Following the previous, have a comprehensive service catalog. - Don't assume the reader knows what you know. Explain everything from primitives. - Aim for self-service. - Service owners and/or their operations support must be professional and available enough to provide input when self-service, board messaging, and peer discussions are unable to provide an authoritative resolution. - Reuse, reuse, reuse, and reuse some more. - Build tools that can visualize, chart, and record query results from almost anywhere. - Don't be Twitter: Build selective authorization into every internal API. - Least (but necessary) privilege: issue enough reason-tagged authority delegations such that people can do their jobs. Locking down every bit of internal telemetry and analytics preventing joins between datasources doesn't scale OR create a situation where people are perennially in technical violation of the wording of official policy to do their jobs. - Reward the reduction and efficient maintenance of code because too often, only adding features is rewarded. - Don't make the common cases difficult and awkward. - Avoid code generation. - Avoid unnecessary layers of abstraction. - Avoid building layer upon layer of CLI codegen or service commands lacking in documentation and missing man pages. - Hire some people with actual software engineering, software architecting, systems engineering, and systems operations experience. (The names and responsibilities of these roles seem to change every 5 years now without any particular logic.)