I have spent enough time in DevOps to know that building solid platform engineering foundations was never about creating another job title or collecting more tools. Instead, DevOps was built around collaboration: developers and operations working together to deliver software faster, more reliably, and with fewer handoffs.
That idea remains valuable. However, the problem is that modern software delivery has become far more complicated than many early DevOps practices anticipated. Cloud services, containers, Kubernetes, infrastructure automation, security controls, observability, compliance, and distributed systems have created a massive operational surface area. Consequently, development teams are often expected to understand and manage too much of it while still trying to deliver customer-facing features.
Platform engineering is not a replacement for DevOps. Rather, it is a practical evolution of DevOps principles for organizations dealing with scale and complexity. Ultimately, the goal is to create an internal developer platform that gives engineering teams reliable self-service capabilities, sensible defaults, and clear paths to production.
From my perspective as a platform engineer, the transition is not mainly about buying a portal or standardizing on a particular technology. Instead, establishing strong platform engineering foundations is about building the right capabilities, understanding developer problems, and treating the platform as an internal product.
Why Traditional DevOps Reaches Its Limits
Traditional DevOps helped remove the wall between development and operations. In many organizations, however, the result was not always shared ownership. Instead, operational responsibility gradually shifted heavily toward application teams.
For instance, a typical development team may now be responsible for:
- Writing and reviewing application code.
- Creating infrastructure definitions.
- Managing deployment pipelines.
- Configuring cloud resources.
- Setting up logging, metrics, and tracing.
- Managing secrets and access policies.
- Responding to production incidents.
- Tracking cloud costs.
- Meeting security and regulatory requirements.
Each responsibility may be reasonable on its own. Together, however, they create a significant cognitive burden.
The issue is not that developers are incapable of learning infrastructure. Rather, the issue is that every product team should not have to become an expert in every supporting system. As a result, when each team builds its own deployment process, monitoring approach, infrastructure modules, and security controls, the organization creates duplication and inconsistency.
I have seen this pattern many times. First, one team creates a pipeline that works well. Subsequently, another team copies it and changes several steps, and a third team uses a completely different system because the existing examples are difficult to understand. Six months later, the organization consequently has multiple deployment methods, inconsistent security checks, uneven observability, and no clear ownership.
DevOps created the collaboration model. In contrast, modern platform engineering foundations create the reusable systems that allow that collaboration to work at scale.
Additionally, the CNCF Platforms White Paper describes internal platforms as curated collections of capabilities, frameworks, and experiences designed to help internal users deliver software more effectively. It also emphasizes that platforms should reduce cognitive load, improve reliability, support self-service, and embed security and governance directly into common workflows.
What an Internal Developer Platform Really Is
An internal developer platform is a collection of tools, services, automation, documentation, and workflows that help developers build and operate applications.
It sits above underlying infrastructure and presents developers with a simpler experience. Behind the scenes, the platform might use cloud services, Kubernetes, infrastructure-as-code tools, identity systems, security scanners, artifact repositories, and observability products. However, developers should not need to understand every implementation detail to use the supported path.
That distinction matters. Specifically, an internal developer platform is not simply:
- A Kubernetes cluster.
- A developer portal.
- A collection of Terraform modules.
- A centralized CI/CD pipeline.
- A service catalog.
- A ticketing workflow.
Those can all be components of a platform, but none of them alone defines the platform. In short, a useful way to think about an internal developer platform is as a product that helps a developer move smoothly from an idea to a running, observable, and supportable service.
For example, a developer should be able to start a new service and automatically receive a practical foundation that includes:
- A source repository.
- A standard build process.
- Automated tests.
- Security checks.
- An approved deployment workflow.
- A suitable runtime environment.
- Logging and monitoring.
- Documentation.
- Ownership information.
- A clear support and retirement process.
Ultimately, the developer still owns the application and its business logic, while the platform team owns the quality of the experience and the reusable capabilities that support it.
The Five Platform Engineering Foundations
A successful transition from traditional DevOps requires more than automation; it needs strong platform engineering foundations to ensure long-term stability and adoption.
1. Start with developer problems
The first foundation is user research. Therefore, platform teams should begin by understanding where development teams lose time. This means observing workflows, reviewing support requests, examining incident patterns, and speaking directly with engineers.
Useful questions include:
- How long does it take to create a new service?
- How many people are involved in a production deployment?
- Which steps are still manual?
- Where do teams wait for another department?
- Which tools are difficult to discover?
- What causes failed deployments?
- How do developers find logs and dashboards?
- What happens when an application needs a database?
- Which security controls are often added late?
These questions are far more useful than starting with, “Should we use a particular portal?”
Furthermore, the CNCF maturity model recommends identifying the current state and then improving incrementally rather than treating maturity as a race toward a fixed final level. That is good advice because platform needs vary by organization. For example, a small company may benefit from a well-maintained set of templates and documentation, whereas a large enterprise may need automated provisioning, service catalogs, policy enforcement, and multiple runtime options. Both can have effective platforms.
2. Build a thin and useful platform layer
The second foundation is scope discipline. Platform teams are often tempted to own everything. However, this creates a centralized bottleneck that looks different from the old operations bottleneck but produces the exact same frustration.
The platform team does not need to build every underlying service. Instead, it should provide the thinnest useful layer that creates a consistent and reliable developer experience.
For instance, the cloud provider may operate the database service, while the platform team provides:
- A supported database option.
- Automated provisioning.
- Backup defaults.
- Access control.
- Connection information.
- Secret integration.
- Monitoring.
- Cost visibility.
- Upgrade guidance.
Consequently, this approach allows the platform team to focus on integration, usability, reliability, and governance rather than rebuilding capabilities that already exist. A thin platform is not a weak platform; rather, it is a focused platform.
3. Offer paved paths without creating locked roads
The third foundation is the paved path. A paved path is a recommended way to complete a common engineering task, and it should make the safe and supported option the easiest option.
A good application path may include a template for creating a service, a standard deployment workflow, built-in security validation, and automatic observability. As a result, developers can follow the path without learning every underlying tool.
However, the path should remain optional where possible because not every application has the same requirements. For instance, a low-risk internal service may need a simple runtime, while a high-volume customer-facing system may require specialized infrastructure.
The platform should support common use cases well while also providing an escape route for legitimate exceptions. If teams are forced into a path that does not meet their needs, they will work around it. Moreover, once workarounds become common, platform adoption declines.
Microsoft describes the goal of platform engineering as “self-service with guardrails,” where developers receive autonomy within agreed security, compliance, operational, and cost boundaries. Indeed, that balance is essential. Too little guidance creates inconsistency, whereas too much control creates bureaucracy.
4. Make security and operations part of the default experience
The fourth foundation is secure and operable by default. Security should not be a final approval gate that appears after an application is ready to launch. Similarly, reliability should not depend on every team remembering to configure dashboards and alerts. These capabilities should be part of the standard delivery experience.
Accordingly, solid platform engineering foundations provide:
- Identity-based access.
- Secure secret handling.
- Dependency and artifact scanning.
- Policy validation.
- Approved base images.
- Standard network controls.
- Audit records.
- Log and metric collection.
- Health checks.
- Deployment verification.
- Backup and recovery patterns.
The important point is that these controls should be understandable and automated. A platform that simply blocks developers without explaining why will consequently be treated as an obstacle. In contrast, the best platform controls feel almost invisible because they are integrated into normal workflows. Thus, developers receive useful feedback early, and security teams gain more consistent enforcement.
This also changes the relationship between platform engineering and operations. Instead of asking application teams to become infrastructure specialists, the platform provides operational capabilities as reusable building blocks.
5. Measure outcomes, not platform activity
The fifth foundation is measurement. It is easy to report how many templates were created, how many clusters were provisioned, or how many plugins were installed. However, those figures may show activity, but they do not prove that the platform is actually helping developers.
Therefore, better measures include:
- Time required to create a new service.
- Time from code change to production.
- Deployment frequency.
- Lead time for changes.
- Change failure rate.
- Time to restore service after an incident.
- Time required to provision a test environment.
- Percentage of services using standard observability.
- Developer satisfaction.
- Support requests per platform capability.
- Adoption and retention of platform workflows.
In addition, the CNCF Platforms White Paper connects platform success with developer productivity, organizational efficiency, delivery performance, and user satisfaction. It also references the four commonly used DORA measures: deployment frequency, lead time for changes, time to restore service, and change failure rate.
Of course, no single metric tells the full story. A shorter deployment time is not an improvement if failure rates increase. Similarly, higher platform adoption is not automatically positive if teams use it only because of a rigid mandate. As a result, I prefer to combine quantitative measures with regular conversations. A short developer survey, a review of support tickets, and a few interviews can reveal problems that usage data misses
A Practical Plan for Implementing Platform Engineering Foundations
The move from traditional DevOps to an internal developer platform should happen gradually by establishing your platform engineering foundations phase by phase.
Phase 1: Map the current delivery journey
Document how a service moves from creation to production. Include the steps, systems, approvals, teams, and waiting periods.
Do not document only the official process. In fact, the unofficial process often reveals the real problems. Ask developers what they do when the documented path fails or when a required capability is missing. Specifically, look for repeated work such as manually creating repositories, copying pipeline files, requesting environments, configuring alerts, or obtaining access to shared services.
Phase 2: Choose one partner team
Do not attempt to onboard the entire organization at once. Instead, select one development team that has a real problem, a supportive engineering manager, and enough time to provide feedback.
The partner team should be involved in design and testing from the beginning. Thus, they are not just early adopters; they are customers and collaborators. Furthermore, a small pilot limits risk, allowing the platform team to learn what developers actually need before committing to a broad architecture.
Phase 3: Deliver a minimum viable platform
The first version should solve one complete journey rather than provide dozens of disconnected features.
For example, the initial platform might support the creation and deployment of a standard web service. It could include a project template, a build pipeline, a deployment workflow, basic secrets integration, and standard logging. Ultimately, the goal is not to create a perfect platform; the goal is to create a useful path that a developer can complete with minimal assistance.
Phase 4: Improve the experience
After the pilot, measure where users still struggle. Then, improve names, documentation, error messages, interfaces, and recovery procedures.
A platform feature is not finished when its automation works. Rather, it is finished when users can understand it, use it, troubleshoot it, and know where to get help. Consequently, this is where product management and technical writing become important platform skills. A platform team needs to manage a roadmap, communicate changes, deprecate old paths, and explain decisions clearly.
Phase 5: Expand carefully
Once the first path is stable, add capabilities that serve multiple teams. For instance, common candidates include databases, queues, identity integration, environment provisioning, artifact management, and observability.
However, avoid adding a capability merely because it is fashionable. Each addition creates an ongoing maintenance responsibility. Therefore, the platform should grow organically according to user demand and organizational priorities.
Common Mistakes When Building Platform Engineering Foundations
One common mistake when defining your platform engineering foundations is building the portal first. However, a polished interface cannot compensate for unreliable automation or unclear ownership.
Another mistake is treating the platform purely as an infrastructure project. In reality, infrastructure is important, but developers experience the platform through workflows, documentation, feedback, and support.
A third mistake is forcing adoption too early. Mandates may produce usage numbers, but they do not create trust. Instead, a platform earns adoption when it is demonstrably easier and safer than the alternatives.
A fourth mistake is creating overly broad abstractions. If the platform hides so much that developers cannot understand how their services behave, debugging subsequently becomes harder. Abstraction should remove unnecessary complexity, not remove useful information.
A fifth mistake is ignoring the day-two experience. Provisioning a service is only the beginning. In addition, developers need upgrades, scaling, incident response, cost information, access changes, and retirement procedures.
Finally, platform teams should avoid promising universal standardization. Instead, the right objective is consistent experience and sensible governance, not identical technology everywhere.
FAQ
Is platform engineering replacing DevOps?
No. Platform engineering extends DevOps practices for organizations that need to support many teams and complex systems. In short, DevOps remains a culture and operating model, while platform engineering provides reusable capabilities that help teams apply those principles consistently.
What is the difference between an internal developer platform and a developer portal?
An internal developer platform includes the capabilities, automation, workflows, services, and interfaces used by developers. In contrast, a developer portal is simply one possible interface for discovering and consuming those capabilities. The portal may be useful, but it is not the entire platform.
Should every company build an internal developer platform?
Not necessarily. Every company can benefit from reducing repeated engineering work, but the appropriate solution depends on size, complexity, and team needs. For instance, for some smaller organizations, a small set of templates, automation, and documentation may be enough.
What should a platform team build first when setting up platform engineering foundations?
Start with a high-frequency, painful workflow that affects several teams. For example, new-service creation, deployment, environment provisioning, observability, and database access are common starting points. The first capability should be selected through user research rather than technology preference.
Are golden paths mandatory?
They should usually be recommended and well supported rather than mandatory. However, exceptions are sometimes necessary, especially for compliance or security requirements. Even so, teams should understand the reason for restrictions and have a documented process for requesting an alternative.
How large should a platform engineering team be?
There is no universal number. Rather, team size depends on the number of users, supported capabilities, reliability expectations, and organizational complexity. Therefore, a small team should begin with a narrow scope rather than attempting to support every infrastructure service immediately.
How can platform adoption be increased?
Make the platform useful, discoverable, and easy to use. Additionally, provide reliable self-service, clear documentation, responsive support, and a visible roadmap. Adoption tends to grow naturally when development teams experience a real reduction in waiting, manual work, and operational uncertainty.
Does an internal developer platform eliminate developer responsibility for production systems?
No. The platform can provide defaults, automation, and shared operational capabilities, but product teams still need to understand their applications, define service expectations, respond to incidents, and own business outcomes. The platform reduces unnecessary infrastructure work; it does not remove accountability.
Final Thoughts
The transition from traditional DevOps to internal developer platforms is a shift from individual enablement to scalable enablement.
In the early days of DevOps, a skilled engineer might sit with a development team and help create a deployment process. That approach can work for a small number of teams. However, it becomes difficult when an organization has dozens or hundreds of services, multiple cloud environments, strict compliance requirements, and increasingly complex production systems.
Platform engineering captures the lessons of DevOps and turns them into reusable products. Consequently, strong platform engineering foundations give developers a clear path to production, embed security and reliability into ordinary workflows, and preserve team autonomy through sensible guardrails.
The work begins with technology, but it succeeds through trust. Ultimately, developers must see the platform as a service that helps them deliver software, not as another control layer imposed on them.
That is the central lesson of platform engineering foundations: build for the people who use the platform, start with a real problem, measure the outcome, and improve continuously. A platform is never finished; instead, it grows as the organization learns how to deliver better software with less unnecessary effort.
References
- Cloud Native Computing Foundation, “CNCF Platforms White Paper”.
- Cloud Native Computing Foundation, “Platform Engineering Maturity Model”.
- Microsoft Engineering, “Building Paved Paths: The Journey to Platform Engineering”.
- Cloud Native Computing Foundation, “A Conversation About the Future of Internal Developer Portals”.
- PlatformEngineering.org, “How to Measure the Success of Internal Platforms”.
