The Second Wave of Platform Engineering, with Octopus Deploy

Key Concepts

• Platform Engineering: A discipline focused on building internal developer platforms (IDPs) to accelerate software delivery and improve developer experience.
• Continuous Delivery: Automating the software release process to enable frequent and reliable deployments.
• Kubernetes: A container orchestration system that automates the deployment, scaling, and management of containerized applications.
• Internal Developer Platform (IDP): A self-service infrastructure and tooling environment designed to empower developers.
• Day 0/Day 300 Problem: Day 0 refers to the initial setup and creation of templates/pipelines. Day 300 refers to the challenges of maintaining, updating, and scaling those templates/pipelines over time.
• Golden Path: A standardized, well-defined path for developers to deploy applications, aiming for consistency and reduced complexity.
• AI Integration in Platform Engineering: Utilizing AI for self-service remediation of deployment failures and augmenting platform engineer capabilities.

Scaling Platform Engineering: Challenges and Solutions with Octopus Deploy

Introduction

This discussion, recorded at KubeCon and CloudNativeCon North America, centers on the challenges of scaling platform engineering initiatives, particularly in organizations adopting Kubernetes. Heather Joslin of The New Stack interviews Bob Walker, Field CTO of Octopus Deploy, to explore the evolving landscape of platform engineering and how tools like Octopus Deploy address common pain points. A disclosure is made that Inside Partners, owner of The New Stack, is an investor in Octopus Deploy.

The Kubernetes Knowledge Gap & the "Mini Cloud" Analogy

A primary challenge facing organizations scaling with Kubernetes is the steep learning curve and the breadth of concepts involved. Walker describes Kubernetes as a “mini cloud inside of a cloud,” highlighting the complexity of managing it effectively. This complexity makes it difficult to scale best practices across large development organizations (1,000-20,000 developers) without introducing errors and security vulnerabilities. He recounts a past experience where a misconfiguration in a cloud environment led to unintended exposure, illustrating the potential risks. The sheer volume of Kubernetes documentation – exemplified by the existence of multiple “getting started” books – underscores its inherent complexity.

The Shift in Developer-Operations Communication

Walker notes a loss of common language between developers and operations teams with the move to Kubernetes. Historically, developers and operations personnel shared a common understanding of deployment processes (e.g., IIS deployments). Kubernetes has disrupted this, requiring both groups to relearn fundamental concepts. Developers prioritize feature delivery, while operations focus on Kubernetes scaling and best practices, creating a communication gap. This reset of expectations is natural with new technology, but requires deliberate bridging.

Platform Engineering: From Hype to Maturity (V2 & V3)

Platform engineering, initially a “hotness” a year or two ago, is now entering a maturity phase. Observations from Platform Engineering Day at KubeCon revealed that many organizations are on their second or third iteration of their platform. This indicates a learning process – initial attempts often require significant refinement. The trend is moving away from DIY solutions and towards commercial tools specifically designed for platform engineering.

Common Pitfalls in Platform Engineering Adoption

Walker identifies two key issues hindering successful platform engineering adoption:

1. Unrealistic Expectations: Platform engineers often attempt to create a single, perfect template to address all possible use cases. This leads to overly complex, difficult-to-maintain templates that ultimately fail to gain traction. He emphasizes that “when you try to make things for everybody, you make things for nobody.”
2. Treating the Platform as an Ivory Tower: A top-down, prescriptive approach ("behold my golden path") alienates developers. Successful platforms are built with a product mindset, prioritizing user feedback and collaboration. A “golden path” that no one uses is ineffective. If the platform is too complex to debug, platform engineers become a bottleneck, reverting to a traditional operations role (Operations 2.0 or 3.0).

Octopus Deploy’s Approach to Addressing These Challenges

Octopus Deploy focuses on solving the “Day 300 problem” of templating – the challenges of maintaining and iterating on templates after initial creation. While Day 0 (initial template creation) is important, the long-term maintainability is crucial. Specifically, Octopus Deploy addresses these challenges through:

• Robust Template Iteration: Providing a controlled and robust way to modify templates when integrations change (e.g., a REST API update from GitHub).
• Policy Enforcement: Implementing policies to ensure developers use the correct template versions, with warnings and eventual blocking of deployments for non-compliance. This enforces standardization while providing flexibility.
• Collaboration & Git Integration: Backing all platform configurations with Git enables pull requests, allowing developers to contribute suggestions and fostering a sense of ownership.
• Argo CD Support: Recent addition of support for Argo CD, a popular GitOps continuous delivery tool, further expands Octopus Deploy’s capabilities.
• Platform Hub Feature: A centralized feature encompassing templating, policies, and Argo CD integration, creating a comprehensive platform engineering experience.

The Future of Platform Engineering & AI Integration

Walker predicts a rise in commercial vendor offerings to fill the gap left by DIY solutions. He also highlights the potential of AI in platform engineering, but cautions against using it as a “cheat code.” He advocates for targeted AI applications, such as self-service remediation of deployment failures. Octopus Deploy’s AI integration focuses on leveraging telemetry data to identify common failure patterns and provide developers with suggested solutions, freeing up platform engineers to address more complex issues. The goal is to augment platform engineer capabilities, not replace them.

Advice for Platform Engineering Teams Facing Setbacks

For teams whose initial platform iterations haven’t been successful, Walker advises:

• Measure Impact: Track key metrics like deployment frequency and change failure rate to demonstrate the platform’s value.
• Embrace Failure as a Learning Opportunity: Recognize that iteration is essential and learn from mistakes.
• Treat Platform Engineers as Force Multipliers: Empower developers and avoid creating knowledge silos. The ultimate goal is for developers to be self-sufficient.

Conclusion

The conversation highlights the evolving nature of platform engineering, moving from initial hype to a more mature, pragmatic approach. Successful platform engineering requires a focus on long-term maintainability, collaboration, and realistic expectations. Tools like Octopus Deploy are emerging to address the challenges of scaling platform engineering initiatives, particularly in complex environments like Kubernetes, and are beginning to incorporate AI to further empower developers and platform engineers alike.