The 5 Pillars of Platform Engineering
Over the past few years, something has happened that I did not entirely expect: people have started paying attention to what I have to say.
I see people following me on LinkedIn. I see people subscribing because they want to hear more. I see conversations continue after I have added my thoughts to them. I take an enormous amount of pride in that. After spending this long working in technology, it means something to know that my experience, and the way I have learned to reason through problems, has value to other people.
It also creates a responsibility that I take very seriously.
If people are going to spend their time listening to me, I owe them more than confident-sounding bullshit. I do not want to repeat whatever the industry currently finds fashionable, tell people what they want to hear, or manufacture certainty just to make myself sound good. I want what I say to be as grounded in truth as I can make it. I want people to be able to challenge the reasoning, follow it for themselves, and trust that I will correct it when the reasoning does not hold up.
That does not mean I will always be right. Nobody worth listening to can honestly promise that. Trust is not built by pretending to be infallible; it is built by showing the work, being clear about the boundaries of an argument, and being willing to change the conclusion when a better one emerges.
This series begins with a fairly good example of exactly that.
Why I am calling it Platform Engineering
I am deliberately framing this as The 5 Pillars of Platform Engineering, not the five pillars of DevOps.
Before I go any further, I also need to be clear about the term Platform Engineering. I know that it already has an established industry meaning, usually centered on internal developer platforms and golden paths. This is not merely a loose collection of blog posts using the same phrase. PlatformEngineering.org operates a substantial professional community and offers multiple Platform Engineering certifications. Its Certified Professional program focuses directly on designing and scaling internal developer platforms [1].
Their own definition provides the bridge to what I am proposing:
A platform is not a tool, a portal, or a dashboard, but the sum of paths enabled by a set of capabilities.
Source: What is platform engineering?, PlatformEngineering.org [2]
Those capabilities are exposed through interfaces so that people inside the organization can reach useful outcomes with as little friction as possible. That is a strong description of what a platform is and how its users experience it.
The Five Pillars describe what sits underneath that sum. Every path and capability ultimately depends on some combination of them. The established definition describes the platform as a product and delivery model. I am defining the technical foundation required to engineer it.
I am not trying to replace their definition with mine. I am arguing that their sum of paths has a base, and that the base can be described.
This lack of agreement is not unique to Platform Engineering. It is one of the recurring problems in our industry. DevOps described a philosophy and operating model, but the industry turned it into a job title and used it to mean almost anything. We never reached a durable consensus before much of the industry moved on to the next term.
Google's own SRE literature draws a useful boundary with the wonderfully nerdy formulation, "class SRE implements interface DevOps." SRE is a concrete engineering discipline that implements parts of the broader philosophy. Platform Engineering is not Google's replacement name for SRE, and I am not claiming that it is [3].
When I use Platform Engineering throughout this series, I mean the engineering foundation beneath those paths and capabilities, including the engineers who build and operate them. I see it as the modern successor to the broad technical function that the industry previously, and often incorrectly, labeled DevOps Engineering. The internal-platform definition and the Five Pillars are not competing definitions. They describe different layers of the same discipline.
There is no universal consensus here. That is why I am stating my definition and reasoning before building a framework on top of them.
I recently came across a LinkedIn post [4] arguing that, if you wanted to be able to work anywhere, there were four things you needed to master: Linux, Kubernetes, automation, and security.
My immediate reaction was that the list was categorically wrong.
Not necessarily because the things on it were unimportant. Linux, Kubernetes, automation, and security can all be extremely important. The problem was that they do not belong at the same level. Linux and security are foundational bodies of knowledge. Kubernetes is a particular implementation. Automation is an applied engineering discipline. Putting them beside one another is a little like listing physics, bridges, manufacturing, and a specific model of crane as four equivalent fields of study.
So, naturally, I responded with what I thought was the better list: Linux, networking, security, and automation.
There was still a problem, but it was not simply that my answer was wrong. I was trying to repair the original list while accepting the original author's constraints. I was still looking for four items that could fit inside the same frame.
I did not need to accept that frame. I needed to challenge it.
Once I stopped trying to produce a better four-item answer and instead asked what actually qualifies as foundational, the structure changed. Automation is not primitive enough to be a foundation. It is something we build from more fundamental abilities. Storage could no longer be folded into Linux because it has a large and distinct conceptual model of its own. Scripting emerged as the foundation beneath automation.
That left me with five foundational domains:
The 5 Pillars of Platform Engineering
Linux / Systems. Networking. Security. Storage. Scripting.
These are not the five hottest technologies to learn this year. They are not a certification roadmap, nor are they the only subjects a Platform Engineer will ever need. They are durable bodies of knowledge underneath modern infrastructure.
The goal is not to become the world's foremost expert in all five. That would be absurd. Each one is an entire career. The goal is to have enough grounding in each that, when you encounter an unfamiliar system, you can reason about what it is doing instead of merely memorizing its interface.
Learn what the stack is made of, not just the stack.
Linux / Systems
I use Linux as the practical label and Systems as the broader conceptual category. Linux is the dominant operating environment across modern infrastructure, but this pillar is not about memorizing distributions or becoming a kernel developer. It is about understanding the machine beneath the abstractions we operate.
The center of this pillar is process lifecycle and resource management. A Platform Engineer should understand how processes are started and supervised, and how the operating system allocates resources to them. When something breaks, somebody has to be able to investigate what the machine is actually doing rather than simply restarting a container and hoping the problem becomes somebody else's.
Containers and cloud services still inherit systems concepts. Their interfaces may hide those concepts for a while, but hiding a thing does not make it stop existing.
Networking
Networking is one of the most glaring omissions in many modern DevOps and Platform Engineering skill lists. We have somehow reached a point where people are encouraged to learn an ingress controller before they understand how traffic gets from one machine to another.
The Platform Engineering discipline I am describing is full of systems communicating with other systems. Routing and DNS are the two primary concepts I would start with. A Platform Engineer should understand how traffic finds its destination and how a name becomes that destination well enough to determine where communication failed.
Cloud networking and service meshes are not replacements for networking. They are abstractions of networking concepts. The abstraction may be useful, and often is, but it cannot repeal the model underneath it.
Security
Security is foundational because it crosses every other pillar. It is present in who may execute a process, which system may reach another system, who may read stored data, and which identity may invoke an automated operation.
Identity and trust boundaries are the center of this pillar. A Platform Engineer should understand who or what is acting, and where that authority begins and ends. Product-specific controls are implementations of that model. Learning the product without understanding the model beneath it produces configurations that may work while remaining poorly understood, and occasionally terrifying.
Security cannot be the product you bolt onto a finished platform immediately before an audit. It is a property of the entire system and therefore has to be part of the engineer's foundation.
Storage
Storage was the pillar I initially buried inside Linux. That works only until you look closely enough to realize how much independent theory is hiding there.
Filesystems and redundancy are the center of this pillar. Filesystem behavior includes concepts such as journaling and native snapshots. Redundancy begins with understanding RAID and its failure models. A Platform Engineer does not need to be a storage specialist, but should understand which layer provides a capability and what kinds of failure it does and does not protect against.
More advanced storage topics build on that foundation rather than replacing it. You cannot properly reason about remote or distributed storage without first understanding the devices, filesystems, redundancy models, and data behavior underneath them.
Scripting
This pillar took the most work to name.
My original list used automation, but automation is an applied discipline. It depends on the ability to express logic and interact programmatically with systems. The foundation underneath automation is scripting.
I briefly considered calling the pillar development, but that points too far into the broader Software Engineering and Computer Science tree. Platform Engineers develop software and tooling, sometimes quite substantial software, but that does not mean the entire SWE or CS body of knowledge is a prerequisite to understanding Platform Engineering. There is plenty of overlap, but the disciplines have different centers of gravity.
By scripting, I also do not mean knowing a few Bash commands copied from Stack Overflow. The practical baseline is shell competency plus useful fluency in Python. Shell provides direct interaction with the systems being operated, while Python provides enough structure to build real automation and tooling. Go is the natural next step when scripts need to become standalone tools or long-lived services.
A Platform Engineer needs enough programming ability to make systems behave reliably, repeatedly, and programmatically.
That also means being comfortable with the less glamorous material that glues modern platforms together: JSON, YAML, SQL, regex, and the other formats and domain-specific languages we encounter along the way. They are not all programming languages, but we still need to be able to work with and troubleshoot them.
Platform Engineers need programming fluency. They do not necessarily need full software-engineering specialization.
Foundations, disciplines, and implementations
The distinction between these layers is the real point of the framework.
Linux / Systems, Networking, Security, Storage, and Scripting are the foundations. Applied disciplines and technical implementations are constructed from them.
That does not make the higher layers less important. It simply describes their place in the dependency tree.
A useful test is to ask whether something can be decomposed into combinations of the five pillars. Kubernetes is an implementation, while CI/CD is an applied practice. Both matter, but neither is foundational.
Observability presents the strongest argument for inclusion, so it deserves a more explicit answer. It extends across all five pillars by giving us information about how the systems built from them are behaving. That information does not explain itself. You must understand the underlying system before its telemetry becomes evidence instead of decoration. Observability is extremely important, but it is a natural next step built upon the pillars rather than a pillar itself.
The library came first
I had actually started building this framework before I knew that was what I was doing. I previously published The Engineering Foundations Library, a collection of ten books that I personally consider worth reading.
I did not choose those books to support the Five Pillars. The framework did not exist yet. Looking back, though, the books fit naturally into the same foundation. I had selected them because they teach durable ways to understand systems rather than whichever products happen to be popular right now.
That does not prove the Five Pillars are correct, but it does tell me that the framework was not manufactured to fit a single argument. The same structure was already present in the material I trusted enough to recommend.
Although the library was published first, it now belongs at the end of this journey. The individual articles will establish each pillar, and the library will bring them back together as a practical path for continuing the work.
Where this goes next
This article is the starting point, not the complete curriculum. Each pillar deserves its own treatment, and each can be followed far beyond what any one person needs to know.
The next five entries in this series will take the pillars individually: Linux / Systems, Networking, Security, Storage, and Scripting. The objective will not be to dump an impossible list of trivia into each article. It will be to identify what belongs at the foundation, what grows above it, and why those concepts matter when a supposedly simple abstraction inevitably leaks.
After that, we can move upward and examine how higher-level disciplines and platforms are built from these foundations.
Tools change. Foundations transfer.
-Villain