Cloud Transformation & Data Infrastructure

Du willst Deine Infrastruktur mit Terraform verwalten, aber dann passiert es doch, dass Änderungen manuell gemacht wurden – und Du eine Lösung dafür finden musst. Der Umgang damit unterscheidet sich von Fall zu Fall.

Es ist eine große Stärke von Terraform, dass es mit Änderungen außerhalb der von ihm verwalteten Ressourcen umgehen kann. Die Stichworte sind: data, import, removed, ignore_changes, lock, variables.

Viele Security-Überlegungen rund um Azure drehen sich primär um die Netzwerksicherheit. Welche weiteren Security-Säulen im Kontext von Microsoft Fabric betrachtet werden sollten, wird im Folgenden aufgezeigt.

Wie kann ich Datenquellen, die über Private Endpoints abgesichert sind, in Fabric einbinden? Wie gehe ich mit Azure Data Lakes hinter einer Firewall um? Der Blog-Beitrag zeigt auf, welche Möglichkeiten Fabric nativ bietet.

Wie im ersten Teil erwähnt, werden wir in dieser Blogserie zunächst verschiedene Teile unserer Referenzarchitektur einer Cloud Data Platform vorstellen. Im Anschluss adaptieren wir diese auf die drei großen Cloud-Anbieter – Google Cloud Platform, AWS und Azure. Falls Du den ersten Blogbeitrag, der sich mit dem Ingestion-Teil unseres Modells beschäftigt, noch nicht gelesen hast, kannst Du das noch nachholen. Für alle anderen geht es nun mit dem Data-Lake-Teil der b.telligent Referenzarchitektur weiter, bevor wir uns in Teil 3 ausführlicher mit der Analytical Platform beschäftigen.

Die Welt der mittelständischen Unternehmen bewegt derzeit vor allem ein Thema: Industrie 4.0. Denn der Druck wächst enorm, da der Anschluss an die Digitalisierung nicht verpasst werden darf, um auch langfristig erfolgreich am Markt interagieren zu können. Was die meisten Unternehmen aber nicht wissen: Es müssen nicht sämtliche internen Abläufe über Bord geworfen werden, um bei den Themen Big Data und Industrie 4.0 mithalten zu können. Viel wichtiger ist es, sich die Neugier seiner eigenen Mitarbeiter zu Nutze zu machen und die Datenkultur in alle Abteilungen zu tragen. Erfahren Sie in diesem Blogbeitrag, wie auch Sie den Wandel zur Digitalisierung Schritt für Schritt meistern können.

Hast Du schon mal darüber nachgedacht, wie die ideale Cloud-Data-Platform-Architektur aussehen sollte? Wir schon! In unserer kostenlosen Online-Event-Reihe Data Firework Days haben wir die b.telligent Referenzarchitektur für Cloud-Datenplattformen vorgestellt, einen Blueprint für den Aufbau einer erfolgreichen Datenplattform für Deine Analytics-, KI-/ML- oder DWH-Anwendungsfälle. Und wir sind noch einen Schritt weiter gegangen. Da wir alle wissen, dass es da draußen nicht die „eine“ Cloud gibt, haben wir unser Modell auch für die drei großen Cloud-Anbieter – Google Cloud Platform, AWS und Azure – adaptiert. In dieser Blogserie wollen wir in den ersten beiden Beiträgen zunächst unsere Referenzarchitektur beschreiben und uns dann, in den Teilen 4 bis 6, mit den Implementierungsmöglichkeiten für die einzelnen Anbieter beschäftigen. Los geht‘s, begleite uns auf unserer Reise durch die Cloud.

Herzlichen Glückwunsch, Du hast es geschafft und die bisherigen Ausführungen zu unserem Referenzarchitekturmodell unbeschadet überstanden! Der mühsamste und lästigste Teil liegt damit schon hinter uns. Falls Du gerade erst mit Teil 3 in unsere Blogserie einsteigst, kein Problem! Klicke einfach auf die Links zu Teil 1 und Teil 2. Dort erfährst Du mehr zu Ingestion und Data Lakes sowie der gesamten Referenzarchitektur.

Zu Teil 1 und Teil 2 der Blogserie.

Architekturempfehlung und How-to Data Processing mit Azure Synapse Analytics. In diesem Beitrag geben wir zwei Architekturempfehlungen, zeigen, wie diese umgesetzt werden können und wie die Daten für die Visualisierung bereitgestellt werden.