diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 0000000..56d6da2 --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,22 @@ +{ + "workbench.colorCustomizations": { + "activityBar.activeBackground": "#93e6fc", + "activityBar.background": "#93e6fc", + "activityBar.foreground": "#15202b", + "activityBar.inactiveForeground": "#15202b99", + "activityBarBadge.background": "#fa45d4", + "activityBarBadge.foreground": "#15202b", + "commandCenter.border": "#15202b99", + "sash.hoverBorder": "#93e6fc", + "statusBar.background": "#61dafb", + "statusBar.foreground": "#15202b", + "statusBarItem.hoverBackground": "#2fcefa", + "statusBarItem.remoteBackground": "#61dafb", + "statusBarItem.remoteForeground": "#15202b", + "titleBar.activeBackground": "#61dafb", + "titleBar.activeForeground": "#15202b", + "titleBar.inactiveBackground": "#61dafb99", + "titleBar.inactiveForeground": "#15202b99" + }, + "peacock.remoteColor": "#61dafb" +} \ No newline at end of file diff --git a/content/en/docs/project/intro-stakeholder-workshop/DevOps-Lifecycle-1.jpg b/content/en/docs/project/intro-stakeholder-workshop/DevOps-Lifecycle-1.jpg new file mode 100644 index 0000000..c40430a Binary files /dev/null and b/content/en/docs/project/intro-stakeholder-workshop/DevOps-Lifecycle-1.jpg differ diff --git a/content/en/docs/project/intro-stakeholder-workshop/DevOps-Lifecycle.jpg b/content/en/docs/project/intro-stakeholder-workshop/DevOps-Lifecycle.jpg new file mode 100644 index 0000000..c40430a Binary files /dev/null and b/content/en/docs/project/intro-stakeholder-workshop/DevOps-Lifecycle.jpg differ diff --git a/content/en/docs/project/intro-stakeholder-workshop/_index.md b/content/en/docs/project/intro-stakeholder-workshop/_index.md new file mode 100644 index 0000000..e54fef8 --- /dev/null +++ b/content/en/docs/project/intro-stakeholder-workshop/_index.md @@ -0,0 +1,94 @@ +--- +title: Stakeholder Workshop Intro +weight: 50 +description: An overall eDF introduction for stakeholders +--- + + +## Edge Developer Framework Solution Overview + +> This section is derived from [conceptual-onboarding-intro](../conceptual-onboarding/1_intro/) + +1. As presented in the introduction: We have the ['Edge Developer Framework'](./edgel-developer-framework/). \ + In short the mission is: + * Build a european edge cloud IPCEI-CIS + * which contains typical layers infrastructure, platform, application + * and on top has a new layer 'developer platform' + * which delivers a **cutting edge developer experience** and enables **easy deploying** of applications onto the IPCEI-CIS +2. We think the solution for EDF is in relation to ['Platforming' (Digital Platforms)](../conceptual-onboarding/3_platforming/) + 1. The next evolution after DevOps + 2. Gartner predicts 80% of SWE companies to have platforms in 2026 + 3. Platforms have a history since roundabout 2019 + 4. CNCF has a working group which created capabilities and a maturity model +3. Platforms evolve - nowadys there are [Platform Orchestrators](../conceptual-onboarding/4_orchestrators/) + 1. Humanitec set up a Reference Architecture + 2. There is this 'Orchestrator' thing - declaratively describe, customize and change platforms! +4. Mapping our assumptions to the [CNOE solution](../conceptual-onboarding/5_cnoe/) + 1. CNOE is a hot candidate to help and fulfill our platform building + 2. CNOE aims to embrace change and customization! + + +## 2. Platforming as the result of DevOps + +### DevOps since 2010 + +![alt text](DevOps-Lifecycle.jpg) + +* from 'left' to 'right' - plan to monitor +* 'leftshift' +* --> turns out to be a right shift for developers with cognitive overload +* 'DevOps isd dead' -> we need Platforms + +### Platforming to provide 'golden paths' + +> don't mix up 'golden paths' with pipelines or CI/CD + +![alt text](../conceptual-onboarding/3_platforming/humanitec-history.png) + +#### Short list of platform using companies + +As [Gartner states](https://www.gartner.com/en/newsroom/press-releases/2023-11-28-gartner-hype-cycle-shows-ai-practices-and-platform-engineering-will-reach-mainstream-adoption-in-software-engineering-in-two-to-five-years): "By 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery." + +Here is a small list of companies alrteady using IDPs: + +* Spotify +* Airbnb +* Zalando +* Uber +* Netflix +* Salesforce +* Google +* Booking.com +* Amazon +* Autodesk +* Adobe +* Cisco +* ... + +## 3 Platform building by 'Orchestrating' + +So the goal of platforming is to build a 'digital platform' which fits [this architecture](https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering) ([Ref. in German)](https://www.gartner.de/de/artikel/was-ist-platform-engineering): + +![alt text](image.png) + +### Digital Platform blue print: Reference Architecture + +The blue print for such a platform is given by the reference architecture from Humanitec: + +[Platform Orchestrators](../conceptual-onboarding/4_orchestrators/) + +### Digital Platform builder: CNOE + +Since 2023 this is done by 'orchestrating' such platforms. One orchestrator is the [CNOE solution](../conceptual-onboarding/5_cnoe/), which highly inspired our approach. + +In our orchestartion engine we think in 'stacks' of 'packages' containing platform components. + + +## 4 Sticking all together: Our current platform orchestrating generated platform + +Sticking together the platforming orchestration concept, the reference architecture and the CNOE stack solution, [this is our current running platform minimum viable product](../plan-in-2024/image-2024-8-14_10-50-27.png). + +This will now be presented! Enjoy! + + + diff --git a/content/en/docs/project/intro-stakeholder-workshop/devops.png b/content/en/docs/project/intro-stakeholder-workshop/devops.png new file mode 100644 index 0000000..efa787a Binary files /dev/null and b/content/en/docs/project/intro-stakeholder-workshop/devops.png differ diff --git a/content/en/docs/project/intro-stakeholder-workshop/image.png b/content/en/docs/project/intro-stakeholder-workshop/image.png new file mode 100644 index 0000000..ed09018 Binary files /dev/null and b/content/en/docs/project/intro-stakeholder-workshop/image.png differ diff --git a/content/en/docs/solution/design/_index.md b/content/en/docs/solution/design/_index.md new file mode 100644 index 0000000..f5f925c --- /dev/null +++ b/content/en/docs/solution/design/_index.md @@ -0,0 +1,7 @@ +--- +title: Design +weight: 1 +description: Edge Developver Framework Design Documents +--- + +This design documentation structure is inspired by the [design of crossplane](https://github.com/crossplane/crossplane/tree/main/design#readme). diff --git a/content/en/docs/solution/design/proposal-local-deployment.md b/content/en/docs/solution/design/proposal-local-deployment.md new file mode 100644 index 0000000..3ef08c1 --- /dev/null +++ b/content/en/docs/solution/design/proposal-local-deployment.md @@ -0,0 +1,23 @@ +--- +title: Agnostic EDF Deployment +weight: 2 +description: The implementation of EDF must be kubernetes provider agnostic +--- + +* Type: Proposal +* Owner: Stephan Lo (stephan.lo@telekom.de) +* Reviewers: EDF Architects +* Status: Speculative, revision 0.1 + +## Background + +EDF is running as a controlplane - or let's say an orchestration plane, correct wording is still to be defined - in a kubernetes cluster. +Right now we have at least ArgoCD as controller of manifests which we provide as CNOE stacks of packages and standalone packages. + +## Proposal + +The implementation of EDF must be kubernetes provider agnostic. Thus each provider specific deployment dependency must be factored out into provider specific definitions or deployment procedures. + +## Local deployment + +This implies that EDF must always be deployable into a local cluster, whereby by 'local' we mean a cluster which is under the full control of the platform engineer, e.g. a kind cluster on their laptop. \ No newline at end of file