doc(onboarding): WiP - sections EDF, platforming and orchestrators added
|
|
@ -4,14 +4,14 @@ weight: 1
|
|||
---
|
||||
|
||||
|
||||
{{% blocks/lead color="dark" %}}
|
||||
You are new to IPCEI-CIS subproject 'DeveloperFramework' ?
|
||||
|
||||
You want to know about the context of 'Platform Engineering' and \
|
||||
why we think it's the stuff we need to create the DeveloperFramework?
|
||||
{{% pageinfo color="info" %}}
|
||||
## Summary
|
||||
|
||||
So please feel free to read this Onboarding guide!
|
||||
{{% /blocks/lead %}}
|
||||
This onboarding section is for you when are new to IPCEI-CIS subproject 'Edge Developer Framework (EDF)' and you want to know about
|
||||
* its context to 'Platform Engineering'
|
||||
* and why we think it's the stuff we need to care about in the EDF
|
||||
{{% /pageinfo %}}
|
||||
|
||||
|
||||
## Storyline of our current project plan (2024)
|
||||
|
|
|
|||
|
|
@ -3,6 +3,13 @@ title: Edge Developer Framework
|
|||
weight: 1
|
||||
---
|
||||
|
||||
{{% pageinfo color="info" %}}
|
||||
## Summary
|
||||
|
||||
tbd
|
||||
|
||||
{{% /pageinfo %}}
|
||||
|
||||
## What are the specifications we know from the IPCEI-CIS Project Portfolio document
|
||||
|
||||
> Reference: IPCEI-CIS Project Portfolio
|
||||
|
|
@ -17,9 +24,9 @@ e. Development of DTAG/TSI Edge Developer Framework
|
|||
### Development of DTAG/TSI Edge Developer Framework (p.14)
|
||||
| capability | major novelties |||
|
||||
| -- | -- | -- | -- |
|
||||
| e.1. Edge Developer full service framework (SDK + day1 +day2 support for edge installations) | Adaptive CI/CD pipelines for heterogeneous edge environments | Decentralized and selfhealing deployment and management | edge-driven monitoring and analytics |
|
||||
| e.2. Built-in sustainabilityoptimization in Edge developer framework | sustainabilityoptimized edge-aware CI/CD tooling | sustainability-optimized configuration management | sustainability-optimized efficient deployment strategies |
|
||||
| e.3. Sustainable-edgemanagement-optimized user interface for edge developers | sustainabilityoptimized User Interface | Ai-Enabled intelligent experience | AI/ML-based automated user experience testing and optimization |
|
||||
| e.1. Edge Developer full service framework (SDK + day1 +day2 support for edge installations) | Adaptive CI/CD pipelines for heterogeneous edge environments | Decentralized and self healing deployment and management | edge-driven monitoring and analytics |
|
||||
| e.2. Built-in sustainability optimization in Edge developer framework | sustainability optimized edge-aware CI/CD tooling | sustainability-optimized configuration management | sustainability-optimized efficient deployment strategies |
|
||||
| e.3. Sustainable-edge management-optimized user interface for edge developers | sustainability optimized User Interface | Ai-Enabled intelligent experience | AI/ML-based automated user experience testing and optimization |
|
||||
|
||||
### DTAG objectives & contributions (p.27)
|
||||
|
||||
|
|
@ -27,24 +34,13 @@ DTAG will also focus on developing an easy-to-use Edge Developer framework for s
|
|||
developers to manage the whole lifecycle of edge applications, i.e. for day-0-, day-1- and up to day-2-
|
||||
operations. With this DTAG will strongly enable the ecosystem building for the entire IPCEI-CIS edge to
|
||||
cloud continuum and ensure openness and accessibility for anyone or any company to make use and
|
||||
further build on the edge to cloud continuum. Providing the use of the tool framework via an open-sourceapproach will further reduce entry barriers and enhance the openness and accessibility for anyone or
|
||||
further build on the edge to cloud continuum. Providing the use of the tool framework via an open-source approach will further reduce entry barriers and enhance the openness and accessibility for anyone or
|
||||
any organization (see innovations e.).
|
||||
|
||||
### WP Deliverables (p.170)
|
||||
|
||||
e.1 Edge developer full-service framework
|
||||
|
||||
This tool set and related best
|
||||
practices and guidelines will
|
||||
adapt, enhance and further
|
||||
innovate DevOps principles and
|
||||
their related, necessary
|
||||
supporting technologies
|
||||
according to the specific
|
||||
requirements and constraints
|
||||
associated with edge or edgecloud development, in order to
|
||||
keep the healthy and balanced
|
||||
innovation path on both sides,
|
||||
the (software) development side
|
||||
and the operations side in the
|
||||
field of DevOps.
|
||||
This tool set and related best practices and guidelines will adapt, enhance and further innovate DevOps principles and
|
||||
their related, necessary supporting technologies according to the specific requirements and constraints associated with edge or edge cloud development, in order to keep the healthy and balanced innovation path on both sides,
|
||||
the (software) development side and the operations side in the field of DevOps.
|
||||
|
|
@ -4,90 +4,37 @@ weight: 10
|
|||
---
|
||||
|
||||
|
||||
## Platform reference architecture
|
||||
|
||||
## Project context
|
||||
An interesting difference between the CNCF white paper building blocks and them from Internaldeveloperplatforms is the part [**orchestrators**](https://internaldeveloperplatform.org/platform-orchestrators/).
|
||||
|
||||
## Platforms
|
||||
This is something extremely new since late 2023 - the rise of the automation of platform engineering!
|
||||
|
||||
{{% pageinfo color="info" %}}
|
||||
Since 2010 we have DevOps. This brings increasing delivery speed and efficiency at scale.
|
||||
Next we got high cognitive loads for developers.
|
||||
So we need on top of DevOps an instrumentation to ensure and enforce speed, quality, security in modern, cloud native software development.
|
||||
{{% /pageinfo %}}
|
||||
It was Humanitec creating a definition of platform architecture, as they needed to defien what they are building with their 'orchestrator':
|
||||
|
||||
<img src="./vendor-neutral-idp-final.gif" width="600" alt="https://developer.humanitec.com/introduction/overview/">
|
||||
|
||||
## Declarative Platform Orchestration
|
||||
|
||||
Based on the refence architecture you next can build - or let's say 'orchestrate' - different platform implementations, based on declarative definitions of the platform design.
|
||||
|
||||
https://humanitec.com/reference-architectures
|
||||
|
||||
<img src="./platform-architectures.webp" width="600" alt="https://humanitec.com/blog/aws-azure-and-gcp-open-source-reference-architectures-to-start-your-mvp">
|
||||
|
||||
> Hint: There is a [slides tool provided by McKinsey](https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures) to set up your own platform deign based on the reference architecture
|
||||
|
||||
### What comes next?
|
||||
|
||||
[Next](../cnoe/) we'll see how we are going to do platform orchestration!
|
||||
|
||||
## Addendum
|
||||
|
||||
|
||||
## History
|
||||
## Building blocks from Humanitecs 'state-of-platform-engineering-report-volume-2'
|
||||
|
||||
https://platformengineering.org/blog/the-story-of-platform-engineering
|
||||
You remember the [capability mappings from the time before orchestration](../platforming)? Here we have a [similar setup based on Humanitecs platform engineering status ewhite paper](https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2):
|
||||
|
||||

|
||||
|
||||
https://martinfowler.com/articles/talk-about-platforms.html
|
||||
|
||||
https://developers.redhat.com/articles/2024/05/06/what-platform-engineering-and-why-do-we-need-it#why_we_need_platform_engineering
|
||||
|
||||
https://orkohunter.net/blog/a-brief-history-of-platform-engineering
|
||||
|
||||
https://softwareengineeringdaily.com/2020/02/13/setting-the-stage-for-platform-engineering/
|
||||
<img src="./platform-tooling-humanitec-platform-report-2024.PNG" width="600" alt="https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2 Whitepaper_ State of Platform Engineering Report.pdf">
|
||||
|
||||
|
||||
### DevOps, Cloud Native, and the Rise of Platform Engineering
|
||||
|
||||
https://www.linkedin.com/pulse/evolution-platform-engineering-gaurav-goel
|
||||
|
||||
|
||||
## CNCF Working group / White paper
|
||||
|
||||
--> porfolio
|
||||
|
||||
|
||||
### Platform definition / essence
|
||||
|
||||
|
||||
https://medium.com/@bijit211987/what-is-platform-engineering-and-how-it-reduce-cognitive-load-on-developers-ac7805603925
|
||||
|
||||
#### Ontology: What is 'Platform' (Digital Platform) --> Fowler / Thoughtworks
|
||||
|
||||
https://martinfowler.com/articles/talk-about-platforms.html
|
||||
|
||||
##### What is a 'Platform' anyway?
|
||||
|
||||
> Words are hard, it seems. ‘Platform’ is just about the most ambiguous term we could use for an approach that is super-important for increasing delivery speed and efficiency at scale. Hence the title of this article, here is what I’ve been talking about most recently.
|
||||
\
|
||||
Definitions for software and hardware platforms abound, generally describing an operating environment upon which applications can execute and which provides reusable capabilities such as file systems and security.
|
||||
\
|
||||
Zooming out, at an organisational level a ‘digital platform’ has similar characteristics - an operating environment which teams can build upon to deliver product features to customers more quickly, supported by reusable capabilities.
|
||||
\
|
||||
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.
|
||||
|
||||
#### myths :-)
|
||||
|
||||
https://cloud.google.com/blog/products/application-development/common-myths-about-platform-engineering?hl=en
|
||||
|
||||
|
||||
### Platform Teams
|
||||
|
||||
https://platformengineering.org/blog/how-to-build-your-platform-engineering-team
|
||||
|
||||
#### in comparison: devops vs sre vs platform
|
||||
|
||||
https://www.qovery.com/blog/devops-vs-platform-engineering-is-there-a-difference/
|
||||
|
||||

|
||||
|
||||
## Internal Developer Platforms
|
||||
|
||||
--> portfolio cont'd
|
||||
|
||||
## Platform Orchestrator
|
||||
|
||||
--> dynamic configuration
|
||||
|
||||
Humanitec, massdriver, CNOE, Kratix, ... (?) ...
|
||||
|
||||
## Reference Architecture
|
||||
|
||||
## Developer Framework Architecture
|
||||
|
||||
## Developer Framework Project Epics & Use Cases
|
||||
|
||||
|
|
|
|||
|
After Width: | Height: | Size: 98 KiB |
|
Before Width: | Height: | Size: 723 KiB After Width: | Height: | Size: 723 KiB |
|
After Width: | Height: | Size: 397 KiB |
|
|
@ -1,56 +1,88 @@
|
|||
---
|
||||
title: Platforming
|
||||
title: Platform Engineering aka Platforming
|
||||
linktitle: Platforming
|
||||
weight: 2
|
||||
---
|
||||
|
||||

|
||||
|
||||
## Project context
|
||||
|
||||
## Platforms
|
||||
|
||||
{{% pageinfo color="info" %}}
|
||||
## Summary
|
||||
|
||||
Since 2010 we have DevOps. This brings increasing delivery speed and efficiency at scale.
|
||||
Next we got high cognitive loads for developers.
|
||||
So we need on top of DevOps an instrumentation to ensure and enforce speed, quality, security in modern, cloud native software development.
|
||||
But next we got high 'cognitive loads' for developers and production congestion due to engineering lifecycle complexity.
|
||||
So we need on top of DevOps an instrumentation to ensure and enforce speed, quality, security in modern, cloud native software development. This instrumentation is called 'goldne paths' in intenal develoepr platforms (IDP).
|
||||
{{% /pageinfo %}}
|
||||
|
||||
|
||||
## History
|
||||
## History of Platform Engineering
|
||||
|
||||
https://platformengineering.org/blog/the-story-of-platform-engineering
|
||||
Let's start with a look into the history of platform engineering. A good starting point is [Humanitec](https://humanitec.com/), as they nowadays are one of the biggest players (['the market leader in IDPs.'](https://internaldeveloperplatform.org/#how-we-curate-this-site)) in platform engineering.
|
||||
|
||||

|
||||
They create lots of [beautiful articles and insights](https://humanitec.com/blog), their own [platform products](https://humanitec.com/products/) and [basic concepts for the platform architecture](https://humanitec.com/platform-engineering) (we'll meet this later on!).
|
||||
|
||||
https://martinfowler.com/articles/talk-about-platforms.html
|
||||
|
||||
https://developers.redhat.com/articles/2024/05/06/what-platform-engineering-and-why-do-we-need-it#why_we_need_platform_engineering
|
||||
|
||||
https://orkohunter.net/blog/a-brief-history-of-platform-engineering
|
||||
|
||||
https://softwareengineeringdaily.com/2020/02/13/setting-the-stage-for-platform-engineering/
|
||||
<img src="./humanitec-history.png" width="600" alt="https://platformengineering.org/blog/the-story-of-platform-engineering">
|
||||
|
||||
|
||||
### DevOps, Cloud Native, and the Rise of Platform Engineering
|
||||
### Further nice reference to the raise of platforms
|
||||
|
||||
https://www.linkedin.com/pulse/evolution-platform-engineering-gaurav-goel
|
||||
* [What we **call** a Platform](https://martinfowler.com/articles/talk-about-platforms.html)
|
||||
* [Platforms and the **cloud native** connection](https://developers.redhat.com/articles/2024/05/06/)what-platform-engineering-and-why-do-we-need-it#why_we_need_platform_engineering
|
||||
* [Platforms and **microservices**](https://orkohunter.net/blog/a-brief-history-of-platform-engineering)
|
||||
* [Platforms in the **product** perspective](https://softwareengineeringdaily.com/2020/02/13/setting-the-stage-for-platform-engineering/)
|
||||
|
||||
|
||||
## CNCF Working group / White paper
|
||||
## Benefit of Platform Engineering, Capabilities
|
||||
|
||||
--> porfolio
|
||||
In [The Evolution of Platform Engineering](https://www.linkedin.com/pulse/evolution-platform-engineering-gaurav-goel) the interconnection inbetween DevOps, Cloud Native, and the Rise of Platform Engineering is nicely presented and summarizes:
|
||||
|
||||
> Platform engineering can be broadly defined as the discipline of designing and building toolchains and workflows that enable self-service capabilities for software engineering organizations
|
||||
|
||||
When looking at these 'capabilities', we have CNCF itself:
|
||||
|
||||
### CNCF Working group / White paper defines layerwed capabilities
|
||||
|
||||
There is a CNCF working group which provides the definition of [Capabilities of platforms](https://tag-app-delivery.cncf.io/whitepapers/platforms/#capabilities-of-platforms) and shows a first idea of the layered architecture of platforms as **service layer for developers** ("product and application teams"):
|
||||
|
||||
<img src="./platforms-def.drawio.png" width="600">
|
||||
|
||||
|
||||
### Platform definition / essence
|
||||
> Important: As Platform engineer also notice the [platform-eng-maturity-model](https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/)
|
||||
|
||||
### Platform Engineering Team
|
||||
|
||||
Or, in another illustration for the platform as a developer service interface, which also defines the **'Platform Engineering Team'** inbetween:
|
||||
|
||||
<img src="./platform-self-services.webp" width="600" alt="https://medium.com/@bijit211987/what-is-platform-engineering-and-how-it-reduce-cognitive-load-on-developers-ac7805603925">
|
||||
|
||||
## How to set up Platforms
|
||||
|
||||
As we now have evidence about the nescessity of platforms, their capabilities and benefit as self service layer for developers, we want to thin about how to build them.
|
||||
|
||||
First of all some important wording to motivate the important term 'internal developer platfoms' (we will go into this deeper in the next section [with the general architecture](../orchestrators/)), which is clear today, but took years to evolve and [is still some amount if effort to jump in](https://humanitec.com/blog/wtf-internal-developer-platform-vs-internal-developer-portal-vs-paas):
|
||||
|
||||
* Platform: As defined above: A product which serves software engineering teams
|
||||
* Platform Engineering: Creating such a product
|
||||
* Internal Developer Platforms (IDP): A platform for developers :-)
|
||||
* Internal Developer Portal: The entry point of a developer to such an IDP
|
||||
|
||||
### CNCF mapping from capabilities to (CNCF) projects/tools
|
||||
|
||||
[Capabilities of platforms](https://tag-app-delivery.cncf.io/whitepapers/platforms/#capabilities-of-platforms)
|
||||
|
||||
### Ecosystems in InternalDeveloperPlatform
|
||||
|
||||
Build or buy - this is also in pltaform engineering a tweaked discussion, which one of the oldest player answers like this with some oppinioated internal capability structuring:
|
||||
|
||||
[internaldeveloperplatform.org[(https://internaldeveloperplatform.org/platform-tooling/)
|
||||
|
||||
### What comes next?
|
||||
|
||||
[Next](../orchestrators/) we'll see how these concepts got structured!
|
||||
|
||||
|
||||
https://medium.com/@bijit211987/what-is-platform-engineering-and-how-it-reduce-cognitive-load-on-developers-ac7805603925
|
||||
## Addendum
|
||||
|
||||
#### Ontology: What is 'Platform' (Digital Platform) --> Fowler / Thoughtworks
|
||||
|
||||
https://martinfowler.com/articles/talk-about-platforms.html
|
||||
|
||||
##### What is a 'Platform' anyway?
|
||||
### Digital Platform defintion from [What we **call** a Platform](https://martinfowler.com/articles/talk-about-platforms.html)
|
||||
|
||||
> Words are hard, it seems. ‘Platform’ is just about the most ambiguous term we could use for an approach that is super-important for increasing delivery speed and efficiency at scale. Hence the title of this article, here is what I’ve been talking about most recently.
|
||||
\
|
||||
|
|
@ -60,34 +92,18 @@ Zooming out, at an organisational level a ‘digital platform’ has similar cha
|
|||
\
|
||||
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product. Autonomous delivery teams can make use of the platform to deliver product features at a higher pace, with reduced co-ordination.
|
||||
|
||||
#### myths :-)
|
||||
|
||||
https://cloud.google.com/blog/products/application-development/common-myths-about-platform-engineering?hl=en
|
||||
### Myths :-) - What are platforms _not_
|
||||
|
||||
[common-myths-about-platform-engineering](https://cloud.google.com/blog/products/application-development/common-myths-about-platform-engineering?hl=en)
|
||||
|
||||
### Platform Teams
|
||||
|
||||
https://platformengineering.org/blog/how-to-build-your-platform-engineering-team
|
||||
This is about you :-), the platform engineering team:
|
||||
|
||||
[how-to-build-your-platform-engineering-team](https://platformengineering.org/blog/how-to-build-your-platform-engineering-team)
|
||||
|
||||
#### in comparison: devops vs sre vs platform
|
||||
|
||||
https://www.qovery.com/blog/devops-vs-platform-engineering-is-there-a-difference/
|
||||
|
||||

|
||||
|
||||
## Internal Developer Platforms
|
||||
|
||||
--> portfolio cont'd
|
||||
|
||||
## Platform Orchestrator
|
||||
|
||||
--> dynamic configuration
|
||||
|
||||
Humanitec, massdriver, CNOE, Kratix, ... (?) ...
|
||||
|
||||
## Reference Architecture
|
||||
|
||||
## Developer Framework Architecture
|
||||
|
||||
## Developer Framework Project Epics & Use Cases
|
||||
|
||||

|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 904 KiB After Width: | Height: | Size: 904 KiB |
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 160 KiB |
|
Before Width: | Height: | Size: 600 KiB After Width: | Height: | Size: 600 KiB |