Montag, 10. Juli 2017

PSG Performance Driven Development für den SQL Server

In den letzten Monaten wurde ich häufig danach gefragt, was denn dieses Performance Driven Development (PSG PDD) eigentlich sei? Und welche Technologien wir damit meinen?

In erster Linie verstehen wir unter der Performance Driven Development Methode weniger einen Technologie Ansatz, als vielmehr einen Rahmen an Maßnahmen, damit das Thema Performance im Laufe einer Software Entwicklung den Stellenwert er- und behält, welcher bei Projektstart als notwendig erachtet wurde.

Entstanden ist die Idee zu der Methode u.a. aus dem Feedback unserer Schulungskunden.

Es wurde uns zwar attestiert, dass die Teilnehmer unserer Workshops und Schulungen einen deutlichen Knowhow Fortschritt machen würden, dennoch wäre es für den einzelnen Entwickler immer wieder schwierig sei neues Wissen auch so einzusetzen, dass die Projekte bzw. Produkte davon wirklich partizipieren. Der Alltag von Entwicklern sei ja stark getrieben durch ein agiles geprägtes Umfeld und Stakeholder, für die diese grundlegenden technischen Storys erstmal nicht im Fokus stehen. Performance Themen während einer Entwicklung kann man weder sehen noch erleben. Das ist häufig etwas für „Später“. Und oft ist der generelle Tenor in Projekten, dass das eine Grundschuld sei, welche natürlich ein Entwickler immer im Blick haben muss.

In der Vergangenheit haben Endkunden durch regelmäßige Wiederholungen ihrer Schulungsmaßnahmen versucht diesen Effekten entgegenzuwirken. Ich möchte mich ja nicht über Umsatz beklagen, aber es ist nur bedingt eine Freude, wenn die Teilnehmer dann wiederholt anmerken, dass sie für das Thema dann im Projekt eigentlich keine Zeit hätten, weil es einfach keinem wichtig sei. Und wenn es später in den ersten Tagen in der Produktion zu Problemen kommt, dann ist es meist auch schon zu spät und man erhofft sich Wunder durch ein nachträgliches Tuning.

Ein weiterer Aspekt, welcher uns durch das Feedback der Schulungskunden und Teilnehmer erreichte, war, dass mit jeder neuen SQL Server Version (und damit oft auch Schulung) sich das quasi magische Features erhofft wird, damit der SQL Server endlich mal schnell wird.

Zwar wird der SQL Server mit jeder Version natürlich leistungsfähiger und bringt noch mehr Intelligenz mit, um Performance Herausforderungen zu begegnen, dennoch lassen sich diese immer noch durch viele gängige Methoden in der Entwicklung quasi unbemerkt komplett aushebeln. Des Weiteren steht natürlich die Frage im Raum, wie man denn neue Technologien wie zum Beispiel in-Memory OLTP in Abteilungen bringen soll, wenn für das Thema Performance eigentlich keine Zeit ist. Hier beißt sich die Katze in den Schwanz.

Was heißt das jetzt konkret?

Der Performance Driven Development besteht auf der einen Seite aus einer Reihe von Schulungen, um Entwicklern Hintergründe des SQL Servers so aufzubereiten, dass diese ein notwendiges Verständnis bekommen, wie sie Einfluss auf die zu erwartende Geschwindigkeit ihrer Lösung bekommen.

Diese Schulungen haben wir so ausgestaltet, dass wir unterschiedliche Module in wiederum aufeinander aufbauenden Leveln anbieten.

Ein Ziel war, dass wir die Teilnehmer nicht mit Details überfrachten und sie damit komplett irritiert und bewegungsunfähig zurücklassen.

Auf der anderen Seite gibt es Schulungsmodule, welche sich an unterschiedliche Rollen im Performance Driven Development Konzept wenden. Damit adressieren wir auch Projektleiter, Product Owner usw. Inhalt dieser Module sind weniger technische Details über eine Implementierung, sondern vielmehr Methoden zur Definition von Performance generell und wie diese im Projektverlauf kontinuierlich gemessen werden kann. Eine wesentliche Frage, welche wir im Verlauf dieser Module klären, ist, wie man den Aspekt Performance so beschreibt, dass alle Projektbeteiligten später über dasselbe Erlebnis bzw. Ergebnis sprechen.

Ein Ziel dieser Module ist, dass Projektvereinbarungen so formuliert werden können, dass es keine „Missverständnisse“ bzgl. der erwarteten Performance und der Skalierbarkeit einer Lösung geben wird. Erwartungen hinsichtlich der Möglichkeiten aber auch Grenzen müssen klar in ein System gebracht werden.

Als wichtig hat sich die Balance zwischen der Vermittlung eines konzeptuellen Rahmens als auch konkreter Maßnahmen erwiesen.

Für jedes dieser Module im jeweiligen Niveau bieten wir mittlerweile auf Wunsch auch eine Zertifizierung der erworbenen Kenntnisse an. Damit bieten wir sowohl einen Anreiz für die Teilnehmer als auch Kontrolle für die Stakeholder der Maßnahme an.

Ein weiterer Aspekt bei der Planung der Umsetzung von PSG PDD sind die Teamgrößen in den Unternehmen. Es macht einfach keinen Sinn mit einem generischen Rollenmodell sowohl Teams 5 als auch von 25 Entwicklern zu adressieren.

Ich hoffe, dass ich damit einen kurzen Überblick über den PSG PDD Ansatz geben konnte. In den folgenden Tagen werde ich gern auf die unterschiedlichen Inhalte eingehen, da ich der Meinung bin, dass dieser oder auch vergleichbare Ansätze nötig sind, um den heutigen Anforderungen an Entwicklungsteams zu entsprechen.

Mittwoch, 28. Juni 2017

Was ist eigentlich SQL Server Performance? Und überhaupt?

Neulich wurde ich gefragt, was ich denn die letzten Monate so gemacht hätte. Es wäre ja recht ruhig um mich herum geworden.Keine Sorge! Natürlich bin ich dem Microsoft SQL Server und der Data Platform treu geblieben, auch wenn ich wieder öfters über den Tellerrand blicken durfte.

Womit habe ich mich also die letzten Monate so beschäftigt?

Zum einen bin ich in letzter Zeit immer wieder jenseits der reinen Vermittlung von technischen Features unterwegs. Vielmehr zeigt sich, dass unsere Kunden davon profitieren, dass wir unsere Technologie- und Projekt-Erfahrung in vermittelbare Konzepte und Prinzipien überführt haben. Also neben dem “Was gibt es?” kommen wir im Rahmen unserer Methoden Schulungen immer häufiger auf das “Warum?” und “Wie im Team?” zu sprechen. 

Zum anderen führen wir immer mehr Microsoft Kunden an die “neuen” Themen heran. Wir konzentrieren uns dabei zurzeit auf Azure IaaS und In-Memory OLTP. Wesentlich für uns ist dabei wiederum die Einsicht, dass die reine Vermittlung von Features wenig Wirkung in den Abteilungen (DEV/DBA) zeigt. Daher haben wir diese Technologien in unsere Methoden Welt integriert, um eine möglichst hohe Wirtschaftlichkeit für Microsoft Kunden zu erreichen.

Performance?

Konkret ging das dabei häufig um Fragestellungen rund um die Performance von SQL Server Applikationen. Im Rahmen dieser Tätigkeiten zeigte sich, dass der Begriff Performance oft nur sehr schwammig definiert ist.

Es soll halt schneller werden! Nur mit so einer Aussage bzw. so einem Ziel lässt sich in einem Projekt (agil oder nicht) wenig erreichen.

Vielmehr zeigte sich, dass es diverse Sichtweisen auf die Verfügbarkeit und Performance von Lösungen gibt, welche einen oder mehrere SQL Server nutzen.

Unteranderem distanziere ich mich immer mehr von dem Begriff des häufig bemühten “Tunings”, da es sowohl Entwicklern als auch Budget Verantwortlichen suggeriert, dass ein schlechtes Design später noch durch “ein paar zusätzliche Indizes” zu retten sei.

Mittlerweile offerieren wir hier eine Methode, welche wir als “PSG Performance Driven Development” (PSG PDD) bezeichnen.

Neben der Vermittlung von grundlegenden Fakten über die Funktionsweise der relationalen Datenbank Engine, setzen wir auch einen deutlichen Schwerpunkt auf die Planbarkeit der Verfügbarkeit einer Lösung im späteren Betrieb. Innerhalb von Entwicklungsteams benennen wir Rollen, welche u.a. für die kontinuierliche Durchführung von realistischen Lasttests der Lösung verantwortlich sind.

Ein wenig dazu habe ich bereits in meinen Vorträgen zu dem Thema “7 wichtige Fakten, die jeder Entwickler über den SQL Server wissen sollte” in den Usergroups gezeigt.

Neben Technologie Knowhow und Methoden Kompetenz spielen auch weitere Entwicklungswerkzeuge eine Rolle bei PSG PDD. Dazu gleich noch mehr.

Komplexität?

Da die Nutzung von immer mehr Möglichkeiten im SQL Server und den verwandten Microsoft Diensten auch zu einer deutlichen Steigerung der Komplexität von Lösungen und Umgebungen führen, haben wir uns über die letzten Jahrzehnte auch immer wieder dieses Themas annehmen müssen. Der Reduzierung von Komplexität bei gleichzeitiger Steigerung der Wirksamkeit innerhalb der Prozesse und Wirtschaftlichkeit in der Betreuung.

Als Beispiel sei ein Projekt kurz beschrieben, welches wir schon vor gut einem Jahrzehnt durchführten. Damals sprach uns die Microsoft an, ob wir bei einem internationalem Konzernkunden unterstützen können, welcher eine komplexe Data Management Lösung auf über 1000 SQL Servern weltweit betrieben hat. Es stellte sich schnell heraus, dass die existierende Lösung quasi nicht mehr zu kontrollieren war. Dennoch musste der Betrieb aufrecht erhalten werden, da ein Neudesign auf Basis anderer Technologien und Konzepte nicht möglich war.

Ein klassischer Fall.

Wir haben damals einen Lösungsansatz zum Einsatz gebracht, welchen wir bereits in anderen Projekten erfolgreich eingesetzt haben. Wir nahmen die Umgebung und überführten diese in ein mehrstufiges Repository. Damit nahmen wir sehr viel Komplexität aus dem eigentlichen Betrieb und schufen Werkzeuge, welche die Umgebung zum Teil auch selbständig überwachten und Probleme sofort von sich aus löste.

Diese Methoden haben wir über die Jahre hinweg weiter entwickelt und vielfach eingesetzt. Mittlerweile nennen wir die Muster und Methoden “PSG Repository Driven Design” (PSG RDD).

Zum Teil zeigte ich bereits vor einigen Jahren Muster aus dieser Methode in meinem Vortrag “The Developer Side of the Microsoft Business Intelligence stack”. Wobei die RDD Methode bei weitem nicht nur in Business Intelligence Projekten zum Einsatz gekommen ist.

In letzter Zeit konnten wir damit u.a. komplexe ELT Strecken für Kunden realisieren. Des Weiteren kam die Methoden bei einem umfangreichen Banken Projekt zum Einsatz, um eine über Jahrzehnte gewachsene SQL Server Umgebung wieder unter Kontrolle zu bekommen.

Häufig nutzen wir RDD auch, um umfangreichen Replikationstopologien zu verwalten oder auch, um ebenso große Change Data Capture (CDC) Implementierungen wieder verwaltbar zu gestalten.

Für uns ist dieser deskriptive Ansatz zur Verwaltung von Datenbanken und Servern mittlerweile alltäglich geworden.

Deskriptive IT mit Azure

Damit kommen wir zu einem weiteren Thema mit dem wir uns in letzter Zeit immer intensiver beschäftigt haben: Der Cloud. Speziell natürlich Microsoft Azure.

Gerade das Thema Azure IaaS ist für uns zurzeit sehr interessant. Sowohl für PSG PDD als auch für PSG RDD nutzen wir immer häufiger auch Komponenten in Azure, um temporär notwendige Ressourcen kostengünstig und schnell zu allokieren.

Azure IaaS ist für uns deskriptive IT in Reinform und lässt sich damit ganz hervorragend in unsere Methoden Welt integrieren.

Als ein Beispiel sei die automatische Provisionierung und Deprovisionierung von Umgebungen in Azure für automatische Lasttests genannt, um kontinuierlich die Belastbarkeit von Lösungen zu prüfen und zu dokumentieren. Damit passt Azure auch sehr gut zu unserem Performance Driven Development Ansatz. Selbst wenn die eigentliche Entwicklung und auch der Betrieb der Lösung zurzeit noch on-prem stattfindet.

Dokumentation vs. Inventarisierung

Als ein letztes Thema, welches mich die letzten Monate stark in Beschlag genommen hat, sei noch Dokumentation von SQL Server Umgebung und Applikationen genannt.

Häufig werden wir aufgefordert, um im Auftrag eines Kunden eine Software Entwicklung zu auditieren (extern oder auch intern). Dabei geht es u.a.um die Skalierbarkeit der Lösung hinsichtlich Performance und Ausfallsicherheit.

Einer häufigsten Gründe für eine Einbeziehung unseres Hauses ist der kontinuierliche Wunsch des Software Lieferanten nach immer größerer Hardware, da ja auch die Datenmenge stetig wächst.

Dem muss ich entgegensetzen, dass meiner Meinung nach die Größe einer Datenbank keinen Einfluss auf die Performance einer Lösungen haben sollte. Falls dem so ist, dann lässt dieses meist auf technische Schulden im Design der Lösung schließen.

Ähnlich steht es um die Anzahl von gleichzeitigen Anwendern, wobei ich dieses Argument noch ein klein wenig mehr nachvollziehen kann, da die wenigsten Entwicklungsteams bisher die Möglichkeiten hatten, um echte Lasttests zu fahren.

Bei diesen Audits stellen wir immer wieder fest, dass das Thema Dokumentation und Nachvollziehbarkeit stiefmütterlich betrieben wird. Herausforderungen wie die Planbarkeit von Verfügbarkeit oder gar DevOps rücken damit oft in weite Ferne.

Daher wurden wir aufgefordert Vorschläge zu unterbreiten, wie diesem Mängeln zu begegnen sei. Die daraus entstandenen Dokumentationskonzepte sind wiederum aufgegangen in PSG PDD als auch im PSG RDD.

Eigene Werkezuge

Wie bereits angedeutet, haben wir uns auch mit interner Software Entwicklung beschäftigt.

Dabei haben wir einen Tool Stack entwickelt, welcher sowohl die Performance als auch die Repository Konzepte unterstützt.

Es handelt sich hier um eine Sammlung von Monitoring Werkzeugen, welche unseren PDD Ansatz nahtlos unterstützen. Dazu kommen Werkzeuge für Lasttests, welche sich auch ganz hervorragend in Azure betreiben lassen, um wirklich realistische Last regelmäßig auf einer in der Entwicklung befindlichen Lösung zu erzeugen.

Diese Tools kamen bereits erfolgreich bei einigen unserer größeren Kunden bzw. komplexeren Projekte zum Einsatz.

Wie geht es weiter?

In den nächsten Wochen möchte ich die ruhige Sommerzeit nutzen, um das eine oder andere Thema mal wieder im Detail zu erläutern und der SQL Server Community damit auch wieder Anregungen aus meinem Alltag zu geben.