Tag Archive for: GCP

Why using Infrastructure as Code for developing Cloud-based Data Warehouse Systems?

In the contemporary age of Big Data, Data Warehouse Systems and Data Science Analytics Infrastructures have become an essential component for organizations to store, analyze, and make data-driven decisions. With the evolution of cloud computing, many organizations are now migrating their Data Warehouse Systems to the cloud for better scalability, flexibility, and cost-efficiency. Infrastructure as Code (IaC) can be a game-changer in this scenario. By automating the provisioning and management of cloud resources through code, IaC brings a host of advantages to the development and maintenance of Data Warehouse Systems in the cloud.

So why using IaC for Cloud Data Infrastructures?

Of course you – as a human user – can always login into the admin portal of any cloud provider and manually get your resources like SQL databases, ETL tools, Virtual Networks and tools like Synapse, snowflake, BigQuery or Databrikcs in place by clicking on the right buttons….. But here is why you should better follow the idea of having your code explaining which resources are in what order in place in your cloud:

Version Control for your Cloud Infrastructure

One of the primary advantages of using IaC is version control for your Data Warehouse – or Data Lakehouse – Architecture. Whether you’re using Redshift, Snowflake, or any other cloud-based data warehouse solutions, you can codify your architecture settings, allowing you to track changes over time. This ensures a reliable and consistent development environment and makes it easier to identify issues, rollback updates, or replicate the architecture for other projects.

Scalability Tailored for Data Needs

Data Warehouse Systems often require to scale quickly to handle larger datasets or more queries. Traditional manual scaling methods are cumbersome and slow. IaC allows for efficient auto-scaling based on real-time needs. You can write scripts to automatically provision or de-provision resources depending on your data workloads, making your data warehouse highly adaptive to your organization’s changing requirements.

Cost-Efficiency in Resource Allocation

Cloud resources are priced based on usage, so efficient allocation is crucial for managing costs. IaC enables precise control over cloud resources, allowing you to turn them off when not in use or allocate more resources during peak times. For Data Warehouse Systems that often require powerful (and expensive) computing resources, this level of control can translate into significant cost savings.

Streamlined Collaboration Among Teams

Data Warehouse Systems in the cloud often involve cross-functional teams — data engineers, data scientists, and system administrators. IaC allows these teams to collaborate more effectively. Everyone works with the same infrastructure configurations, reducing discrepancies between development, staging, and production environments. This ensures that the data models and queries developed by data professionals are consistent with the underlying infrastructure.

Enhanced Security and Compliance

Data Warehouses often store sensitive information, making security a paramount concern. IaC allows security configurations to be codified and automated, ensuring that every new resource or service deployed complies with organizational and regulatory guidelines. This proactive security approach is particularly beneficial for industries that have to adhere to strict compliance rules like HIPAA or GDPR.

Reliable Environment for Data Operations

Manual configurations are prone to human error, which can compromise the reliability of a Data Warehouse System. IaC mitigates this risk by automating repetitive tasks, ensuring that the infrastructure is consistently provisioned. This brings reliability to data ETL (Extract, Transform, Load) processes, query performances, and other critical data operations.

Documentation and Disaster Recovery Made Easy

Data is the lifeblood of any organization, and losing it can be catastrophic. IaC allows for swift disaster recovery by codifying the entire infrastructure. If a disaster occurs, the infrastructure can be quickly recreated, reducing downtime and data loss.

Most common IaC solutions

The most common tools for creating Cloud Infrastructure as Code are probably Terraform and Pulumi. However, IaC solutions can be very different in their concepts. For example: While Terraform is a pure declarative configuration language that just describes how the infrastructure will look like (execution then by the Terraform-supporting Cloud Provider), Pulumi on the other hand will execute the deployment by a programming language iteratively deploying the wished cloud resources (e.g. using for loops in Python). While executing Pulumi in any supported programming language like Python or C#, Pulumi generates declarative Infrastructure build plans for the Cloud. Any IaC solution is declaring how the infrastrcture looks like.

Terraform

Terraform is one of the most widely used Infrastructure as Code (IaC) tools, developed by HashiCorp. It enables users to define and provision a data center infrastructure using a declarative configuration language known as HashiCorp Configuration Language (HCL).

The following Terraform script will create an Azure Resource Group, a SQL Server, and a SQL Database. It will also output the fully qualified domain name (FQDN) of the SQL Server, which you can use to connect to the database:

The HCL code needs to be placed into the Terrafirm main.tf file. Of course, Terraform and the Azure CLI needs to be installed before.

Pulumi

Pulumi is a modern Infrastructure as Code (IaC) tool that sets itself apart by allowing infrastructure to be defined using general-purpose programming languages like Python, TypeScript, Go, and C#.

Example of a Pulumi Python script creating a SQL Database on Microsoft Azure Cloud:

Running the script will need the installation of Python, Pulumi and the Azure CLI.

Cloud Provider specific IaC Solutions

Cloud providers might come up with their own IaC solutions, here are the probably most common ones:

Microsoft Azure Bicep is an open-source domain-specific language (DSL) developed by Microsoft, aimed at simplifying the process of deploying Azure resources. It serves as a declarative alternative to JSON for writing Azure Resource Manager (ARM) templates. Bicep compiles down to ARM templates, offering a more concise syntax and easier tooling while leveraging the proven, underlying ARM deployment engine.

AWS CloudFormation is a service offered by Amazon Web Services (AWS) that allows you to define cloud infrastructure in JSON or YAML templates.

Google Cloud Deployment Manager is quite similar to AWS CloudFormation but tailored for Google Cloud Platform (GCP), it allows you to define and deploy resources using YAML or Python templates.

IaC Tools for Server Configuration

There are many other IaC solutions and some of them are more focused on configuration of servers. In common they offer software provisioning as well and a lot detailing in regards to micro-configuration of single applications running on the server.

The most common IaC software for Server Configuration might be Ansible, a YAML-based configuration management tool that uses an agentless architecture. It’s easy to set up and widely used for automating tasks like software provisioning and configuration management. Puppet, Chef and SaltStack are further alternatives and master-agent architecture-based.

Other types of IaC Solutions

IaC solutions with a more narrow focus are e.g. Vagrant as a primarily used IaC tool for setting up virtual development environments, especially for the automation of VM (Virtual Machine) provisioning. The widely used Docker Compose is a tool for defining and running multi-container Docker applications, which can be defined using YAML files.

Furthermore we have tools that are working closely together with IaC tooling, e.g. Prometheus as an open-source monitoring toolkit often used in conjunction with other IaC tools for monitoring deployed resources.

Conclusion

Infrastructure as Code significantly enhances the development and maintenance of Cloud-based Data Infrastructures. From versioning your warehouse architecture and scaling resources according to real-time data needs, to facilitating team collaboration and ensuring security compliance, IaC serves as a foundational technology that brings agility, reliability, and cost-efficiency. As organizations continue to realize the importance of data-driven decision-making, leveraging IaC for cloud-based Data Warehouse Systems will likely become a best practice in data engineering and infrastructure management.

Interview Benjamin Aunkofer - Business Intelligence und Process Mining ohne Vendor-Lock-In

Interview – Business Intelligence und Process Mining ohne Vendor Lock-in!

Das Format Business Talk am Kudamm in Berlin führte ein Interview mit Benjamin Aunkofer zum Thema “Business Intelligence und Process Mining nachhaltig umsetzen”.

In dem Interview erklärt Benjamin Aunkofer, was gute Business Intelligence und Process Mining ausmacht und warum Unternehmen in jedem Fall daran arbeiten sollten, den gefürchteten Vendor Lock-In zu vermeiden, der gerade insbesondere bei Process Mining droht, jedoch leicht vermeidbar ist.

Nachfolgend das Interview auf Youtube sowie die schriftliche Form zum Nachlesen:


Interview – Process Mining, Business Intelligence und Vendor Lock

1 – Herr Aunkofer, wir wollen uns heute über Best Practice bei der Verarbeitung von Daten unterhalten. Welche Fehler sollten Unternehmen unbedingt vermeiden, wenn sie ihre Daten zur Modellierung aufbereiten?

Mittlerweile weiß ja bereits jeder Laie, dass die Datenaufbereitung und -Modellierung einen Großteil des Arbeitsaufwandes in der Datenanalyse einnehmen, sei es nun für Business Intelligence, also Reporting, oder für Process Mining. Für Data Science ja sowieso. Vor einen Jahrzehnt war es immer noch recht üblich, sich einfach ein BI Tool zu nehmen, sowas wie QlikView, Tableau oder PowerBI, mittlerweile gibt es ja noch einige mehr, und da direkt die Daten reinzuladen und dann halt loszulegen mit dem Aufbau der Reports.

Schon damals in Ansätzen, aber spätestens heute gilt es zu recht als Best Practise, die Datenanbindung an ein Data Warehouse zu machen und in diesem die Daten für die Reports aufzubereiten. Ein Data Warehouse ist eine oder eine Menge von Datenbanken.

Das hat den großen Vorteil, dass die Daten auf einer Ebene modelliert werden, für die es viele Experten gibt und die technologisch auch sehr mächtig ist, nicht auf ein Reporting Tool beschränkt ist.
Außerdem veraltet die Datenbanktechnologie nur sehr viel langsamer als die ganzen Tools, in denen Analysen stattfinden.

Im Process Mining sind ja nun noch viele Erstinitiativen aktiv und da kommen die Unternehmen nun erst so langsam auf den Trichter, dass so ein Data Warehouse hier ebenfalls sinnvoll ist. Und sie liegen damit natürlich vollkommen richtig.

2 – Warum ist es so wichtig einen Vendor Lock zu umgehen?

Na die ganze zuvor genannte Arbeit für die Datenaufbereitung möchte man keinesfalls in so einem Tool haben, das vor allem für die visuelle Analyse gemacht wird und viel schnelleren Entwicklungszyklen sowie einem spannenden Wettbewerb unterliegt. Sind die ganzen Anbindungen der Datenquellen, also z. B. dem ERP, CRM usw., sowie die Datenmodelle für BI oder Process Mining direkt an das Tool gebunden, dann fällt es schwer z. B. von PowerBI nach Tableau oder SuperSet zu wechseln, von Celonis nach Signavio oder welches Tool auch immer. Die Migrationsaufwände sind dann ein ziemlicher Showstopper.

Bei Datenbanken sind Migrationen auch nicht immer ein Spaß, die Aufwände jedoch absehbarer und vor allem besteht selten die Notwendigkeit dazu, die Datenbanktechnologie zu wechseln. Das ist quasi die neutrale Zone.

3 – Bei der Nutzung von Daten fallen oft die Begriffe „Process Mining“ und „Business Intelligence“. Was ist darunter zu verstehen und was sind die Unterschiede zwischen PM und BI?

Business Intelligence, oder BI, geht letztendlich um die zur Verfügungstellung von guten Reports für das Management bis hin zu jeden Mitarbeiter des Unternehmens, manchmal aber sogar bis zum Kunden oder Lieferanten, die in Unternehmensprozesse inkludiert werden sollen. BI ist gewissermaßen schon seit zwei Jahrzehnten ein Trend, entwickelt sich aber auch immer weiter, mit immer größeren Datenmengen, in Echtzeit usw.

Process Mining ist im Grunde eng mit der BI verwandt, man kann auch sagen, dass es ein BI für Prozessanalysen ist. Bei Process Mining nehmen wir uns die Log-Daten von operativen IT-Systemen vor, in denen Unternehmensprozesse erfasst sind. Vornehmlich ERP-Systeme, CRM-Systeme, Dokumentenmangement-Systeme usw.
Die Daten bereiten wir in sogenannte Event Logs, also Prozessprotokolle, auf und laden sie dann ein eines der vielen Process Mining Tools, egal in welches. In diesen Tools kann man dann Prozess wirklich visuell betrachten, filtern und analysieren, rekonstruiert aus den Daten, spiegeln sie die tatsächlichen operativen Vorgänge wieder.

Auch bei Process Mining tut sich gerade viel, Machine Learning hält Einzug ins Process Mining, Prozesse können immer granularer analysiert werden, auch unstrukturierte Daten können unter Einsatz von AI mit in die Analyse einbezogen werden usw.
Der Markt bereinigt sich übrigens auch dadurch, dass Tool für Tool von größeren Software-Häusern aufgekauft werden. Also der Tool-Markt ist gerade ganz krass im Wandel und das wird die nächsten Jahre auch so bleiben.

4 – Wie ist denn die Best Practice bei der Speicherung, Aufbereitung und Modellierung von Daten?

BI und Process Mining sind eigentlich eher Methoden der Datenanalytik als einfach nur Tools. Es ist ein komplexes System. Ganz klar hierfür ist der Aufbau eines Data Warehouses, dass aus Datensicht quasi so eine Art Middleware ist und Daten zentral allen Tools bereitstellt. Viele Unternehmen haben ja um einiges mehr als nur ein Tool im Haus, die kann man dann auch alle weiterhin nutzen.

Was gerade zum Trend wird, ist der Aufbau eines Data Lakehouses. Ein Lakehouse inkludiert auch clevere Art und Weise auch einen Data Lake.

Den Unterschied kann man sich wie folgt vorstellen: Ein Data Warehouse ist wie das Regel zu Hause mit den Ordnern zum Abheften aller wichtigen Dokumente, geordnet nach … Ordner, Rubrik, Sortierung nach Datum oder alphabetisch. Allerdings macht es auch große Mühe, diese Struktur zu verwalten, alles ordentlich abzuheften und sich überhaupt erstmal eine Logik dafür zu erarbeiten. Ein Data Lake ist dann sowas wie die eine böse Schublade, die man eigentlich gar nicht haben möchte, aber in die man dann alle Briefe, Dokumente usw. reinwirft, bei denen man nicht weiß, ob man diese noch braucht. Die Inhalte des Data Lakes sind bestenfalls etwas vorsortiert, aber eigentlich hofft man ja nicht, da wieder irgendwas drin wiederfinden zu müssen.

5 – Sie haben ja einen guten Marktüberblick: Wie gut sind deutsche Unternehmen in diesen Bereichen aufgestellt?

Grundsätzlich schon mal gar nicht so schlecht, wie oft propagiert wird. In beinahe jedem deutschen Unternehmen existiert mittlerweile ein Data Warehouse sowie Initiativen zur Einführung von BI, Process Mining und Data Science bzw. KI, in Konzernen natürlich stets mehrere. Was ich oft vermisse, ist so eine gesamtheitliche Sicht auf die Dinge, es gibt ja viele Nischenexperten, die sich auf eines dieser Themen stürzen, es aber nicht in Verbindung zu den anderen Themen betrachten. Z. B. steht auch KI nicht für sich alleine, sondern kann sowohl der Business Intelligence als auch Process Mining über den Querverweis befähigen, z. B. zur Berücksichtigung von unstrukturierten Daten, oder ausbauen mit Vorhersagen, z. B. Umsatz-Forecasts. Das ist alles eine Datenevolution, vom ersten Report von Unternehmenskennzahlen über die Analyse von Prozessen bis hin zu KI-getriebenen Vorhersagesystemen.

6 – Wo sehen Sie den größten Nachholbedarf?

Da mache ich es kurz: Unternehmen brauchen Datenstrategien und ein Big Picture, wie sie Daten richtig nutzen, dabei dann auch die unterschiedlichen Methoden der Nutzung dieser Daten richtig kombinieren.

Sehen Sie die zwei anderen Video-Interviews von Benjamin Aunkofer:

Interview Benjamin Aunkofer – Datenstrategien und Data Teams entwickeln!