Platform Engineering: Scaling Standards not Problems
Platform Engineering is a DevOps evolution, besides the cultural shift, the companies need to be mature in their architecture standards, such as Application Integrations, Hexagonal Development, Cloud Foundations (multi-account strategy), and after that implement a Platform that supplies their needs in terms of Infra as Code but also scale architecture standard decisions!
Let’s talk about Application Integrations first. Why is this so important before Platform Engineering? Look, if you don’t have a well-defined standards how your components, systems, or accounts will communicate between them using choreography, orchestration, API-First or even workflow-first, (everyone will do their own way)! Improved communication between systems will enhance scalability, facilitate easier maintenance, and optimize costs.
Moving to Hexagonal Development will bring a clean separation of a business domain from external dependencies, a better testability because you can mock the adapters easily, and easier maintenance. Which is super important because it creates a clear boundary between your business logic and infrastructure. The big pro here is that you can change your infrastructure without touching your business rules. It’s more complex initially, mainly because you may need to re-write some of your systems and apps, and some developers might think it’s over-engineering. But trust me, when you start implementing Platform Engineering, you’ll thank me later for this separation!
Landing zones with proper security controls, multi-account strategy, Well-Architected Framework implementation, Organization-level policies and proper Tagging strategy are the basics of Cloud Foundations and without proper those, you’ll end up with a big mess! It is fundamental having a better security, cost control, and governance. It takes time to implement, but, trying to implement Platform Engineering without good Cloud Foundations is like trying to run before you can walk!
Finally, the Platform Engineering tools, such as Internal developer portals, Service catalogs, Automated CI/CD pipelines, and Observability stack are the cherries on top, but they only work if you have all the previous layers well implemented.
So, what I’m trying to say is: you need to develop through these stages. Each layer builds upon the previous one, because a Platform Engineering will scale all your standards, the good ones and the bad ones. Take a moment to review architecture standards if you're not well-prepared to prevent scaling problems. For example, lacking scalability and cost control can lead to undesirable cost increases. Yes, it’s a long journey, but trying to skip steps will only create a technical debt that you’ll have to pay later, with interest!
Remember, Platform Engineering is not just about the tools — it’s about creating a solid foundation that can support your company’s growth. It’s like building — you need strong foundations before adding the fancy stuff on top! 🏗️💪
