top of page
  • Dan Donahue

My Take On What Happened to Platform Engineering

By Dan Donahue, Principal Solutions Architect at Nethopper.io.


The importance of Internal Developer Platforms (IDPs)

Let me start by saying that an IDP, or Internal Developer Platform is absolutely required if you don’t want to have to search and hire a Kubernetes unicorn–which does not exist–or develop the IDP yourself, which takes a lot of time and a lot of money. 


I wrote an ebook to define what happened to Platform Engineering in the frenzied push for application modernization that has left many organizations mired in their cloud native initiatives. (I’ve also talked about it extensively in this audio/podcast of the same name).



Platform Engineering eBook by Dan Donahue
Platform Engineering eBook by Dan Donahue


I understand most technical ebooks are supposed to be lots of bits and bytes and devoid of any personal nuances, but this one is going to be different. The bits and bytes will certainly be present, but they will be mixed with personal experiences because by nature I am a Platform Software Engineer. It’s what I’ve done for almost 25 years. I am very passionate about it. 


Much of what I’ve read recently in blogs, social media posts, and books compelled me to write this whitepaper because:

Platform Engineering seems to be a new concept to many. It is not. 

Platform Engineering simply moved from Software Engineering to DevOps/IT. Therein lies the awakening of DevOps/IT folks to Platform Engineering and the challenge it presents for them.


​In his book Platform Engineering on Kubernetes, which I highly recommend, author Mauricio Salatino makes a similar statement regarding the platform engineering term. Mauricio says: 


“Platform engineering is not a new term in the tech industry. But it is quite new in the cloud-native space and the context of Kubernetes. We were not using the term in the cloud-native communities when I started writing this bookback in 2020.” 

​In 2013, I was hired by a startup to architect, develop, and deliver platform software for 4G and 5G mobile network solutions. In that role, like many of my startup roles before it, I was expected to, and did develop platform software from scratch to support the core application software (mobile networking protocol stacks) running in remote radio heads (RRH) and COTS server running in the network core. 

 

The mandate to move to cloud-native

In late 2018, the same startup company mandated both the RRH and COTS servers move to cloud-native, or in other words, Kubernetes. The deliverables of my role changed from architecting proprietary platform software to architecting solutions based on lots of open source (OSS) tools and applications. 

Rearchitecting the core software application out of the monolithic images and into containerized microservices-based images was the easy part. Replacing the infrastructure support provided by the proprietary platform software proved to be the most difficult.

I was dragged kicking and screaming into that effort and subsequently into the Kubernetes world. I was required to develop a platform solution that supported the new microservices based architecture. I didn’t like it. 


At first, I was frustrated sifting through the plethora of information available for learning Kubernetes and other CNCF (Cloud Native Computing Foundation) projects. It was initially overwhelming, but in time I found the engineering principles required to develop Cloud Native platforms were not so different from developing proprietary ones and, so, I made my peace with Kubernetes. 


So, I wrote the “What Happened to Platform Engineering?” ebook

My ebook is an attempt at articulating my journey in such a way that helps others on their cloud-native platform engineering journey.  If you’re interested in this topic, I’d recommend you a recent podcast with the Kubernetes Byte’s hosts, Ryan Wallner and Bhavin Shah, called Ops Ops Hooray! Navigating IDPs from an Ops perspective (by Bubernetes Bytes). In this episode, we talk about the unique operations perspective required for an effective IDP implementation. Check it out.


 

Has your company embraced platform engineering/cloud-native IDP?

  • Yes, we’re implementing it.

  • Yes, but we’re still figuring out what our IDP should be.

  • Sure, if you consider a spreadsheet a form of IDP.

  • Not yet. We’re in the learning/planning phases.



 


bottom of page