1~
2Habang nagiging mas kumplikado ang mga software system  -  microservices, Kubernetes, multi-cloud, CI/CD pipelines, observability stacks  -  mas maraming oras ang ginugugol ng mga developer sa infrastructure at mas kaunti sa pagbuo ng mga produkto. Nilulutas ng **Platform Engineering** ito sa pamamagitan ng paglikha ng internal platform na nag-a-abstract ng complexity at nagbibigay sa mga developer ng self-service tools para mas mabilis na mag-ship.
3~
4Hinuhulaan ng Gartner na sa 2027, **80% ng mga software engineering organization** ay magtatayo ng platform teams. Sa gabay na ito, tuklasin natin kung ano ang Platform Engineering, bakit ito mahalaga, at paano bumuo ng Internal Developer Platform mula sa simula.
5~
6## Ano ang Platform Engineering?
7~
8Ang Platform Engineering ay ang disiplina ng pagdisenyo at pagbuo ng mga toolchain at workflow na nagbibigay-daan sa self-service capabilities para sa mga software engineering organization. Ang output ay isang **Internal Developer Platform (IDP)**  -  isang layer na nasa pagitan ng mga developer at infrastructure.
9~
10```mermaid
11graph TD
12    subgraph "Developers"
13        D1[Frontend Team]
14        D2[Backend Team]
15        D3[Data Team]
16    end
17~
18    subgraph "Internal Developer Platform"
19        Portal[Developer Portal]
20        Templates[Service Templates]
21        CICD[CI/CD Pipelines]
22        Infra[Infrastructure Abstraction]
23    end
24~
25    subgraph "Infrastructure"
26        K8s[Kubernetes]
27        Cloud[Cloud Services]
28        DB[Databases]
29        Monitor[Monitoring]
30    end
31~
32    D1 --> Portal
33    D2 --> Portal
34    D3 --> Portal
35    Portal --> Templates
36    Portal --> CICD
37    Portal --> Infra
38    Infra --> K8s
39    Infra --> Cloud
40    Infra --> DB
41    CICD --> Monitor
42```
43~
44### Platform Engineering vs DevOps
45~
46Ang Platform Engineering ay hindi kapalit ng DevOps  -  ito ang susunod na evolution. Sinabi ng DevOps na "ikaw ang gumawa, ikaw ang magpatakbo." Sinasabi ng Platform Engineering na "gagawin naming madali ang paggawa at pagpapatakbo."
47~
48| Aspeto | DevOps | Platform Engineering |
49|--------|--------|---------------------|
50| **Focus** | Kultura at mga praktis | Mga produkto at self-service |
51| **Diskarte** | Bawat team ang namamahala ng infra | Ang platform team ang nag-a-abstract ng infra |
52| **Cognitive Load** | Mataas (bawat team natututo ng lahat) | Mababa (may golden paths na ibinibigay) |
53| **Output** | CI/CD pipelines, IaC scripts | Internal Developer Platform |
54| **Users** | Lahat ng engineering | Ang platform team ang naglilingkod sa engineering |
55~
56## Bakit Mahalaga ang Platform Engineering
57~
58### Ang Problema ng Cognitive Load
59~
60Sa isang tipikal na modernong organisasyon, kailangang maunawaan ng developer ang:
61~
62- Mga Git workflow at branching strategy
63- CI/CD pipeline configuration
64- Container building at registry management
65- Kubernetes manifests at Helm Charts
66- Cloud provider services (AWS/GCP/Azure)
67- Networking, DNS, TLS certificates
68- Monitoring, logging, alerting setup
69- Database provisioning at migrations
70- Security policies at compliance
71~
72Napakalaking cognitive burden iyan na nag-aalis ng focus sa totoong produkto.
73~
74### Ang Golden Path
75~
76Ipinapakilala ng Platform Engineering ang konsepto ng **golden paths**  -  opinionated, maayos na sinusuportahan, at dokumentadong mga landas para sa karaniwang mga gawain. Ang golden path ay hindi mandato; ang mga developer ay *maaaring* lumihis, pero ginagawa ng platform ang tamang bagay na madaling bagay.
77~
78```mermaid
79flowchart LR
80    Dev[Developer] -- "Create new service" --> Portal[Portal]
81    Portal -- "Select template" --> Template[Service Template]
82    Template -- "Auto-provision" --> Repo[Git Repository]
83    Template --> Pipeline[CI/CD Pipeline]
84    Template --> Infra[Kubernetes Namespace]
85    Template --> Monitor[Dashboards + Alerts]
86    Repo --> Ready[Ready to Code!]
87```
88~
89**Halimbawa ng golden path para sa paglikha ng bagong microservice:**
901. Pumipili ang developer ng "Bagong Backend Service" sa portal
912. Pumipili ng wika/framework (Node.js, Go, Python)
923. Awtomatikong gumagawa ang platform ng: Git repository, CI/CD pipeline, Kubernetes namespace, monitoring dashboards, at alert rules
934. Kino-clone ng developer ang repository at nagsisimulang mag-code kaagad
94~
95## Pagbuo ng Internal Developer Platform
96~
97### Layer 1: Developer Portal
98~
99Ang portal ay ang iisang entry point para sa mga developer. Ang pinakasikat na open-source option ay ang **Backstage** (ginawa ng Spotify, ngayon ay CNCF project).
100~
101Mga pangunahing feature:
102- **Service catalog**: Bawat service, ang may-ari nito, dokumentasyon, at mga dependency
103- **Software templates**: Scaffolding para sa bagong mga service na may built-in best practices
104- **Tech docs**: Documentation as code, rendered at searchable
105- **Plugin ecosystem**: Extensible gamit ang custom functionality
106~
107```yaml
108# backstage/catalog-info.yaml
109apiVersion: backstage.io/v1alpha1
110kind: Component
111metadata:
112  name: user-service
113  description: Manages user accounts and authentication
114  annotations:
115    github.com/project-slug: myorg/user-service
116    backstage.io/techdocs-ref: dir:.
117spec:
118  type: service
119  lifecycle: production
120  owner: team-auth
121  system: identity-platform
122  dependsOn:
123    - resource:postgresql-main
124  providesApis:
125    - user-api
126```
127~
128### Layer 2: Infrastructure Abstraction
129~
130Hindi dapat direktang sumulat ang mga developer ng Terraform o Kubernetes YAML. Dapat magbigay ng mga abstraction ang platform.
131~
132**Mga Tool:**
133- **Crossplane**: Kubernetes-native infrastructure provisioning
134- **Terraform na may modules**: Pre-built, tested infrastructure modules
135- **Pulumi**: Infrastructure bilang totoong code (TypeScript, Python, Go)
136~
137```yaml
138# Example: Crossplane composition for a database
139apiVersion: database.example.com/v1
140kind: PostgreSQLInstance
141metadata:
142  name: user-db
143spec:
144  size: small        # Abstraction: small = 2 vCPU, 4GB RAM
145  version: "16"
146  backup: daily
147  team: auth-team
148```
149~
150Sa halip na i-configure ang mga RDS parameter, VPC subnet, security group, at backup policy, ang developer ay tinutukoy lang ang `size: small` at `backup: daily`. Ang platform ang bahala sa natitira.
151~
152### Layer 3: CI/CD Standardization
153~
154I-standardize ang CI/CD para hindi bawat team ang gagawa ng sariling pipeline.
155~
156```yaml
157# .github/workflows/platform-ci.yml
158# Teams just include the shared workflow
159name: Build and Deploy
160on:
161  push:
162    branches: [main]
163~
164jobs:
165  pipeline:
166    uses: myorg/platform-workflows/.github/workflows/standard-pipeline.yml@v2
167    with:
168      language: node
169      deploy-target: production
170    secrets: inherit
171```
172~
173**Mga pangunahing praktis:**
174- Shared CI/CD templates na ini-include ng mga team (hindi kinokopya)
175- Awtomatikong security scanning (SAST, dependency audit)
176- Standardized deployment strategies (canary, blue/green)
177- Awtomatikong rollback sa failed health checks
178~
179### Layer 4: Observability
180~
181Pre-configured monitoring para makakuha ang mga developer ng dashboards at alerts kaagad.
182~
183- **Metrics**: Prometheus + Grafana na may standard dashboards bawat service
184- **Logging**: Structured logging na may centralized collection (Loki, ELK)
185- **Tracing**: Distributed tracing gamit ang OpenTelemetry
186- **Alerting**: PagerDuty/Opsgenie integration na may sensible defaults
187~
188```mermaid
189graph LR
190    Service[Your Service] -- "OpenTelemetry SDK" --> Collector[OTel Collector]
191    Collector --> Prometheus[Prometheus]
192    Collector --> Loki[Loki]
193    Collector --> Tempo[Tempo]
194    Prometheus --> Grafana[Grafana Dashboards]
195    Loki --> Grafana
196    Tempo --> Grafana
197    Grafana --> PagerDuty[PagerDuty Alerts]
198```
199~
200## Pagsukat ng Tagumpay
201~
202Paano mo malalaman na gumagana ang platform mo? I-track ang mga metrics na ito:
203~
204### DORA Metrics
205- **Deployment frequency**: Gaano kadalas umabot ang code sa production
206- **Lead time para sa mga pagbabago**: Oras mula sa commit hanggang production
207- **Change failure rate**: Porsyento ng mga deployment na nagdudulot ng mga pagkabigo
208- **Mean time to recovery**: Oras para maibalik ang service pagkatapos ng incident
209~
210### Platform-Specific Metrics
211- **Oras hanggang sa unang deploy**: Gaano katagal mula sa "bagong service" hanggang sa unang production deploy
212- **Developer satisfaction (NPS)**: Regular na i-survey ang mga user mo
213- **Self-service ratio**: % ng infrastructure requests na nahahawakan nang walang tickets
214- **Golden path adoption**: % ng mga service na sumusunod sa recommended path
215~
216## Mga Karaniwang Pagkakamali
217~
218### 1. Labis na Ginagawa, Masyadong Maaga
219Magsimula sa pinakamalaking pain point, hindi sa malaking vision. Kung masakit ang mga deployment, magsimula doon. Kung ilang linggo ang provisioning, magsimula doon.
220~
221### 2. Hindi Tinatrato ang Platform bilang Produkto
222Kailangan ng platform team ang product manager, user research, at feedback loops. Ang mga developer ang iyong mga customer  -  unawain ang kanilang mga pangangailangan.
223~
224### 3. Ipinipilit sa Halip na Aakitin
225Ang pinakamahusay na mga platform ay boluntaryong ginagamit dahil pinapadali nila ang buhay ng mga developer. Kung kailangan mong ipag-utos ang paggamit, hindi sapat ang kabutihan ng platform mo.
226~
227### 4. Binabalewala ang Developer Experience
228Ang platform na may masamang UX ay hindi gagamitin. Mag-invest sa malinaw na dokumentasyon, kapaki-pakinabang na error messages, at mabilis na feedback loops.
229~
230## Paano Magsimula
231~
232Isang praktikal na roadmap para sa pagbuo ng iyong unang IDP:
233~
234```mermaid
235flowchart TD
236    A[Month 1-2: Discovery] --> B[Month 3-4: MVP]
237    B --> C[Month 5-6: Iterate]
238    C --> D[Month 7+: Scale]
239~
240    A --> A1[Interview developers]
241    A --> A2[Map pain points]
242    A --> A3[Choose first golden path]
243~
244    B --> B1[Deploy Backstage]
245    B --> B2[First service template]
246    B --> B3[Standardized CI/CD]
247~
248    C --> C1[Gather feedback]
249    C --> C2[Add infrastructure abstraction]
250    C --> C3[Improve docs and onboarding]
251~
252    D --> D1[More templates and golden paths]
253    D --> D2[Self-service infrastructure]
254    D --> D3[Advanced observability]
255```
256~
257### Minimum Viable Platform
258~
2591. **Service catalog** (Backstage)  -  alamin kung ano ang umiiral at kung sino ang may-ari
2602. **Isang service template**  -  golden path para sa pinakakaraniwang uri ng service mo
2613. **Standardized CI/CD**  -  shared pipeline na ini-include ng mga team
2624. **Basic docs**  -  paano gamitin ang platform, saan humingi ng tulong
263~
264Magagawa mo ang MVP na ito sa 2-3 buwan na may team na 2-3 engineers.
265~
266## Konklusyon
267~
268Ang Platform Engineering ay hindi tungkol sa pagbuo ng perpektong platform mula sa unang araw. Ito ay tungkol sa unti-unting pagbawas ng cognitive load sa mga developer para makapag-focus sila sa pagbuo ng mga produkto. Magsimula nang maliit, sukatin ang impact, at mag-iterate batay sa developer feedback.
269~
270Ang mga organisasyong nag-iinvest sa Platform Engineering ay magkakaroon ng malaking competitive advantage: mas mabilis na delivery, mas masayang mga developer, at mas reliable na mga sistema.
271~
272**Mga Resources:**
273- [Team Topologies](https://teamtopologies.com/)  -  ang librong nagpopularize ng platform teams
274- [Backstage](https://backstage.io/)  -  ang open-source developer portal ng Spotify
275- [CNCF Platforms White Paper](https://tag-app-delivery.cncf.io/whitepapers/platforms/)  -  community definition at best practices
276- [platformengineering.org](https://platformengineering.org/)  -  community, events, at resources
277~