Let’s be honest: platform engineering is evolving fast, and a lot of teams are being forced to write the rules while still collecting context. Plenty of terms and topics are still up for debate—from, “Is this just DevOps 2.0?” to “How much abstraction is too much?"
In this blog we pulled together 10 of the biggest topics being debated today. While we may not have all the answers, we think just getting up to speed on what's left to decide helps all of us get better.
1. Is Platform Engineering Just DevOps 2.0?
This is one of the most persistent questions in the platform engineering world—are we just rebranding DevOps with some new terminology? The short answer is no, but the relationship between the two is worth unpacking.
DevOps is fundamentally a cultural movement, aiming to break down the silos between development and operations teams. It’s about fostering collaboration and using automation and tooling to improve software delivery and infrastructure management. DevOps emphasizes continuous integration/continuous delivery (CI/CD), automating pipelines, and ensuring that development, testing, and operations all move as one seamless process.
Platform engineering, on the other hand, is a more focused discipline within the broader DevOps ecosystem. It involves building internal platforms that provide developers with self-service access to infrastructure, deployment pipelines, and operational tools. The platform engineering team creates and maintains these "developer platforms" or Internal Developer Platforms (IDPs) so that developers can focus on writing and shipping code without worrying about the underlying complexity. It takes DevOps concepts, like automation and CI/CD, and packages them into a user-friendly interface.
In essence, platform engineering operationalizes DevOps. It’s an evolution rather than a rebranding. It’s the next step in managing increasingly complex systems as teams scale and the demand for faster, more efficient software delivery grows. DevOps gets you going, but platform engineering helps you scale.
2. Are Portals and Platforms the Same Thing?
The players in this market haven't made it easy to distinguish between Portals and Platforms. Some refer to the Portal as a "UI" to the Platform. Other say that the Portal is what gives the Platform shape and meaning.
What everyone can agree to, however, is that platforms are collections of tooling and processes—often with integrations, workflows, and automations throughout. But if your Portal is where your business logic lives (not unusual as the layer that also houses the catalog), and serves the entry point to all of your systems and tools, it has unique value that can be an abstraction of—or wholly separate to—the platform.
So the answer to this question is usually down to what level of "platform" you already have in place by the time you need to optimize for abstraction and experience. Portals can be valuable in lieu of any automation across your existing tools, or it can extend and enhance what you have.
3. How Much Abstraction is Too Much?
Abstraction in platform engineering can be a double-edged sword. The more abstraction you provide, the simpler it is for developers to build and deploy without worrying about underlying infrastructure. But at what point does abstraction become too much of a good thing? When developers don’t understand the underlying systems because they’re too abstracted, it can lead to frustration, mistakes, and ultimately a lack of flexibility when something goes wrong.
Over-abstraction can also create a dangerous divide between platform engineers and developers. The platform team might think they’re making life easier for developers, but in reality, they could be removing too much control. Developers might need access to tweak configurations or troubleshoot issues but find themselves locked out or dependent on a handful of "platform gatekeepers."
While abstraction can save time in the short run, it can make debugging a nightmare in complex systems. If developers don’t understand how their applications interact with infrastructure, you could be headed for trouble when something breaks.
Finding the right level of abstraction is a constant debate in platform engineering, but it’s clear that too much can be just as harmful as too little
4. Can Platform Engineering Survive in a Multi-Cloud World?
Multi-cloud environments are becoming the norm as companies diversify their infrastructure across platforms like AWS, Google Cloud, and Azure. The appeal is clear: no vendor lock-in, flexibility, and redundancy. But with this flexibility comes a lot of complexity for platform engineers. Each cloud has its own APIs, services, and pricing structures, making the job of unifying these environments a monumental task.
One of the biggest challenges in a multi-cloud world is maintaining consistency. Different clouds come with different ways of handling identity management, networking, security policies, and more. This fragmentation can make it difficult for platform teams to create a seamless experience for developers. The question becomes: Can platform engineers create a unified system that makes multiple clouds feel like one?
Without the right abstraction layers, platform engineers risk being overwhelmed by the operational overhead. Multi-cloud may be the future, but surviving it requires the right mix of tools, processes, and automation. It’s not just about juggling multiple platforms but making them work together in a cohesive way that doesn’t leave engineers drowning in complexity.
5. Should you Follow Declarative or Imperative Infrastructure Management?
The debate between Declarative vs. Imperative Infrastructure Management is like choosing between autopilot and manual driving—both get you there, but the ride’s different.
Declarative: "Set It and Forget It:" With declarative, you define what you want (e.g., "3 servers running") and let the system handle how to make it happen. Tools like Terraform offer consistency and easy rollbacks, ideal for large teams needing repeatability. But, it can be rigid—troubleshooting can feel like untangling a mess when things go wrong.
Imperative: "Hands-On Control:" Imperative management gives you step-by-step control ("create server 1, configure it, then server 2"). It’s great for flexibility and custom setups, but doesn’t scale as well and can lead to inconsistencies as environments grow.
Which is Better? Declarative is best for scalability and consistency, while imperative shines with granular control. Many teams blend both, using declarative for big-picture infrastructure and imperative scripts for fine-tuning. It’s all about the right balance.
6. How Do You Balance Security and Developer Autonomy?
Balancing security and developer autonomy is a fine art—platform engineers need to ensure developers have the freedom to move fast while keeping the organization’s infrastructure secure. Give devs too much autonomy, and you risk vulnerabilities and non-compliance. Lock things down too much, and you stifle innovation and slow releases to a crawl.
A survey by GitLab found that 70% of developers say security slows them down, yet only 40% of companies say they have shifted security left by embedding it into the development process. This shows there’s a real need for security automation that allows devs to move fast and safely. The challenge is to find a sweet spot between governance and freedom. Developers want self-service and the ability to push to production without waiting for approvals, but platform engineers need to ensure these actions don't compromise security.
Finding this balance often comes down to automating security practices in ways that feel natural for developers. Instead of being roadblocks, these checks can be integrated into their existing workflows, keeping both sides happy. The key is building a platform that keeps both speed and safety in mind, ensuring that security becomes an enabler rather than a bottleneck.
7. Do We Need a Platform Engineering Team, or Should Dev Teams Own the Platform?
This is one of the hottest debates in platform engineering today: should you centralize platform engineering under one team, or let individual dev teams manage their own infrastructure? Both sides have valid points, and the decision often depends on company size, culture, and complexity of infrastructure.
In favor of centralizing platform engineering, you get consistency, standardization, and efficiency. When one team owns the platform, you reduce duplication of efforts and avoid the chaos that comes with every dev team building their own tools and processes. For larger organizations with complex infrastructure, having a dedicated platform team that maintains tools, monitors infrastructure, and sets best practices makes sense.
However, the flip side is that centralized teams can become bottlenecks, slowing down development. According to Humanitec's Platform Engineering Survey, 62% of companies report bottlenecks when centralized platform teams don't enable sufficient developer autonomy. As a result, some argue for a decentralized model where dev teams own the platform themselves, building and maintaining their own tools.
Example: At Netflix, teams are given a lot of autonomy, with platform engineers focusing on enabling self-service. Developers are responsible for deploying their services, but they have standardized tools and guidelines provided by the platform engineering team to ensure consistency.
The ideal solution might be somewhere in between: centralizing key infrastructure like Kubernetes clusters and CI/CD pipelines, but giving individual dev teams autonomy over smaller tooling decisions. This hybrid approach helps balance efficiency with flexibility, ensuring consistency without stifling developer creativity.
8. The "Platform Monolith" Problem: Are We Building Platforms Too Big?
Here’s a debate that’s been quietly gaining traction: Are we over-engineering our internal platforms? The idea is that in our zeal to create the ultimate self-service platform for developers, we might actually be building a new kind of monolith—just one that’s internal. Instead of freeing up dev teams, we could be trapping them in an overly complex, hard-to-maintain, all-encompassing platform.
Platform engineering’s goal is to provide developers with tools that abstract away the complexity of managing infrastructure. But sometimes, in trying to solve every developer problem with an internal platform, engineers end up creating an enormous, bloated system that’s hard to navigate and maintain. It's a far cry from the lean, modular platforms that are supposed to offer agility.
Some argue that platforms should focus on core capabilities—things like CI/CD pipelines, observability, and security—but leave more specialized tasks in the hands of the teams using them. In this view, platforms shouldn’t be one-size-fits-all; instead, they should provide flexible, composable components that teams can adopt as needed.
There’s a delicate balance between creating enough automation to make things easier for developers and overwhelming them with too many features. The key is keeping platform teams nimble and focused on solving real, immediate pain points—without building an unmanageable beast.
9. The Great Kubernetes Debate: To Go All-In or Not?
Let’s talk Kubernetes. Platform engineers can't seem to avoid this topic: Should we fully embrace Kubernetes for everything, or is it overkill for certain workloads? Kubernetes is great for container orchestration, but is every microservice and internal app really ready for such a heavy-duty solution?
The Case for Going All-In on Kubernetes: There’s no doubt that Kubernetes has become the de facto standard for container orchestration. For large-scale systems where applications need to run across multiple environments and require automation for scaling, Kubernetes is king.
The Pushback: However, some engineers argue that Kubernetes can be overkill for smaller teams or simpler apps. Do you really need a full Kubernetes setup if you're just managing a few services in a single cloud provider? Some argue that Kubernetes adds complexity, with engineers needing to learn its intricacies before they can effectively use it. Not to mention the added overhead of managing the platform itself—you now have to manage Kubernetes as much as you do your actual apps.
The Middle Ground: Many organizations are finding a hybrid approach to be the sweet spot. Instead of running everything on Kubernetes, platform engineers are selective about which services and environments require Kubernetes, while using simpler orchestration methods (or even managed services) for less critical apps.
In the end, whether to go all-in on Kubernetes depends on the scale, complexity, and nature of the workloads. The real debate boils down to this: Do you adopt Kubernetes for its potential scalability, even at the cost of complexity, or do you opt for a simpler approach to keep operations lean?
10. What Role Does AI Play in Platform Engineering?
Yes, we had to. Platform engineers are facing a rapidly evolving landscape, and one of the hottest debates is around the role of AI in shaping the future of platform engineering. Will AI streamline processes and automate tasks to the point where developers can focus solely on coding, or will it create an overwhelming complexity that needs constant management? What's to be done about it either way?
Copilots are empowering developers to write code faster than ever, but that means platform engineers are being flooded with more code, microservices, and applications that need to be deployed, managed, and monitored. This surge in code is great for innovation, but it introduces new challenges—especially in scaling infrastructure, managing dependencies, and ensuring security compliance across increasingly fragmented ecosystems.
Now for the optimistic take: AI isn’t just creating more work; it could be the secret weapon platform engineers need to create delightful developer experiences at scale. AI can streamline platform operations by automating repetitive tasks like infrastructure scaling, monitoring, and incident response.
Imagine AI-driven systems that create self-healing platforms. When a service crashes or underperforms, AI systems can automatically identify the root cause and resolve the issue without human intervention. This would free platform engineers from constant firefighting, allowing them to focus on building better tools and systems that enhance developer productivity. But we may still be a ways away from this future.
The real debate here isn't about which path AI will take (surely both), but about what we'll do about it. In the end, the role of AI in platform engineering is still unfolding. Platform teams will need to adopt the right mix of automation and human oversight to ensure that AI’s promise of speed doesn’t become a burden of complexity. While AI can help build more flexible and resilient platforms, it’s the platform engineers who will need to guide how that technology is implemented for long-term success.
Conclusion: The Future of Platform Engineering is Still Up for Debate
Platform engineering continues to evolve rapidly, and so do the discussions around how best to manage infrastructure and development teams. Whether you’re grappling with how much abstraction to offer developers or whether to centralize your platform engineering team, these conversations are shaping how we build, deploy, and manage infrastructure today.
