By Internal developer platforms fail most often not because teams lack skill, but because they over-optimize for simplicity too early. Abstracting away all complexity before understanding real customer requirements bakes hidden assumptions into the platform architecture. When the first large workload arrives with legitimate flexibility demands, there is no safe path to adapt without a redesign.
In this interview on TFiR, Corey McGalliard, Engineering Manager at Akamai Cloud, walks through the over-abstraction trap that platform teams fall into, what their first large customer revealed about the limits of a one-size-fits-all design, and how modular architecture with cross-organizational contribution loops replaced the brittle PaaS-style approach.
Guest: Corey McGalliard, Engineering Manager at Akamai Cloud
Show: TFiR
Here is what every platform engineer and engineering manager needs to know.
Technical Deep Dive
Q: What is the most common mistake platform engineering teams make when building an internal developer platform?
Corey McGalliard, Engineering Manager at Akamai Cloud, identifies over-abstraction as the primary trap. Teams attempt to hide all complexity from end users, aiming to create a system so simple that someone can hand over a container and the platform handles everything. This approach embeds a large number of undocumented assumptions into the platform design, assumptions that only surface when real users with real workloads appear.
“You try to abstract away everything, try to make it to where it’s as simple as possible for someone to pick it up. There are a lot of assumptions that go into the way that works. It’s really complex.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Q: What is the difference between a configurable flat platform and a PaaS-style platform in internal platform engineering?
McGalliard describes a spectrum in platform design. On one end sits a highly configurable, feature-rich flat platform with many knobs available to users. On the other end sits a PaaS or software-as-a-service mentality where users interact with a minimal surface and the platform manages all underlying decisions. Most teams designing internal platforms gravitate toward the PaaS end early, which creates the abstraction and flexibility problem at scale.
“You have the idea of having all the bells and whistles, a very configurable flat platform, and then you have on the other side something closer to a PaaS or software-as-a-service mentality.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Q: How did Akamai’s platform team discover the limits of their over-abstracted design?
McGalliard explains that the problem became clear the moment Akamai’s first large customer engaged with the platform. That customer immediately surfaced specific flexibility requirements the platform could not accommodate. The encounter forced the team to recognize that flexibility is not a feature to add later; it is an architectural decision that must be considered from the beginning.
“Our first large customer just immediately started saying, I need this flexibility or that flexibility. We learned that not only do we need to consider flexibility in the platform, but we also need to extend almost like modularity to our users.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Q: What does a modular platform engineering approach look like in practice?
McGalliard’s answer centers on two shifts. First, the platform exposes modularity to users so they can contribute capabilities back to the platform itself. Second, platform ownership is distributed across the organization. Rather than one team being responsible for building everything, expertise from multiple teams across the organization is pulled in to build and extend the platform. This model makes the system flexible without requiring the core team to anticipate every use case in advance.
“It’s not all on one team. It’s more about pulling in the expertise you have throughout the organization to build the platform.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Q: Can a one-size-fits-all internal developer platform work at enterprise scale?
McGalliard’s position is direct: a one-size-fits-all platform cannot hold up against the real diversity of enterprise workloads and team requirements. The correct path is not to simplify until all variation disappears, but to build modular architecture that gives users and contributing teams the ability to extend and adapt the system. Flexibility becomes a structural property of the platform rather than a request handled case by case.
“You can’t immediately make this a one-size-fits-all solution, but you can build a more modular way and give the ability to make the system flexible.” — Corey McGalliard, Engineering Manager, Akamai Cloud
Resources & Documentation
- Akamai Cloud, cloud computing and infrastructure platform from Akamai Technologies
***
👇 Click to Read Full Raw Transcript
Swapnil Bhartiya: When we look at teams, you know, maybe your teams or other teams that you know, because Akamai also serve a lot of customers and you partner a lot, where you see they are doing platform engineering wrong, where you’re like, they don’t fully grasp the concept of where you’re like, this is how it should be done. So let’s focus first on what people are doing wrong when it comes to platform engineering.
Corey McGalliard: That’s a really hard question. One thing that a trap that we fell into, and I’m sure other people have done this as well, right? You try to abstract away everything, right? You try to make it to where it’s as simple as possible for someone to pick it up. So you, in, in kind of the, the way you think about this, you have the idea of like having all the bells and whistles, having a very like, configurable flat platform, and then you have on the other side something that’s more closer to a PAAS or like a software as a service kind of mentality. Right? And a lot of us, when we start looking at this, oh, we just want to give it so that. Build it so that you can just hand us a container. There’s a lot of assumptions that go into the way that that works. It’s really complex, right? And what we fell into, we started to go down this path and our first large customer just immediately started saying, well, I need this flexibility or that flexibility. So we learned that not only do we need to kind of consider flexibility in the platform, but we also need to extend almost like modularity to our users so they can contribute back to us and that we can also pull in other expertise within the organization. It’s not all on one team, but it’s more about pulling in the expertise you have throughout the organization to build the platform. Right. So you can’t immediately make this like one size fits all solution, but you can build a more modular way and give the ability to make the system flexible. Right. Does that make sense?
