{"id":46897332,"url":"https://github.com/felipe-veas/platform-engineering-model","last_synced_at":"2026-03-10T23:33:45.871Z","repository":{"id":339879131,"uuid":"1163695827","full_name":"felipe-veas/platform-engineering-model","owner":"felipe-veas","description":"A reference model for building and scaling internal developer platforms in modern organizations","archived":false,"fork":false,"pushed_at":"2026-02-22T02:18:37.000Z","size":19,"stargazers_count":0,"open_issues_count":0,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-02-22T09:58:37.746Z","etag":null,"topics":["developer-experience","devops","documentation","internal-developer-platform","platform-engineering"],"latest_commit_sha":null,"homepage":null,"language":null,"has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/felipe-veas.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-02-22T02:04:23.000Z","updated_at":"2026-02-22T02:34:59.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/felipe-veas/platform-engineering-model","commit_stats":null,"previous_names":["felipe-veas/platform-engineering-model"],"tags_count":null,"template":false,"template_full_name":null,"purl":"pkg:github/felipe-veas/platform-engineering-model","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/felipe-veas%2Fplatform-engineering-model","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/felipe-veas%2Fplatform-engineering-model/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/felipe-veas%2Fplatform-engineering-model/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/felipe-veas%2Fplatform-engineering-model/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/felipe-veas","download_url":"https://codeload.github.com/felipe-veas/platform-engineering-model/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/felipe-veas%2Fplatform-engineering-model/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":30362120,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-03-10T21:41:54.280Z","status":"ssl_error","status_checked_at":"2026-03-10T21:40:59.357Z","response_time":106,"last_error":"SSL_connect returned=1 errno=0 peeraddr=140.82.121.5:443 state=error: unexpected eof while reading","robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":false,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["developer-experience","devops","documentation","internal-developer-platform","platform-engineering"],"created_at":"2026-03-10T23:33:45.326Z","updated_at":"2026-03-10T23:33:45.861Z","avatar_url":"https://github.com/felipe-veas.png","language":null,"readme":"# Platform Operability\n\n## Overview\n\nThis repository is the foundational handbook for how we design, build, and operate internal developer platforms to make production fundamentally safer. The primary audience includes senior engineers, Site Reliability Engineers (SREs), platform teams, and engineering management.\n\nThe operational philosophies codified here aren't theoretical. They come from running large-scale distributed systems and recovering from severe organizational reliability failures. This isn't a Kubernetes tutorial, a GitOps implementation guide, or a CI/CD setup manual. It's a blueprint for organizational reliability maturity, platform thinking, and operational safety design. Our objective is to let product teams ship software fast and safely without forcing them to become infrastructure experts.\n\n## 1. The Operational Problem: The Blast Radius of Human Error\n\nAs engineering organizations scale, production complexity grows exponentially. We consistently see the same critical problem: expecting product engineers to also be infrastructure experts. In a growing microservices architecture, the cognitive load required to manage cloud networking, IAM, container orchestration, and stateful data stores becomes overwhelming. When product developers have to manage their own infrastructure without strong abstractions, they constantly context-switch between application logic and systems administration.\n\nThis context switching isn't just annoying; it drives production incidents. When a developer who spends 90% of their time writing application code suddenly has to configure a production database cluster or debug a network policy, they will make mistakes. The blast radius of these errors expands as the company grows, resulting in misconfigured security groups, untracked changes, and fragile \"snowflake\" environments held together by one person's tribal knowledge. Human capacity for managing complexity is finite. Pushing operational complexity onto developers guarantees failure at scale.\n\n## 2. The Incorrect Solution: The Extremes of \"DevOps\" and \"ITIL\"\n\nOrganizations usually try to fix this by swinging toward one of two dangerous extremes. The first is a naive take on \"You build it, you run it.\" To force accountability, management hands product teams raw access to cloud consoles and puts them on brutal on-call rotations. They assume accountability magically generates operational expertise. Instead, it generates burnout, deployment fear, and a highly fragmented infrastructure where every team reinvents the wheel and ignores security practices just to ship on time.\n\nThe second incorrect solution is reactionary ITIL (Information Technology Infrastructure Library) governance. Organizations build isolated \"Ops\" silos that act as human firewalls. Every infrastructure change, deployment, and configuration update gets gated behind Jira tickets, manual reviews, and Change Advisory Board (CAB) meetings. This assumes human scrutiny scales and that adding approval layers creates safety.\n\n## 3. The Reliability Risks Created\n\nBoth approaches actively degrade reliability. The free-for-all access model creates systemic configuration drift. Because infrastructure is provisioned manually or via isolated scripts, there is no single source of truth for production state. During an incident, responders can't trust the documentation. Mean Time To Recovery (MTTR) skyrockets because debugging requires reverse-engineering the environment on the fly.\n\nConversely, the \"human firewall\" approach destroys deployment frequency and inadvertently increases risk. When deploying is painful, slow, and bureaucratic, teams naturally batch changes into massive, infrequent releases. Large batch deployments are inherently dangerous. When a massive release fails, the rollback is complex and highly disruptive. Furthermore, human gatekeepers in a CAB rarely have the deep context needed to evaluate technical risk, turning the approval process into operational theater instead of actual safety.\n\n## 4. A Safer Platform-Oriented Approach\n\nTo get both high velocity and high reliability, we have to treat the internal developer platform as a critical product where the primary feature is operational safety. A well-designed platform abstracts operational complexity and codifies safety mechanisms. It provides \"paved paths\"—standardized, supported workflows where the most secure and reliable way to deploy software is also the easiest.\n\nInstead of demanding developers master infrastructure, the platform handles the undifferentiated heavy lifting. It decouples the intent of a deployment from its execution. Developers declare what they need (e.g., \"a resilient database,\" \"a stateless web service\"), and the platform's control plane makes it happen, automatically handling provisioning, networking, observability, and failovers. The platform ensures all resources are secure by default, compliant with policy, and wired into the incident response framework.\n\n## 5. Emphasizing Decision-Making and Operational Behavior\n\nPlatform engineering is an exercise in shaping human behavior and organizational culture. The goal isn't to remove developer accountability, but to eliminate unnecessary cognitive load so they can focus on their actual domain. Product engineers still own the business logic, performance, and health of their services. The platform just gives them the capabilities to operate those services safely.\n\nWe need to shift organizational decision-making away from tribal knowledge, heroic firefighting, and manual runbooks. We need to move toward codified intent, automated guardrails, and deterministic state reconciliation. Through the documents in this repository, you'll see how to design systems that prevent incidents before they happen, structure safe self-service interfaces, and manage production risk at scale by prioritizing architectural control over human intervention.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffelipe-veas%2Fplatform-engineering-model","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Ffelipe-veas%2Fplatform-engineering-model","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Ffelipe-veas%2Fplatform-engineering-model/lists"}