Skip to content

chore: import latest reference architectures #681

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mrbobbytables merged 3 commits into from
Sep 28, 2026
Merged

chore: import latest reference architectures #681

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
3463d78
chore: import reference architectures
castrojo Sep 28, 2026
8cf0bc0
style: format generated architecture JSON with Prettier
mrbobbytables Sep 28, 2026
fb81b34
fix: correct 'adpation' typo in imported colopl.md
mrbobbytables Sep 28, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 9 additions & 4 deletions .prettierignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,13 @@
# Imported architecture pages are regenerated verbatim by
# `npm run import:architectures`; formatting them locally would be overwritten
# (and re-break the gate) on the next import. See issue #528.
docs/architectures/cern-scientific-computing.md
docs/architectures/swisscom-kubernetes-service.md
# `npm run import:architectures` and embed JSX component props (e.g.
# CNCFProjectCard `description={"..."}`) inline in prose. Prettier's markdown
# formatter rewraps that prose across lines, which breaks the JS string
# literal and fails the MDX build with "Could not parse expression with acorn"
# (see #681, #795); any local reformatting would also be overwritten by the
# next import anyway. Excludes every generated org page but keeps the
# hand-authored index.
docs/architectures/*.md
!docs/architectures/index.md
# Workflow file: formatting it requires a credential with the Workflows permission:
.github/workflows/create-milestones.yml
# Blog posts contain MDX JSX comments ({/* truncate */}) that prettier's markdown
Expand Down
12 changes: 6 additions & 6 deletions data/metrics.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
{
"generated": true,
"generatedAt": "2026-09-24T02:38:41.405Z",
"generatedAt": "2026-09-28T02:48:30.866Z",
"sources": {
"landscape": {
"repository": "https://github.com/cncf/landscape",
"revision": "0448002c82defabcb100ba959475fbed3b91f3ab",
"revision": "97b2e16fdf4147166df9427299998a83991b0958",
"sourceUrl": "https://github.com/cncf/landscape/blob/main/landscape.yml"
},
"architectures": {
Expand All @@ -20,7 +20,7 @@
"value": 255,
"source": "landscape",
"sourceUrl": "https://landscape.cncf.io/",
"collectedAt": "2026-09-24T02:38:41.405Z",
"collectedAt": "2026-09-28T02:48:30.866Z",
"note": "Projects explicitly marked with a CNCF maturity level in landscape.yml."
},
{
Expand All @@ -29,7 +29,7 @@
"value": 8,
"source": "architectures",
"sourceUrl": "https://github.com/cncf/architecture/tree/main/content/en/architectures",
"collectedAt": "2026-09-24T02:38:41.405Z",
"collectedAt": "2026-09-28T02:48:30.866Z",
"note": "Published architecture directories under content/en/architectures."
}
],
Expand Down Expand Up @@ -108,7 +108,7 @@
"sourceUrl": "https://landscape.cncf.io/",
"values": [
{
"date": "2026-09-24",
"date": "2026-09-28",
"value": 649
}
]
Expand Down Expand Up @@ -153,7 +153,7 @@
"generated": true,
"source": "cncf/tab and cncf/architecture GitHub APIs",
"sourceUrl": "https://github.com/cncf/tab/issues?q=is%3Aissue+label%3Aarea%2Freference-architecture",
"observedAt": "2026-09-24T02:38:41.405Z",
"observedAt": "2026-09-28T02:48:30.865Z",
"cards": [
{
"id": "open-submissions",
Expand Down
561 changes: 133 additions & 428 deletions docs/architectures/adobe.md
View file
Open in desktop

Large diffs are not rendered by default.

193 changes: 81 additions & 112 deletions docs/architectures/allianz.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,169 +1,138 @@
---
title: "Enabling Allianz Direct's scaling through Platform Engineering"
sidebar_label: 'Allianz Direct'
sidebar_label: "Allianz Direct"
---

import CNCFProjectCard from '@site/src/components/CNCFProjectCard';

> Imported from the
> [CNCF Cloud Native Reference Architecture project](https://github.com/cncf/architecture/tree/3ddf917facd0aea9694cc9c12c52e583fd2f86cb/content/en/architectures/allianz).
> Source revision: `3ddf917facd0aea9694cc9c12c52e583fd2f86cb`. Documentation is
> distributed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).
> Imported from the [CNCF Cloud Native Reference Architecture project](https://github.com/cncf/architecture/tree/3ddf917facd0aea9694cc9c12c52e583fd2f86cb/content/en/architectures/allianz). Source revision: `3ddf917facd0aea9694cc9c12c52e583fd2f86cb`. Documentation is distributed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).

## Relevant CNCF projects

<CNCFProjectCard name="Kubernetes" href="https://www.cncf.io/projects/kubernetes/" logo="/img/cncf-projects/kubernetes-kubernetes-icon-color.svg" since="2021" version="1.29.6" description="- Kubernetes has been the foundation for our Internal Developer Platform and almost all of Adobe's containerized workloads run on Kubernetes clusters." />
<CNCFProjectCard name={"Kubernetes"} href={"https://www.cncf.io/projects/kubernetes/"} logo={"/img/cncf-projects/kubernetes-kubernetes-icon-color.svg"} since={"2021"} version={"1.29.6"} description={"- Kubernetes has been the foundation for our Internal Developer Platform and almost all of Adobe's containerized workloads run on Kubernetes clusters."} />

<CNCFProjectCard name="Helm" href="https://www.cncf.io/projects/helm/" logo="/img/cncf-projects/helm-helm-icon-color.svg" since="2021" version="v3.12.3" description="- Helm is our package manager and helps us abstract out some of the complexity by including them as dependencies and only exposing the values.yaml file." />
<CNCFProjectCard name={"Helm"} href={"https://www.cncf.io/projects/helm/"} logo={"/img/cncf-projects/helm-helm-icon-color.svg"} since={"2021"} version={"v3.12.3"} description={"- Helm is our package manager and helps us abstract out some of the complexity by including them as dependencies and only exposing the values.yaml file."} />

<CNCFProjectCard name="Argo" href="https://www.cncf.io/projects/argo/" logo="/img/cncf-projects/argo-argo-icon-color.svg" since="2021" description="We are using all four projects under Argo: Argo CD: v2.9.22" />
<CNCFProjectCard name={"Argo"} href={"https://www.cncf.io/projects/argo/"} logo={"/img/cncf-projects/argo-argo-icon-color.svg"} since={"2021"} description={"We are using all four projects under Argo: Argo CD: v2.9.22"} />

## Platform Engineering @ Allianz Direct

Allianz Direct has been working on building Platform Engineering for the past
several years. We have created a cloud-native future-proof platform which offers
an organisation-wide-devops(orgOps) experience on top of public cloud. Business,
Software Engineers, Security, Compliance, Architecture, Support and Cost
Efficiency are few of our stakeholders.
## Platform Engineering @ Allianz Direct
Allianz Direct has been working on building Platform Engineering for the past several years. We have created a cloud-native future-proof platform which offers an organisation-wide-devops(orgOps) experience on top of public cloud. Business, Software Engineers, Security, Compliance, Architecture, Support and Cost Efficiency are few of our stakeholders.

### Platform Engineering Team Topology - internal

The PE team is internally organised in DDOs - Distributed DevOps, where each ddo
owns a Domain. This setup follows the reverse Conway manoeuver where the
reference architecture structure dictates the teams setup. The PE team consist
of 13 members. All of them internal employees.
The PE team is internally organised in DDOs - Distributed DevOps, where each ddo owns a Domain.
This setup follows the reverse Conway manoeuver where the reference architecture structure dictates
the teams setup.
The PE team consist of 13 members. All of them internal employees.

The PE team is being supported by auxiliary teams: Developer Service Hub (DSH):
entry level engineers handling the low complexity tasks such as: access
management, 1st level technical support, SRE onboarding, ticket sorting and
filtering Cloud Auditing Hub (CAH): entry level engineers with a focus on
compliance and audit Production Management Hub (PMH): entry level engineers with
a focus on incident and problem management Technical Tribe Leads (TTL):
Technical leads on the Tribe (department) level that became our evangelist for
best practices and continuous innovation partners.
The PE team is being supported by auxiliary teams:
Developer Service Hub (DSH): entry level engineers handling the low complexity tasks such as: access management,
1st level technical support, SRE onboarding, ticket sorting and filtering
Cloud Auditing Hub (CAH): entry level engineers with a focus on compliance and audit
Production Management Hub (PMH): entry level engineers with a focus on incident and problem management
Technical Tribe Leads (TTL): Technical leads on the Tribe (department) level that became our evangelist for best practices and
continuous innovation partners.

### Platform Engineering Team Topology - external
Externally, the team has decided to scale by building on the concept of FDOs - Federated DevOps, where
each squad (developing team) has built internal devops expertise focusing a minimum amount of time on
Operations concerns. A FDO community has flourished and enabled successfully an extremely aggressive organisation scale up
The PE serves an approx. 500 engineers and 1500 employees.

Externally, the team has decided to scale by building on the concept of FDOs -
Federated DevOps, where each squad (developing team) has built internal devops
expertise focusing a minimum amount of time on Operations concerns. A FDO
community has flourished and enabled successfully an extremely aggressive
organisation scale up The PE serves an approx. 500 engineers and 1500 employees.

## Platform Engineering Architecture
## Platform Engineering Architecture

The PE team has built a Cloud Native Platform that serves the core B2C business
of a fully digital insurance player acting on several european markets.
The PE team has built a Cloud Native Platform
that serves the core B2C business of a fully digital insurance player acting on
several european markets.

![High Level Diagram](/img/architectures/allianz/PEArchitecture.jpg)

It serves also all the newly created B2B business initiatives. The highly
aggressive scale-up of the both B2B and B2B businesses forced the PE team to
redesign the architecture towards a multi-tenant architecture with minimum
operational effort. On top, the Platform has become a Organisation Group
Standard and an example for Global initiatives. This forced the PE team to
choose a light architecture under a second Platform based on Fargate ECS,
reducing the operational effort and talent demand to minimum.
It serves also all the newly created B2B business initiatives.
The highly aggressive scale-up of the both B2B and B2B businesses forced the PE team to redesign the architecture towards
a multi-tenant architecture with minimum operational effort.
On top, the Platform has become a Organisation Group Standard and an example for Global initiatives. This forced the PE team to
choose a light architecture under a second Platform based on Fargate ECS, reducing the operational effort and talent demand to minimum.

PE team delivered several cloud native best practices:

- GitOps (ORGops to be more precise)
- Stateless clusters orchestrated by a management cluster
- Fargate ECS multitenancy
- Fargate ECS multitenancy
- DevSecOps
- SRE

### Special projects that served us well

- AWS obsession with customers served us well. The technical support and
continuous relation with AWS architects helped us maximise our effectiveness
and evolve our architecture as well as complementing our stack with SaaS
services such as EKS, Redis, MSK.
- AWS obsession with customers served us well. The technical support and continuous relation with AWS architects
helped us maximise our effectiveness and evolve our architecture as well as complementing our stack with SaaS services
such as EKS, Redis, MSK.

- AWS managed Kubernetes gave us the flexibility we needed to meet our users
needs with as little overhead as possible. Most of our application choices
come directly from our users, however our infrastructure choices were made to
balance our compliance needs, usability and supportability.
- AWS managed Kubernetes gave us the flexibility we needed to meet our users needs with as little overhead as
possible. Most of our application choices come directly from our users, however our
infrastructure choices were made to balance our compliance needs, usability and supportability.

- ArgoCD has become instrumental for us and the core of our internal innovation.
We are currently using it for spinning up and managing our multitenant
implementation whether that is on namespace level or Fargate ECS level.
- ArgoCD has become instrumental for us and the core of our internal innovation. We are currently using it for spinning
up and managing our multitenant implementation whether that is on namespace level or Fargate ECS level.

- PAGT(Prometheus, Alert manager, Grafana and Thanos) stack is the core of our
Observability. It is complemented by OTEL and ELK Stack and enabled us to
build a state of the art SRE journey for all our Stakeholders
- PAGT(Prometheus, Alert manager, Grafana and Thanos) stack is the core of our Observability.
It is complemented by OTEL and ELK Stack and enabled us to build a state of the art SRE journey for all our Stakeholders

### Things that worked well for us

EKS and now EKS + Fargate ECS works great for us. We can fully owns our core
domains and stay hardened with minimum effort. Complementing our Stack with AWS
services especially on Persistence, Data Streaming and Storage increase our
innovation speed. ArgoCD with helm, Atlantis with terraform and Crossplane are
working great for us, allowing us to follow the GitOps way, a great way of
working for heavily regulated industries.
EKS and now EKS + Fargate ECS works great for us. We can fully owns our core domains and stay hardened with minimum effort.
Complementing our Stack with AWS services especially on Persistence, Data Streaming and Storage increase our innovation speed.
ArgoCD with helm, Atlantis with terraform and Crossplane are working great for us, allowing us to follow the GitOps way,
a great way of working for heavily regulated industries.

## Stakeholders value streams

### **Business**

- Cost savings of X%
- Business Delivery expedited by X%
- Security incidents reduced by X%
- Reliability incidents reduced by X%
- Organizational Performance increased by X%

### **End-Customers**

- User Experience improved by X%
- Fast Feedback loop increased by X%
- Reliability increased by X%

### **Developers**
### **Business**
- Cost savings of X%
- Business Delivery expedited by X%
- Security incidents reduced by X%
- Reliability incidents reduced by X%
- Organizational Performance increased by X%

- DevX improved by X%
- Fast Software Delivery improved by X%
- Productivity increased by X%
- High Quality increased by X%
- Innovation increased by X%
### **End-Customers**
- User Experience improved by X%
- Fast Feedback loop increased by X%
- Reliability increased by X%

### **Security**
### **Developers**
- DevX improved by X%
- Fast Software Delivery improved by X%
- Productivity increased by X%
- High Quality increased by X%
- Innovation increased by X%

- Cloud native Security costs reduced by X%
### **Security**
- Cloud native Security costs reduced by X%

### **Compliance**
### **Compliance**
- Cloud compliance costs reduced by X%

- Cloud compliance costs reduced by X%
### **Legal**
- Cloud native legal cost reduced by X%

### **Legal**
### **QA**
- Automation increased by X%

- Cloud native legal cost reduced by X%

### **QA**

- Automation increased by X%

### **FinOps/Sustainability**

- Cloud Costs reduced by X%
### **FinOps/Sustainability**
- Cloud Costs reduced by X%

## Some things did not work as expected

Service Mesh did not work well for us. The Operational costs and lack of
integration on the CNI level made us revert the journey. Sidecar, eBPF Service
Mesh seems to be the way forward for us.

Service Mesh did not work well for us. The Operational costs and lack of integration on the CNI level made us revert the journey.
Sidecar, eBPF Service Mesh seems to be the way forward for us.
## Architecture evolution

The Architecture was designed as a single tenant but due to its success it
needed to evolve to support multitenancy on AWS account level, next on namespace
level and now, due to the Global impact, on the Fargate ECS level. Inevitably we
ended with three Platforms(Architectures) that need to be simplify towards a
maximum two that will evolve rapidly. Migration work is inevitable.
The Architecture was designed as a single tenant but due to its success it needed to evolve to support multitenancy on
AWS account level, next on namespace level and now, due to the Global impact, on the Fargate ECS level.
Inevitably we ended with three Platforms(Architectures) that need to be simplify towards a maximum two that will evolve rapidly.
Migration work is inevitable.

## The Journey

It took us 4 years to move towards the current Platform Engineering setup. There
is more to come. The full Journey as it happened till today 28.10.2024 can be
seen in the following diagram:
It took us 4 years to move towards the current Platform Engineering setup. There is more to come. The full Journey as it happened till today 28.10.2024 can be seen in the following diagram:

![High Level Diagram](/img/architectures/allianz/PEJourney.jpg)
Loading
Loading