LEARN

Platform Engineering 101: Origins, Goals, DevOps vs SRE & Best Practices

Platform engineering is the practice of automating infrastructure operations and enabling self-service infrastructure capabilities within collaborative Dev, Ops and QA teams. It involves designing and building platforms, technologies and workflows that enable self-service capabilities to automatically manage, provision and operate complex modern software architecture environments.

In fact, Platform Eng has gotten so popular of late that Puppet, who publishes annual State of DevOps reports, released their 2023 version focused solely on Platform Engineering. Let’s see what all the hype is about.



What is platform engineering?

Platform engineering is one of the most popular trends in the domain of Software Development Life Cycle (SDLC) methodologies and team topologies in enterprise IT organizations. It follows the DevOps philosophy of:

  • Collaborative SDLC functions and responsibilities
  • Adoption of automation tools to rapidly deliver high quality software products at scale

Platform engineering naturally evolves from DevOps and SRE under the philosophy of “you build it, you run it”, but making it easier for teams to systematically extract value at every stage of the SDLC pipeline.

Platform engineering vs DevOps: Is DevOps dead?

When DevOps gained popularity and encouraged IT teams to follow a shift-left SDLC model, Devs were inherently assigned more responsibilities to manage…

  • The SDLC workflows
  • ITOps
  • Processes governing software quality

At the same time, SDLC processes and infrastructure operations become more complicated with the rapid adoption of microservices and containers. Infrastructure as Code (IaC) promised to reduce the manual efforts it takes to manage infrastructure operations, but in highly scalable and large-scale IT environments, any cloud-native setup became infinitely more complex.

Regardless of the automation tools in place, DevOps anti-patterns emerged in DevOps teams. In many ways, IT teams were adopting their own varied flavors of DevOps. (This is reminiscent of the era when Agile methodology was reaching maturity in the enterprise IT world, yet many organizations found themselves adopting their own flavors of Agile, which was nothing more than faster Waterfall cycles.)

In the present DevOps era, many organizations are still adopting mixed SDLC models, which create Shadow Operations.

(Read about DevOps automation.)

Shadow operations in DevOps

Shadow operations — similar to shadow IT — refer to the unauthorized use of technologies and processes as a way to work around technical constraints and fixed organizational policies. ITOps teams, developers and QA personnel may adopt shadow operations to solve a specific problem, which can work as a quick fix, but often leads to…

  • Unnecessary security and compliance risks
  • Scalability limitations
  • Version control issues

Without these quick fixes and workarounds, developers must rely on internal platform teams for reusable ITOps services. If the organization is operating teams in silos, collaboration is lacking between Devs and Ops despite the apparent adoption of some DevOps principles, it may be difficult to understand and deliver on the specific tooling and workflow expectations of the DevOps teams.

One approach is to provide a common set of reusable tools and workflow guidelines, but the fast-paced DevOps environment may evolve rapidly and require continuous corporations with the internal platform teams. Organizations riding the wave of DevOps trends expect Devs not only to develop core software functionality, but to also own the infrastructure, operations, and the end-to-end deployment pipeline.

The turn to platform

More recently, organizations are invested into initial platform-building projects in the form of portals that curate all required tooling, workflow guidelines and processes, embedding self-service and automation capabilities — for easy consumption based on unique developer requirements. The portal includes API-driven self-service technology solutions. This allows DevOps teams to self-service deploy and operate infrastructure systems with reduced manual and cognitive load.

The idea behind this activity is not to create an additional DevOps pipeline to host and deliver ITOps tooling as a platform — it’s to integrate the Internal Developer Platform within the existing DevOps pipeline.

Platform engineering concepts & best practices

In essence, platform engineering enables the common DevOps goals pertaining to infrastructure system operations and management: the infrastructure platform should be:

  • scalable, dependable and secure.
  • built with established industry standardons.


Automation and self-service capabilities should empower developers to identify, procure and provision any tool and services they need to streamline ITOps and DevOps pipeline. Additionally, platform engineering is focused on the following key best practices:

  • Determine a clear objection for the platform, that is aligned with your organizational goals and DevOps principles of collaboration, automation and faster delivery of high-quality software.
  • Treat your platform with a product mindset. Identify the needs of your end-users – developers and ITOps personnel managing shift-left DevOps pipeline. Take advantage of user feedback for continuous improvement of the platform and self-service capabilities accessible to the DevOps teams.
  • Identify common problems and resolve developer pain points. These should include all challenges from a technology and cultural perspective. Evaluate the engineering metrics and KPIs in context of end-user feedback.
  • Embrace platform engineering teams as value creators. Often, ITOps and platform teams are seen as cost-centers that merely operate to keep the servers alive. The evolution of DevOps toward platform engineering doesn’t necessarily require reinventing the wheel.

Platform engineering teams are encouraged to find creative ways to solve the same infrastructure operations challenges facing DevOps teams. If the problem is worth solving, business will eventually associate value with it — and eventually external vendors and the wider enterprise IT industry will catch up with Internal Developer Platform tools and services marketed value creators instead of cost-centers.

What is Splunk?

This posting does not necessarily represent Splunk's position, strategies or opinion.

Muhammad Raza
Posted by

Muhammad Raza

Muhammad Raza is a technology writer who specializes in cybersecurity, software development and machine learning and AI.