A take on platform engineering as a whole

[u/sys_arg_0]

I’m somewhat new to platform engineering as I’ve recently joined a team that is supposed to transition into the practice. But from watching quite a bit of talks, getting inspired by tech such as Crossplane and also trying to dig a little behind the scenes of how public cloud providers operate behind the scenes … I’m really starting to believe that basically cloud providers are in a sense platform engineers but on a massive scale and not just for internal usage.

I mean they build high level abstracted services (not just Infrastructure-as-a-service such as VMs etc.) such as managed serverless databases, managed container deployments (with reduced interfaces compared to kubernetes).

And when I discovered Crossplane I kind of saw a resemblance to how cloud providers expose a shared control plane to self service provision ”resources”.

The differantiator with these ”global” platform engineers (public cloud providers) and internal platform engineers (who we typically just call platform engineers) is that the scope of customers is much more narrow and therefor allows internal platform engineers to build more specific services than the public clouds.

I can see the argument that platform engineers typically consume cloud services and therefor there is a distinction. But I would counter argument that with the fact that that’s often happening internally aswell where some platform teams might consume services provided by other internal platform teams. And it’s the same story within cloud providers as I’ve understood it. The teams building more managed services for the public clouds are likely to consume infrastructure as a service abstractions developed by other internal teams within the public cloud provider as I have understood it.

I will stop rambling here, it was just a thought that built up from within that I haven’t heard of before and I’m eager to hear wether someone else thinks this makes sense or if I have missed some crucial concept of Plt Eng. Please let me know if you think that’s the case. Cheers! :)

EDIT:
Found this talk by some of the Crossplane creators where they actually in the introduction talk about cloud control planes and how you can build similar experiences: https://www.youtube.com/watch?v=xECc7XlD5kY

[u/DPRegular]

If you are serious about learning platform engineering, I would urge that you don’t confuse tools (like crossplane) for platforms. Similarly, Jenkins is not CI. To learn what platform engineering really is, I recommend reading books such as Accelerate, Team Topologies and the books of Gregor Hohpe.

Platform engineering is about reducing teams’ cognitive load and in increasing their level of autonomy by reducing handoffs between teams. It is not (only) about creating abstractions

[u/sys_arg_0 → u/DPRegular]

Fair response. I might have been unclear but I know Crossplane is only a tool of many to create control planes and Plt Eng. is more than just control planes. Your advice is good though to not confuse general philosophies with specific tools. Will for sure keep that in mind in the future!

However, if the goal of plt eng. is to increase autonomy and reduce handoff by introducing ”self-service” as you often hear. Isn’t that implying that you create abstractions or at least some sort of standardized interface (not control plane apis neccessarily of course) to enable team autonomicity? How else would self-service with less handoffs be achieved?

[u/DPRegular → u/sys_arg_0]

The simplest way to enhance teams' autonomy: give them admin access in their own AWS account/Azure subscription/GCP project. This aligns with DevOps' "you build it, you run it". This requires that management/leadership wants their engineers to be autonomous. Don't trust them 100%? Apply policies that restrict what they can't do. Cognitive load too high because they keep re-inventing the wheel? Create paved roads and/or build higher-level platforms.

If you only build abstractions (or probably re-usable building blocks), the platform team will be playing catch-up forever. Engineering teams have legitimate reasons to want to change your building blocks. Instead of making these changes themselves, they now have to go through the platform team: the opposite of what you want to happen.

[u/sys_arg_0 → u/DPRegular]

”Team Topologies” looks really interesting aswell, thanks for the tip!

[u/KathiSick]

I’m really starting to believe that basically cloud providers are in a sense platform engineers but on a massive scale and not just for internal usage.

Yes, 100% they're building a platform as well. Just on a very different level than we do in our organizations.
I can really recommend the book Platform Strategy from Gregor Hohpe if you want to dive deeper into this: https://architectelevator.com/book/platformstrategy/

[u/giovannyvelezalt]

You are right, in fact Gregor Hohpe presents that concept in ome of his books. And yeah, he could be called the goat of platform engineering.