Ich habe mich gefragt, wie Workload und Infrastruktur-Deployment als eine Einheit betrachtet werden können. Gute Software ist schließlich erst dann wertvoll, wenn sie stabil mit der dazugehörigen Infrastruktur betrieben werden kann. Dabei sollen interne Developer-Plattformen helfen. Bei meiner Suche nach einer Lösung für dieses Problem im Aufbau von Developer-Plattformen bin ich auf den Platform Orchestrator gestoßen.

**Was ist ein Platform Orchestrator?**  
Man kann sich den Platform Orchestrator als einen Rule-Engine vorstellen, die versteht, was die Entwickler\*innen benötigen und es basierend auf den Konfigurationen und Templates, die vom Platform-Team bereitgestellt werden, anbietet. [Humanitecs Platform Orchestrator](https://humanitec.com/products/platform-orchestrator) ist eine solche Regel-Engine. Neben dem SaaS Produkt von Humanitec gibt es noch andere explizite Platform Orchestrator wie z.B. [Kratix](https://www.kratix.io/) oder [KusionStack](https://www.kusionstack.io/zh/). Thoughtworks hat Platform Orchestrator als Tool-Kategorie 2023 in ihr bekanntes [Technologie-Radar](https://www.thoughtworks.com/en-de/radar/techniques/platform-orchestration) aufgenommen. Wie einen Platform Orchestration Layer ebenfalls implementieren kann, erklärt mein Kollege Jonas Hecht in seinem Artikel [Going full GitOps with Crossplane & ArgoCD](https://www.codecentric.de/wissens-hub/blog/full-gitops-with-crossplane-and-argocd).

Wir sehen immer wieder, dass sich fast jedes Plattform-Design im Wesentlichen darauf konzentriert, vorgefertigte Git-Repository Templates mit unterschiedlichsten Konfigurationsdateien über ein vermeintliches Developer-Portal bereitzustellen. Danach bleibt es den Entwickler\*innen überlassen, das “Skriptchaos” zu warten. Wenn sie damit überlastet sind, übertragen sie dieses Chaos an die IT-Operations-Teams. Das Ergebnis ist, dass die Entwickler\*innen langsamer werden, auf andere warten müssen und die IT-Operations-Mitarbeitenden sich durch unzählige Tickets kämpfen müssen. Dabei leidet die Time-to-Market, das Lebenselixier jedes Softwareentwicklungsprozesses.

![Developer Platform - Frontend Backend.png](https://media.graphassets.com/WzcOGA2jSEG9Z8oOKXGt)

Platform Architekturen sollten in Front- und Backend unterteilt werden. Platform Orchestrator bilden den Kern eines solchen Backends. Die Idee ist es, die gesamte Anwendung inklusive ihrer Infrastruktur-Ressourcen \- Datenbanken, Objekt-Storage oder DNS etc. \- bei jedem einzelnen Deployment neu zu konfigurieren. Ein Platform Orchestrator liest im Wesentlichen ein Rezept von Entwickler\*innen und erstellt dynamisch Anwendungs- und Infrastruktur-Konfigurationen bei jedem Deployment. Auf diese Weise gibt es im Deployment keinen Unterschied zwischen dem ersten und dem x-ten Mal. Dieser Ansatz ermöglicht ein hohes Maß an Standardisierung und ermöglicht es den Plattform Engineers, hoch skalierbare sogenannte Golden-Paths zu erstellen, die standardmäßig alle Ressourcen, Konfigurationen und Richtlinien enthalten. Außerdem führt dies zur deutlichen Reduzierung der Anzahl an Konfigurationsdateien.

**Der Platform Orchestrator schafft klare geteilte Verantwortung**  
Der Orchestrator integriert sich in die Pipeline, ist an die Image-Registry und das Secret-Management angebunden und möglicherweise auch an ein Developer-Portal und Service-Katalog \- Post-CI also. Was genau der Orchestrator dort macht, basiert auf den Eingaben von zwei in der Regel unterschiedlichen Benutzergruppen. Die erste Gruppe sind die Entwickler\*innen. Sie wissen am besten, welche Infrastruktur-Ressourcen ihre Workload benötigt, wie diese Ressourcen angebunden werden müssen und möglicherweise auch, wie sie mit anderen Workloads kommunizieren soll. Um dies zu beschreiben, gibt es für jede Workload ein kleines Rezept, die sogenannte Workload-Specification. In diesem Fall ist das [score](https://score.dev/). Wenn die Workload beispielsweise von einer PostgreSQL-Datenbank abhängt, dann wird genau das und nur das in die Workload-Specification eingetragen. Diese Rezepte sind umgebungsagnostisch und um es möglichst einfach zu machen, basieren sie auf der YAML-Syntax und liegen im gleichen Repository wie der Applikations Code selbst.

Wir wissen jetzt, dass die Workload von einer PostgreSQL-Datenbank abhängt. Wir wissen nicht, ob wir diese Workload an eine vorhandene Datenbank anschließen oder eine neue erstellen sollen. Wir wissen auch nicht, wie wir die Konfiguration für das Anwendungs-Deployment erstellen sollen. Wie viel Rechenleistung benötigen wir? Brauchen wir Sidecars, Labels und Annotationen? Welche Security- und Compliance Anforderungen gibt es an diese Infrastruktur Ressourcen? Diese fehlenden Informationen werden vom Platform Team, unserer zweiten Benutzergruppe, bereitgestellt. Das Platform Team hinterlegt im Orchestrator vorher sogenannte [Resource Definitions](https://humanitec.com/marketplace#resource-definitions). Das ist sozusagen der Capability-Katalog, den die Plattform zur Verfügung stellt und an dem sich Entwickler\*innen bedienen können. Über gängige Infrastructure as Code Tools wie Terraform oder Crossplane wird beschrieben, wie in unserem Beispiel Postgres Datenbanken auszusehen haben.

Um den Ablauf jetzt einmal greifbar zu machen, gehen wir ihn Schritt für Schritt einmal durch.  
Im ersten Schritt pushen wir unseren Applikations Code und unser kleines Rezept, die Workload Spezifikation, in unsere CI-Pipeline. Die CI-Pipeline pusht das Image in die Image-Registry und das Rezept an den Platform Orchestrator. Der Orchestrator erhält die Information, dass ein neues Image erstellt wurde, sowie den Pfad zu diesem Image und das Rezept selbst. Daraufhin startet nun das sogenannte RMCD-Execution Pattern. RMCD steht für Read, Match, Create and Deploy. Im Read-Schritt liest der Orchestrator das Rezept und erkennt in unserem Beispiel, dass die Workload von einer Postgres-Datenbank abhängt. Im Match-Schritt versteht er den Kontext, z.B. dass die Bereitstellung für eine Entwicklungsumgebung oder die Produktivumgebung erfolgt. Er findet dann heraus, welche Resource Definitions und Regeln, Ressource Criterias, das Platform Team in dieser Situation anwenden möchte. In der Create-Phase erstellt der Orchestrator die Anwendungskonfigurationen. Dann findet er heraus, ob die Workload an eine vorhandene Ressource angeschlossen werden soll oder ob eine neue erstellt werden muss. Wenn eine neue erstellt werden muss, kann er dies mithilfe der hinterlegten Resource Definition tun. 

Anschließend ruft er die Anmeldeinformationen für die Ressource ab und indiziert sie zur Laufzeit über Secrets in den Container. In der Deploy-Phase wird die Workload bereitgestellt und wir sind fertig. Diesen Prozess wiederholt der Orchestrator bei jeder Bereitstellung. Das hat einen erheblich positiven Einfluss auf die Standardisierung, Benutzerfreundlichkeit und Wartbarkeit der Applikations- und Infrastruktur Ressourcen über ihre gesamte Lebenszeit. 

![humanitec Platform Orchestrator - RMCD Pattern.png](https://media.graphassets.com/yQ1kYybNRYWFyoszwkQ4)

**Fazit**  
Bei Internal Developer Platforms geht es nicht darum, die initiale Bereitstellung von Services und ihre Infrastruktur Abhängigkeiten durch ein paar Templates oder ein schickes Developer-Portal zu optimieren. Tag fünfhundert, tausend oder zweitausend im Lebenszyklus dieser Komponenten sind die, wo am häufigsten zeitraubende Probleme entstehen. Deswegen liegt da auch der Hebel, um wirklich langfristig mehr Effektivität im Softwareentwicklungsprozess zu schaffen. Durch weniger und einfachere Konfigurationsdateien, klare, geteilte Verantwortlichkeiten zwischen Entwickler\*innen und dem Platform Team, kann die kognitive Last in den Teams reduziert, die Hürden für die Nutzung der Plattform niedrig gehalten und folglich die Adaption der Plattform gefördert werden. Der Humanitec Platform Orchestrator kann für diese Herausforderung eine unterstützende Komponente sein. 

Wenn du dich für den Aufbau interner Entwickler Plattformen oder speziell für den Platform Orchestrator von Humanitec interessierst, schau doch mal [hier](https://www.codecentric.de/leistungen/platform-engineering) vorbei. Dort erklären wir unseren Ansatz für erfolgreiche Plattform Initiativen. 


Der Platform Orchestrator von Humanitec ist eine SaaS Tool zum effektiven Aufbau von Backends für interne Developer Plattformen. Er hilft dabei klare getrennte Verantwortlichkeiten zwischen Platform Team und Entwickler*innen herzustellen und den gesamten Lifecycle einer Workload und dazugehörigen Komponenten zu verwalten.

Der Platform Orchestrator von Humanitec

Service Lead Platform Engineering

<p>Die <a href="https://kubernetes.io/docs/concepts/overview/kubernetes-api/" target="_blank">Kubernetes API</a>  stellt bereits eine ganze Menge an verschiedensten Ressourcen für die Container-Orchestrierung bereit: Services, Deployments, Ingress-Objekte, Namespaces, RBAC und viele mehr. Allerdings kann es manchmal nötig sein, diese API um weitere Typen zu erweitern. Sei es, um ggf. einen externen Webservice anzusprechen und aber diesen zur Laufzeit wie ein Kubernetes-Objekt zu behandeln. Eine gute Möglichkeit, dies zu erreichen, sind sogenannte <a href="https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/" target="_blank">Custom Resource Definitions</a>  (CRD). Um die Implementierung dieser zu vereinfachen, wurde im Juli von der Kubernetes API Machinery SIG das Tool <a href="https://github.com/kubernetes-sigs/kubebuilder" target="_blank">Kubebuilder</a>  veröffentlicht. Ziel von Kubebuilder ist es, die Implementierung von CRDs durch Abstraktion zu vereinfachen und gleichzeitig die bereits bestehenden Vorteile von Kubernetes (kubectl, RBA etc.) direkt mit zu unterstützen.</p><p>Doch was macht es und wie funktioniert es? Welche weiteren Möglichkeiten gibt es?</p><h2> Kubebuilder – Was und wie?</h2><p>Stand heute ist Kubebuilder in der Version <b>1.0.5</b> verfügbar. Ziel des Frameworks ist die Implementierung der CRD über das sog. <a href="https://kubernetes.io/docs/reference/command-line-tools-reference/kube-controller-manager/" target="_blank">Controller Pattern</a> . Ein klassischer Controller benötigt von Grund auf das Handling mit diversen weiteren Komponenten der Kubernetes API (Lister, Informer etc.). Darüber hinaus müssen im klassischen Ansatz diverse Dateien von Hand erstellt werden, damit ein Code-Generator fehlende Teile generieren kann. Kubebuilder nimmt einem dies ab. Er übernimmt die komplette Generierung eines Projektes. Von den Controllern über die Resource Models, Tests, CRDs, RBAC Settings und vieles mehr. Dies ermöglicht einem die Fokussierung auf die Implementierung des eigentlichen Use Cases.</p><h2>Ablauf</h2><p>Die offizielle <a href="https://book.kubebuilder.io/" target="_blank">Dokumentation</a>  zu Kubebuilder gibt bereits einen guten Überblick über die notwendigen Schritte zum Starten eines Projektes. Zuerst muss die Kubebuilder Binary auf dem eigenen Rechner installiert werden. Ist dies geschafft, ist es tatsächlich nicht mehr als ein:</p><div>

```sh
kubebuilder init --domain meinedomain.tld --license <license der Wahl> --owner
```

</div><p>Die darauf folgende Anfrage sollte mit „y“ beantwortet werden, um das lokale Vendoring mit dem Dependency Manager <a href="https://golang.github.io/dep/" target="_blank">dep</a>  zu initialisieren.</p><p>Sobald das geschafft ist, existiert bereits ein lauffähiges Projekt. Allerdings ohne einen CRD. Dieser kann einfach über</p><div>

```sh
kubebuilder create api --group <group> --version v1beta1 --kind <kind>
```

</div><p> erzeugt werden.</p><p>Innerhalb des Verzeichnisses <b>pkg/apis/…</b> findet sich der CRD-Code wieder, zu dem nach Belieben z. B. Felder hinzugefügt werden können. Der Platz für die Controller-Implementierung findet sich unter <b>pkg/controller/…</b></p><h2>Demo-Implementierung</h2><p>Um dem Ganzen ein bisschen näher zu kommen, habe ich ein <a href="https://github.com/codecentric/kubebuilder-starwars-example" target="_blank">Demo-Projekt</a>  vorbereitet. Dieses benutzt den Custom CRD „Starship“, um sich entsprechende Daten aus der bekannten Star Wars API zu laden.</p><p>Dies bedeutet für den zusammengefassten Ablauf:</p><ul><li>Ein Starship wird im Cluster deployed</li><li>Controller bemerkt Änderung und bekommt die Spec des Starships</li><li>Nimmt designierten Namen des Schiffes aus dem Spec</li><li>Durchsuchung der API nach dem Schiff</li><li>Objektstatus mit entsprechenden Daten aktualisieren</li></ul><p>Hat alles geklappt, kann das Objekt per <code>kubectl</code> ganz einfach abgefragt werden und man bekommt die folgenden Antworten:</p><p><a href="https://media.graphassets.com/aJC50mDsQBWfAU3OoZ3J"><img width="250" height="107" src="https://media.graphassets.com/aJC50mDsQBWfAU3OoZ3J" alt="Kubebuilder Antworten" /></a> </p><p>Weitere Informationen, wie ihr das Ganze z.B. selber einmal testen könnt, findet ihr auf dem GitHub <a href="https://github.com/codecentric/kubebuilder-starwars-example" target="_blank">Repository</a> .</p><h2>Weitere Möglichkeiten</h2><p>Weitere Möglichkeiten, vereinfacht eine derartige Implementierung zu bekommen, ist das <a href="https://github.com/operator-framework/operator-sdk" target="_blank">Operator Framework</a>  von RedHat/CoreOS oder <a href="https://github.com/GoogleCloudPlatform/metacontroller" target="_blank">Metacontroller</a>  der Google Cloud Platform. Beide Projekte verfolgen einen ähnlichen Ansatz, zeigen aber dennoch Unterschiede auf.</p><h2>Fazit</h2><p>Kubebuilder macht das Entwickeln von Custom CRDs deutlich einfacher. Verglichen mit einer CRD-Implementierung von Grund auf ist der vorgestellte Ansatz deutlich einfacher und schneller. Ob die daraus resultierende, starrere Struktur auch in komplexen Szenarien funktioniert, kann ich noch nicht beurteilen. Interessant ist dieser Ansatz aber auf jeden Fall.</p>

Kubebuilder und ein Custom CRD – Möge die Macht mit dir sein!

<p>Back in 2015, the first version of the by now famous edge router Traefik saw the light of day. Lots and lots of work has been put into the application, making it one of the most used proxies in the whole containerized infrastructures landscape. Recently, they <a href="https://blog.containo.us/back-to-traefik-2-0-2f9aa17be305" target="_blank">announced</a>  a huge overhaul and refactoring to make Traefik future-ready. In this blog post series, we will showcase some of the new features in Traefik 2.0, highlight changes and see what the future may look like.</p><h2>Parts</h2><p>As written in their announcement, Traefik 2.0 brings in a lot of new features, along with internal changes.</p><ul><li>configuration & new routing rule syntax</li><li>Kubernetes CRD</li><li>TCP Support</li><li>Cross Provider Support</li></ul><p>But without further ado, let’s start.</p><h2>Configuration in Traefik 2.0</h2><p>The whole configuration structure itself changed. A simple v1 configuration would have looked like this:</p>

```

checkNewVersion = true

[entryPoints]
  [entryPoints.http]
  address = ":80"

[file]
[backends]
  [backends.backend1]
    # ...

[frontends]
  [frontends.frontend1]
    # ...

```

<p>A simple v2, would look like this</p>

```

[Global]
checkNewVersion = true

[entrypoints]
    [entrypoints.http]
    address = ":80"

[providers]
[providers.file]
[http]
    [http.routers]
       [http.routers.my-router]
          rule = "Path(`/test`)"
          service = "whoami"
          entrypoint=["http"]

    [http.services]
          [http.services.whoami.loadbalancer]
            [[http.services.whoami.loadbalancer.servers]]
              url = "http://localhost:8080"

```

<p>As you can see, there is no root level configuration any more. All root-related configuration has moved below the <strong>Global</strong> section, which makes it more readable.</p><p>Also, a provider is now prefixed and enabled with <code>providers.Name</code>. In that example, it’s therefore the file provider with a basic entrypoint, a default router and service. More about that vocabulary (router and service) and also an introduction to the middleware can be found <a href="https://docs.traefik.io/v2.0/routing/overview/" target="_blank">here</a> .</p><p>Given that new structure of routers, middleware and services, it’s also possible to reuse middleware across routers and unify behavior.</p>

```

[http]
    [http.routers]
       [http.routers.whoami-router]
          rule = "Host(`whoami.mydomain.com`)"
          service = "whoami"
          entrypoint=["http"]
          middlewares = ["test-user"]

       [http.routers.whoami2-router]
          rule = "Host(`whoami2.mydomain.com`)"
          service = "whoami"
          entrypoint=["http"]
          middlewares = ["test-user"]

       [http.middlewares]
         [http.middlewares.test-user.basicauth]
           users = ["test:$apr1$H6uskkkW$IgXLP6ewTrSuBkTrqE8wj/"]

       [http.services]
         [http.services.whoami.loadbalancer]
           [[http.services.whoami.loadbalancer.servers]]
             url = "http://localhost:8080"

```

<p>In that example, the test-user middleware, which adds basic authentication, is shared and reused across two routers. Therefore, it could be used for 2 different services, which in the end reduces configuration complexity as there is no need to configure the same option multiple times.</p><h2>New routing rule syntax</h2><p>Previously, routing rules were a bit fuzzy to implement. Especially if you wanted to implement rules which were more difficult than matching a given hostname. The new rule syntax in Traefik 2.0 gives you an expressive syntax with well-known DSL keywords such as <strong>AND</strong>, <strong>OR</strong> or even <strong>parenthesis</strong></p><p>First, let’s match a simple request against <strong>www.mydomain.com/myapp</strong>.<br /> The first line will always be an example from v1 and the second from v2</p>

```

rule = Host: `www.mydomain.com`, PathPrefix:`/myapp`
rule = Host: (`www.mydomain.com`) && PathPrefix:(`/myapp`)

```

<p>That’s not that huge of a difference. Now, let’s check for two different hosts in a logical <em>or</em>.</p>

```

rule = Host: `www.mydomain.com`, Host: `www.myseconddomain.com`, PathPrefix:`/myapp`
rule = (Host: (`www.mydomain.com`) || Host: (`www.myseconddomain.com`) && PathPrefix:(`/myapp`)
```

<p>)<br /> That’s a difference already. With v2, you can also combine a lot more items:</p>

```
rule = (Method(`PUT`) || (Method(`POST`) && Query(`action`, `update`))) && Host('api.domain')
```

<p></p><h2>Conclusion</h2><p>The new configuration options and especially the new rule syntax in Traefik 2.0 provide a lot more flexibility – especially in terms of how you want to route traffic to your applications or in reducing complexity, as you don't have to implement the same action multiple times.</p><p>In the next post, we will have a brief look at the new Kubernetes CRD and how the handling will change compared to the "old" Ingress style configuration.</p>

Traefik 2.0 – Configuration & new routing rule syntax

It's 2024 and <a href="https://www.youtube.com/watch?v=9gwYNiCaldY" target="_blank">Software is still eating the world</a>. Whether it's powering an e-commerce platform, driving AI applications, or supporting critical business processes within organizations, there's a high likelihood that these applications are running in some form of cloud-native environment. Central to the success of these applications is networking, the pathway that ultimately leads users to engage with your app. In the realm of cloud-native application networking, there's a flurry of rapid development, a trend that has been ongoing and continues to shape the landscape in 2024. In this blog post, we'll provide a high-level overview of some of these key topics before delving deeper into it in separate blog posts later on.

## Gateway API
Undoubtedly, Gateway API stands out as one of the most talked-about topics in Ingress Management within the Kubernetes ecosystem. With its <a href="https://kubernetes.io/blog/2023/10/31/gateway-api-ga/" target="_blank"> General Availability (GA) </a> release in late October last year, the momentum around this topic skyrocketed. The adoption of the Kubernetes Gateway API is witnessing rapid growth within the open-source community, leading to an expanding ecosystem of projects supporting its functionalities.

Cloud-native API Gateway solutions such as Traefik, Kong, and others stand to benefit significantly from the adoption of the Kubernetes Gateway API. This adoption trend fosters a collaborative environment, where each new project embracing the Kubernetes Gateway API standard adds value to the ecosystem.

## Cillium
Another technology making waves is Cilium. Cilium serves as a Container Network Interface <a href="https://www.cni.dev" target="_blank">(CNI)</a> plugin, providing essential networking capabilities for containerized environments. Leveraging eBPF <a href="https://www.kentik.com/kentipedia/what-is-ebpf-extended-berkeley-packet-filter/" target="_blank">(extended Berkeley Packet Filter)</a> technology, Cilium delivers efficient and scalable networking solutions tailored to modern cloud-native applications, particularly in handling  <a href="https://en.wikipedia.org/wiki/East-west_traffic" target="_blank"> East-west traffic</a>.

With the acquisition of <a href="https://isovalent.com/blog/post/cisco-acquires-isovalent/" target="_blank">Isovalent</a>, the main contributor to Cilium, in December last year, there has been even more traction. Being eBPF-based, Cilium is sometimes referred to as a "sidecar-less Service Mesh," a concept we'll explore in detail in a later post.

## Istio (Ambient)
Istio has been a prominent topic since its release in July 2018, undergoing significant evolution in both its inner workings and usage patterns. A notable development is the introduction of Ambient mode in September 2022, offering a new dataplane mode for <a href="https://istio.io/v1.15/blog/2022/introducing-ambient-mesh/" target="_blank">Istio without sidecars</a>. While currently labeled Alpha, Ambient mode is on its way to graduating to Beta, potentially revolutionizing how Istio is deployed and used, opening up new possibilities through its altered architecture.


## Conclusion
This post touches upon three major topics in cloud-native application networking. Subsequent blog posts will delve deeper into each, including:

* A hands-on example with Gateway API
* Differentiation between Cilium and Istio Ambient
* Hands-on guides with Cilium and Istio Ambient

If you have questions on specific topics or suggestions for additional topics, please feel free to reach out.

Cloud-native (application) networking in 2024

When Gateway API debuted in October last year, this concluded a nearly four-year-long process that started in summer 2019. Gateway API is the successor of core Ingress definition, aiming towards various goals. This blog post will give a brief overview of its history, the whys, and how it's done today. 

## Brief history
I remember this as though it happened yesterday: Prior to KubeCon NA San Diego 2019, known folks within the SIG Network started discussing and pitching this "crazy" idea of a new concept for Ingress Management on Kubernetes. This time, vendors of Ingress Controllers were taken into discussion early on, to help craft a spec that would support everyone in reaching one of the many common goals; Remove Ingress annotation spread and allowed for better separation of concerns. During said KubeCon, the new idea was proposed to the public audience: Gateway API.

From then on, multiple vendors took part in that journey of designing this new standard, the successor of traditional Ingress eventually hitting v1alpha1 in <a href="https://kubernetes.io/blog/2021/04/22/evolving-kubernetes-networking-with-the-gateway-api/" target="_blank">April 2021 </a> and finally hitting <a href="https://kubernetes.io/blog/2023/10/31/gateway-api-ga/" target="_blank"> GA</a> right in time for the last Kubecon NA. It is now ready for production use and intended to regulate the flow of traffic from external clients to services within the cluster, known as the *ingress* or *north/south scenario*. Nevertheless, the Gateway API is increasingly favored for handling inter-service (east/west) traffic, owing to <a href="https://gateway-api.sigs.k8s.io/mesh/" target="_blank">GAMMA</a>, an experimental project undergoing trials across various implementations.

## Why
The Ingress API lacks numerous functionalities necessary for fulfilling common routing needs. It cannot match patterns based on query string parameters or define Layer 4 (protocol based, such as TCP, UDP or similar) routing. Similarly, it lacks capabilities for matching based on headers or HTTP methods. This deficiency in out-of-the-box API features has compelled API implementations to devise custom mechanisms atop the API, such as annotations and decorators.
![traditional.png](https://media.graphassets.com/KJmiwATS62eG3o9rg3wR)

Consequently, this situation has given rise to what is commonly referred to as "Ingress API annotation hell." While one may learn to navigate the Ingress API, it only covers roughly 20% of what is necessary for success. Transitioning from one provider to another without relearning everything becomes a daunting task.

```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.org/proxy-connect-timeout: "30s"
    nginx.org/proxy-read-timeout: "20s"
    nginx.org/client-max-body-size: "4m"
    ...
spec:
  ingressClassName: nginx-example
  rules:
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80
```

Alternatively, ingress controllers such as Traefik, Gloo Edge or others introduced their own set of CRDs to overcome that issue.

```
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: testName
  namespace: default
spec:
  entryPoints:
    - web
  routes:
  - kind: Rule
    match: Host(`test.example.com`)
    middlewares:
    - name: middleware1
      namespace: default
    priority: 10
    services:
    - kind: Service
      name: foo
      namespace: default
      passHostHeader: true
      port: 80
      responseForwarding:
        flushInterval: 1ms
      scheme: https
      sticky:
        cookie:
          httpOnly: true
          name: cookie
          secure: true
      strategy: RoundRobin
      weight: 10
  tls:
    certResolver: foo
    domains:
    - main: example.net
      sans:
      - a.example.net
      - b.example.net
    options:
      name: opt
      namespace: default
    secretName: supersecret
```

While this works to enable users, it's by far not optimal. This not only entails some sort of vendor lock-in, but it also means dropping out of usability with various community-maintained tools within the ecosystem, since those tools do not necessarily understand vendor-specific resources.

The Gateway API addresses this issue effectively. Apart from fulfilling core routing requirements, the Ingress API's permission model proves inadequate for practical usage. The Gateway API significantly enhances the permission model by introducing a new API layer (Routes), which segregates tasks associated with different personas involved in managing the cluster's lifecycle. Also, the number of open-source projects supporting Kubernetes Gateway API is growing rapidly, creating a robust open ecosystem for features and capabilities for Gateway API users.

## How
Since Gateway API by itself has more layers, the structure looks a little different:

![gateway-3.png](https://media.graphassets.com/HGlpHzP5QDqJZCcHXHem)

This separation allows for a very role-oriented design allowing multiple personas to fulfill their relevant use cases.

Through the separation of Gateways and Routes, operators still have full control of very common settings such as TLS while individual development teams can fully focus on their routing needs.

In terms of routing, the Gateway API brought about significant enhancements to the Ingress API across various topics. One notable improvement is the introduction of separate APIs for Routes. By dissociating routes from the ingress, the Gateway API enabled the incorporation of multiple route types (Layer 4 and Layer 7 such as HTTP), paving the way for the future introduction of additional routes. As of now, the Gateway API supports the following route types (with varying levels of maturity, as denoted in parentheses):

* HTTPRoute (v1)
* GRPCRoute (v1alpha2)
* TLSRoute (v1alpha2)
* TCPRoute (v1alpha2)
* UDPRoute (v1alpha2)

In addition to these Routes, the Gateway API has added brand-new routing capabilities to enable users.

* HTTP Header Matching
* HTTP Method Matching
* HTTP Query Parameters matching

### HTTP Route backend weights
The Weight attribute in a HTTPRoute backendRef determines the proportion of requests directed to the referenced backend. This is calculated as the weight divided by the amount of all weights in the BackendRefs list. For example, if Service A has a weight of 20 and Service B has a weight of 10, approximately two thirds of the requests will be routed to Service A. This is useful for scenarios such as canary deployments.

### HTTP Route Filters
HTTP Route Filters are the new standard approach to configure additional behavior such as modifying request headers or enabling request mirroring. Different types of filters exist as of today, including the option to attach custom filters to the rule via an *ExtensionRef* field. This can be used by various Ingress Controllers to hook into their extended usage such as middlewares in Traefik or plugins in Kong.

### Cross-namespace references
Unlike in the basic Ingress API, it is now possible to reference objects in another namespace. This enables common best-practices the community has asked for, such as a Gateway and Route in Namespace abc reference a service in Namespace cde or a Route in Namespace B configures a Gateway in Namespace C.

### Extensions
Another huge differentiator is the official way to extend the Gateway API to add functionalities. Vendors can  use the <a href="https://github.com/kubernetes-sigs/gateway-api/blob/main/geps/gep-713.md" target="_blank"> PolicyAttachment specification</a> to directly attach policies to configure there own custom behaviour. Alternatively, there is a way to <a href="https://github.com/kubernetes-sigs/gateway-api/pull/2813/" target="_blank"> 'inherit'</a> Policies from meta resources porting to routs. 

### Traction to know
The number of open-source projects supporting Kubernetes Gateway API is growing rapidly, ensuring an open ecosystem for features and capabilities for Gateway API users. As of today, multiple well-known projects such as external-dns, cert-manager, Argo Rollouts and more have already adopted Gateway API as a way to configure their respective features.

What's more, there are the <a href="https://gateway-api.sigs.k8s.io/implementations/" target="_blank"> 24 different implementations</a> from vendors listed on the official docs as well.

## Conclusion & next up
The Gateway API stands out as a very collaborative API in the history of Kubernetes. Multiple community members as well as vendors contributed tremendous efforts to this specification, ensuring its longevity as a standard for years to come. Since Gateway API is now Generally Available, it's officially deemed production-ready.

As a close follow up to this post, we will take the Gateway API for a hands-on spin, combining it with multiple other open-source solutions, thereby showcasing its great capabilities and ease of integration.

Demystifying the Kubernetes Gateway API: What the heck is it and why should you care?

Ever wondered how the technology that seamlessly manages microservices traffic evolved from early implementations to lean, kernel-level solutions? Let's dive into the fascinating journey of service meshes, from Linkerd 1.x to the cutting-edge technologies Istio Ambient and Cilium.

Running microservices-based architectures, especially in cloud-native environments, presents numerous challenges. Issues such as traffic management, resilience, observability, security, and access control are critical to address. This is where the concept of a service mesh comes into play, providing essential capabilities that translate into significant business value.

## A brief history
The emergence of the first "service mesh" marked a significant milestone in the evolution of microservices architectures. Linkerd 1.x, introduced in April 2017, paved the way for managing service-to-service communication in complex distributed systems. 
![linkerd.png](https://media.graphassets.com/fPP42RqSDqnzIxLhV7cQ)
Despite its groundbreaking capabilities, Linkerd 1.x encountered several challenges that shaped the subsequent evolution of service mesh technology. Linkerd 1.x was built on Java, relying on the JVM for its runtime environment. While Java offered flexibility and compatibility, its memory-intensive nature made it challenging to size properly, leading to potential resource inefficiencies. Deployed as a Kubernetes DaemonSet, Linkerd 1.x operated on a one-proxy-per-node basis. While this approach provided uniformity and simplicity in deployment, it also introduced the issue of <a href="https://www.techtarget.com/searchcloudcomputing/definition/noisy-neighbor-cloud-computing-performance">noisy neighbors</a>. With each node hosting its own proxy, resource contention and performance bottlenecks could arise, impacting the overall system performance.

## The first sidecar (proxy)
As service mesh technologies evolved to address challenges like the "noisy neighbor" issue, a pivotal shift occurred towards sidecar-based architectures. This marked a significant departure from previous deployment models, offering a more granular and efficient approach to managing service-to-service communication.
![sidecar.png](https://media.graphassets.com/0U8M9q5kSaiyE5jxpvaw)
Moving networking functionality closer to the application with sidecar proxies enabled each service to have its own networking counterpart. This approach facilitated more seamless communication between services while mitigating the impact of noisy neighbors. Sidecar proxies operated as transparent intermediaries, seamlessly intercepting and managing traffic between services without requiring changes to the application code. By being part of the application's lifecycle, sidecar proxies ensured consistent deployment and management alongside application instances. Sidecar proxies offered a single-tenant environment for each application, reducing the blast radius of potential failures and enabling more efficient resource sizing.

While sidecar proxies became the de facto standard for service meshes, they introduced their own set of challenges and considerations:
* Increased costs: Deploying sidecar proxies incurred additional resource overhead and operational costs, particularly in environments with a large number of microservices.
* Race conditions: Managing concurrent traffic and interactions between sidecar proxies could lead to race conditions and potential performance bottlenecks.
* Maintenance and upgrades: Upgrading sidecar proxies could be challenging, as all instances needed to restart simultaneously, potentially impacting service availability and performance.

## Introducing the CNI
As service mesh technologies continue to evolve, questions arise about the most efficient and cost-effective way to provide essential capabilities such as access control and traffic management. One alternative approach gaining traction is leveraging Container Network Interface (CNI) solutions, which operate at lower network layers compared to traditional HTTP proxies. CNIs operate at layers 3 and 4 of the OSI model, enabling them to handle network-related tasks such as routing, packet filtering, and load balancing. This lower-level integration offers potential performance and efficiency benefits compared to HTTP proxies operating at layer 7. In Kubernetes environments, CNIs play a crucial role in enabling networking between containers and pods. They are responsible for configuring network interfaces, setting up IP addresses, and managing network policies to control communication between pods.

## Understanding eBPF
eBPF (extended Berkeley Packet Filter) represents a groundbreaking advancement in kernel-level technology, offering powerful capabilities for network management and performance optimization. eBPF builds upon the foundation of Berkeley Packet Filter (BPF), a kernel-level technology initially developed for packet filtering. While BPF provided a solid framework for filtering network packets, eBPF expands its capabilities to include dynamic code execution and event-driven processing. Unlike its predecessor, which was limited to kernel-level code execution, eBPF operates from user space, enabling a wide range of applications beyond packet filtering. This versatility has transformed eBPF into a versatile system-level extension technology with applications in networking, security, and observability. eBPF programs are event-driven and react to specific trigger points within the kernel or application processes. These trigger points, known as *hook points*, include network events such as packet reception or transmission. Despite running from user space, eBPF programs execute within the kernel environment, allowing for seamless integration with kernel functions and data structures. This unique architecture enables eBPF to achieve unprecedented levels of performance and efficiency.

## Exploring service mesh in the kernel
The idea of embedding service mesh capabilities directly within the kernel environment opens up new possibilities for optimizing network management and communication in microservices architectures. While sidecar proxies have been instrumental in enabling service mesh functionality, they introduce overhead and complexity due to their deployment model and resource requirements. This prompts the exploration of alternative approaches such as integrating service mesh functionality directly into the kernel. Kube-Proxy, the internal proxy used in Kubernetes clusters, can be considered an early form of service mesh within the kernel. However, its reliance on iptables for traffic management limits its capabilities compared to modern service mesh solutions.

## Cillium, eBPF-powered Kubernetes CNI
Cilium, powered by eBPF technology, represents a groundbreaking advancement in Kubernetes networking and service mesh solutions. Developed by Isovalent and now part of IBM, Cilium offers a wide range of features and capabilities for managing network communication and security in Kubernetes environments. Cilium leverages eBPF technology to provide high-performance, low-overhead networking capabilities in Kubernetes clusters. By operating at the kernel level, Cilium offers efficient packet processing and fine-grained control over network traffic.  As a CNI, Cilium offers a comprehensive feature set for managing networking tasks, including layer-4 load balancing, BGP routing, Egress control, and even replacing Kube-proxy. This versatility makes Cilium a powerful choice for networking in Kubernetes environments. In addition to networking functionality, Cilium provides robust observability and security features. This includes metrics collection, distributed tracing, service mapping, encryption, and network policies, enhancing visibility and control over cluster operations. In mid-2022, Cilium expanded its capabilities to include service mesh functionality, marking a significant milestone in its development. The introduction of the "Cilium Service Mesh" represents a shift towards sidecar-less service mesh architectures, leveraging the power of eBPF for transparent and efficient communication between services.

## Exploring sidecarless service mesh
A sidecar-less service mesh represents a paradigm shift in how organizations approach microservices communication and management, offering a more streamlined and efficient solution compared to traditional sidecar-based approaches. 

Unlike traditional service mesh architectures that rely on sidecar proxies for communication between services, a sidecar-less service mesh operates without the need for additional proxy containers. Instead, it leverages technologies such as eBPF to implement networking functionality directly within the kernel environment. By leveraging eBPF at the kernel level, a sidecar-less service mesh offers full transparency and efficiency in service communication. Without the overhead of sidecar containers, services can communicate directly through optimized networking paths, reducing latency and resource consumption.

## It doesn't work without ~~Sidecars~~ Proxies
While sidecar-less service mesh architectures offer significant benefits in terms of efficiency and resource optimization, they come with inherent limitations, particularly in addressing HTTP-specific functionalities that are traditionally handled by layer 7 proxies.
| Functionality    | Networking Layer | 
| -------- | ------- |
| Traffic Management (Load Balancing, retry, timeout, circuit breaking, JWT validation, traffic splitting, mirroring...)  | L7    |
| Request Level Authorization (Headers, JWT Claims, Path, Rate Limit..) | L7     |
| Request Observability (Request count, 500x status, latency, sizes)    | L7    |
| mTLS, protocol / port authorization, source / dest authorization    | L4    |
| Connection observability     | L4    |
| Network Policies    | L4/L3    |

While sidecar-less implementations excel at handling tasks at layers 3 and 4 of the OSI model, they fall short in addressing the intricate requirements of layer 7 functionalities. This creates a coverage gap, leaving critical aspects of microservices communication unaddressed. Organizations opting for sidecar-less service mesh architectures must carefully consider the trade-offs involved. While they benefit from reduced resource overhead and simplified deployment, they may sacrifice certain HTTP-specific functionalities and granular control over application-layer communication.

## Exploring Istio Ambient – the "hybrid"
Istio Ambient represents a significant evolution in Istio's architecture, introducing a hybrid approach that combines elements of traditional sidecar-based service mesh with sidecar-less principles. Istio Ambient mode marks a pivotal shift in Istio's design philosophy, offering a simplified operational model and introducing a lightweight shared node proxy model. The recent graduation of Istio Ambient to Beta signifies its readiness for wider adoption, showcasing Istio's commitment to embracing innovative approaches in service mesh architecture. Istio Ambient comprises several key components that collectively enable its hybrid service mesh architecture:
* **Z-Tunnels**: Serving as the backbone of Istio Ambient's data plane, Z-Tunnels facilitate secure communication and authentication between workloads in the mesh. Additionally, they provide essential functions such as mTLS, authentication, and telemetry.
* **Istio CNI**: In Ambient mode, Istio CNI configures traffic redirection to Z-Tunnels using eBPF, simplifying network management and enhancing performance.
* As a Layer 7 Envoy Proxy per workload, the Waypoint Proxy complements the functionality of Z-Tunnels by offering HTTP-specific capabilities. It serves as a second component alongside Z-Tunnels, providing enhanced layer-7 features when necessary.

![ambient.png](https://media.graphassets.com/MBqW8njzSkSE92NgMtRC)

The hybrid nature of Istio Ambient is characterized by its ability to dynamically adapt to workload requirements, seamlessly transitioning between layer 4 and layer 7 functionalities as needed. 

## Work *with* and not *against* each other 
While people tend to believe that you can either use a CNI such as Cilium or a Service Mesh such as Isto Ambient, in reality you should use them together. Cilium excels at addressing lower-level networking requirements, providing robust solutions for traffic management, network policy enforcement, and security. By leveraging Cilium's capabilities, organizations can establish granular control over network traffic and ensure compliance with security policies. For example, Cilium's network policies enable organizations to define access control rules based on various criteria such as endpoint labels, ports, and protocols. These policies offer a flexible and scalable approach to network segmentation and isolation, ensuring that only authorized services can communicate with each other.
```
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "l3-rule"
spec:
  endpointSelector:
    matchLabels:
      role: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        role: frontend
```
```
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "l4-rule"
spec:
  endpointSelector:
    matchLabels:
      app: myService
  egress:
    - toPorts:
      - ports:
        - port: "80"
          protocol: TCP
```
Cilium also offers matching on l7 capabilities, but it will also use an embedded (or stand-alone per node) envoy proxy on those scenarios.
```
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: "l7-rule"
spec:
  endpointSelector:
    matchLabels:
      app: myService
  ingress:
  - toPorts:
    - ports:
      - port: '80'
        protocol: TCP
      rules:
        http:
        - method: GET
          path: "/path1$"
        - method: PUT
          path: "/path2$"
          headers:
          - 'X-My-Header: true'
```

On the contrary, Istio's authorization policies provide additional layers of security by enforcing access control at the application layer. By defining policies based on Spiffe and Spire identities, organizations can restrict access to sensitive resources and prevent unauthorized interactions between services.

```
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: httpbin
  namespace: foo
spec:
  action: DENY
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/my-service-account
  - to:
    - operation:
        methods: ["POST"]
        ports: ["8080"]
```
## Conclusion
The evolution of service meshes represents a transformative journey in microservices networking, offering unprecedented capabilities to modernize and optimize cloud-native architectures. As organizations embark on this journey, it's essential to approach tool selection with careful consideration, recognizing that there is no one-size-fits-all solution.

In navigating the complexities of cloud-native networking, I advocate for a holistic approach that embraces diversity in tooling. For organizations seeking comprehensive networking solutions, the integration of Cilium as a CNI and Istio Ambient as a service mesh exemplifies the power of complementary technologies. Cilium excels at addressing low-level networking requirements, while Istio Ambient provides advanced service mesh capabilities, creating a synergistic relationship that enhances overall network resilience and scalability. However, the decision of which tools to pick ultimately depends on a myriad of factors, including workload characteristics, performance requirements, compliance standards, and operational preferences. 

From sidecars to sidecarless: Tracing the evolution of service mesh technologies with Istio and Cilium

I recall the days when writing a web application in C# with .NET meant deploying it on an IIS web server for accessibility. Today, this approach seems outdated, especially with the shift towards microservice-based architectures. Fortunately, Microsoft has significantly revamped .NET, releasing it as .NET Core, which caters to modern development needs.
## .NET Core
NET Core has been in existence since its initial release in June 2016. It represents a versatile, open-source framework designed for creating modern, cloud-native applications. It marks a significant departure from the traditional .NET framework, which was primarily tied to Windows environments. With .NET Core, developers gain the flexibility to build applications that can seamlessly run on macOS, Linux, and Windows operating systems. This platform independence makes .NET Core an ideal choice for developing microservice-based applications using C#.
## Developing a Microservice-Based Application
Developing a microservice-based application involves several key steps that are fundamental regardless of the application's specific requirements. Due to the distributed nature of these applications, developers need to carefully address the following challenges during the development phase:

- Service Invocation: Managing how services communicate with each other efficiently and reliably, considering factors like latency and response times.
- State Handling: Dealing with data consistency and synchronization across distributed services, which becomes challenging when services are updated independently and need to maintain coherent states.
- Asynchronous Messaging: Implementing robust messaging patterns (like queues or event-driven communication) to ensure reliable and scalable interaction between services, while handling potential message losses or delays.
- Service Orchestration: Coordinating the workflow and interaction between multiple microservices to achieve complex business processes, while ensuring fault tolerance and scalability.
- Transfer Encryption: Ensuring end-to-end security by encrypting data transferred between microservices to protect against eavesdropping and data breaches.

Fortunately, since these challenges are common, there are established solutions available to address them.
## Dapr
One effective solution for overcoming the challenges of developing distributed applications is Dapr (Distributed Application Runtime). Dapr is an open-source project initiated by Microsoft to simplify the development of distributed systems. It provides a set of building blocks and APIs that abstract and simplify common tasks. These APIs are typically served by a sidecar placed next to your service, allowing for easy integration.

By abstracting these functionalities, Dapr offers API endpoints that enable developers to focus on business logic without worrying about the specific implementation details of the underlying infrastructure. Dapr is environment-agnostic and language-agnostic, supporting any platform that can handle HTTP and potentially gRPC.

Dapr's building blocks can be mixed and matched as needed, offering features such as:
- Direct Service Invocation
- Pub/Sub
- State Management
- Service-to-Service Encryption (mTLS)
- Observability
- Secrets Management

These features make Dapr a versatile tool for developing microservice-based applications. For the German speaking audience, there is a <a href="/podcast/softwerkercast-episode-46-moderne-microservices-landschaften-kubernetes-dapr-gateway-api-and-mehr" target="_blank">podcast episode available </a> where I discuss some of that as well 
## Aspire.NET
Aspire.NET is another significant component to consider. Developed and open-sourced by Microsoft, Aspire.NET was recently released in its first major version (1.0) on May 21. It is a cloud-ready stack with strong conventions designed for production-ready distributed applications, streamlining end-to-end development in .NET Core. Aspire.NET focuses on three main areas:
- Orchestration
- Reusable Components
- Tooling

In terms of orchestration, Aspire.NET provides a way to compose your app based on the resources it needs, such as apps and databases. These components can include reusable components like Redis or PostgreSQL databases, distributed as NuGet Packages. Tooling-wise, Aspire.NET follows a specific project structure to streamline development:
- AnyServiceProjects: These can be any services your application needs, such as APIs or frontends. That's your business logic.
- AppHost: This project handles high-level orchestration for your application, integrating various components like APIs, service containers, and executables, and managing their communication.
- ServiceDefaults: This project provides default configurations for your .NET Aspire application, which can be extended and customized as needed. It covers aspects like health checks, OpenTelemetry settings, and more.
Aspire.NET thus provides a robust framework for developing and managing distributed applications with .NET Core.

## A Concrete Example
Alright, enough with the theoretical explanations. With all the tools at our disposal, let's build a demo app to showcase their combined capabilities. This demo app, is a simple voting application. You can vote for your favourite colour and you'll see the results on the right hand side. For this example, we will have three different services (or projects, in C# terminology) inside our solution:

- Web Service: This will host the web frontend. We will use Razor Components in combination with HTMX to render the page.
- Colour Service: This service will provide a simple HTTP REST API to retrieve all possible/existing colours and allow voting for a given colour.
- Vote Service: This service will be responsible for actually saving a vote. Communication will be established using Pub/Sub for creating a vote and a simple API to get the current vote count.

![components.png](https://media.graphassets.com/vjoZESwxQ4ihnjCyCm0A)

All three services will utilize a Dapr sidecar to offload complexity:
- The Web Project will use a Dapr sidecar to establish HTTP connectivity, including service discovery.
- The Colour Service will use a Dapr sidecar to implement Pub/Sub as the publisher.
- The Vote Service will use a Dapr sidecar to implement Pub/Sub as the receiver and to handle state management.
These components will leverage Dapr to simplify interactions with Redis for Pub/Sub and state management.

You can find the source code <a href="https://github.com/SantoDE/aspire-dapr-dotnet-core-htmx" target="_blank">here </a>.
## Let's Get It Running (Locally)
Remember the AppProject part ensuring orchestration? Now it's getting handy! If you've checked out the code from above, you can see the AppProject code like this:
```
using Aspire.Hosting.Dapr;
var builder = DistributedApplication.CreateBuilder(args);

var stateStore = builder.AddDaprStateStore("statestore");
var pubSub = builder.AddDaprPubSub("pubsub");

DaprSidecarOptions sidecarOptionsVote = new()
{
    EnableApiLogging = true,
    LogLevel = "DEBUG",
    AppId = "votes"
};

DaprSidecarOptions sidecarOptionsColours = new()
{
    EnableApiLogging = true,
    LogLevel = "DEBUG",
    AppId = "colours"
};

DaprSidecarOptions sidecarOptionWeb = new()
{
    EnableApiLogging = true,
    LogLevel = "DEBUG",
    AppId = "web"
};

var voteApi = builder.AddProject<Projects.voting_app_VotesService>("voteservice")
    .WithDaprSidecar(sidecarOptionsVote)
    .WithReference(stateStore)
    .WithReference(pubSub)
    .WithExternalHttpEndpoints();

var colourApi = builder.AddProject<Projects.voting_app_ColourService>("colourservice")
    .WithExternalHttpEndpoints()
    .WithDaprSidecar(sidecarOptionsColours)
    .WithReference(pubSub)
    .WithReference(voteApi);

var frontend = builder.AddProject<Projects.voting_app_Web>("web")
    .WithExternalHttpEndpoints()
    .WithDaprSidecar(sidecarOptionWeb);

builder.Build().Run();
```
This file describes the overall structure of our landscape. Aspire will take care of the orchestration based on this project. To get it running locally, all we need to do now is a simple:

```
dotnet run --project voting-app.AppHost
Buildvorgang wird ausgeführt...
info: Aspire.Hosting.Dapr.DaprDistributedApplicationLifecycleHook[0]
      Starting Dapr-related resources...
info: Aspire.Hosting.Dapr.DaprDistributedApplicationLifecycleHook[0]
      Using default Dapr state store for component 'statestore'.
info: Aspire.Hosting.Dapr.DaprDistributedApplicationLifecycleHook[0]
      Using default Dapr pub-sub for component 'pubsub'.
info: Aspire.Hosting.DistributedApplication[0]
      Aspire version: 8.0.1+a6e341ebbf956bbcec0dda304109815fcbae70c9
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application starting.
info: Aspire.Hosting.DistributedApplication[0]
      Application host directory is: /Users/manuelzapf/Projects/codecentric/pocs/sms_dotnet_core/voting-app.AppHost
info: Aspire.Hosting.DistributedApplication[0]
      Now listening on: https://localhost:17168
info: Aspire.Hosting.DistributedApplication[0]
      Login to the dashboard at https://localhost:17168/login?t=88984ad3d019e079e78cb118728dd109
info: Aspire.Hosting.DistributedApplication[0]
      Distributed application started. Press Ctrl+C to shut down.
```

As we can see in the logs above, the application and the Aspire Dashboard have started up. We can check the app running by visiting https://localhost:7044.
![app.png](https://media.graphassets.com/qxPxwL9QQmOrj3f4pRCP)
Additionally, the Aspire Dashboard is now up and running, showing all our deployed components.
![aspire.png](https://media.graphassets.com/SaRJa9CQS8yDH23EYluu)
The Aspire Dashboard provides more capabilities than just running resources. It's also the key point for structured logging, metrics, and traces. It's a great starting point for observing and debugging your distributed applications, all thanks to the OpenTelemetry integration that comes with Aspire.

![Bildschirmfoto 2024-06-27 um 16.13.23.png](https://media.graphassets.com/ZWSBh34mTVivlGW2bpxH)

## Bonus Points: Let's Deploy It Using Azure Development Kit
Alright, we have the application and all components running locally. The easiest next step is to deploy everything to the Azure Cloud using the Azure Developer CLI. Once installed and authenticated against your account, you can deploy with just two commands:
```
azd init
azd up
```

After running these commands, the AZD CLI will create [Bicep](https://learn.microsoft.com/de-de/azure/azure-resource-manager/bicep/) templates (kinda like Cloudformation, the IaaC from Azure) and use them to deploy our described application utilizing Azure Container Apps.

```
Packaging services (azd package)

Provisioning Azure resources (azd provision)
Provisioning Azure resources can take some time.

Subscription: manuel.zapf@codecentric.de (XXX)
Location: Germany West Central

  You can view detailed progress in the Azure Portal:
  XXX

  (✓) Done: Resource group: rg-voteservice-example
  (✓) Done: Log Analytics workspace: law-xmjcalomp65aw
  (✓) Done: Container Registry: acrxmjcalomp65aw
  (✓) Done: Container Apps Environment: cae-xmjcalomp65aw
  (✓) Done: Container App: daprstore

Deploying services (azd deploy)

  (✓) Done: Deploying service colourservice
  - Endpoint: https://colourservice.bravewater-24618931.germanywestcentral.azurecontainerapps.io/

  (✓) Done: Deploying service voteservice
  - Endpoint: https://voteservice.bravewater-24618931.germanywestcentral.azurecontainerapps.io/

  (✓) Done: Deploying service web
  - Endpoint: https://web.bravewater-24618931.germanywestcentral.azurecontainerapps.io/

  Aspire Dashboard: https://aspire-dashboard.ext.bravewater-24618931.germanywestcentral.azurecontainerapps.io

SUCCESS: Your up workflow to provision and deploy to Azure completed in 3 minutes 12 seconds.
```
By browsing to the URL of either the web service or the Aspire Dashboard, you can see all components running and working.

## Conclusion
In conclusion, the combination of .NET Core, Dapr, and Aspire offers a powerful toolkit for developing modern distributed applications. With .NET Core's maturity and cross-platform capabilities, coupled with Dapr's simplification of distributed system complexities through its sidecar model and Aspire's robust orchestration and tooling, developers can accelerate their development process significantly.

These technologies provide a streamlined approach to implementing microservices architectures, handling tasks like service invocation, asynchronous messaging, state management, and observability out of the box. By leveraging Dapr's sidecar pattern, developers can focus more on business logic and less on infrastructure concerns, all while benefiting from the reliability and scalability that Azure and other cloud environments provide.

Whether you're building from scratch or modernizing existing applications, the integration of .NET Core, Dapr, and Aspire offers a compelling solution that empowers developers to innovate and deliver robust, scalable applications efficiently.

Modern Microservices: Unleashing the Power of .NET Core, Aspire, and Dapr

In a <a href="https://www.codecentric.de/wissens-hub/blog/modern-microservices-unleashing-the-power-of-net-core-aspire-and-dapr" target=_blank>recent blog post</a>, we introduced Dapr (Distributed Application Runtime) and highlighted its potential as a valuable tool for cloud-native applications, in combination with Aspire. This post dives deeper into the inner workings of Dapr, explaining its architecture, components, and how to leverage its capabilities effectively.

## Dapr under the hood
As previously mentioned, Dapr (Distributed Application Runtime) is an excellent toolkit for building distributed applications. It offers various components, known as Building Blocks, each serving a specific function. Dapr's strength lies in its language-agnostic nature, allowing developers to create applications in any language of their choice while leveraging as many of Dapr's Building Blocks as needed.

### Sidecars and Architecture
Dapr achieves this by being divided into two distinct parts. The first part is the Dapr runtime, which is the core of Dapr, responsible for orchestration and acting as a portable control plane. The second part is the sidecar, which is unique to each Dapr-enabled application. A sidecar is a secondary process running alongside the application, serving as a transparent companion. When an application needs to use a building block, it communicates through the sidecar, which facilitates the use of the specified component. Integrating with a sidecar is straightforward, as all building blocks are exposed as HTTP or gRPC-based APIs. Applications simply call their own sidecar, which provides access to the necessary APIs to utilize the building blocks.

### Buildings Blocks
As of version 1.1, Dapr provides multiple building blocks, with different maturities:

![building_blocks.png](https://media.graphassets.com/9jgpfIPrS6W04t7GdukI)
Source: https://docs.dapr.io/images/building_blocks.png

- Service Invocation: Service invocation allows applications to interact through well-defined endpoints using HTTP or gRPC messages. Dapr offers an endpoint that functions as a reverse proxy with integrated service discovery, incorporating distributed tracing and error handling.
- State Management: Application state refers to any data an application needs to retain beyond a single session. Dapr offers key/value-based state and query APIs with pluggable state stores for persistence.
- Pub/Sub Messaging: Pub/Sub is a loosely coupled messaging pattern in which publishers send messages to a topic, and subscribers subscribe to that topic to receive the messages. Dapr facilitates the pub/sub pattern for communication between applications.
- Workflows: The Workflow API allows you to define long-running, persistent processes or data flows that involve multiple microservices using Dapr workflows or workflow components. It can be integrated with other Dapr API building blocks, enabling workflows to invoke other services or retrieve secrets, thus offering flexibility and portability.
- Resource Bindings: A binding provides a two-way connection to an external cloud or on-premise service or system. Dapr enables you to invoke the external service through its binding API and allows your application to be triggered by events from the connected service.
- Actors: An actor is a self-contained unit of computation and state with single-threaded execution. Dapr offers an actor implementation based on the virtual actor pattern, providing a single-threaded programming model and automatically garbage collecting actors when they are not in use.
- Secrets: Dapr offers a secrets building block API that integrates with various secret stores, including public cloud stores, local stores, and Kubernetes, to manage secrets. Services can use the secrets API to retrieve sensitive information, such as a database connection string.
- Configuration: The Configuration API allows you to retrieve and subscribe to application configuration items from supported configuration stores. This enables an application to access specific configuration information, such as during startup or when changes are made in the configuration store.
- Distributed Lock: The distributed lock API allows you to lock a resource, ensuring that multiple instances of an application can access the resource without conflicts and maintain consistency guarantees.
- Cryptography: The Cryptography API allows you to perform cryptographic operations, such as encrypting and decrypting messages, without exposing keys to your application.

### Portability is key aka Dapr Components
The impressive aspect of these building blocks is their interchangeability. To use a building block, you first need to configure a component. For example, with Pub/Sub Messaging, Dapr supports a variety of message broker systems such as Redis, Kafka, RabbitMQ, and cloud-based solutions like AWS SNS/SQS or Azure Service Bus. To use RabbitMQ, you would simply configure a component like this:

```
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order-pub-sub
spec:
  type: pubsub.rabbitmq
  version: v1
  metadata:
  - name: host
    value: "amqp://localhost:5672"
scopes:
  - orderprocessing
  - checkout
```
Once Dapr has loaded this component, utilizing it becomes a breeze. For example in C#, it would be as simple as:
```
await client.PublishEventAsync(order-pub-sub, checkout, eventPayload, cancellationToken);
``` 
This makes Dapr-enabled applications highly portable across different environments, as the core application code does not change. If you switch from RabbitMQ to Redis, for example, all you need to do is reconfigure the component, and everything will continue to work seamlessly.

### Added capabilities
Since the sidecars are a central component, not only in providing APIs for the building blocks but also within the actual traffic flow, they offer additional capabilities in terms of observability, security, and resiliency. 

- **Observability**: Dapr provides distributed tracing, metrics, and logs, all of which can be exported to a receiver of your choice using OpenTelemetry. 
- **Resiliency**: The sidecar manages timeouts, retries/back-offs, and circuit breaking, as well as health checks for both the application and the sidecar itself. 
- **Security**: Connections between sidecars and the control plane are secured using mTLS. Additionally, for service invocation and pub/sub, you can implement access policies to control who can access what, providing fine-grained access control.

These enhanced capabilities make Dapr a powerful tool for managing the complexities of distributed applications.

### Is Dapr a Service mesh?
Let's answer that question simply: No, Dapr is not a service mesh. Does it offer overlapping capabilities? Yes, definitely. So, how exactly does Dapr compare to the likes of Linkerd, Istio, or potentially Cilium?

First off, a service mesh focuses primarily on networking inside a cluster, providing capabilities to enhance everything network-related. Dapr, on the other hand, is application-centric. It provides building blocks that make building distributed applications easier and quicker. While both use sidecars, this is a technical implementation detail rather than a defining feature of a service mesh. The overlapping capabilities between service meshes and Dapr include service-to-service encryption (mTLS), service invocation, metrics and tracing, and resiliency features like retries..

![service-mesh.png](https://media.graphassets.com/qCRx3PQLSlaA8DeB0fea)
Source: https://docs.dapr.io/images/service-mesh.png

Networking-wise, when a Dapr-enabled app calls another app, it uses the application's ID known to Dapr. Dapr then routes that request through the underlying network, which could potentially be a service mesh that handles the actual networking path.

This distinction explains why it's not a matter of choosing Dapr or a service mesh, but rather how Dapr and a service mesh can work together effectively.

## Example
Alright, that's been a lot of theory so far. Let's dive into an actual example. Since Dapr is a portable runtime, all it takes to run a Dapr-enabled app is an environment, either self-hosted or within Kubernetes (K8s) with the Dapr runtime installed. For this example, we'll use a simple local Kubernetes cluster (Minikube, Kind, K3s, etc.) and the well-known microservice-demo from Google Cloud, which I've edited to utilize Dapr.

![dapr_microservice_demo.png](https://media.graphassets.com/rYF29YrvQ5SUB08vZuW6)

Let's create a quick Kind cluster for this example, though any other local Kubernetes environment will work as well:

```
kind create cluster -n dapr-demo
```

Once the cluster is installed, the only thing missing is the actual Dapr runtime. Fortunately, Dapr provides a convenient CLI that we'll use heavily for this demo. To get the runtime into our local cluster, use the following command:

```
dapr init --dev -k
⌛  Making the jump to hyperspace...
ℹ️  Note: To install Dapr using Helm, see here: https://docs.dapr.io/getting-started/install-dapr-kubernetes/#install-with-helm-advanced

ℹ️  Container images will be pulled from Docker Hub
✅  Deploying the Dapr control plane with latest version to your cluster...
✅  Deploying the Dapr dashboard with latest version to your cluster...
✅  Deploying the Dapr Redis with latest version to your cluster...
✅  Deploying the Dapr Zipkin with latest version to your cluster...
ℹ️  Applying "statestore" component to Kubernetes "default" namespace.
ℹ️  Applying "pubsub" component to Kubernetes "default" namespace.
ℹ️  Applying "appconfig" zipkin configuration to Kubernetes "default" namespace.
✅  Success! Dapr has been installed to namespace dapr-system. To verify, run `dapr status -k' in your terminal. To get started, go here: https://aka.ms/dapr-getting-started
``` 

This command will install the following components inside our cluster as part of the Dapr runtime, which we can quickly check with:

```
dapr status -k
  NAME                   NAMESPACE    HEALTHY  STATUS   REPLICAS  VERSION  AGE  CREATED
  dapr-operator          dapr-system  True     Running  1         1.13.5   1d   2024-07-03 15:10.23
  dapr-sidecar-injector  dapr-system  True     Running  1         1.13.5   1d   2024-07-03 15:10.23
  dapr-dashboard         dapr-system  True     Running  1         0.14.0   1d   2024-07-03 15:10.25
  dapr-sentry            dapr-system  True     Running  1         1.13.5   1d   2024-07-03 15:10.23
  dapr-placement-server  dapr-system  True     Running  1         1.13.5   1d   2024-07-03 15:10.23
```

Not only does this command install the Dapr runtime, but it also deploys a default Zipkin installation as a tracing backend and a Redis instance for pub/sub and state store purposes.

For this pub/sub setup, the necessary components will be applied to Kubernetes by default with the --dev command:

```
dapr components -k
⚠  In future releases, this command will only query the "default" namespace by default. Please use the --namespace flag for a specific namespace, or the --all-namespaces (-A) flag for all namespaces.
  NAMESPACE  NAME        TYPE          VERSION  SCOPES  CREATED              AGE
  default    pubsub      pubsub.redis  v1               2024-07-08 13:51.37  38s
  default    statestore  state.redis   v1               2024-07-08 13:51.36  39s
```

With the runtime installed and healthy, we can proceed to the next step. The Dapr CLI also has a run command, which can launch apps and sidecars directly through Dapr. Additionally, it has a multi-run capability to start multiple apps (and their sidecars) together, similar to Docker Compose, but Dapr handles the sidecar placement and wiring. In the example repo mentioned above, I've already set this up. Hence, a simple:

```
kubectl apply -f ./src/emailservice/components/subscription.yml
dapr run -k -f dapr.yaml
``` 
This will bring up the entire microservice demo. To see that everything has started, we can use the Dapr dashboard:

```
dapr dashboard -k
ℹ️  Dapr dashboard found in namespace:	dapr-system
ℹ️  Dapr dashboard available at:	http://localhost:8080
```

You can also port-forward the frontend service to access the demo app:

```
kubectl port-forward -n default svc/frontend 8081:80
```

Once inside the demo app, you can go through an end-to-end flow, from selecting a product to completing the checkout. After completing the checkout, by checking the email service logs, you should see a result like this:

```
emailservice {"timestamp": 1720179148.6441565, "severity": "INFO", "name": "emailservice-server", "message": "A request to send order confirmation email for order fcd1bdec-3ac1-11ef-b1a7-faf1d76d4272 to someone@example.com has been received.", "taskName": null}
```

## How does this work
This works by configuring the frontend service to use its sidecar for interservice communication by setting the addresses of those services to the sidecar.

Example:
```
    env:
      PRODUCT_CATALOG_SERVICE_ADDR: localhost:50001
      AD_SERVICE_ADDR: localhost:50001
      CART_SERVICE_ADDR: localhost:50001
      CHECKOUT_SERVICE_ADDR: localhost:50001
      CURRENCY_SERVICE_ADDR: localhost:50001
      SHIPPING_SERVICE_ADDR: localhost:50001
      RECOMMENDATION_SERVICE_ADDR: localhost:50001
      SHOPPING_ASSISTANT_SERVICE_ADDR: localhost:50001
```

Now, the frontend service goes through the sidecar rather than directly to the service, allowing for control of the traffic flow. For pub/sub, the checkout service sends a gRPC request to the sidecar to emit the "checkout" event. The sidecar connects to Redis to actually emit the event. The email service's sidecar subscribes to the topic in Redis and, once an event is emitted, wraps the event into an HTTP call to notify the email service. Additionally, in the default Kubernetes configuration, all services communicate using mTLS, ensuring secure communication.

## Conclusion and next steps
In conclusion, Dapr stands out as a robust and versatile tool for building cloud-native, distributed applications. Its architecture, based on the separation of the runtime and sidecar, enables seamless integration and flexibility across various programming languages and environments. The array of building blocks, such as Service Invocation, State Management, Pub/Sub Messaging, and many others, allows developers to easily incorporate essential functionalities into their applications.

Dapr's portability is a key advantage, allowing applications to remain consistent across different environments by simply reconfiguring components. This makes it highly adaptable and efficient, particularly in hybrid cloud setups or during migrations. The added features of observability, security, and resiliency further enhance its appeal, providing comprehensive support for modern application needs. Overall, Dapr is a valuable addition to any cloud-native toolkit, offering a comprehensive and flexible solution for managing the complexities of distributed application development and deployment.

Exploring Dapr: A Deep Dive into Distributed Application Runtime

In a recent blog post, we explored how Dapr works and how to test it on a simple local Kubernetes cluster. One of Dapr's key advantages is its component system, which enhances portability. In this post, we'll take our previously daperized demo app and deploy it in an AKS environment, utilizing some of Azure's managed services through Dapr to demonstrate its portability.

## Quick Recap on Components
Each Dapr building block (e.g., PubSub) can be used within Dapr by defining a component. A component is an instance of a building block and comes with its own configuration. For example, a PubSub component using RabbitMQ would look like this:
```
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: order-pub-sub
spec:
  type: pubsub.rabbitmq
  version: v1
  metadata:
  - name: host
    value: "amqp://localhost:5672"
scopes:
  - orderprocessing
  - checkout
```

Once an application calls a Dapr sidecar to publish a message, the Dapr sidecar sends it to RabbitMQ, and everything flows as usual from there. Various cloud providers have components to integrate with Dapr. For this blog post, we will focus on AKS and show an example with it.

## Talking about requirements
If you want to follow along with this blog post, you will need to have some requirements in place.

* Installed Azure CLI
* Helm or Dapr CLI
* Access to an Azure Subscription

## Lets get an AKS Cluster
To quickly set up an AKS cluster, we'll use the Azure az CLI. First, we will create a resource group and then create an AKS cluster inside it.

```
az group create --name dapr-aks --location germanywestcentral
az aks create --resource-group dapr-aks --name dapr-aks --node-count 2 --generate-ssh-keys --tier free 
```

The output should look like this:

```
{
  "id": "/subscriptions/70abc615-f4d6-474a-8c0e-2d30a9d41d84/resourceGroups/dapr-aks",
  "location": "germanywestcentral",
  "managedBy": null,
  "name": "dapr-aks",
  "properties": {
    "provisioningState": "Succeeded"
  },
  "tags": null,
  "type": "Microsoft.Resources/resourceGroups"
} 
The behavior of this command has been altered by the following extension: aks-preview
{
  "aadProfile": null,
  "addonProfiles": null,
   SNIP
  "workloadAutoScalerProfile": {
    "keda": null,
    "verticalPodAutoscaler": null
  }
} 
```

With the ressource group and cluster created, we need to connect to the cluster to proceed! This is simply done with
```
az aks get-credentials -n dapr-aks -g dapr-aks
```
Lets test connectivty with a simple command:
```
kubectl get nodes
NAME                                STATUS   ROLES   AGE     VERSION
aks-nodepool1-21855256-vmss000000   Ready    agent   5m53s   v1.28.10
aks-nodepool1-21855256-vmss000001   Ready    agent   5m54s   v1.28.10
```

## Install Dapr 3 options to choose from
Generally speaking, there are three major possibilities to install the Dapr runtime on an AKS cluster each with its own pros and cons. For the sake of completeness, we will cover all three methods: Dapr CLI, Helm, and the AKS-managed Dapr extension. Each method offers a different level of control and convenience. If I were to choose, I'd usually go with the Helm approach for its balance of flexibility and ease of use.

1. **Dapr CLI**: Quick and straightforward, ideal for development and testing environments.
2. **Helm**: Offers more customization and is well-suited for production environments.
3. **AKS-managed Dapr extension**: Simplifies management by offloading maintenance to Azure, though it may have some limitations in customization.

Let's dive into each method in more detail.

### Install Dapr runtime with Dapr CLI
As shown in the last blog post, the Dapr CLI already has a built-in functionality to bootstrap the runtime on a Kubernetes cluster. A simple command:
```
dapr init -k 
```
will install the runtime with all the necessary services. This time, we won't use the `-dev` flag, as we don't want any Dapr configuration components to be available in the cluster already.

```
dapr init -k
⌛  Making the jump to hyperspace...
ℹ️  Note: To install Dapr using Helm, see here: https://docs.dapr.io/getting-started/install-dapr-kubernetes/#install-with-helm-advanced

ℹ️  Container images will be pulled from Docker Hub
✅  Deploying the Dapr control plane with latest version to your cluster...
✅  Deploying the Dapr dashboard with latest version to your cluster...
✅  Success! Dapr has been installed to namespace dapr-system. To verify, run `dapr status -k' in your terminal. To get started, go here: https://aka.ms/dapr-getting-started
```

Quickly checking that its deployed

```
dapr status -k
  NAME                   NAMESPACE    HEALTHY  STATUS   REPLICAS  VERSION  AGE  CREATED
  dapr-sidecar-injector  dapr-system  True     Running  1         1.13.5   53s  2024-07-18 12:39.23
  dapr-placement-server  dapr-system  True     Running  1         1.13.5   53s  2024-07-18 12:39.23
  dapr-operator          dapr-system  True     Running  1         1.13.5   53s  2024-07-18 12:39.23
  dapr-dashboard         dapr-system  True     Running  1         0.14.0   51s  2024-07-18 12:39.25
  dapr-sentry            dapr-system  True     Running  1         1.13.5   53s  2024-07-18 12:39.23
```

And we are good to go! By default, the Dapr CLI is the only method that also installs the dashboard.

### Install Dapr runtime with Helm

As suggested by the Dapr CLI command, you can also use Helm to install Dapr. The Dapr CLI actually utilizes the official Helm chart under the hood to deploy the components, making the CLI essentially a convenience wrapper. To install Dapr manually using Helm, there are just a few steps involved. 

```
helm repo add dapr https://dapr.github.io/helm-charts/
helm repo update
helm upgrade --install dapr dapr/dapr \
--version=1.13 \
--namespace dapr-system \
--create-namespace \
--wait
```

The output should look like this:
```
"dapr" has been added to your repositories
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "dapr" chart repository
Update Complete. ⎈Happy Helming!⎈
Release "dapr" does not exist. Installing it now.
NAME: dapr
LAST DEPLOYED: Thu Jul 18 12:49:15 2024
NAMESPACE: dapr-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing Dapr: High-performance, lightweight serverless runtime for cloud and edge

Your release is named dapr.

To get started with Dapr, we recommend using our quickstarts:
https://github.com/dapr/quickstarts

For more information on running Dapr, visit:
https://dapr.io
```

Checking the pods
```
kubectl get pods -n dapr-system
NAME                                     READY   STATUS    RESTARTS   AGE
dapr-operator-5789c8dc5b-fcxwz           1/1     Running   0          60s
dapr-placement-server-0                  1/1     Running   0          60s
dapr-sentry-774c876df5-wj9xp             1/1     Running   0          60s
dapr-sidecar-injector-867c5f9485-jgxvw   1/1     Running   0          60s
```
This confirms that everything is up and running, and we are good to go.

#### Dapr Dashboard
To install the Dapr Dashboard, you'll need to use its official Helm chart as well.

```
helm install dapr-dashboard dapr/dapr-dashboard --namespace dapr-system
NAME: dapr-dashboard
LAST DEPLOYED: Thu Jul 18 12:55:37 2024
NAMESPACE: dapr-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
```

### Azure Managed Dapr runtime installation
Last but not least, AKS offers a managed Dapr installation that you can utilize as well. This managed option alleviates the need for you to handle the runtime yourself, but it does come with some limitations.

To set it up, you can use the following commands:

```
az extension add --name k8s-extension
az provider register --namespace Microsoft.KubernetesConfiguration
az feature registration create --namespace Microsoft.KubernetesConfiguration --name ExtensionTypes
az k8s-extension create --cluster-type managedClusters \
--cluster-name dapr-aks \
--resource-group dapr-aks \
--name dapr \
--extension-type Microsoft.Dapr \
--auto-upgrade-minor-version false
```

Once this is done, you'll have a Dapr runtime managed by AKS. As already seen with the Helm instals, this managed installation does not include the Dapr Dashboard, which you will need to install manually if required.

## Setup Service Bus for PubSub
Alright, with the Dapr runtime now set up, we can proceed. Since we’re working in AKS, we'll leverage Azure Service Bus for our PubSub component instead of managing an alternative solution ourselves. To achieve this, follow these three steps:

* Create a Service Bus Namespace
* Create a Queue within that Namespace
* Retrieve the Authorization Key

These steps can be easily accomplished using the Azure CLI. Here’s how you can do it:

```
# Step 1: Create a Service Bus Namespace
az servicebus namespace create --resource-group dapr-aks --name dapr-aks-orders-bus-ns --location westeurope

# Step 2: Create a Queue in the Namespace
az servicebus queue create --resource-group dapr-aks --namespace-name dapr-aks-orders-bus-ns --name orders

# Step 3: Get the Authorization Key
az servicebus namespace authorization-rule keys list --resource-group dapr-aks --namespace-name dapr-aks-orders-bus-ns --name RootManageSharedAccessKey --query primaryConnectionString --output tsv

{
  "createdAt": "2024-07-10T14:01:58.1974899Z",
  "disableLocalAuth": false,
  "id": "/subscriptions/70abc615-f4d6-474a-8c0e-2d30a9d41d84/resourceGroups/dapr-aks/providers/Microsoft.ServiceBus/namespaces/dapr-aks-orders-bus-ns",
  "location": "westeurope",
  "metricId": "70abc615-f4d6-474a-8c0e-2d30a9d41d84:dapr-aks-orders-bus-ns",
  "minimumTlsVersion": "1.2",
  "name": "dapr-aks-orders-bus-ns",
  "premiumMessagingPartitions": 0,
  "provisioningState": "Succeeded",
  "publicNetworkAccess": "Enabled",
  "resourceGroup": "dapr-aks",
  "serviceBusEndpoint": "https://dapr-aks-orders-bus-ns.servicebus.windows.net:443/",
  SNIP
  "status": "Active",
  "type": "Microsoft.ServiceBus/namespaces/queues",
  "updatedAt": "2024-07-18T14:43:45Z"
}
Endpoint=sb://dapr-aks-orders-bus-ns.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=9eq5sPFWFzFVIFzTscAaI2xgZ/1LhbOl++ASbBK9GbY=
```
The most important part is the Endpoint= in the authorization key output. This will be used to configure the PubSub component in Dapr.

## Setup PubSub component in Dapr

Now it’s time to configure Dapr with Azure Service Bus. We need to create a Dapr component in YAML format for our AKS cluster. Here's how you can configure it:
```
apiVersion: dapr.io/v1alpha1
kind: Component
metadata:
  name: pubsub
spec:
  type: pubsub.azure.servicebus.queues
  version: v1
  metadata:
  - name: connectionString # Required when not using Azure Authentication.
    value: "Endpoint=sb://dapr-aks-orders-bus-ns.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=9eq5sPFWFzFVIFzTscAaI2xgZ/1LhbOl++ASbBK9GbY="
```
In this configuration:

* The name of the component is set to pubsub, matching the name used in previous examples. This facilitates the reusability and portability of your Dapr building blocks
* The type is specified as pubsub.azure.servicebus.queues, indicating that we're using Azure Service Bus for PubSub.
* The connectionString is provided to authenticate with Azure Service Bus as fetched previously

This enables the reusability and portability. A sidecar will just emit the event to the component, not knowing whether its redis (as previously) or now Azure Sercive Bus.

## Test things
With everything set up, you’re almost ready to see your demo app in action. Here’s what you need to do:

* First, apply the necessary configurations to your AKS cluster:

```
kubectl apply -f deploy/components.yml
kubectl apply -f src/emailservice/components/subscription.yml
```

* Second, start the application
```
dapr run -f dapr.yaml -k
```

This setup will deploy the same Microservice Demo application as in the latest blog post. The difference now is that instead of Redis, Azure Service Bus handles the PubSub functionality.

* Third, Access the Frontend
* 
Find the IP address of the LoadBalancer service for the frontend application:

```
kubectl get service frontend
NAME       TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE
frontend   LoadBalancer   10.0.72.187   4.182.85.177   80:30896/TCP   66s
```
Use the EXTERNAL-IP to access your application through your browser. Once you have navigated through the entire demo and done a checkout, we can validate the that azure service bus is working in two places. 

* A) in the azure portal

![azure_service_bus.png](https://media.graphassets.com/tERpVRKS6SU4wiJF4wUQ)

* B) as last time, in the log of the email service

```
{"timestamp": 1721314877.7026074, "severity": "INFO", "name": "emailservice-server", "message": "A request to send order confirmation email for order 958d281b-4516-11ef-abe6-8ead7dd66b53 to someone@example.com has been received.", "taskName": null}
```

## More integration with Azure
Azure Service Bus for PubSub is just one example of how Dapr integrates with Azure’s managed services to simplify your architecture. Dapr supports various other Azure services to manage complexity efficiently. Here are a few more examples:

* State Management: Use Azure Blob Storage, Table Storage, SQL Server, CosmosDB, PostgreSQL, or MariaDB.
* PubSub: Besides Azure Service Bus, you can utilize Azure Event Hub, Kafka, or Redis.
* Secrets Management: Integrate seamlessly with Azure Key Vault.
* Configuration: Use PostgreSQL or Redis for configuration management.

These integrations underscore Dapr's commitment to portability. By merely adjusting configurations, you can switch between different managed services without needing to alter your application's code. This flexibility is central to Dapr's design, enabling you to easily adapt your applications to various environments.

## Conclusion
In this blog post, we've highlighted Dapr's impressive portability by migrating our daperized demo app from a local Kubernetes cluster to Azure Kubernetes Service (AKS). Through this transition, we leveraged Azure’s managed services via Dapr, showcasing how effortlessly applications can adapt to different environments with minimal changes. Whether transitioning from Redis for PubSub in a local setup to Azure Service Bus in the cloud, Dapr maintains the decoupling and manageability of your microservices, ensuring a smooth and scalable deployment process.

Integrating Dapr with Azure Kubernetes Service (AKS): Portability is key

Integrating Dapr with Cilium: A Sidecar-Less Service Mesh Approach combined with a powerful distributed application runtime

Solution Architect

Der Roundtable ist eine einmalige Gelegenheit, in das Thema Platform Engineering und Developer Plattformen einzutauchen, von Branchenführern wie Kaspar von Grünberg zu lernen und sich intensiv auszutauschen. Der direkte Dialog und der praxisorientierte Austausch sind entscheidend, um das volle Potenzial von Developer Portalen zu erkennen und zu nutzen.

Wir freuen uns auf den inspirierenden Abend!

Expertenwissen, Networking und neue Perspektiven im Platform Engineering. Sichere Dir Deinen Platz am 13. März 2025 in München!

Direkt zu Google Maps

Location

Agenda

Direkt zur Tiefgarage navigieren

Anfahrt

Erhalte spannende Einblicke von Kaspar von Grünberg, Marc Schnitzius und Manuel Zapf über strategische Plattform-Entwicklung und KPIs für Plattform-Teams. 

EVT | 2025-03-13 | Roundtable MUC - Platform Engineering

Entdecke das volle Potenzial von Developer Portalen

Jetzt anmelden

Nimm am 13. März 2025 am exklusiven Roundtable in München teil. Erhalte von Experten wie Kaspar von Grünberg wertvolle Einblicke und Best Practices zur Entwicklung und Optimierung interner Developer Plattformen. Diskutiere mit Marc Schnitzius und Manuel Zapf über strategische Plattform-Entwicklung und KPIs für Plattform-Teams. Networking, Einblicke und neue Perspektiven erwarten Dich!

Roundtable Platform Engineering in München – Entdecke das volle Potenzial deiner Developer Portale

Roundtable Platform Engineering 

Unser Leistungsangebot

Erreiche mit Platform Engineering einen skalierbaren und effizienten Entwicklungsprozess.

Platform Engineering für mehr Effizienz und Innovationskraft

Zum Webinar

Erfahre es in unserem on demand Webinar! 

Ist Platform Engineering für dein Unternehmen sinnvoll? 

Du möchtest mehr zum Thema Platform Engineering erfahren? 

Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Cloud-Native

Data & Machine Learning

Generative KI

IT-Security

Produktentwicklung

Weitere Leistungen...

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

<p><strong>codecentric München</strong><br>August-Everding-Straße 20<br>81671 München</p>

<p><strong>16:00 Uhr:</strong> Herzlich willkommen &amp; Check-in</p><p><strong>16:30 Uhr</strong>: Begrüßung der Teilnehmer*innen und Vorstellung 🎙️</p><p><strong>16:45 Uhr</strong>: Table Session </p><p><strong>ab 18:00 Uhr</strong>: Wrap-up und Get-together bei kühlen Getränken 🥤🍺 und Fingerfood 🥪 🍕.</p>

<p>Falls du mit dem Auto anreist, kannst du in der Tiefgarage vom PLAZA parken. Die Adresse für die Tiefgarage ist die Hanne-Hiob-Straße 10. </p><p>Wenn du mit dem ÖPNV anreist, kannst du jede S-Bahn bis zum Ostbahnhof nehmen. Von dort aus ist das PLAZA sehr gut zu Fuß erreichbar.</p>

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Roundtable Platform Engineering

Roundtable Platform Engineering in München – Entdecke das volle Potenzial deiner Developer Portale

Jetzt anmelden

Mehr laden

Wir freuen uns auf den inspirierenden Abend!

Jetzt anmelden

Du möchtest mehr zum Thema Platform Engineering erfahren?

Platform Engineering für mehr Effizienz und Innovationskraft

Unser Leistungsangebot

Ist Platform Engineering für dein Unternehmen sinnvoll?

Zum Webinar

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten