Auch gestern durfte ich wieder auf einer internationalen Community-Veranstaltung – dem Cloud Summit – über Azure Arc-enabled Data Services sprechen, natürlich in der Hauptsache wie man eine Azure SQL Managed Instance im eigenen Rechenzentrum betreiben kann. Wie bereits auf dem DataSaturday #14 in Oslo, habe ich bei den verschiedenen Möglichkeiten von Azure Arc begonnen und habe die einzelnen Komponenten der Umgebungen vorgestellt, was wird benötigt und wie kann man dies recht einfach deployen. Zum Ende hin gab es wieder eine ausführliche Demonstration wie man einen Data Controller auf Kubernetes deployen kann und wie man dann mittel Azure Data Studi eine Managed Instance oder PostgreSQL Hyperscale ausrollen kann.
Ich habe mich sehr gefreut ein Teil dieser mehrere Tage gehenden Veranstaltung Cloud Summit 2021 zu sein, der Vortrag selber war aus meiner Sicht ein sehr gelungener, alles hat funktioniert, die Zeit wurde etwas knapp aber auch daran kann man zukünftig arbeiten/nachbessern.
Ich wollte mit diesem kurzen Beitrag nur schnell die Slides online stellen und mich bei den Organisatoren und Sponsoren des Cloud Summits recht herzlich bedanken !
Björn arbeitet in Hamburg als Senior Consultant – Microsoft Data Platform und Cloud bei Kramer&Crew. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und DataGrillen teil und organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.
Heute war es soweit – ich durfte endlich einmal auf dem Data Saturday (ehemals SQLSaturday) in Oslo sprechen… das endlich lag nicht an den Organisatoren sondern eher an mir bzw an der Pandemie, da ich mich bis 2020 nicht getraut hatte, Vorträge auf Englisch zu halten, hatte ich auch keine Sessions für Oslo eingereicht. Am liebsten wäre ich natürlich vor Ort gewesen, denn Norwegen bzw Oslo sind wunderschön, ich kenne mittlerweile auch mehrere Community-Member in der Region die ich nun auch schon lange Zeit nicht mehr gesehen habe, aber es musste dieses Jahr erst einmal virtuell bleiben, vielleicht ja im nächsten Jahr wieder in person.
Nun aber zu meinem Vortrag zur Einführung in Azure Arc bzw Azure Arc Data Services, um den es am Samstag, den 04. September 2021 um 9:45 ging. Azure Arc selber ist erst einmal eine Plattform, ein Service den Microsoft in Azure bereitstellt, um die Verwaltung von verschiedenen Umgebungen – Hardware, virtuelle Maschinen, Windows, Linux, AWS, GCP oder was auch immer – in einer zentralen Stelle zu verwalten und zu administrieren.
Einführung in Azure Arc
Damit kann man nun beispielsweise seine on-premise Windows oder Linux Server mit dem Azure Portal verbinden, um diese von dort aus zu administrieren. Oder auch von der Vielzahl an Services aus der Cloud wie zum Beispiel Security oder Compliance, diese Benefits bringt eben Azure Arc mit sich, in dem man seine on-premise Systeme in die Analysen dieser Azure-Services mit einbinden kann. Des weiteren kann man auch Automatisierungen wie zum Beispiel Patching oder Backups aus dem Azure Portal oder anderen Azure Services heraus erstellen und administrieren, was einen erhebliche Vorteil in der Vereinheitlichung der Systeme und Prozesse bedeutet.
Und das nicht nur mit on-premise Servern bzw Systemen sondern eben auch Multi-Cloud und auch “disconnected” Systemen, auch mit Kubernetes Clustern oder SQL Servern
Azure Arc-enabled servers
Azure Arc-enabled Kubernetes
SQL Server auf Azure Arc-enabled Servers
Alle Applikationen, Systeme und Umgebungen zentral vereint
Azure Arc Data Services
Unter Azure Arc Data Services versteht man nun die Möglichkeit eine Azure SQL Managed Instance oder eine Postgres Hyperscale auf einem “x-beliebigen” Kubernetes Cluster zu betreiben, ob dieses Kubernetes Cluster nun im eigenen Rechenzentrum oder in einer anderen Cloud steht, ist erst einmal egal, Hauptsache es handelt sich um ein CNCF-zertifiziertes Kubernetes-Cluster.
Um aber eben eine Managed Instance in seinem eigenen Rechenzentrum zu betreiben, muss man mehrere Schritte befolgen… zum einen sollte man das Kubernetes-Cluster zu einem Azure Arc eneabled Kubernetes machen, zum anderen muss man einen “Connector/Agent” auf diesem Cluster ausrollen, den Data-Controller. Dieser Data Controller stellt die Schnittstelle zwischen Azure, dem Azure Portal und der SQL Managed Instance her. Nun kann man über verschiedene Wege – Azure Portal, Azure CLI oder Azure Data Studio – auf diesem Cluster eine voll funktionsfähige SQL Managed Instance deployen und nutzen.
Deployment einer Azure SQL Managed Instance auf einem Data Controller auf dem eigenen Kubernetes Cluster
Aus persönlicher Sicht, ist dies eine großartige Geschichte, einen zentralen Anlaufpunkt für alle genutzten Services und Applikationen zu haben und somit auch die zusätzlichen (Sicherheit bringenden) Features aus Azure auf allen Systemen zu nutzen. Alles in allem ein Zugewinn für das Unternehmen!
Wenn man selber diese Möglichkeit des Rollouts von Azure Data Services ausprobieren möchte, dann kann ich jedem nur empfehlen sich mit den Jumpstart Szeanarien von Microsoft zu beschäftigen, hier werden vorgefertige Umgebungen ausgerollt mit denen man dann problemlos testen kann, was wie wo funktioniert:
Björn arbeitet in Hamburg als Senior Consultant – Microsoft Data Platform und Cloud bei Kramer&Crew. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und DataGrillen teil und organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.
Eigentlich hätte ich diesen Beitrag schon vor Jahren mal schreiben sollen ;-), um die Historie bzw die Entstehungsgeschichte dieses Blogs zu beleuchten. Aber wie heißt es so schön… es ist nie zu spät.
Damals hatte ich meine ersten Initiativen und Aktivitäten mit der deutschen SQL Server Community unternommen, die ersten Veranstaltungen besucht und die ersten Kontakte geknüpft und musste leider feststellen, dass meine Kenntnis vom SQL Server auch nach mehr als 10 Jahren eher gering ausfiel. Dies gefiel mir selber nicht und ich habe mir das Ziel gesetzt mich mehr mit dem Produkt zu beschäftigen, also im Grunde genau die Geschichte warum ich in der Community aktiv bin. Zu der zeit war ich als Datenbank-Administrator beschäftigt und habe gemeinsam mit meinem Kollegen Thomas, die SQL Server unserer Kunden betreut. Thomas wusste aus anderen Bereich zum SQL Server viel und ich wusste ja auch schon viel, so haben wir uns wunderbar ergänzt. Gemeinsam wollten wir diesen Blog betreiben und über unsere täglichen Erlebnisse, Probleme oder Herausforderungen schreiben. Da wir beide – in einem größeren Team verteilt über Deutschland – aus Hamburg kamen und es um unsere Hauptaufgabe – den SQL Server – ging, war die Suche nach einem Namen relativ einfach…
Aufgrund meiner – damals noch aktiven Selbstständigkeit – war ich bereits im Besitz eines entsprechenden Webspace und die Domäne “SQL-aus-Hamburg.de” war schnell registriert. Der erste Blogbeitrag ließ auch nicht lange auf sich warten, dann wurde es etwas ruhiger 🙁 Wir hatten uns das wahrscheinlich einfacher vorgestellt, die Arbeit wurde mehr… ich kann nicht mehr genau sagen, warum wir nichts geschrieben haben… vielleicht war es oder wir damals einfach noch nicht so weit… Thomas hatte immer gute Ideen und hat mir sozusagen die Überschriften geliefert… aber leider nie selber geschrieben (soll kein Vorwurf sein!)… und dann kam alles anders… Leider ist Thomas unerwartet und plötzlich verstorben, ich musste und habe dann diesen Blog unter demselben Namen weitergeführt.
Für mich ist dieser Blog im Grunde immer noch, siehe die letzten Posts zum Azure SQL Database Refresh, nur ein Notizbuch, in dem ich meine eigenen Erfahrungen für mich selber Revue passieren lasse, um sie vielleicht irgendwann doch einmal herauszusuchen oder mich daran zu erinnern, wann ich was wie erfolgreich lösen konnte.
Warum SQL-aus-HH ???
In den sozialen Medien findet man mich entsprechend auch unter @SQL_aus_HH, für den deutschsprachigen Leser überhaupt kein Problem eine Verbindung zwischen Hamburg und HH zu ziehen… ursprünglich hatte ich auch nie mit dem Gedanken gespielt, dass ich irgendwann auch mal englischsprachige Beiträge schreibe oder sogar Vorträge auf internationalen Veranstaltungen halte… daher hier noch einmal zur Verdeutlichung für die “Ausländer”.
Hamburg ist eine Hansestadt und trägt daher auf dem deutschen KFZ-Nummernschild die Abkürzung HH für “Hansestadt Hamburg“.
Bereits im Mittelalter verdienten sich Kaufleute mit dem Fernhandel eine goldene Nase. Besonders erfolgreich war die Hanse. So nannte sich vor etwa 700 Jahren ein Bündnis aus Städten und Kaufmannsverbänden. Der Hansebund wurde geschlossen, um den Handel zwischen den Mitgliedern, den Hansestädten, zu vereinfachen. Damals erschwerten zahlreiche Zölle, verschiedene Währungen und Maßeinheiten den Fernhandel. […] Letztendlich trugen nur noch Hamburg, Bremen und Lübeck offiziell den Titel einer Hansestadt. Hamburg und Bremen haben ihre hanseatische Eigenständigkeit zum Teil sogar bis heute bewahrt. Sie sind – neben Berlin – die einzigen deutschen Städte, die gleichzeitig ein eigenes Bundesland sind. Auch ihre Autokennzeichen weisen auf den mittelalterlichen Städtebund hin: HH steht für die Hansestadt Hamburg und HB für die Hansestadt Bremen.
Da dieser Blog damals von zwei Personen geführt werden sollte, hatte ich mir auch Gedanken über einen Namen für meinen “persönlichen Auftritt” gemacht bzw wollte im Zusammenhang mit einem Favicon für den Blog etwas “kreativer” sein… als “Nord-DBA”… bitte fragt mich nicht nach den Gründen/Gedanken, die zu diesem Namen geführt haben… ich kann es schlicht weg nicht mehr sagen, aber seit gut 10 Jahren gibt es eben dieses Favicon als “Erkennungszeichen” für diesen Blog.
Solltet ihr noch Fragen zu der Entstehungsgeschichte meines Blogs haben… so schreibt mich einfach an.
Björn arbeitet in Hamburg als Senior Consultant – Microsoft Data Platform und Cloud bei Kramer&Crew. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und DataGrillen teil und organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.
Jeder meiner Kunden hat sich irgendwann mal die Frage gestellt oder zumindest sollte er sich diese Frage stellen, “brauche ich für meine SQL Server oder einen meiner SQL Server eine gewisse Hochverfügbarkeit”. Leider enden diese Überlegungen immer bei der Frage nach dem Budget… natürlich kosten solche HA-Lösungen mehr Geld, je nach Auswahl der Lösung und der Ausstattung der Umgebung müssen entsprechende Lizenzen zur Verfügung gestellt werden. Aber wenn man die im “worst-case” anfallenden Kosten während oder durch einen Ausfall dagegen rechnet, sollte man ganz klar zur Einsicht kommen, dass diese Kosten vertretbar sind.
Ich durfte heute auf der Data Blaster Community Conference 2021 einen Vortrag dazu halten (Vielen Dank liebe SQLPASS Deutschland), hier kommt eine kleine Zusammenfassung aus meinem Vortrag.
Ich habe direkt am Anfang dargestellt, wie hoch solche Kosten sein können, hierzu habe ich mit Hilfe eines Online-Rechners von Percona eine beispielhafte Rechnung aufgemacht. Der SQL Server fällt für 1-2 Stunden aus, 5 Mitarbeiter sind an dem Restore beschöftigt, jeder von ihnen verdient 100.000 pro Jahr, 100 weitere Mitarbeiter können nicht richtig arbeiten, diese verdienen durchschnittlich 50.000 pro Jahr. Im folgenden Screenshot könnt ihr die Zahlen lesen, die unter Umständen während des Ausfalls, bei der Behebung und deren Nachwirkungen entstehen können.
Bei Gesamtkosten von rund 8.000.000 Euro für einen Ausfall eines SQL Servers von rund 2 Stunden, würde ich mir schon vorher überlegen, ob ich z.B. 250.000 Euro im Rahmen der Installation mehr ausgebe, um einen zweiten Server hinzustellen und mit den jeweiligen Lizenzen auszustatten. Aber wie können solche Hochverfügbarkeiten im SQL Server Umfeld aussehen, dazu komme ich in den nächsten Abschnitten, aber erst einmal sollten wir die Überschriften klären… 😉
Hochverfügbarkeit vs Desaster Recovery
Die Definition von Hochverfügbarkeit auf wikipedia.de lautet wie folgt :
Hochverfügbarkeit (englischhigh availability, HA) bezeichnet die Fähigkeit eines Systems, trotz Ausfalls einer seiner Komponenten mit einer hohen Wahrscheinlichkeit (oft 99,99 % oder besser) den Betrieb zu gewährleisten. In Abgrenzung zur Fehlertoleranz kann es bei dem Betrieb im Fehlerfall zu einer Unterbrechung kommen.
Im Vergleich dazu die Definition von Desaster Recovery
Der englische Begriff Disaster Recovery (im Deutschen auch Katastrophenwiederherstellung oder Notfallwiederherstellung genannt) bezeichnet Maßnahmen, die nach einem Ausfall von Komponenten in der Informationstechnik eingeleitet werden. Dazu zählt sowohl die Datenwiederherstellung als auch das Ersetzen nicht mehr benutzbarer Infrastruktur, Hardware und Organisation. Umfassender als Disaster Recovery ist der Begriff Business Continuity, der nicht die Wiederherstellung der IT-Dienste, sondern unterbrechungsfreie Geschäftsabläufe in den Vordergrund stellt.
Bei der Hochverfügbarkeit geht es eben mehr darum, die eintretende Zeit des Ausfalls, also die Downtime möglichst gering zu halten, so dass alle angeschlossenen Systeme möglichst ohne Datenverlust und manuellen Eingriff schnellstmöglich weiterlaufen. Hierzu sollte man sich vor der Installation natürlich Gedanken zur Prozessgestaltung, den zu erreichenden Zielen und der Notwendigkeit zu machen.
Was braucht das Business?
Was kostet es das Business wenn sie nicht mehr arbeiten können?
Gibt es ggfs einen Kompromiss zwischen Technik und Business? Müssen es wirklich die minimalsten Ausfallzeiten (< 10 Sekunden) sein oder reichen vielleicht auch maximale Ausfallzeiten von kleiner einer Minute?
Was kann die Technik überhaupt abbilden? Wissen, Prozesse u.ä.
Welceh rechtlichen Rahmen müssen ggfs eingehalten werden?
Und erst wenn man diese Fragen vorher geklärt hat, kann man sich Gedanken über die eigentliche Hochverfügbarkeitslösung machen und wie diese implementiert werden kann/soll.
Das AlwaysOn Failover-Cluster (FCI)
Kommen wir zu einer der möglichen Lösungen zur Realisierung der Hochverfügbarkeit des SQL Servers innerhalb des eigenen Rechenzentrums, das Windows Failover Cluster (im Grunde identisch zu einem Linux Failover Cluster, hier sollte man sich an die Angaben/Dokumentation der jeweiligen Distribution und eingesetzten Cluster-Software halten).
Initial erstellt man aus zwei Windows Servern mit dem zusätzlich installierten Failover-Cluster Feature ein Windows Failover Cluster, grob gesagt, man verbindet beide Server logisch (und im AD) miteinander. Beide kennen sich und wissen nun, dass sie zusammengehören und tauschen mehrere entsprechenden Health-Status Informationen untereinander aus. Dieses Windows Failover Cluster erhält eine eigene IP und einen eigenen DNS Namen, sowie ein Cluster-Named-Object im AD, dieses CNO “steuert” später das Cluster im AD.
Zu den notwendigen Storage-Requirements kann ich hier wenig sagen, da dies von den jeweiligen Umgebungen abhängt… SAN, NAS, NFS, HCI oder ähnliches, auf jeden Fall muss es sich um einen Storage handeln, der in der Lage ist beiden Servern Zugriff zu gewähren. Microsoft schreibt dazu folgendes:
Storage
Im Gegensatz zur Verfügbarkeitsgruppe muss eine FCI freigegebenen Speicher zwischen allen Knoten der FCI für Datenbank und Protokolle verwenden. Der freigegebene Speicher kann die Form von WSFC-Clusterdatenträgern, direkten Speicherplätzen (Storage Spaces Direct, S2D), Datenträgern auf einem SAN oder Dateifreigaben auf einem SMB aufweisen. Auf diese Weise verfügen alle Knoten in der FCI immer dann über die gleiche Sicht der Instanzdaten, wenn ein Failover auftritt. Dies bedeutet jedoch, dass der freigegebene Speicher das Potenzial hat, die einzelne Fehlerquelle zu sein. Die FCI hängt zudem von der zugrunde liegenden Speicherlösung ab, um Datenschutz sicherzustellen.
Nun kann man mit der eigentlichen Installation des SQL Servers beginnen, auf dem Node 1 wird die Basis-Installation für das SQL Server Failover Cluster geschaffen “Erstellung eines Failover-Clusters”, während auf dem Node 2 “nur” ein Knoten zu einem bestehenden SQL Server Cluster hinzugefügt wird.
Je nach Ausgestaltung dieses Cluster – nur eine Instanz oder mehrere Instanzen – müssen SQL Server Lizenzen beschafft werden. Hierbei kann man zwischen zwei Betriebsmodis unterscheiden, aktiv/passiv oder aktiv/aktiv. Bei aktiv/passiv dürfen die SQL Server Instanzen immer nur auf einem Knoten des Clusters laufen, im Fehlerfall für einen begrenzten Zeitraum auch auf beiden Knoten. Bei aaktiv/aktiv können beide Knoten gleichermaßen und zeitlich unbegrenzt voll genutzt werden, was gerade bei mehreren Instanzen unter Umständen Sinn machen kann, da man so eine gewisse Last-Aufteilung vornehmen kann.
Sollte nun ein Knoten im Cluster ausfallen, so kann der zweite Knoten vereinfacht gesagt nicht mehr der anderen Seite kommunizieren und versucht schnellstmöglich die ausgefallenen Services auf seine Seite zu holen und dort zu starten.
Ein hybrides Szenario ist hierbei leider nicht möglich, da es keine Möglichkeit der gesharten Ressourcen zwischen on-premise und Cloud gibt. Aber man kann alternativ auch ein Failover-Cluster in der Azure Cloud aufbauen. Hierzu benötigt man eine Proximity Placement Group, entsprechende Managed Disks mit aktiviertem “Shared Storage” Feature und die beschriebenen zwei virtuellen Maschinen, die eigentliche Installation und Betrieb ist im Grunde identisch.
Mehr zu Hochverfügbarkeiten des SQL Servers kommt demnächst in einem zweiten Beitrag.
Björn arbeitet in Hamburg als Senior Consultant – Microsoft Data Platform und Cloud bei Kramer&Crew. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und DataGrillen teil und organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.
Am gestrigen Dienstag durfte ich zwei Sessions auf der aMS Germany 2020 halten, ein virtueller Event organisiert durch mehrere Community-bekannte Größen wie Sascha Fredrich und Martin Gudel. Diese Zusammenarbeit zeigt auch sehr schön, dass es möglich ist solche Veranstaltungen zu organisieren, auch wenn man 100te Kilometer auseinander wohnt. Sascha im Süden von Deutschland (also zumindest für mich – Süden 😉 ) und Martin in Hamburg. Dem Organisationsteam gehörten auch noch Patrick Guimonet an, sowie Mr. OneDrive Hans Brender, gemeinsam haben Sie einen Event erstellt, der insgesamt in7 parallelen Tracks mit mehr als 50 Session beinhaltet.
meine erste Session – Einstieg in Azure SQL Managed Instance
In dieser Session ging um einen ersten groben Einblick, was die Azure SQL Managed Instance ist, was sie kann und was man für sein Geld bekommt. Begonnen habe ich mit einem ersten Überblick welche Möglichkeiten Azure SQL alles bietet, zum Beispiel das Deployment eines normalen SQL Server in einer Azure virtuellen Maschine oder als Azure SQL Database in den unterschiedlichen Ausprägungen. Weiter ging es mit den verschiedenen Fakten zu aktuellen Features und Fakten rund um die Managed Instance und woran man bei der Vorbereitung und Planung eines Deployments denken sollte.
In der Demo bin ich einmal ein exemplarisches Deployment einer Azure SQL Managed Instance über das Portal durchgegangen und habe zu den wichtigsten Konfigurationspunkten etwas erklärt, damit alle Teilnehmer der Session verstehen was wichtig ist und was man beachten sollte. In meiner Demo-Umgebung konnte ich abschließend noch zeigen, wie sich die neue Instanz sowohl im SQL Server Management Studio als auch im Azure Data Studio darstellt.
Fragen wurden leider keine gestellt, was darauf hindeutet, dass mein Vortrag verständlich und nicht zu kompliziert war. 😉
meine zweite Session – Change your skills – Überblick über aktuelle Lernpfade und Zertifizierungen
Da ich mich in diesem Jahr verstärkt um das Thema Zertifizierungen gekümmert habe, vor allem meine eigenen, und immer wieder in Gesprächen feststellen musste, das viele hier große Fragen haben, wollte ich hier einmal Licht ins Dunkel bringen. Also ging es in diesem Vortrag um die verschiedenen – unter anderem kostenfreien – Möglichkeiten wie man zum einen Wissen aufbauen kann zu den aktuellen Themen im Microsoft Umfeld, zum anderen wie man mit diesem Wissen sich die dazugehörigen Prüfungen vorbereiten kann.
Microsoft bietet mit Microsoft Learn ein sehr gute Plattform und vor allem in Zeiten der Corona-Pandemie erweiterte Möglichkeiten zur Weiterbildung, wie man hier seinen eigenen Bildungsweg findet und welche Inhalte für wen relevant sind, sowie was man mit diesem Wissen erreichen kann, darum ging es in diesem Vortrag. Ich wollte einen Überblick über die unterschiedlichen Plattformen und Wege aufzeigen mit denen man sich den neuen Herausforderungen in der aktuellen Projektsituation bewähren kann oder eben auf neue, zukünftige Aufgaben vorbereiten kann.
Gerade heute habe ich erst wieder ein längeres Gespräch mit einem Kollegen gehabt, der mich zu den Details in der Vorbereitung und Durchführung einer Microsoft Prüfung aus dem Home-Office heraus befragte. Ich erklärte im die wichtigen Punkte beim System-Test, dem CheckIn-Prozess und auf was man achten muss, wenn man die Prüfung aus den eigenen vier Wänden angehen möchte. Denn Microsoft hat diese Möglichkeit eingeräumt bzw ausgeweitet, damit viele neue Teilnehmer – trotz geschlossener Prüfungscenter – und gerade bei Kurzarbeit oder Unternehmungsschließung sich auf neue Abenteuer vorbereiten kann.
Hierzu gibt es auch eine neue Zusammenarbeit zwischen Microsoft und Linkedin, bei der es darum geht, Arbeitssuchenden oder Umschulungswilligen eine Plattform zu bieten, auf einfachen und unkomplizierten Wegen sich Wissen anzueignen und so sich Vorteile auf dem Arbeitsmarkt zu verschaffen.
Mir haben diese beiden Vorträge – sowohl in der Vorbereitung und der Durchführung – sehr viel Spaß gemacht, ich hoffe ich konnte zumindest einem Teilnehmer ein wenig helfen. Vielen Dank den Organisatoren und Sponsoren der #aMSGermany2020.
Björn arbeitet in Hamburg als Senior Consultant – Microsoft Data Platform und Cloud bei Kramer&Crew. Er nimmt regelmäßig an den PASS Regionalgruppen Treffen in Hamburg, den Veranstaltungen der PASS wie SQLSaturday und DataGrillen teil und organisiert in Hamburg das Azure Meetup. Er interessiert sich neben den Themen rund um den SQL Server, Powershell und Azure für Science-Fiction, Snowboarden, Backen 😉 und Radfahren.
