zuerst viele DevFrameworkPlatformEngineers arbeiten lokal, mit zentralem Deployment nach OTC in einen/max zwei Control-Cluster
wir gehen anfangs von ca. 5 clustern aus
jeder cluster mit 3 Knoten/VM (in drei AvailabilityZones)
pro VM 4 CPU, 16 GB Ram, 50 GB Storage read/write once, PVCs ‘ohne limit’
public IPs, plus Loadbalancer
Keycloak vorhanden
Wildcard Domain ?? –> Eher ja

Next Steps: (Vorschlag: in den nächsten 2 Wochen)

Florian spezifiziert an Tobias
Tobias stellt bereit, kubeconfig kommt an uns
wir deployen

1 - Workstreams

This page is WiP (23.8.2024).

Continued discussion on 29th Aug 24
idea: Top down mit SAFe, Value Streams
paralell dazu bottom up (die zB aus den technisch/operativen Tätigkeietn entstehen)
Scrum Master?
Claim: Self Service im Onboarding (BTW, genau das Versprechen vom Developer Framework)
Org-Struktur: Scrum of Scrum (?), max. 8,9 Menschen

Stefan and Stephan try to solve the mission ‘wir wollen losmachen’.

Solution Idea:

First we define a rough overall structure (see ‘streams’) and propose some initial activities (like user stories) within them.
Next we work in iterative steps and produce iteratively progress and knowledge and outcomes in these activities.
Next the whole team decides which are the next valuable steps

Overall Structure: Streams

We discovered three streams in the first project steps (see also blog):

Research, Fundamentals, Architecture
POCs (Applications, Platform-variants, …)
Deployment, production-lifecycle

# 
## Stream 'Fundamentals'
### [Platform-Definition](./fundamentals/platform-definition/)
### [CI/CD Definition](./fundamentals/cicd-definition/)
## Stream 'POC'
### [CNOE](./pocs/cnoe/)
### [Kratix](./pocs/kratix/)
### [SIA Asset](./pocs/sia-asset/)
### Backstage
### Telemetry
## Stream 'Deployment'
### [Forgejo](./deployment/forgejo/)

DoR - Definition of Ready

Bevor eine Aufgabe umgesetzt wird, muss ein Design vorhanden sein.

Bezüglich der ‘Bebauung’ von Plaztform-Komponenten gilt für das Design:

Die Zielstellung der Komponenet muss erfasst sein

1.1 - Fundamentals

References

Fowler / Thoughtworks

alt text

nice article about platform orchestration automation (introducing BACK stack)

https://dev.to/thenjdevopsguy/creating-your-platform-engineering-environment-4hpa

1.1.1 - Activity 'Platform Definition'

Summary

Das theoretische Fundament unserer Plattform-Architektur soll begründet und weitere wesentliche Erfahrungen anderer Player durch Recherche erhoben werden, so dass unser aktuelles Zielbild abgesichert ist.

Rationale

Wir starten gerade auf der Bais des Referenzmodells zu Platform-Engineering von Gartner und Huamitec. Es gibt viele weitere Grundlagen und Entwicklungen zu Platform Engineering.

Task

Zusammentragen, wer was federführend macht in der Plattform Domäne, vgl. auch Linkliste im Blog
Welche trendsettenden Plattformen gibt es?
Beschreiben der Referenzarchitektur in unserem Sinn
Begriffsbildung, Glossar erstellen (zB Stacks oder Ressource-Bundles)
Architekturen erstellen mit Control Planes, Seedern, Targets, etc. die mal zusammenliegen, mal nicht
Beschreibung der Wirkungsweise der Platform-Orchestration (Score, Kubevela, DSL, … und Controlern hierzu) in verscheidenen Platform-Implemnetierungen
Ableiten, wie sich daraus unser Zielbild und Strategie ergeben.
Argumentation für unseren Weg zusammentragen.
Best Practices und wichtige Tipps und Erfahrungen zusammentragen.

1.1.2 - Activity 'CI/CD Definition'

Summary

Der Produktionsprozess für Applikationen soll im Kontext von Gitops und Plattformen entworfen und mit einigen Workflowsystemen im Leerlauf implementiert werden.

Rationale

In Gitops basierten Plattformen (Anm.: wie es zB. CNOE und Humanitec mit ArgoCD sind) trifft das klassische Verständnis von Pipelining mit finalem Pushing des fertigen Builds auf die Target-Plattform nicht mehr zu.

D.h. in diesem fall is Argo CD = Continuous Delivery = Pulling des desired state auf die Target plattform. Eine pipeline hat hier keien Rechte mehr, single source of truth ist das ‘Control-Git’.

D.h. es stellen sich zwei Fragen:

Wie sieht der adaptierte Workflow aus, der die ‘Single Source of Truth’ im ‘Control-Git’ definiert? Was ist das gewünschte korrekte Wording? Was bedeuen CI und CD in diesem (neuen) Kontext ? Auf welchen Environmants laufen Steps (zB Funktionstest), die eben nicht mehr auf einer gitops-kontrollierten Stage laufen?
Wie sieht der Workflow aus für ‘Events’, die nach dem CI/CD in die single source of truth einfliessen? ZB. abnahmen auf einer Abnahme Stage, oder Integrationsprobleme auf einer test Stage

Task

Es sollen existierende, typische Pipelines hergenommen werden und auf die oben skizzierten Fragestellungen hin untersucht und angepasst werden.
In lokalen Demo-Systemen (mit oder ohne CNOE aufgesetzt) sollen die Pipeline entwürfe dummyhaft dargestellt werden und luffähig sein.
Für den POC sollen Workflow-Systeme wie Dagger, Argo Workflow, Flux, Forgejo Actions zum Einsatz kommen.

Further ideas for POSs

see sample flows in https://docs.kubefirst.io/

1.2 - POCs

Further ideas for POSs

see sample apps ‘metaphor’ in https://docs.kubefirst.io/

1.2.1 - Activity 'CNOE Investigation'

Summary

Als designiertes Basis-Tool des Developer Frameworks sollen die Verwendung und die Möglichkeiten von CNOE zur Erweiterung analysiert werden.

Rationale

CNOE ist das designierte Werkzeug zur Beschreibung und Ausspielung des Developer Frameworks. Dieses Werkzeug gilt es zu erlernen, zu beschreiben und weiterzuentwickeln. Insbesondere der Metacharkter des ‘Software zur Bereitstellung von Bereitstellungssoftware für Software’, d.h. der unterschiedlichen Ebenen für unterschiedliche Use Cases und Akteure soll klar verständlich und dokumentiert werden. Siehe hierzu auch das Webinar von Huamnitec und die Diskussion zu unterschiedlichen Bereitstellungsmethoden eines RedisCaches.

Task

CNOE deklarativ in lokalem und ggf. vorhandenem Cloud-Umfeld startbar machen
Architektur von COE beschreiben, wesentliche Wording finden (zB Orchestrator, Stacks, Kompoennten-Deklaration, …)
Tests / validations durchführen
eigene ‘Stacks erstellen’ (auch in Zusammenarbeit mit Applikations-POCs, zB. SIA und Telemetrie)
Wording und Architektur von Activity ‘Platform-Definition’ beachten und challengen
Alles, was startbar und lauffähig ist, soll möglichst vollautomatisch verscriptet und git dokumentiert in einem Repo liegen

Issues / Ideas / Improvements

k3d anstatt kind
kind: ggf. issue mit kindnet, ersetzen durch Cilium

1.2.2 - Activity 'SIA Asset Golden Path Development'

Summary

Implementierung eines Golden Paths in einem CNOE/Backstage Stack für das existierende ‘Composable SIA (Semasuite Integrator Asset)’.

Rationale

Das SIA Asset ist eine Entwicklung des PC DC - es ist eine Composable Application die einen OnlineShop um die Möglichkeit der FAX-Bestellung erweitert. Die Entwicklung begann im Januar 2024 mit einem Team von drei Menschen, davon zwei Nearshore, und hatte die typischen ersten Stufen - erst Applikationscode ohne Integration, dann lokale gemockte Integration, dann lokale echte Integration, dann Integration auf einer Integrationsumgebung, dann Produktion. Jedesmal bei Erklimmung der nächsten Stufe mit Erstellung von individuellem Build und Deploymentcode und Abwägungen, wie aufwändig nachhaltig und wie benutzbar das jeweilige Konstrukt sein sollte. Ein CI/CD gibt es nicht, zu großer Aufwand für so ein kleines Projekt.

Die Erwartung ist, dass so ein Projekt als ‘Golden Path’ abbildbar ist und die Entwicklung enorm bescheunigt.

Task

SIA ‘auf die Platform heben’ (was immer das bedeutet)
Den Build-Code von SIA (die Applikation und einen Shop) in einen CI/CD Workflow transformieren

References

https://platformengineering.org/blog/decoding-golden-paths-the-highway-for-your-developers

Scenario (see IPCEICIS-363)

graph TB
  Developer[fa:fa-user developer]
  PlatformDeliveryAndControlPlaneIDE[IDE]
  subgraph LocalBox["localBox"]
    LocalBox.EDF[Platform]
    LocalBox.Local[local]
  end
  subgraph CloudGroup["cloudGroup"]
    CloudGroup.Test[test]
    CloudGroup.Prod[prod]
  end
  Developer -. "use preferred IDE as local code editing, building, testing, syncing tool" .-> PlatformDeliveryAndControlPlaneIDE
  Developer -. "manage (in Developer Portal)" .-> LocalBox.EDF
  PlatformDeliveryAndControlPlaneIDE -. "provide "code"" .-> LocalBox.EDF
  LocalBox.EDF -. "provision" .-> LocalBox.Local
  LocalBox.EDF -. "provision" .-> CloudGroup.Prod
  LocalBox.EDF -. "provision" .-> CloudGroup.Test

1.2.3 - Activity 'Kratix Investigation'

Summary

Ist Kratix eine valide Alternative zu CNOE?

Rationale

Task

Issues / Ideas / Improvements

1.3 - Deployment

Mantra:
Everything as Code.
Cloud natively deployable everywhere.
Ramping up and tearing down oftenly is a no-brainer.
Especially locally (whereby ’locally’ means ‘under my own control’)