My approach to Internal Developer Platform Referen...
# generalp
Piotr Szwed
04/03/2025, 7:03 AMMy approach to Internal Developer Platform Reference Architecture with no Terraform, 100% API and K8s Operators oriented:
https://www.linkedin.com/posts/szwed_reference-architecture-for-internal-developer-ac[…]m=member_desktop&rcm=ACoAAAAmDMAB9K6x47V6dAPanyR9obR3EJ8rMh0
Piotr Szwed
04/03/2025, 7:04 AMkcp is used to extend K8s API to the entire Organization, so you can even make a coffee with use of the IDP platform (assuming that the cofee machine exposes a REST API)
b
Ben
04/03/2025, 7:20 AMThe devil is in the details. How are you architecting and implementing the API mesh?
p
Piotr Szwed
04/03/2025, 7:40 AMwe leverage the: https://github.com/kcp-dev/kcp/ project
Piotr Szwed
04/03/2025, 7:41 AMkcp is like a CRD manager allowing to split and divide CRDs in any way you want (per team, per role, per department, per cloud, per use case..)
Piotr Szwed
04/03/2025, 7:42 AMso TeamA is allowed to use AWS APIs only, teamB is allowed to make coffee, TeamC has access to DataLake APIs only
j
Juan Roldán
04/03/2025, 10:03 AMI reaaaally like this approach that doesn't rely on Terraform 🚀
My 2 cents on this giving I've experienced a bit of pain dealing with CRDs definitions management and maintenance:
Have a proper backup/restore strategy in place for CRDs.
For CRDs defined as GitOps that's all right and it's usually less complex to restore. CRDs handled "on the fly" by any tools out there that just create them for you when you need them and store them in the cluster, those are the ones that you need to watch out for.
p
Piotr Szwed
04/03/2025, 9:48 PM@Juan Roldán kcp helps a lot with CRDs, and I believe this is just the beginning
j
Juan Roldán
04/04/2025, 6:58 AMGlad to hear that ! : )