Bringing the engineering to Platform Engineering: A look at how software development patterns apply to platform building

At Platform Engineering Day 2024 it was said that “platform engineering is an exercise in software development not operations". This is a simple statement on the surface, but has deep implications.

The gang of four structural designs such as the facade pattern and architectural evolutions from layered to microservice components are examples of a well documented history of software engineering. Over the decades, not only have the patterns and techniques been captured, but so have the tradeoffs and contexts in which to consider them.

Software development has a much longer and better documented history than platform building and if we can tap into those experiences we as platform engineers can accelerate our learning and impact. This talk will focus on the key software engineering patterns that appear to be most useful in this new platform building wave so that you too can build not only useful, but also maintainable and extensible platforms.

Transcript

1. Bringing the engineering to Platform Engineering A look at how software development patterns apply to platform building Abby Bangser (she/her) abby@syntasso.io @a_bangser
2. An output A solution Finite An activity Human interaction Unbounded Platforms Platform Engineering ≠
3. Platform engineering… …is a practice built up from DevOps principles… It's both product-based mindset shift and a set of tools and systems to support it . - https://learn.microsoft.com/en-us/platform-engineering/what-is-platform-engineering …builds products for other teams inside the company - the end users of the platform team's product are other teams within the company. - https://martinfowler.com/articles/platform-teams-stuff-done.html …is a discipline within software development… - https://www.redhat.com/en/topics/devops/platform-engineering
4. "Platform Engineering" Track KubeCon NA 2023 and EU 2024
5. Instead of engineering, we discuss platform tools • Observability / Networking / Security • CD (GitOps) • Provisioning infrastructure • Portals for service discovery and scaffolding
6. And if not tools, then platform "realities" • “Build for the 80%” • “Templates enable self service” • “Platforms provide only central services” • “Kubernetes is your platform”
7. I am here to collaborate and dream a better reality. To be clear, I am not here to preach from a pedestal. https://www.deviantart.com/deniseesposito/art/Imagine-John-Lennon-403599550
8. • “Build for the 80%” • “Templates enable self service” • “Platforms provide only central services” • “Kubernetes is your platform” ◦ How do you still enable the 20% to be compliant and efficient? ◦ Who manages upgrades, updates, and running software? ◦ sure, but what about high value “inner-loop” tooling e.g. local environments? ◦ Few orgs are 100% k8s, how do you support non-k8s services & experience? Some questions we could be asking ourselves
9. Some problem statements platform engineering should probably address • Simple and consistent local environments • A sharing ecosystem across the organisation • Push changes for high priority updates • Retiring home grown tools as they become widely available
10. Key engineering principles to apply to platforms 1. Choose architectures intentionally ◦ Think about rate of change, coupling, and resiliency requirements 2. Deliver small, fast, and safe changes ◦ Build trust through CI/CD testing and rollout/rollback plans ◦ Even “offline” apps can have CD, look at mobile/desktop app patterns 3. Prioritise cross functional requirements ◦ User experience including onboarding, maintenance onus, and overall cognitive load ◦ Speed to market to capture opportunity and reduce risk
11. Choose architectures intentionally: There is no "right" answer https://aws.amazon.com/compare/the-difference-between-monolithic-and-microservices-architecture/
12. Build services as domain objects • Foundational requirements • Interface for requests • Custom delivery per request Features (and changes) should be: • Atomic • Versioned • Testable • Independent
13. Deliver small, fast, and safe changes: And that means all the way to users https://thenewstack.io/deployment-strategies/
14. Build test environments & production observability https://firebase.google.com/docs/projects/dev-workflows/overview-environments But this may be dev for your app developer users!
15. Build in cross functional requirements: Build with day 2 in mind from the start https://www.puppet.com/blog/day-0-day-1-day-2-operations Day 2 is true for year 2 as well
16. Focus on delivering changes and reducing TOIL https://medium.com/@gurpreet.singh_89/must-know-site-reliability-engineering-sre-terminology-part-3-8645f37d7768
17. A small example from my experience
18. A common platform experience Version 2.1
19. A common platform experience Version 2.1 Version 2.1
20. A common platform experience Version 2.1 Version 2.1 Version 2.0
21. A common platform experience Version 2.1 Version 2.1 Version 2.0 Version 0.9
22. Applying platform engineering to that problem
23. Implementation Engineering can be done through evolution
24. Implementation Introduce an API that users interact with A P I
25. Implementation Then they don't mind about implementation A P I
26. Implementation Then allow the API to unleash BOTH sides A P I Business Logic
27. Our responsibility as platform engineers • Build sustainable, testable, operable, and usable systems • Leverage experiences from relevant peers and industries • Don't allow current technology to limit the scope of impact
28. Join TAG App Delivery to discuss more!
29. Thank you Abby Bangser (she/her) abby@syntasso.io @a_bangser