After reading my new favorite article on the internet, "DevOps is Bullshit", three times from top to bottom, and having a good laugh, the reality hit me. Platform Engineering is becoming the new buzzword, just like DevOps did 10 or so years ago.

And I don't like it.

But why? Isn't Platform Engineering the silver bullet that will save us, make people happy, and finally enable developers to provide tangible value with no show-stoppers?

Probably not.

But why?

Because back in the day (these words make me feel as old as the world, and my back starts to hurt), DevOps came along being exactly that—a utopian world with phoenixes and unicorns (kudos to you if you got the reference). It was a world where developers are as productive as ever, where operations people are not a bunch of nerds living behind the fence, building servers from sticks and stones. They no longer need to look at the ever-growing service desk ticket count (and tens of unanswered chats from devs wanting to be productive) with one eye and production dashboards with the other. The strabismus consequences were real.

Platform Engineering is advertised as the "destroyer" of DevOps, claiming that DevOps failed as an approach. Except it didn't. The real problem lies in the poor understanding of the entire life cycle of the DevOps model and mentality across the majority of organizations. Most companies still believe that any combination of CI/CD, Kubernetes, and cloud equals DevOps. That's the ugly truth (hint: it's not). This misconception has persisted for multiple years and has led us to a point where it's easier to discard the good old DevOps world, take only a few valuable principles, and start living happily in the new Platform Engineering world.

But simply renaming the DevOps team into the Platform Engineering team won't bring the change the industry needs to become faster, smarter, more organized, and more enjoyable. This name shift should come with some simple rules.

P.S. 1.0: You don't have to change the names of your teams—simply follow the rules.

P.S. 2.0: If you have five developers, you don't need platform engineering or DevOps. What you need is a simple code ownership flow. Thank you for reading. Goodbye 🖤

Now, let's explore what Platform Engineering should be.

Rule #1:

A Platform Engineering organization within your project or company is what used to be called a center of excellence. It comprises a group of multidisciplinary engineers who create tools that the entire organization can leverage. Developers use these tools not because they are created by Platform Engineering, but because they are easy to use, integrate, robust, and reliable. There are only a couple of things should have a centralized blueprint that your development teams (yes, multiple teams) should follow:

• Self-Service: Developers should have access to any rights they need within one click of a button.

• Observability: Dashboards, tracing, logging—all the fun stuff.

• Version Control System: This includes build and release pipelines and a kanban board.

• Compliance: Everyone loves compliance. This should be addressed as the first step because it is the most complex thing to get right.

Everything else is a technology that engineers should be free to choose, provision, and manage themselves. As long as a piece of technology solves their problems, they should be free to use (also manage and observe) it. Developers should be empowered to proactively suggest tools and frameworks that could become the company standard. If a new, shiny toy improves the application, workflow, or saves time in any way, developers should be encouraged to bring it to the attention of Platform Engineering.

This doesn't happen out of the box. Experimentation should either be a logical part of the development process if you trust the people you hire, or it should be a planned activity if you belong to one of those political, bureaucratic companies that boast about their awesome development environment on paper but limit them as much as possible when it comes to the actual work.

Rule #2:

I have been advocating for the "everything outside the sandbox is production" approach for years now. Finally, it is becoming a more widely adopted model. One of the pillars of Platform Engineering is to build useful tools for your internal teams. They are the stakeholders who use the product you create.

Rule #3:

Once you have the core pillars of your platform engineering platform (lol) up and running, used, and praised, start extending your reach to other tools. Engage with your development teams, identify the tools they have in common, and work with them as your customers (because they are) to create packages that they can directly integrate into their code. Nobody will care whether Kafka, Dataflow, or Event Streams are running behind the scenes as long as they can handle event processing. Of course, there will always be instances where things don't work together due to reasons beyond your control. In such cases, either refactor the incompatible components or let the developers handle a solution that works well for their specific needs. This approach makes it easier for your product to move across clouds, service providers, and even technologies with minimal engineering overhead. As long as you have a clear contract with R&D about the functionality they need you to provide as part of your company's essential technology components' library, the format in which you accept logging and tracing data, or any other pain points.

P.S.: essential technology components - a functionality that needs to be covered for your application to work, e.g. event streaming, caching etc.

The Inevitable Reality:

Many organizations will simply rename their DevOps teams to Platform Engineering teams and bask in the bonus points for a successful transformational initiative. However, they will likely continue working in the same way they did 10 years ago. My hope is that there will be enough manpower to bring about the mental transformation that DevOps should have achieved.