Modern applications demand more than just faster deployment - they require a fundamental shift in how you think about design, delivery, and operations. As organizations move from waterfall to DevOps to cloud-native architectures, platform engineering has emerged as the discipline that ties it all together, creating the foundation for high-performing software teams.

Main Insights

• Modern apps must be built on five core principles: cloud-native composable/API-first architectures, declarative GitOps-driven delivery, observability with closed-loop automation, zero-trust security by design, and platform engineering as foundation
• Platform engineering transforms abstract DevOps methodologies into concrete deliverables through Internal Developer Platforms (IDPs) that reduce cognitive load while maintaining developer autonomy
• Zero-trust security isn't a single firewall solution - it requires workload-level identity, granular network segmentation, and continuous verification at every layer
• Observability means correlating vast amounts of telemetry data into actionable insights tied to SLOs, not just collecting metrics

​

Jad El-Zein brings over 26 years of IT industry experience to this discussion, including 11 years with Lockheed Martin and more than 15 years at VMware and Broadcom. As a principal technologist at VMware by Broadcom, he has led major IT transformation initiatives for U.S. Federal agencies and global enterprises, with expertise spanning full-stack datacenter and cloud architectures, cloud management and automation, AI and ML development, and modern application platforms. He holds two U.S. patents focused on machine learning approaches to cloud optimization.

You can watch the full discussion here if you missed it: https://www.youtube.com/live/X6R57b0KLGQ

The evolution: From waterfall to platform engineering

The journey to modern applications didn't happen overnight. The waterfall era worked for a time, with requirements defined upfront and software built and tested in sequential phases. But it couldn't keep pace with rising complexity or business demands.

DevOps represented a huge leap forward, breaking down silos between development and operations while introducing automation, continuous integration and delivery, and a culture of shared responsibility. Yet DevOps largely operated within the constraints of traditional infrastructure.

The cloud-native era changed everything. Applications now must be designed for elasticity, scale, and resilience from day one. New greenfield apps are composed of microservices, built for Kubernetes, and deployed with GitOps practices. As El-Zein notes, "Where waterfall was slow and fragile, cloud native is agile and self-healing."

This evolution wasn't just about changing tools - it represented a fundamental shift in mindset. Organizations moved from predictable release cycles to continuous innovation, from infrastructure management to platform engineering, and from isolated teams to cross-functional collaboration with developer experience front and center.

Principle 1: Cloud-native composable, API-first architectures

Composability allows you to lifecycle one capability or service without redeploying the entire application and all its dependencies. Think of it as building with Lego blocks - you can swap out individual pieces without tearing down the whole structure.

"Composability turns the platform into a programmable catalog," El-Zein explains. This approach creates layers: base services and infrastructure at the bottom (more static capabilities like shared data services, physical infrastructure, CPU, memory, networks), reusable components in the middle, and applications at the top. All of these feed into your data, connectivity, and security.

When you want to build a specific application, making it composable allows you to be flexible and agile when any of those more static components change. Instead of ripping out and replacing huge swaths of code, you identify the pieces that need to change and replace just that component or module.

API-first design makes composability reliable. Development teams define the API spec or Kubernetes Custom Resource Definition (CRD) and functional details for respective services upfront. Each API becomes a contract that everyone agrees on - your platform engineering team, your engineers, and so on. These contracts form the foundation for your composable modules.

In the world of Kubernetes and microservices, the Kubernetes declarative API becomes your go-to. This concept extends beyond just building services for new apps - it applies to building the infrastructure itself. When provisioning or deploying entire clouds and platforms, you can leverage these same constructs and capabilities.

Principle 2: Declarative GitOps-driven delivery and operations

Over the last four or five years, the industry has largely settled on declarative configuration and continuous reconciliation as the baseline for provisioning and lifecycling modern applications. This commonality spawned GitOps.

The Cloud Native Computing Foundation's Open GitOps initiative calls out four core principles:

• Declarative - The desired state of your system is declared
• Versioned and immutable - All changes are tracked in version control
• Pulled automatically - Software agents automatically pull the desired state
• Continuously reconciled - The system continuously works to match the desired state

Many teams suggest they follow all these GitOps processes without necessarily doing it to the letter, but the important thing is that when you adopt GitOps you gain reproducibility, rollback simplicity, and full change audit history. As El-Zein puts it, "It almost writes its own recovery plan or runbook."

For regulated environments - federal agencies, banking, healthcare - these properties are essential. Git becomes your single source of truth for Kubernetes objects, network policies, pipeline definitions, and even telemetry wiring. A GitOps controller (Argo CD, Flux) continuously observes and reconciles actual state with that desired state, surfacing drift and enabling fast, auditable rollbacks.

Principle 3: Observability and closed-loop automation

Observability is not just collecting metrics. Modern apps and their infrastructure produce metrics, logs, traces, events, and alerts at scale. Observability is the ability to collect, correlate, and translate that telemetry into actionable insights.

Telemetry must drive decisions. You want to know what is about to happen, not just what already happened. That is why Service Level Objectives (SLOs) are central: they frame user-centric tolerances (for example, "99.9% of account inquiries must be completed in 500 ms"). Observability provides the measurement framework to assess and act on those objectives.

Treat telemetry configuration as code: metrics pipelines, dashboards, alert rules, SLO definitions, and runbooks must live in version control alongside infrastructure manifests. That allows you to iterate quickly when an SLO is missed - change detectors, tweak thresholds, and update runbooks in a controlled, auditable way.

Building closed-loop automation means wiring telemetry into decision paths: alerting that triggers automated mitigations (scale-ups, circuit breakers), and telemetry-driven runbooks that escalate only when human intervention is required. Use OpenTelemetry agents, Prometheus-style scraping, and centralized correlation to make that loop practical.

Principle 4: Zero-trust security, compliance, and resilience by design

Zero-trust starts with the assumption that nothing is inherently trusted. Not code, not pods, not nodes, not the network, not users. Every request requires explicit authentication, authorization, and inspection.

Microservices architectures change the perimeter: the real boundary is the workload itself. Implement zero-trust through workload identity (mutual TLS), granular east-west segmentation, service-account least privilege, and continuous verification. Distributed firewalls, IDS/IPS, and per-vNIC controls can enforce lateral movement restrictions at scale.

A common pitfall is believing VLANs and zones alone are sufficient. In practice, teams open holes to make things work and lateral communication proliferates. Zero-trust requires proof: policy as code, per-workload enforcement, and validation of assumptions through testing and telemetry.

Virtual Private Clouds and network policy constructs let platform engineers carve isolated environments and expose safe, well-governed interfaces to developers. Define those boundaries as code and bring security into the platform's golden path, not outside of it.

Principle 5: Platform engineering as foundation

Platform engineering is the discipline of designing and building the tool chains and workflows that enable self-service and developer autonomy. The prime deliverable is the Internal Developer Platform (IDP).

The IDP must be treated as a product: it is versioned, improved, and honed by feedback loops from developers and operators. A well-designed IDP provides a "golden path" - an opinionated, automated workflow that abstracts complexity while preserving guardrails for security and compliance.

When done right, the IDP reduces cognitive load: developers deploy services without manual networking tickets, load balancer requests, or ad-hoc infrastructure changes. Platform teams automate those steps, expose sane defaults, and offer escape hatches for advanced use cases.

Platform engineering itself benefits from platform thinking: the team builds tool chains (their own platform) to produce and manage the IDP. That includes infrastructure stacks, platform services, developer UX layers, governance automation, and telemetry-driven incident and capacity management.

If you enjoyed this, find here more great insights and events from our Platform Engineering Community.

If you want to learn more, check our instructor-led Platform Engineering Certified Practitioner course and learn all the concepts and best practises how to approach platform engineering in your organization.

Key takeaways

• Composability and API-first design are non-negotiable - Build modular components with explicit contracts (APIs/CRDs) so you can change pieces independently without disrupting the entire system.
• GitOps provides reproducibility and auditability - Treat desired state as versioned code and use continuous reconciliation to reduce error and improve governance, especially critical for regulated environments.
• Observability must be actionable - Correlate telemetry to SLOs and automate responses where possible; treat observability configuration as code to enable rapid iteration and improvement.
• Zero-trust needs to be enforced at workload boundaries - Use workload identity, micro-segmentation, and policy-as-code to limit lateral movement rather than relying solely on network perimeters.
• Treat the IDP as a product - Platform engineering delivers developer experience through a versioned, opinionated platform that abstracts complexity while enabling autonomy and maintaining security guardrails.

​