From 720d68803d8389a406737987c7f3390838aff0fa Mon Sep 17 00:00:00 2001
From: Nicolai Ort <info@nicolai-ort.com>
Date: Tue, 1 Apr 2025 12:06:58 +0200
Subject: [PATCH] docs(day0): past present future

---
 content/day0/07_past-present-future.md | 60 ++++++++++++++++++++++++++
 content/day0/_index.md                 |  3 +-
 2 files changed, 62 insertions(+), 1 deletion(-)
 create mode 100644 content/day0/07_past-present-future.md

diff --git a/content/day0/07_past-present-future.md b/content/day0/07_past-present-future.md
new file mode 100644
index 0000000..015a586
--- /dev/null
+++ b/content/day0/07_past-present-future.md
@@ -0,0 +1,60 @@
+---
+title: The past, the present and the future of platform engineering
+weight: 7
+tags:
+ - platform
+ - cloudnativecon
+---
+
+<!-- {{% button href="https://youtu.be/rkteV6Mzjfs" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}} -->
+
+The good old baseline is "iam an an developer, i write code - now i have to do stuff to continue writing code".
+Most developers will continue on to "now i have to write scripts" on order to just do their jobs instead of working on infra.
+
+These scripts evolve to tools which evolve into an internal platform (if everyone starts using it).
+Other base components can also feel like platforms (for example application servers).
+
+## The early day evolution
+
+- Hudson
+- Docker: Not really building platforms, rather standardized application packaging
+- Kubernetes (and Nomad + Swarm): A new concept of scheduling instead of jsut running the application in a container
+
+=> We've been building platforms (or failing to build them) for years and years but now we kinda agree about what a platform is
+
+## Present
+
+We have the base idea of a platform
+
+```mermaid
+graph LR
+    ServiceConsumers-->|Consume through|HTTPAPI-->|Trigger work on|Controllers-->|So|Services
+    ServiceOwner-->|Manages|Services
+```
+
+- The fist question: Do we use public controllers (e.g. the cncf landscape projects) or build our own?
+- Result: Mostly a mix starting with public, realizing needs and expanding
+
+## Make it your own
+
+- Goal: Make the platform domain specific for your developers
+- Evolution: Tools like DAPR for developers or Crossplane for api-building
+- Build the API and Controllers first - dashboard, gitops, observability, ... second
+- Remember that kubernetes can manage anything - not just containers
+
+TODO: Steal image
+
+## Blueprints
+
+Take all of the projects you need, combine them and hide the complexity
+High level architecture of internal platforms is the same as public ones (aws, ...) but internal and built on kubernetes.
+
+TODO: Steal images for platform blueprints (3 slides)
+
+## Future
+
+- Platform Engineering certification by the CNCF is on the horizon
+- Do we need to hide kubernetes from developers? Maybe -> The CNCF is starting groups to get app devs closer to platform engineers
+- More multi-cluster specialized tools are sprawling in the last year (scheduling, discovery, management)
+- AI things are happening and we should utilize it but not just by calling a llm directly and calling it a day -> e.g. dapr llm abstraction api
+- Platforms are not built in isolation, we need to help each other
\ No newline at end of file
diff --git a/content/day0/_index.md b/content/day0/_index.md
index 8282059..619860b 100644
--- a/content/day0/_index.md
+++ b/content/day0/_index.md
@@ -10,7 +10,8 @@ This year I spent most of my time at the platform engineering day.
 ## Talk recommendations
 
 - [So you want to hire for platform engineering](../06_hire-engineers)
+- [The past, the present and the future of platform engineering](../07_past-present-future)
 
 ## Other stuff I learned or people i talk to
 
-- TODO:
\ No newline at end of file
+- Meshcloud: They build developer platform tooling (currently mostly integrated with cloud providers)
\ No newline at end of file