Die meisten Netzwerkautomatisierungsprogramme kommen an derselben Stelle ins Stocken. Rechenressourcen, Netzwerkkonfiguration und Anwendungsbereitstellung werden per Code gesteuert, während DNS, DHCP und die Verwaltung von IP-Adressen weiterhin über Support-Tickets abgewickelt werden. Der Grund dafür liegt selten in der Automatisierungstoolkette. Vielmehr verwaltet „Infrastructure-as-Code“ den Konfigurationszustand, während DDI ein aktuelles, umkämpftes Bestandsverzeichnis führt, das eher geschlichtet als deklariert werden muss. Um diese Lücke zu schließen, bedarf es einer für die Automatisierung konzipierten DDI-Schicht, und es gibt drei Wege, eine solche zu erhalten. BlueCat Micetro orchestriert die bereits in der Produktion befindlichen DNS- und DHCP-Server über eine einzige API. BlueCat Integrity konsolidiert DNS, DHCP und IPAM auf einer Plattform, auf der jede Schnittstellenaktion über ein dokumentiertes API-Äquivalent verfügt. BlueCat Horizon koordiniert die gesamte Infrastruktur über eine gehostete Steuerungsebene, während die Protokoll-Dienste weiterhin lokal ausgeführt werden.
· 01 — Warum Netzwerkautomatisierungsprogramme bei DNS, DHCP und IP Halt machen
Warum kommen Netzwerkautomatisierungsprogramme ins Stocken , wenn sie bei DNS, DHCP und der IP-Adressverwaltung ankommen?
Netzwerkautomatisierungsprogramme kommen bei DDI ins Stocken, da DNS, DHCP und die IP-Adressverwaltung in der Regel noch immer auf fragmentierten, manuellen Legacy-Tools basieren, die außerhalb der Automatisierungskette liegen.
Diese Systeme bieten nur einen begrenzten Einblick in die Netzwerkaktivitäten, verfügen über keine verbindlichen Datensätze, die von der Automatisierung abgefragt werden können, und erfordern, dass jede Änderung erneut von einem Menschen vorgenommen werden muss – sodass die einzige Abhängigkeit, die alle anderen automatisierten Workflows gemeinsam haben, weiterhin manuell bleibt.
Veraltete DDI-Systeme und -Prozesse schaffen blinde Flecken, die die Automatisierung nicht nur verlangsamen, sondern sogar unsicher machen. Fragmentierte Tools beanspruchen bis zu 30 Prozent der Arbeitszeit des IT-Personals für Routineaufgaben, und dieselbe Fragmentierung erhöht das Ausfallrisiko, da es keine einheitliche Übersicht gibt, um eine konfliktbehaftete Änderung zu erkennen, bevor sie in die Produktion gelangt. Eine auf dieser Grundlage aufgebaute Automatisierung übernimmt diese blinden Flecken, anstatt sie zu beseitigen.
Die Vereinheitlichung von DDI verändert nicht nur die Schnittstelle, sondern auch die Wirtschaftlichkeit der Arbeit. Unternehmen, die von einem veralteten DDI-Management auf eine einheitliche Plattform umsteigen, berichten von einer um 75 Prozent schnelleren Problemlösung und einer Reduzierung des Zeitaufwands für DDI-Vorgänge um 86,8 Prozent sowie von der Beseitigung DNS-bedingter Ausfälle. Diese Vorteile ergeben sich aus drei Eigenschaften, von denen die Automatisierung tatsächlich abhängt: vollständige Transparenz und Kontrolle, durchgängige Prozessautomatisierung und Zuverlässigkeit der Infrastruktur.
86,8 %
86,8 %
Unternehmen, die von veralteten DDI-Management-Systemen auf eine einheitliche Plattform umsteigen, berichten von einer Reduzierung des Zeitaufwands für DDI-Vorgänge um 86,8 Prozent und einer um 75 Prozent schnelleren Problemlösung.
Learn with BlueCat how visibility and control, process automation, and infrastructure reliability offer three reasons to adopt Unified DDI.
5 min·Blog
Weiterlesen →
· 02 — Wo universelle Automatisierungstools an ihre Grenzen stoßen
Können Ansible und Terraform DNS, DHCP und den IP-Adressraum eigenständig verwalten?
Ansible, Terraform und ähnliche Tools können DNS- und IP-Änderungen vornehmen, dienen jedoch nicht als System of Record für den Adressraum.
„Infrastructure-as-Code“ legt den gewünschten Konfigurationszustand fest, während DDI einen Live-Bestand – endlich und umkämpft – über Teams und Umgebungen hinweg koordinieren muss. Ohne eine Plattform, die diesen Bestand verwaltet und über eine API bereitstellt, kommt es vor, dass die Automatisierung Adressen als frei deklariert, deren Verfügbarkeit sie nicht überprüfen kann.
Die praktischen Grenzen zeigen sich zunächst bei der Skalierbarkeit und dann bei der Abdeckung. Unternehmen, die täglich Tausende von DNS-Änderungen in dynamischen Cloud-Umgebungen verwalten, benötigen eine automatisierte Konfliktlösung und eine konsistente Durchsetzung von Richtlinien – und zwar nicht nur pro Pipeline. Allzweck-Tools verfügen über kein natives Konzept für einen Adresspool, einen Konflikt oder eine Richtliniengrenze, sodass jede Pipeline diese Regeln neu implementiert und jede Implementierung von den anderen abweicht.
Die zweite Einschränkung ist die DDI-Plattform selbst. Vielen älteren DDI-Systemen fehlen die API-Fähigkeiten, die moderne Automatisierungsworkflows erfordern, was bedeutet, dass die Einschränkung überhaupt nicht beim Automatisierungstool liegt. Wenn die Plattform nur einen Teil der Möglichkeiten ihrer Schnittstelle offenlegt, endet die Automatisierung an dieser Grenze, und die manuelle Ausnahme wird zur Dauerlösung. „Security by Design“, Cloud-Integration und API-Programmierbarkeit entscheiden darüber, ob eine DDI-Schicht an einem Automatisierungsprozess teilhaben kann oder lediglich daneben steht.
Learn with BlueCat how security by design, cloud integration, and API programmability offer three technical reasons to adopt Unified DDI.
6 min·Blog
Weiterlesen →
· 03 — Die drei Wege, um die Lücke zu schließen, und was sie voneinander unterscheidet
Welche Ansätze gibt es zur Automatisierung von DNS, DHCP und IPAM, und wie unterscheiden sie sich?
Es gibt drei praktische Vorgehensweisen.
Koordinieren Sie die bereits im Einsatz befindlichen DNS- und DHCP-Server hinter einer einzigen Steuerungsebene, ohne sie zu ersetzen. Konsolidieren Sie DNS, DHCP und IPAM auf einer „API-first“-Plattform, auf der jede Schnittstellenaktion über ein dokumentiertes API-Äquivalent verfügt. Oder koordinieren Sie die gesamte Infrastruktur über eine gehostete Steuerungsebene, während die Protokoll-Dienste weiterhin lokal ausgeführt werden. Alle drei Ansätze ergeben eine automatisierbare DDI-Schicht; sie unterscheiden sich darin, was mit der bereits von Ihnen betriebenen Infrastruktur geschieht und inwieweit Sie die Plattform selbst betreiben.
Orchestrierung eignet sich für Umgebungen, in denen die bestehenden Server erhalten bleiben müssen. Eine Steuerungsebene liegt über Microsoft, BIND, Kea und Cloud-Diensten, stellt eine einheitliche API für alle dar und lässt die zugrunde liegende Infrastruktur unberührt, sodass Automatisierungsmuster ohne Migrationsaufwand etabliert werden können. Die Konsolidierung eignet sich für Umgebungen, die ohnehin standardisiert werden. Der Ersatz fragmentierter Tools durch eine einzige Plattform beseitigt die Übersetzungsebene vollständig und bietet der Automatisierung einen einzigen maßgeblichen Datensatz mit vollständiger programmatischer Abdeckung – allerdings auf Kosten einer Migration.
Der dritte Ansatz betrifft nicht die Funktion der Steuerungsebene, sondern den Betreiber. Eine gehostete Steuerungsebene zentralisiert Richtlinien, Identitäten, Berichterstattung und Automatisierung, während DNS und DHCP weiterhin lokal in jeder Umgebung auflösen – dies eignet sich für Umgebungen, deren Schwerpunkt sich in die Cloud verlagert hat, oder für Teams, die nicht über die Kapazitäten zum Betrieb einer weiteren Plattform verfügen. Allen drei gemeinsam ist die ihnen zugrunde liegende Anforderung: umfassende APIs, die DDI mit DevOps-Pipelines, Sicherheitstools, ITSM-Plattformen und Infrastructure-as-Code-Praktiken verbinden, sodass End-to-End-Workflows auf der Grundlage autoritativer Daten statt einer Kopie davon ablaufen.
Unify DNS, DHCP, and IPAM (DDI) to boost visibility, automation, and security. Explore nine reasons to modernize DDI and streamline network operations.
19 min·Blog
Weiterlesen →
· 04 — Was Ihre bestehende Infrastruktur für Sie entscheidet
Wie lässt sich feststellen, welcher DDI-Automatisierungsansatz zu Ihrer bestehenden Infrastruktur passt?
Die Vorgehensweise hängt von zwei Faktoren ab, die Sie bereits heute überprüfen können: Wie viel der Infrastruktur läuft bereits in der öffentlichen Cloud außerhalb der Kontrolle des DDI-Teams, und wie vollständig ist die API-Abdeckung Ihrer aktuellen Plattform?
Die Fragmentierung über verschiedene Cloud-Konten hinweg spricht für eine koordinierende Steuerungsebene. Eine Plattform, deren Schnittstelle mehr kann als ihre API, deutet auf Konsolidierung hin. Eine Infrastruktur, die zwar funktioniert, aber nicht programmgesteuert erreichbar ist, spricht für Orchestrierung.
Beginnen Sie mit der Cloud-Sicherheitslage, da diese in der Regel bereits für Sie festgelegt ist. Eine EMA-Umfrage unter 333 IT-Fachkräften ergab, dass 44 Prozent der DDI-Teams der Meinung sind, nicht genügend Einfluss darauf zu haben, wie DDI in der Public Cloud implementiert und verwaltet wird, und dass Teams, denen dieser Einfluss fehlt, ihre DDI-Strategie häufiger als erfolglos bezeichnen. 79 Prozent der Unternehmen integrieren bereits die lokale IP-Adressverwaltung in ihre Cloud-Umgebungen, und bei Multicloud-Unternehmen ist dies sogar noch häufiger der Fall.
Prüfen Sie dann die API-Abdeckung, denn sie ist der aussagekräftigste Indikator in den Daten. 89 Prozent der Unternehmen betrachten DDI als „Source of Truth“ für die Netzwerkautomatisierung, und 83 Prozent verfügen über DDI-Lösungen mit APIs, doch weniger als 44 Prozent sind damit voll und ganz zufrieden. Diese Zufriedenheitslücke spiegelt den Erfolg deutlich wider: 70 Prozent der Unternehmen mit sehr erfolgreichen DDI-Strategien sind mit ihren APIs voll und ganz zufrieden, gegenüber 17 Prozent derjenigen, deren Strategien Schwierigkeiten haben. Wenn eine Aktion in der Schnittstelle vorhanden ist, aber kein dokumentiertes API-Äquivalent hat, stoppt die Automatisierung an dieser Grenze.
70 %
70 %
70 Prozent der Unternehmen mit sehr erfolgreichen DDI-Strategien sind mit ihren DDI-APIs voll und ganz zufrieden, gegenüber 17 Prozent derjenigen, deren Strategien Schwierigkeiten bereiten.
Only 40% of enterprises believe they are fully successful with their DDI solution. Learn how to find greater success with new research from EMA and BlueCat.
8 min·Blog
Weiterlesen →
Sprechen Sie mit einem BlueCat-Experten darüber, wie Sie die Automatisierung in Ihrer Umgebung auf DNS, DHCP und die IP-Adressverwaltung ausweiten können.
· 05 — Orchestrierung der bereits im Betrieb befindlichen DNS- und DHCP-Server
Wie ermöglicht die Orchestrierung die Automatisierung bestehender DNS- und DHCP-Server, ohne diese zu ersetzen?
Durch die Orchestrierung wird eine Steuerungsebene über die bereits laufenden DNS- und DHCP-Server gelegt und eine einheitliche API für alle diese Server bereitgestellt.
Microsoft, BIND, Kea, Cisco Meraki und cloudbasierte Dienste laufen weiterhin wie bisher, während Adressraum, Datensätze und Richtlinien zentral verwaltet werden. Ein einziger Automatisierungs-Workflow deckt dann jedes Backend ab, anstatt eines pro Plattform – genau diese Lücke lässt die allgemeine „Infrastructure-as-Code“-Lösung offen.
BlueCat Micetro erfüllt diese Rolle als unterbrechungsfreies Overlay, das die bestehende DNS-, DHCP- und IPAM-Infrastruktur über eine einzige Weboberfläche mit REST-, SOAP- und JSON-RPC-Zugriff sowie Ansible-Modulen zum Aufbau von Workflows integriert und orchestriert. Da die zugrunde liegenden Server unberührt bleiben, bleiben bestehende Betriebsmodelle und Investitionen erhalten, und Automatisierungsmuster werden etabliert, ohne dass eine Migration das Team von seiner ersten funktionsfähigen Pipeline trennt.
Die Governance-Seite ist ebenso wichtig wie die API. Dass mehrere Administratoren DNS-Änderungen ohne einheitliche Aufsicht vornehmen, ist ein häufiger Fehlerfall, und Genehmigungsworkflows, rollenbasierter Zugriff sowie eine detaillierte Änderungsverfolgung ermöglichen eine Automatisierung, ohne die Kontrolle zu verlieren. Für Umgebungen, in denen veraltete Microsoft-DNS-Systeme modernisiert werden, bieten MDDS-Appliances, erweiterte Protokollierung und Failover-Funktionen einen schrittweisen Übergangspfad anstelle einer sofortigen Umstellung.
BlueCat Micetro is an easy, intuitive DDI orchestration solution that overlays your existing DNS, DHCP, and IPAM services to provide centralized visibility…
With Micetro, integrate, orchestrate, and automate your current DNS, DHCP, and IPAM network infrastructure via a single web interface.
5 min·Page
View Micetro →
· 06 — Konsolidierung auf einer einzigen „API-first“-Plattform
Was bietet eine „API-first“-DDI-Plattform für die Automatisierung, was ein Overlay nicht bietet?
Durch die Konsolidierung entfällt die Übersetzungsschicht.
Eine einzige Plattform verwaltet DNS, DHCP und IPAM als einen einzigen maßgeblichen Datensatz, und jede in der Benutzeroberfläche verfügbare Aktion ist als dokumentierter API-Aufruf verfügbar, sodass keine Funktion außerhalb der Reichweite der Automatisierung liegt. Das ist besonders wichtig, wenn die Automatisierung über DDI hinaus auf Sicherheitstools, Observability und ITSM ausgeweitet werden muss, da die Grenze der API zur Grenze dessen wird, was korreliert werden kann.
BlueCat Integrity beantwortet die Frage nach der Abdeckung strukturell und nicht durch bloße Behauptungen. Integrity X betreibt eine eigene Schnittstelle auf derselben REST-v2-API, die es seinen Kunden zur Verfügung stellt – definiert in OpenAPI und einsehbar in Swagger –, sodass manuelle Arbeit zu einer Spezifikation für die Automatisierung wird und nicht zu einem konkurrierenden Umgehungsweg. Die zentralisierte DNS-, DHCP- und IP-Verwaltung umfasst bereits von vornherein richtliniengesteuerte Governance, rollenbasierte Zugriffskontrolle, Compliance-Prüfungen und automatisierte Änderungsverfolgung.
Diese Reichweite geht über DDI hinaus. Integrity ist darauf ausgelegt, mit den Netzwerküberwachungstools von LiveAction zusammenzuarbeiten, und Teams, die beide Lösungen einsetzen, empfinden die Arbeit als einfacher als bei der isolierten Nutzung einer der beiden, da keine der Plattformen Daten speichert, auf die die andere keinen Zugriff hat. Das ist der praktische Test für den Anspruch „API-first“: ob die Daten einer Plattform für Systeme zugänglich sind, die nicht dem DDI-Anbieter gehören.
1:1Parität zwischen UI und API
1:1 Parität zwischen UI und API
Jede Aktion in der Integrity X-Oberfläche wird als echter, dokumentierter REST-v2-API-Aufruf ausgeführt, sodass keine Funktionsfähigkeit der Schnittstelle außerhalb der Reichweite der Automatisierung liegt.
Tame network complexity with Integrity's full-stack DDI management platform and get visibility and control over your DNS, DHCP, and IPAM.
9 min·Page
View Integrity →
· 07 — Koordination der Automatisierung über eine SaaS-Steuerungsebene
Wann sollte die DDI-Automatisierung über eine gehostete Steuerungsebene statt über eine selbst betriebene koordiniert werden?
Eine gehostete Steuerungsebene ist dann sinnvoll, wenn die Infrastruktur über verschiedene Clouds und Umgebungen verteilt ist und die Koordinierung – und nicht die Leistungsfähigkeit – die entscheidende Einschränkung darstellt.
Richtlinien, Identitäten, Berichterstellung und Automatisierung werden zentralisiert, während DNS und DHCP weiterhin lokal ausgeführt werden. So wird Konsistenz erreicht, ohne dass Protokoll-Dienste oder Telemetriedaten mit hohem Datenaufkommen aus den Umgebungen verlagert werden müssen, in denen sie entstehen.
BlueCat Horizon stellt diese Steuerungsebene als eine Reihe von SaaS-basierten Plattformdiensten bereit, die sowohl DDI als auch die mit LiveAction erworbenen Lösungen zur Netzwerküberwachung umfassen. Es bietet gemeinsame API-Gateways, Authentifizierung, Verwaltung von Anmeldedaten, Schnittstellenkonsistenz und zentralisierte KI-Analysen über alle BlueCat-Produkte hinweg – wodurch die Automatisierung portfolioübergreifend kohärent gestaltet wird, anstatt nur innerhalb einzelner Teile des Portfolios korrekt zu funktionieren. EMA identifiziert die Vereinigung von DDI und Observability als strategischen Wandel in der Art und Weise, wie Unternehmen Netzwerkdienste erstellen und nutzen.
Die Zentralisierung der Steuerung ist nicht gleichbedeutend mit der Zentralisierung der Ausführung. Die Steuerungsebene, die KI-Fähigkeiten und die Orchestrierungslogik laufen in der Cloud, während Protokolldienste und Telemetriedaten mit hohem Datenaufkommen vor Ort oder in den eigenen Cloud-Umgebungen des Kunden verbleiben. Diese Trennung ermöglicht eine produktübergreifende Automatisierung, die zuvor unmöglich war: DDI-Daten zu Standort und Kritikalität von Diensten, die Incident-Workflows anreichern, Echtzeit-Einblicke in die Performance, die die Steuerung des DNS-Verkehrs vorantreiben, sowie DNS-basierte Bedrohungserkennung, die automatische Eindämmungsmaßnahmen auslöst.
BlueCat Horizon is a SaaS-first Intelligent NetOps platform unifying DNS, DHCP, IPAM, security, and observability to automate modern network operations AI
6 min·Page
Horizon anzeigen →
· 08 — Wege in die Zukunft
Welcher Weg zu automatisiertem DNS, DHCP und IPAM passt zu Ihrer Netzwerkautomatisierungspraxis?
Der Weg richtet sich nach den Rahmenbedingungen. Wenn die Server bestehen bleiben müssen, orchestrieren Sie sie. Wenn die Plattform bereits ersetzt wird, konsolidieren Sie auf eine mit vollständiger API-Abdeckung. Wenn die Infrastruktur über verschiedene Clouds verteilt ist und das Problem in der Kohärenz liegt, koordinieren Sie sie über eine gehostete Steuerungsebene. Wenn die Entscheidung noch Monate auf sich warten lässt, definieren Sie die Anforderungen jetzt, damit bei der Bewertung die richtigen Aspekte geprüft werden.
PATH 01
Wenn die bestehenden Server erhalten bleiben und eine Migration nicht in Frage kommt
Die bereits in Produktion befindlichen Server orchestrieren
Setzen Sie Micetro über die bestehende Infrastruktur, sodass eine einzige API alle Backends abdeckt, und richten Sie dann die Automatisierung der Bereitstellung auf diese API aus, anstatt für jede Plattform einen eigenen Workflow zu schreiben. Genehmigungsworkflows und rollenbasierter Zugriff gewährleisten die Aufrechterhaltung der Governance, während die Automatisierung ausgeweitet wird. So lassen sich funktionierende Automatisierungsmuster etablieren, ohne die Architektur neu zu gestalten und ohne auf eine Plattformentscheidung warten zu müssen.
Wenn die Plattform bereits ersetzt wird oder die Automatisierung über DDI hinausgehen muss
Konsolidierung auf einer Plattform mit vollständiger API-Abdeckung
Verlagern Sie DNS, DHCP und IPAM auf Integrity, sodass ein einziger maßgeblicher Datensatz jeden Workflow bedient und jede Schnittstellenaktion über ein dokumentiertes API-Äquivalent verfügt. Überprüfen Sie die Abdeckungsparität, bevor Sie den Arbeitsumfang festlegen, denn genau an dieser Grenze scheitern DDI-Automatisierungsprojekte in der Regel. Die Kombination mit Observability-Tools lohnt sich erst, sobald der DDI-Datensatz programmgesteuert erreichbar ist.
Wenn die Infrastruktur verteilt ist und das Problem in der Kohärenz und nicht in der Leistungsfähigkeit liegt
Koordinieren Sie die Infrastruktur über eine gehostete Steuerungsebene
Verbinden Sie bestehende DDI-Systeme über Horizon, damit Richtlinien, Identitäten, Berichterstattung und Analysen einheitlich sind, während Protokolldienste weiterhin lokal ausgeführt werden. Eine produktübergreifende Automatisierung zwischen DDI und Observability wird möglich, ohne dass Telemetriedaten verschoben oder jede Integration manuell neu verknüpft werden muss. Entscheiden Sie sich hierfür, wenn die Infrastruktur verteilt ist und keine einzelne Plattformentscheidung Abhilfe schaffen würde.
Wenn eine DDI-Aktualisierung ansteht, die Entscheidung jedoch noch nicht getroffen wurde
Legen Sie vor der Evaluierung „Automation-First“-Anforderungen fest
Formulieren Sie zunächst Anforderungen hinsichtlich der Gleichwertigkeit der API-Abdeckung, der hybriden Transparenz, der Durchsetzung von Richtlinien und der Migrationsgarantien und nutzen Sie diese dann als Grundlage für die Bewertung. Fragen Sie, ob für jede Schnittstellenaktion ein dokumentiertes API-Äquivalent existiert, und stellen Sie diese Frage noch vor der Funktionsvorführung. Anforderungen, die erst im Nachhinein definiert werden, beschreiben eher die Demo als die tatsächliche Infrastruktur.
Diese Antworten gehen auf häufig gestellte Fragen von Teams ein, die ihre bestehende Netzwerkautomatisierung auf DNS, DHCP und die IP-Adressverwaltung ausweiten möchten.
Terraform kann DNS-Einträge und IP-Zuweisungen erstellen und ändern, sofern ein Anbieter vorhanden ist, kann jedoch nicht als System of Record für den Adressraum fungieren. Es legt den gewünschten Zustand aus einem Repository fest, während IPAM in Echtzeit einen begrenzten, gemeinsam genutzten Bestand über Teams und Pipelines hinweg verwalten muss. BlueCat Integrity ist für diese Rolle konzipiert und fasst DNS, DHCP und IPAM zu einem einzigen autoritativen Datensatz zusammen, der über eine dokumentierte REST-API erreichbar ist. Ohne eine Plattform, die diese Funktion übernimmt, kann Terraform eine Adresse deklarieren, ohne überprüfen zu können, ob diese tatsächlich frei ist.
Ansible eignet sich gut dazu, DDI-Änderungen voranzutreiben, sobald eine maßgebliche Instanz festgelegt hat, wie diese Änderungen aussehen sollen. Was ihm von Haus aus fehlt, ist das Konzept eines Adresspools, eines Konflikts oder einer Richtliniengrenze, sodass diese Regeln in jedem Playbook neu implementiert werden und sich im Laufe der Zeit voneinander entfernen. BlueCat Micetro ist für diese Kombination konzipiert: Es speichert die Regeln einmalig und stellt sie über REST- und Ansible-Module bereit, sodass bestehende Playbooks jedes Backend erreichen können – weshalb die beiden in der Regel kombiniert und nicht als Ersatz füreinander eingesetzt werden.
Je nachdem, was mit den bereits in Betrieb befindlichen DNS- und DHCP-Servern geschieht und wer die darüberliegende Ebene betreibt, orchestriert Micetro bestehende Microsoft-, BIND-, Kea-, Meraki- und Cloud-Dienste als unterbrechungsfreies Overlay, sodass es sich für Umgebungen eignet, in denen diese Server bestehen bleiben. Integrity konsolidiert DNS, DHCP und IPAM auf einer API-first-Plattform, was sich für Umgebungen eignet, die standardisiert werden, oder für Automatisierungsvorhaben, die sich auf Sicherheits- und Observability-Tools ausweiten müssen. Horizon koordiniert eine verteilte Umgebung von einer gehosteten Steuerungsebene aus, während Protokoll-Dienste weiterhin lokal ausgeführt werden. Es handelt sich um je nach Situation ausgewählte Alternativen, nicht um aufeinanderfolgende Phasen.
Fragen Sie, ob jede in der Benutzeroberfläche verfügbare Aktion ein dokumentiertes API-Äquivalent hat, und bitten Sie darum, die Spezifikation statt einer Zusammenfassung einzusehen. Lücken in der Abdeckung sind der Grund, warum Automatisierungsprojekte ins Stocken geraten, da eine einzige nicht exponierte Aktion zu einer dauerhaften manuellen Ausnahme in einem ansonsten automatisierten Workflow wird. BlueCat Integrity löst dieses Problem strukturell: Integrity X betreibt seine eigene Benutzeroberfläche auf derselben REST-v2-API, die es seinen Kunden zur Verfügung stellt, sodass jede Aktion in der Benutzeroberfläche ein dokumentierter API-Aufruf ist. Umfragedaten zeigen, dass die Zufriedenheit mit DDI-APIs eng mit dem Gesamterfolg von DDI zusammenhängt, was dies eher zu einer Leitfrage als zu einem technischen Detail macht.
Nein. Eine Orchestrierungsebene liegt über bestehenden Microsoft-, BIND-, Kea- und Cloud-Diensten und stellt eine einheitliche API für alle dar, während die Server an Ort und Stelle verbleiben. BlueCat Micetro erfüllt diese Rolle als unterbrechungsfreies Overlay, sodass Automatisierungsmuster etabliert werden können, ohne dass eine Migration im Weg steht. Eine Migration ist dann in Betracht zu ziehen, wenn das Ziel ein einziger maßgeblicher Datensatz statt einer einheitlichen Schnittstelle ist oder wenn die API-Abdeckung der bestehenden Plattform die Automatisierung behindert.
DDI enthält die maßgebliche Aufzeichnung darüber, was eine Adresse ist und zu welchem Dienst sie gehört, während die Überwachungstools ein Bild davon liefern, wie sich das Netzwerk tatsächlich verhalten hat. Teams, die beides gemeinsam einsetzen, profitieren in der Regel stärker von beiden Komponenten, als es jede für sich allein leisten könnte. BlueCat Horizon basiert auf dieser Kombination und vereint DDI und Netzwerk-Observability auf einer einzigen SaaS-Plattform. Entscheidend für den Erfolg ist in jedem Fall, dass die DDI-Plattform programmgesteuert erreichbar ist – daher bestimmt die API-Abdeckung, ob die beiden Komponenten überhaupt zusammen genutzt werden können.
Prüfen Sie zunächst zwei Dinge: Wie viel der Infrastruktur läuft in der öffentlichen Cloud außerhalb der Kontrolle des DDI-Teams, und deckt die API der aktuellen Plattform alle Funktionen ab, die ihre Schnittstelle leisten kann? Diese beiden Antworten sprechen in der Regel bereits für sich allein für Micetro, Integrity oder Horizon. Automatisieren Sie anschließend zunächst die Workflows, die andere Aufgaben blockieren – typischerweise die Adresszuweisung und die Datensatzerstellung während der Bereitstellung – und erweitern Sie den Umfang, sobald sich die Muster bewährt haben.
Haben Sie noch Fragen?
Erhalten Sie konkrete Antworten von einem BlueCat-Mitarbeiter.
We’re using cookies on this website to improve your experience. Cookies help us learn how you interact with our website and remember you when you come back so we can tailor it to your interests.
To learn more about cookies and how we use them, read our cookie notice.
Some cookies are essential, while others help us to improve your experience by giving us insight into how you are using our website. You may adjust your preferences for non-essential cookies below.
To learn more about cookies and how we use them, read our cookie notice. You can also review our privacy policy for more details on the personal data we collect, use, hold, and disclose when you visit our website or use our products and services.
Functional cookies
Functional cookies are essential cookies that allow us to remember choices or changes you have made (such as to language settings or your choices regarding the use of cookies). These cookies cannot be turned off since they are essential for the operation of our Websites.
Analytics cookies
Analytics cookies are non-essential cookies that collect information on how visitors use our Websites. We use this information with your consent to measure the number of visitors to our Websites, determine whether specific content or communication has been viewed, and to help us improve our Websites and communication. These cookies can be turned off.
Personalisation Storage
Personalisation cookies are non-essential cookies that collect information when you fill out a form on this website. We only use this information with your consent to pre-fill other forms on the site. These cookies can be turned off.
Marketing cookies
Marketing cookies are cookies that are placed by third parties to collect information about your visits and actions on our Websites so that they or we can deliver ads to you later, such as when you are on certain third-party sites or platforms. These cookies may be used by those third parties to build a profile of your interests and show you relevant ads on other websites. These cookies also enable visitors to our Websites to share content on social networks and to enable and evaluate interactions with our communication and social media tools. These cookies can be turned off.
