Produkt
Archito NeuLernt aus Ihren Merge Requests, zeigt, was hängt Integrationen 25
Lösungen
Nach Rolle
Warum AppArch
Ressourcen
Kunden Preise Kontakt
Sprache
Kontakt aufnehmen

Welcher Service gehört wem? Eine Stelle beantwortet das.

Der Service-Katalog erfasst in einem einzigen Datensatz, was jeder Service ist, wem er gehört, wovon er abhängt und wohin er deployt wird - automatisch aus Ihrer Codebasis ermittelt.

Bildschirme aus einer laufenden Installation

Das Inventar entsteht in drei Schritten

Sie füllen keine leere Tabelle von Hand. AppArch leitet Service-Kandidaten aus Ihren verbundenen Repositories ab, Sie bestätigen sie.

  1. 01

    Erkennen

    Verbundene Repositories werden gescannt, Service-Kandidaten tauchen auf. Sie prüfen die Liste und importieren oder verwerfen.

  2. 02

    Zuordnen

    Sie geben jedem Service einen Verantwortlichen, eine Kritikalitätsstufe und einen Lebenszyklusstatus. Kein Service bleibt herrenlos.

  3. 03

    Verknüpfen

    Abhängigkeiten, Deployments, die API-Spezifikation und Dokumentationslinks kommen hinzu. Der Datensatz ist vollständig.

Was steht in einem Service-Datensatz?

Freitext ist kein Feld. Jeder Datensatz hat dieselben Felder, damit das Inventar durchsuchbar und vergleichbar bleibt.

kind

Service-Art

Service, API, Frontend, Bibliothek, Worker, Infrastruktur oder Sonstiges. Der schnellste Weg, das Inventar zu filtern.

lifecycle

Lebenszyklus

Experimentell, Produktion, veraltet oder stillgelegt. Es sagt Ihnen, welchen Services Sie vertrauen können.

tier

Kritikalitätsstufe

Tier 1 ist geschäftskritisch, ein Ausfall ist ein schwerer Vorfall. Tier 3 steht für interne Werkzeuge und Experimente.

owner

Verantwortlich

Jeder Service hat einen Entwickler oder Nutzer als Verantwortlichen. Die Antwort auf wer kennt das hier steht im Datensatz.

dependencies

Abhängigkeiten

Die Infrastruktur, die ein Service mitbringt - PostgreSQL, Redis, Kafka -, wird aus den Kubernetes-Ressourcen Ihrer Deployment-Quelle abgeleitet; die verräterische Ressource wird als Beleg angezeigt.

deployments

Deployments

Sobald Argo CD, Flux oder Kubernetes verbunden ist, wird im Katalog sichtbar, welche Version wo läuft.

api-spec

API-Spezifikation

Die OpenAPI-Spezifikation wird aus dem Repository, per URL oder manuell angehängt. Titel, Version und Endpunktanzahl landen im Datensatz.

links

Links

Dokumentation, Runbook, Dashboard, Bereitschaftsplan, Repository und API-Links stehen direkt beim Service.

Gold, Silver, Bronze: was einem Service fehlt

Jeder Service wird gegen dieselbe Liste geprüft. Eine Prüfung, die nicht passt, etwa eine API-Spezifikation für eine Bibliothek, wird weggelassen statt gegen ihn gezählt.

  1. Gold100%
  2. Silver≥ 75%
  3. Bronze≥ 50%
  4. Keine Stufe< 50%
  • In den letzten 30 Tagen gescanntwenn ein Projekt verknüpft ist
  • API-SpezifikationServices und APIs
  • Deploytaußer Bibliotheken
  • On-Call-Linknur Tier 1

Woher ein Serviceeintrag seine Daten bekommt

Verantwortliche und Links tragen Sie ein. Alles andere wird nach Zeitplan gelesen und bleibt von selbst aktuell.

  • Argo CD · Flux · Kubernetes

    Deployments

    Alle 10 Minuten: Version je Umgebung, Sync-Status, Health sowie mitgebrachte Datenbanken, Caches und Queues.

  • openapi · swagger

    API-Spezifikation

    Im Repository per Name gefunden (Root, docs, api, spec), von einer URL geholt oder eingefügt. Stündlich aktualisiert; ein Fehlschlag behält die letzte gute Kopie.

  • ArchScan

    Verknüpftes Projekt

    Datum und Score des letzten Scans des Projekts hinter dem Service.

  • Von Ihnen eingetragen

    Verantwortliche, Tier, Lebenszyklus, Doku-, Runbook-, Dashboard- und On-Call-Links.

Wann schaut man wirklich in den Katalog?

Ein Inventar ist kein Selbstzweck. In drei Momenten zahlt es sich aus.

Erste Woche

Ein Entwickler kommt ins Team

Wie viele Services es gibt, was jeder tut, wen man fragt. Eine Liste statt einer Woche Flurerklärungen.

03:00 Uhr nachts

Bereitschaft während eines Vorfalls

Verantwortlicher, Runbook-Link, Kritikalitätsstufe und Abhängigkeiten auf einem Bildschirm. Die Minuten, die sonst die Suche kostet, gewinnen Sie zurück.

Quartalsende

Ein Architektur-Review

Wie viele experimentelle Services in die Produktion gerutscht sind, welcher Tier-1-Service keinen Verantwortlichen hat, welcher nie eine Gold-Scorecard erreicht hat. Die Fragen stützen sich auf Daten.

Häufige Fragen

Muss ich den Katalog von Hand füllen?
Nein. Service-Kandidaten werden automatisch aus Ihren verbundenen Repositories abgeleitet, Sie importieren sie aus der Liste der erkannten Services. Ein Service lässt sich auch manuell anlegen.
Woher stammen die Deployment-Informationen?
Aus dem Integrationsmodul. Verbinden Sie Argo CD, Flux oder Kubernetes, landen Deployments im Katalogeintrag. Verbinden Sie nichts, bleibt das Feld leer und der Eintrag funktioniert trotzdem.
Was zeigen die Abhängigkeiten im Katalog?
Die Infrastruktur, die ein Service mitbringt - Datenbanken, Caches, Queues -, gelesen aus den Kubernetes-Ressourcen Ihrer Deployment-Quelle. Es ist kein Aufrufgraph zwischen Services: Wer wen aufruft, ist Laufzeitinformation und braucht Tracing. Die ArchScan-Karte ist wieder etwas anderes: Sie zeigt Abhängigkeiten im Code, zwischen Projekten und Klassen.
In welchen Paketen ist der Katalog enthalten?
Der Katalog gehört wie jedes Modul zu jeder Lizenz. Im PoC sehen Sie ihn zuerst mit Ihren eigenen Repositorys.
Wo werden unsere Daten gespeichert?
Ein Katalogeintrag enthält Metadaten: Name, Art, Verantwortliche, Links. Er liegt wie alles andere in der AppArch-Installation auf Ihren eigenen Servern.

So sieht es im Produkt aus

Alle Screenshots

Bauen Sie Ihr Inventar an einem Nachmittag

Verbinden Sie Ihre Repositories, bestätigen Sie die erkannten Services, weisen Sie Verantwortliche zu. Der Rest bleibt von selbst aktuell.

Abonnieren Sie unseren Newsletter

Neue Module, Release Notes und Beiträge zur Architektur. Abmelden jederzeit mit einem Klick.