EXPERTEN-DOSSIER 2019 - ÜBER 80 SEITEN MIT PRAXISORIENTIERTEM WISSEN FÜR .NET-ENTWICKLER RUND UM .NET CORE, AZURE DEVOPS, TYPESCRIPT, COSMOS DB ...
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Experten-Dossier
2019
Über 80 Seiten mit
praxisorientiertem Wissen für
.NET-Entwickler rund um
.NET Core, Azure DevOps,
TypeScript, Cosmos DB, ML.NET,
Git und Azure!
bastacon www.basta.net
Inhalt Agile & DevOps Die DevOps-Challenge 4 DevOps-Fallstricke und wie man ihnen entkommen kann von Kevin Gerndt Microservices & APIs Warum einfach? Es geht auch komplex! 10 Entwicklung von Microservices mit Microsoft .NET von Dr. Felix Nendzig Go Git! 16 Git erobert die Entwicklerwelt von Uwe Baumann Des Kaisers neue Kleider 21 Aus VSTS wird Azure DevOps – mehr als nur ein neuer Name? von Nico Orschel und Thomas Rümmler .NET Framework & C# R. I. P .NET „Core“ 29 .NET Framework, .NET Core und Mono sind tot – lang lebe .NET 5.0! von Dr. Holger Schwichtenberg Machine Learning für die Zukunft 33 Hintergrund und Einstieg in ML mit .NET von Kevin Gerndt Architektur Kolumne: Stropek as a Service 40 Zehn Hausaufgaben für die Cloud-Architektur – Eine gute Softwarearchitektur setzt klare Ziele voraus von Rainer Stropek Große Business-Apps mit Angular meistern 43 Nachhaltige Angular-Architekturen mit Nx und Strategic Design von Manfred Steyer
Inhalt Sicherheit Du kommst hier nicht rein 48 API Authorization in ASP.NET Core 3.0 mit IdentityServer von Sebastian Gingter Wasm – Ist das sicher oder kann das weg? 53 Neue Besen kehren gut, sagt man. Aber sind sie auch sicher? von Carsten Eilers HTML5 & JavaScript Das Beste aus zwei Welten 59 Mit ASP.NET Core und Angular eine Webanwendung erstellen von Fabian Gosebrink Injections für echte TypeScript-Junkies 70 Dependency Injection in unter 200 Zeilen Code – ohne Leerzeilen von Thomas Mahringer Olis bunte Welt der IT 76 Wenn’s etwas weniger sein darf: React und Redux kombiniert von Oliver Sturm Data Access & Storage Progressive Web Apps auf Knopfdruck? 66 Ohne Umwege zu offlinefähigen Webanwendungen mit Angular und @ angular/service-worker von Manfred Steyer Ganz ir-relational 80 Cosmos DB in eigenen Projekten einsetzen: Grundlagen und Einsatzszenarien von Thorsten Kansy
DOSSIER Agile & DevOps
DevOps-Fallstricke und wie man ihnen entkommen kann
Die DevOps-
Challenge
Noch vor einigen Jahren wurde die IT in Unternehmen als notwendiges Übel wahr-
genommen. Doch in Zeiten von digitalen Geschäftsmodellen und Produkten haben
Unternehmen den wahren Wert dieses Bereichs erkannt. Das birgt jedoch eine
Menge neuer Herausforderungen, denn der Wettbewerbsdruck steigt stetig und die
Entwicklungszyklen werden immer kürzer. DevOps scheint das Allheilmittel zu sein,
der Weg dorthin ist aber steinig.
von Kevin Gerndt zur Vermittlung von Dienstleistungen. Doch sind es
oftmals diese Unternehmen, die durch hohe zweistel-
Das „Digital Mindset“ hat unlängst Einzug in große lige Wachstumszahlen brillieren und schnell einen
deutsche Konzerne gehalten. Das zeigen diverse Studi- Milliardenwert auf die Börsenwaage bringen. Um ein
en und dass die Notwendigkeit erkannt wurde, einen solches produktgetriebenes Wachstum zu erreichen,
neuen Platz in der Führungsetage für den Chief Digital ist es erforderlich, extrem schnell und agil auf Ver-
Officer (CDO) zu schaffen. Der CDO soll Unterneh- änderungen und Anforderungen reagieren zu können.
men erfolgreich durch die digitale Transformation füh- In dieser Disziplin sind die oft „tankerähnlichen“, in
ren. Denn der Wettbewerbsdruck wächst zunehmend Silos organisierten Großunternehmen ganz klar unter-
und immer mehr Firmen setzen auf die Entwicklung legen.
digitaler Produkte und Services. Wer nicht Opfer der Letztendlich ist jedoch alles eine Frage der Strategie
Disruption werden möchte, muss sich diesem Trend und des Willens. Im Jahr 2018 hat Klaus Straub, CIO bei
anschließen und der Konkurrenz immer einen Schritt BMW, angekündigt, das Unternehmen im Rahmen einer
voraus sein. Interessanterweise beschränkt sich diese agilen Transformation ganz klar in Richtung Produkt
Entwicklung nicht nur auf einzelne Branchen, sondern orientierung bzw. Agile Operating Model auszurichten.
ist nahezu in allen Marktsegmenten erkennbar. Wer Unter dem Motto „100 % agil“ ist das erklärte Ziel, bis
hätte vor fünfzehn Jahren schon gedacht, dass Unter- Ende 2019 nicht nur sämtliche laufende IT-Projekte des
nehmen aus dem Bereich Automotive einmal Unsum- Unternehmens auf agil umzustellen, sondern auch die
men in die Entwicklung und Bereitstellung digitaler IT-Organisation vollumfänglich nach agilen Prinzipien
Services investieren würden? auszurichten. Ein zwingendes Erfordernis stellt die enge
Ein gutes Beispiel hierfür ist der Car-Sharing-Dienst Zusammenarbeit zwischen Fachbereichen und der IT-
DriveNow des Automobilherstellers BMW. Durch Abteilung dar.
das Car-Sharing-Angebot verlängert sich einerseits Aber auch hinter den Mauern der IT ist ein enger
die Wertschöpfungskette hin zum Kunden, auf der Schulterschluss gefragt. Gemeint ist damit natürlich
anderen Seite lassen sich wertvolle Benutzerdaten DevOps – die Verschmelzung von Entwicklung und Be-
sammeln. Wie lukrativ Servicemodelle sein können, trieb. Das Schaffen einer DevOps-Kultur ist jedoch viel
zeigen Unternehmen wie myTaxi, HRS oder Uber. mehr als nur das Vorhaben, Abteilungen und Bereiche
Diese Firmen sind weder im produzierenden Gewerbe zusammenzuführen. Es handelt sich vor allem um eine
tätig, noch besitzen sie physische Güter. Sie fungieren Revolution im Kopf aller Beteiligten, einen Umdenkpro-
lediglich als Serviceprovider und bieten die Plattform zess, der von höchster Ebene angeregt werden muss. Vor
www.basta.net 4
DOSSIER Agile & DevOps
allem ist es wichtig, die so häufig im Kopf existierenden reiche. Zögerliche Unternehmen riskieren mittel- und
Silos abzureißen. Doch was genau bedeutet das? langfristig ihre Wettbewerbsfähigkeit. Im schlimmsten
Stellt man sich einmal den klassischen Entwicklungs- Fall werden sie Opfer der Disruption und verschwin-
prozess vor, läuft es meist so, dass die Fachabteilung den vom Markt. Doch auch Unternehmen, die sich un-
mit einem Anforderungskatalog an den Entwicklungs- längst für eine DevOps-Strategie entschieden haben,
bereich herantritt. Dieser entwickelt die Software, um kämpfen mit der Umsetzung. Unternehmen buhlen
sie anschließend an den Betrieb zu übergeben. Das Be- mit allen Mitteln um die Gunst der wertvollen Ent-
triebsteam wiederum stellt dann fest, dass die Software wicklerressourcen. Keine Entwickler zu finden, ist für
so nicht den Betriebsanforderungen entspricht oder viel- moderne Unternehmen existenzgefährdender als der
leicht auch einfach nur essenzielle Artefakte wie etwa fehlende Zugang zu frischem Kapital an den Finanz-
das Betriebshandbuch fehlen. Indes ärgert sich der Fach- märkten. Umso wichtiger ist es, eine solide und nach-
bereich über die mangelnde Kompetenz der IT und die haltige Basis für einen langfristigen Erfolg zu schaffen.
Verzögerung bei der Inbetriebnahme. Ist die Software an Nachfolgend erläutere ich einige der Grundprinzipien
den Betrieb übergeben, lehnt sich die Entwicklungsab- von DevOps.
teilung oftmals entspannt zurück, denn ihre Bringschuld Kultur der Zusammenarbeit: Das A und O einer er-
ist erfüllt. Kommt es im Betrieb einer Applikation zu folgreichen DevOps-Strategie ist das Erlangen einer
Problemen, geht das Fingerzeigen erneut los. Der Betrieb Kultur der Zusammenarbeit. In einer traditionell aus-
beschuldigt die Entwickler, die Entwickler den Betrieb. gerichteten IT verfolgen Entwicklung und Betrieb unter-
In großen Unternehmen können diese Extra runden schiedliche Ziele mit unterschiedlichen Prioritäten. Die
schon einmal Wochen oder gar Monate an Verzug be- Entwicklung ist meist agiler und benötigt die Freiheit,
deuten; ein Zeithorizont, der sich nicht mit einer agilen Änderungen vornehmen zu können, der Betrieb hinge-
Strategie und der Verkürzung von Go-to-Market-Zyk- gen schwört auf Stabilität. Eine enge Zusammenarbeit
len vereinbaren lässt. dieser Bereiche ist jedoch einer der wichtigsten Aspekte,
In einem DevOps-Szenario übernimmt das Team, wenn es um DevOps geht. Das Schaffen eines Informa-
bestehend aus Produktmanagern, Entwicklern und Be- tionsaustauschs in Echtzeit ermöglicht es den Teams,
triebsleuten, gemeinsam die Verantwortung für einen einerseits schnelle Änderungen an einer Applikation
erfolgreichen Ablauf und Betrieb. Alle verfolgen diesel- vornehmen zu können und andererseits eine stabile und
ben Ziele und ziehen am gleichen Strang. Welche kriti- robuste Betriebsumgebung zu erhalten. Tools wie etwa
schen Erfolgsfaktoren neben der Kultur noch existieren Slack, Yammer und Microsoft Teams können dazu
und welche Tools und Plattformen bei der Einführung verhelfen, die Hürden einer klassisch formalen E-Mail-
von DevOps hilfreich sein können, werden wir im Fol- Kommunikation abzubauen.
genden betrachten. Einhalten von Architekturrichtlinien: Um die Be-
treibbarkeit, Stabilität und Kompatibilität einer Soft-
Die Säulen des Erfolgs ware zu sichern, ist es wichtig, Leitlinien zu definieren
Auch wenn einige Unternehmen DevOps nur nutzen, und diesen zu folgen. Enthält eine Applikation bei-
um kurzfristige Effizienzvorteile zu erhalten, wird spielsweise viele direkte Abhängigkeiten zu anderen
diese Methodik doch mehr und mehr zu einem unver- Applikationen, Datenbanken oder anderen Systemen,
zichtbaren Bestandteil für sämtliche Wirtschaftsbe- kann das schnell zu einem hohen Maß an Komplexität
führen. Das kann sich wiederum negativ auf Testauf-
wände, aber auch Key Performance Indicators (KPIs)
wie die Deployment Success Rate auswirken. Probleme
im Applikationsbetrieb müssen schnell identifiziert und
DevOps für klassische behoben werden. Hierfür ist eine standardisierte Integ-
ration von Logging und Monitoring in die Applikation
Windows-Desktopanwendungen
ebenfalls unabdingbar. Oftmals wird im Kontext dieser
Thomas Schissler (agileMax) Design-for-DevOps-Best-Practices von zwölf Faktoren
Der Begriff DevOps wird von vielen mit gesprochen, auf die im späteren Verlauf des Artikels
hypermodernen Cloud- und Webtech- eingegangen wird.
nologien in Verbindung gebracht. Die Infrastruktur und Plattform: Die Infrastruktur trägt
Prinzipien von DevOps lassen sich aber
einen maßgeblichen Teil zu einem stabilen Applikati-
auch für klassische Desktopanwendun-
gen und andere Legacy-Technologien anwenden. Die onsbetrieb bei und ist eine essenzielle Komponente in
technischen Hürden sind oftmals gar nicht so groß, DevOps-Szenarien. Häufig kommen Plattformen wie
aber natürlich sind ein paar Anpassungen dafür not- OpenShift, Clound Foundry oder Azure zum Einsatz,
wendig. Im Vortrag zeigen wir an einem Beispiel, wie die einen sehr hohen Grad der Automation erlauben
eine klassische WPF-Anwendung für DevOps fit ge- und als gemeinsame Basis für das DevOps-Team fun-
macht werden kann und mit welchen Tools Continuous gieren. Die Entwickler können sich dadurch voll und
Delivery und Monitoring möglich werden.
ganz auf ihre Aufgabe – das Entwickeln – fokussieren.
Die Betriebseinheit des Teams kann zum Beispiel die
www.basta.net 5
DOSSIER Agile & DevOps
Entwickler durch das Bereitstellen von Infrastruk- Erzeugen von Messbarkeit: Damit ein DevOps-Team
turtemplates unterstützen. maximal erfolgreich wird und sich die Erfolge auch be-
Dass jede Applikation auf einer einheitlichen Platt- legen lassen, spielt das Erzeugen von Messbarkeit eine
form läuft, trägt zu einer allmählichen Effizienzstei- große Rolle. Dadurch, dass viele Prozesse zentral und
gerung bei, da nicht bei jeder Inbetriebnahme einer automatisiert ablaufen, lassen sich jede Menge Daten
Applikation erneut darüber diskutiert werden muss, wo erzeugen, die sich dann wiederum auswerten lassen und
sich die Logs befinden, wie Loglevel zu konfigurieren aus denen Optimierungspotenziale abgeleitet werden
sind oder wie ein Rollback auf eine frühere Applikati- können. Da eine Vielzahl von KPIs existiert, ist eine
onsversion durchzuführen ist. projektindividuelle Festlegung durchaus sinnvoll, denn
CI/CD Pipeline: Das Verwenden eines zentralen nicht jede KPI hat für jedes Projekt die gleiche Relevanz.
Code-Repositorys ist für Entwickler ein alter Hut und Gute Beispiele für Metriken im Kontext von DevOps
ein wesentlicher Bestandteil von DevOps. Alle Code- sind die Bereitstellungsfrequenz sowie die Bereitstel-
änderungen werden regelmäßig in ein zentrales Re- lungszeit. Ein häufig definiertes Ziel ist es, möglichst vie-
pository wie etwa Git zusammengeführt. Nach dem le, kleine Deployments durchzuführen. Dadurch sinken
Damit ein DevOps-Team maximal erfolgreich wird,
und sich dieser Erfolg auch belegen lässt, spielt
das Erzeugen von Messbarkeit eine große Rolle.
Check-in werden diese Änderungen automatisiert die Testaufwände für ein Release, und potenzielle Fehler
erstellt und getestet. Die Hauptziele von Continuous lassen sich leicht eingrenzen.
Integration bestehen darin, Bugs möglichst schnell zu In diesem Zusammenhang spielt natürlich auch die
entdecken und zu beheben, die Qualität der Software für eine Bereitstellung benötigte Zeit eine große Rol-
zu optimieren und den Zeitraum bis zum Go Live le: Je kürzer die für ein Release benötigte Zeit, desto
auf ein Minimum zu reduzieren. Das übergeordnete schneller lassen sich im Fehlerfall Korrekturen auf dem
Ziel ist, die Entwicklerproduktivität zu steigern und System einspielen. Die allgemeine Servicequalität kann
„Stupid Work Tasks“ zu eliminieren bzw. zu auto- zum Beispiel durch die Verfügbarkeit der Systeme und
matisieren. Das gelingt zum Beispiel durch Testauto- die Anzahl an Benutzertickets gemessen werden. Im Ide-
matisierung; nach einem erfolgreichen Build-Prozess alfall werden Störungen und Probleme behoben, bevor
lassen sich beispielsweise Unit-, Komponenten-, UI-, sie bis zum Benutzer vordringen, zum Beispiel durch ein
Last- oder API-Tests durchführen. Die Ergebnisse intelligentes Application-Monitoring. Hierzu eignen
fließen wiederum in Reports ein, mit denen sich der sich Tools wie Retrace, Grafana oder App Dynamics,
Erfolg des Teams messen lässt. Anhand der Resultate die wiederum eine Vielzahl von Parametern wie etwa
kann ebenfalls eine Entscheidungsgrundlage für z. B. Application-Performance, Bandbreiten oder Applikati-
ein automatisiertes Deployment geschaffen werden. onsfehler überwachen. Neben den hier beispielhaft auf-
Eine hundertprozentige Testautomatisierung ist je- geführten Metriken existiert natürlich noch eine ganze
doch nicht realistisch. Die Kunst liegt darin, unter den Reihe weiterer KPIs.
Testtasks diejenigen zu identifizieren, die sich leicht Um eine kontinuierliche Verbesserung der Werte zu
automatisieren lassen und einen hohen Mehrwert für erreichen, ist es empfehlenswert, einen regelmäßigen
das Team schaffen. Erfahrungsgemäß lassen sich ca. Austausch innerhalb des DevOps-Teams anzustreben.
40–60 Prozent aller Testaufgaben automatisieren. Die Das kann zum Beispiel in Form von Meetings erfolgen,
Integration von Artefakten wie etwa Testautomatisie- bei denen die Beteiligten darüber sprechen, welche Fak-
rung bildet den Continuous-Delivery-Teil einer CI/CD toren sich ihrer Meinung nach besonders negativ auf
Pipeline ab. Gelegentlich wird in diesem Zusammen- einzelne KPIs oder den gesamten Service auswirken.
hang auch von Continuous Deployment gesprochen. Diese Punkte lassen sich dann wiederum gezielt verbes-
Diese zwei Varianten unterscheiden sich lediglich durch sern oder gar eliminieren.
das Vorhandensein einer manuellen Genehmigung. Bei
Continuous Delivery erfolgt das Deployment zunächst DevOps-kompatible Softwarearchitektur
auf eine nicht produktive Test- oder Integrationsumge- Da es sich bei DevOps in erster Linie um eine Philoso-
bung. Nach erfolgreichem Test und einer Freigabe wird phie handelt und nicht um eine Technologie, ergeben
das Release dann in die Produktionsumgebung gestaget. sich vielleicht zunächst Fragen, inwieweit DevOps die
Bei Continuous Deployment wird auf diesen zusätzli- zugrunde liegende Technologie beeinflusst oder sie gar
chen Prüfschritt verzichtet und die Produktionsumge- voraussetzt. Das im Mittelpunkt stehende Ziel von Dev
bung unmittelbar aktualisiert. Ops ist meist die Erreichung maximaler Effizienz und
www.basta.net 6
DOSSIER Agile & DevOps
größtmöglicher Ökonomie. Um diese Ziele zu erreichen, zentral aufgelöst werden. Auch Problemen, die durch
bedarf es neben dem richtigen Mindset und einer Dev eine Diskrepanz in den Versionen entstehen, lässt sich
Ops-kompatiblen Organisation auch der Wahl eines so vorbeugen. Das gleiche Paradigma gilt für Services
fortschrittlichen Technologiestacks. Die Basis hierfür oder Ressourcen, die von einer Applikation verwendet
bildet in der Regel eine DevOps-Plattform wie etwa werden. Dazu zählen zum Beispiel Datenbank- oder
OpenShift, Cloud Foundry oder Azure DevOps. Diese SMTP-Dienste sowie APIs. Eine App muss stets so
Plattformen bieten integrierte Funktionen wie ein Con- entwickelt werden, dass es für die Einbindung und
tainermanagement, die notwendige Containerlaufzeit- Nutzung der Services und Ressourcen unerheblich ist,
umgebung, Lastenausgleichsmodule, Integration von von welchem Anbieter sie zur Verfügung gestellt wer-
Source-Code-Management und Build-Tools, CI/CD den. Im Rahmen eines Bereitstellungsprozesses ist es
Pipelines sowie weitere nützliche Features. üblich, dass pro Umgebung eine eindeutige Konfigu-
Mit der Festlegung auf eine DevOps-Plattform wird ration festgelegt wird. Diese Konfigurationsparameter
also in gewisser Weise auch die Entscheidung für einen müssen sich zwingend von außerhalb der Applikation
Basistechnologiestack gefällt, der in der Regel auch ein ändern lassen. Ein Hinterlegen dieser Konfiguration
Containerkonzept mit sich bringt. Die aktuell wohl be- im Code durch Konstanten, zum Beispiel für System-
kannteste Implementierung der Containertechnologie zugangsdaten oder Datenbankverbindungsfolgen,
ist Docker, die aufgrund ihrer Einfachheit und Benut- stellt einen klaren Verstoß in einer 12-Faktor-Archi-
zerfreundlichkeit den Begriff überhaupt erst populär tektur dar.
gemacht hat. Die Idee hinter Containern ist eigentlich In einer 12-Faktor-App wird strikt zwischen Build-,
recht einfach: Ein Container fasst eine einzelne An- Release- und Run-Phase unterschieden. Checkt der
wendung mitsamt allen notwendigen Abhängigkeiten Entwickler neuen Code ins Repository ein, wird mit
wie etwa Bibliotheken oder statischen Inhalten in einer der Build-Phase die Transformation des Codes in ein
Image-Datei ohne Overhead zusammen. Im Gegensatz ausführbares Paket angestoßen. Im nächsten Schritt,
zu einer virtuellen Maschine enthält ein Container der Releasephase, wird das Build-Ergebnis mit der zum
aber kein komplettes Betriebssystem und benötigt da- Deployment passenden Konfiguration kombiniert.
her auch weniger Ressourcen. Ein bedeutender Vorteil In der Run-Phase, der sogenannten Laufzeit, wird die
der Docker-Container ist die gute Skalierbarkeit: Wer- Applikation dann ausgeführt. Aufgrund dieser strikten
den aufgrund des Lastverhaltens zusätzliche Instanzen Trennung sind Codeänderungen zur Laufzeit nicht mög-
einer Anwendung benötigt, lassen sich nach Belieben lich, weil es keinen Weg gibt, die Änderungen zurück
neue Container auf Basis eines Images erzeugen. Nach in die Build-Phase zu übernehmen. Es empfiehlt sich,
dem Stoppen sind die Container wieder vollständig jedes Release separat mit einem eindeutigen Identifier
aus dem System verschwunden und alle Ressourcen und Erstelldatum und -uhrzeit abzulegen. Das ermög-
werden freigegeben. Die Konfiguration ist so weit wie licht im Fehlerfall ein schnelles Rollback der Lösung.
möglich bereits im Container-Image eingerichtet. Zu- Eine 12-Faktor-App sollte immer zustandslos sein. Alle
sätzlich notwendige Anpassungen sollten skriptbasiert Daten werden in unterstützenden Diensten, in der Re-
erfolgen. gel einer Datenbank, gespeichert. Der RAM oder das
Um das volle Potenzial der Containertechnolo- lokale Dateisystem können als kurzzeitiger Cache für
gie auszunutzen, müssen die darin ausgeführten eine Transaktion verwendet werden. Es darf aber nie-
Applikationen verschiedene Architekturrichtlinien mals davon ausgegangen werden, dass Daten für einen
berücksichtigen. In diesem Kontext wird häufig von längeren Zeitraum vorgehalten werden oder durch eine
12-Faktor-Applikationen gesprochen [1]. Hinter die-
sem Konzept verbergen sich zwölf Punkte, die Ent-
wicklern dabei helfen sollen, Applikationen so zu
designen und zu entwickeln, dass sich diese als SaaS
(Software as a Service) und letztendlich auch prob- Architektur, aber bitte agil!
lemlos in Containern betreiben lassen. Ein wichtiges Urs Enzler (bbv Software Services AG)
und zugleich selbstverständliches Kriterium der zwölf
Architektur steht für Stabilität und weit-
Faktoren ist, dass der Quellcode einer Applikation reichende Entscheidungen. Und das soll
stets in einer Versionsverwaltung wie zum Beispiel Git in einem schnelllebigen, flexiblen agilen
verwaltet wird. Dabei besteht immer eine eindeutige Projekt möglich sein? Ich zeige in dieser
Korrelation zwischen einer Codebasis und einer App. Präsentation, wie sich Architektur mit
Zwei Applikationen können sich nach diesem Kon- den User Stories zusammen evolutionär entwickeln
zept also einen Quellcode teilen. Das Vorhalten des kann, wie Entscheidungen bis zum richtigen Zeit-
punkt vertagt werden können und welche agilen
Quellcodes ist ebenfalls ein wesentliches Erfordernis
Architekturmuster es gibt. Ihr lernt, wie eine agile
für den Aufbau einer CI/CD Pipeline. Applikationen Architektur schnelle Änderungen, einfache Archi-
sollten keine direkten Abhängigkeiten untereinander tekturvalidierung und ein immer lauffähiges System
aufweisen. Durch das Verwenden eines Package Ma- ermöglicht.
nagers lässt sich sicherstellen, dass Abhängigkeiten
www.basta.net 7
DOSSIER Agile & DevOps
Azure DevOps
Die Zeichen, die Microsoft aussendet, sind deutlich:
Schon länger versucht der Konzern, ein Open-Source-
freundlicheres Image aufzubauen. Ein großer Schritt in
diese Richtung war der Beitritt Microsofts zum Open
Innovation Network (OIN) und der damit verbunde-
nen Bereitstellung von 60 000 eigenen Patenten. Ein
weiterer bedeutender Schritt ist das Aufgeben der Mar-
ke „Visual Studio“. Die Cloud-Dienste für Entwickler,
ehemals Visual Studio Team Services (VSTS), laufen
ab sofort unter dem Brand „Azure DevOps“. Auch das
lokal installierbare Gegenstück zu den VSTS, das seit
2005 unter dem Namen „Team Foundation Server“
(TFS) auf dem Markt ist, erhält ab der Version 2019
einen Brand: „Azure DevOps Server 2019“. Dieses
Rebranding soll vor allem dafür sorgen, die Assozia-
tion in den Köpfen vieler Entwickler zwischen Visual
Studio und den klassischerweise damit verbundenen
Programmiersprachen C++, C#, F# etc. zu lösen. Ne-
ben dem neuen Markennamen spendiert Microsoft
natürlich auch noch ein paar neue Features wie etwa
die „Azure Pipelines“. Hierbei handelt es sich um eine
leistungsstarke CI/CD Pipeline Engine, die mit nahezu
jeder gängigen Programmiersprache und einer Vielzahl
von Projekttypen arbeitet. Natürlich gab es auch in
der altbekannten Version bereits eine CI/CD Pipeline,
doch vor dem Hintergrund immer größer werdenden
Abb. 1: Azure DevOps Pipelines
Leistungsdrucks stellt die CI/CD Pipeline eine Kompo-
nente dar, die sicherlich noch viel Potenzial für Opti-
andere Transaktion nutzbar sind. In einer skalierbaren mierung bietet. Azure Pipelines bieten die Möglichkeit,
Umgebung ist es ebenso denkbar, dass ein künftiger verschiedenste Zielsysteme für Bereitstellungsszenarien
Request von einer anderen Instanz als der ursprünglich zu adressieren. Dazu gehören neben den Azure-eigenen
angefragten und somit in einem anderen Transaktions- Services, wie „Azure App Services“ oder „Azure Ku-
Scope bearbeitet wird. Da diese Flexibilität ein we- bernetes Service“ (AKS), auch virtuelle Maschinen,
sentlicher Teil der Grundidee ist, müssen Prozesse so klassische Container Registries oder Deployments zu
ausgelegt werden, dass sie eine möglichst geringe Start- Amazon Web Services. Eine neue Pipeline kann einfach
zeit haben. Im Idealfall ist ein Prozess innerhalb weniger über den Menüpunkt Pipelines auf der linken Seite
Sekunden hochgefahren und einsatzfähig. Eine kurze der Azure-DevOps-Weboberfläche erstellt werden
Start-up Time verleiht dem System noch mehr Agilität (Abb. 1).
und Robustheit. Gleiches gilt natürlich für das Herun- Für das Erstellen einer Build Pipeline ist es zunächst
terfahren eines Prozesses. erforderlich, eine Quelle auszuwählen, von der aus
Um das Verhalten einer laufenden Applikation sicht- der Source Code abgerufen werden soll. Kompatible
bar zu machen, ist Logging unabdingbar. Häufig wer- Quellcodeverwaltungssysteme sind zum Beispiel Git-
den Logs gezielt an einem bestimmten Ort, wie dem Hub, Azure Repos Git, Subversion etc. Anschließend
Dateisystem oder einer Datenbank, abgelegt. Dieses erfolgt die eigentliche Build-Konfiguration, die aber
Verhalten wird oftmals durch die Applikation be- nicht jedes Mal aufs Neue manuell durchgeführt werden
stimmt. Im Fall einer 12-Faktor-App ist es nicht mehr muss. Stattdessen kann der Benutzer aus einem Temp-
Aufgabe der Applikation, sich um einen Ablageort zu latekatalog auswählen. So ist es mittels weniger Klicks
kümmern. Stattdessen werden sämtliche Ereignisse un- beispielsweise möglich, eine Build Pipeline für eine
gepuffert in den stdout-Stream geschrieben. Die wei- Azure-Web-App for ASP.NET zu konfigurieren. Sind
tere Verarbeitung dieser Ereignisinformationen obliegt Container das präferierte Zielmodell, ist eine direkte
dem Hostsystem. Es entscheidet alleinig, ob und wohin Containerisierung mit anschließender Bereitstellung in
die Logs persistiert werden. Das Einhalten der hier auf- einer Container-Registry ebenfalls mit einem überschau-
gezeigten Leitlinien trägt zu einer sauberen und ska- baren Aufwand realisierbar. Wer sich in der Welt von
lierbaren Applikationsarchitektur bei. Auch wenn dies YAML, einem JSON-ähnlichen deklarativen Format,
prinzipiell für jede Applikation gilt, sollte dem Thema wohlfühlt, ist eingeladen, die Build-Konfiguration auf
im Kontext von DevOps eine besondere Bedeutung zu- Basis dieses Formats festzulegen. Das Erstellen einer Re-
gemessen werden. lease-Pipeline fühlt sich ähnlich komfortabel an. End to
www.basta.net 8
DOSSIER Agile & DevOps
Abb. 2: Konfiguration einer Release-Pipeline
end gedacht, dient die Release-Pipeline dazu, den Code „Agile Operating Model“ bis Ende 2019 angekündigt
für die Benutzer auf einem System verfügbar zu machen. hat. Das Zauberwort für das Erreichen all dieser Ziele
Ihre Konfiguration erfolgt mittels eines grafischen Edi- lautet DevOps. Hierzu gehört jedoch viel mehr als nur
tors (Abb. 2). das Einführen neuer Technologien und Plattformen.
Als Ausgangsbasis dient ein sogenanntes „Artifact“. Es gehört ebenfalls mehr dazu als nur das Vorhaben,
Hierbei handelt es sich vereinfacht gesagt um den be- Abteilungen und Bereiche zusammenzuführen. Es han-
reitstellbaren Teil einer Applikation, der in der Regel delt sich erst einmal um eine Revolution im Kopf aller
durch die Build Pipeline erzeugt wird. Am Artefakt Beteiligten, einen Umdenkprozess, der von höchster
selbst lässt sich wiederum das Verhalten über soge- Ebene angeregt werden muss. Dabei ist es vor allem
nannte Trigger festlegen. Der Bereitstellungsprozess wichtig, die häufig im Kopf existierenden Silos abzu-
wird somit zum Beispiel automatisch gestartet, sobald reißen. Auch wenn bei DevOps die Technik nicht im
ein neuer Build zur Verfügung steht. Auch ein manu- Vordergrund steht, bedarf es natürlich entsprechender
eller Eingriff mittels Pull Request lässt sich einstellen. Konzepte und einheitlicher Plattformen, um die größt-
Über die Stages wird definiert, welche Umgebung zu mögliche Effizienz bei der Entwicklung zu erzielen.
welchem Zeitpunkt mit welchen Voraussetzungen de- Finden all diese Punkte Berücksichtigung und gelingt
ployt wird. Um den Konfigurationsprozess so einfach der Schulterschluss zwischen Entwicklung, Betrieb und
wie möglich zu gestalten, existieren auch hierfür zahl- Fachbereichen, steht einer erfolgreichen DevOps-Or-
reiche vorgefertigte Templates für eine Bereitstellung ganisation nichts mehr im Weg.
auf Azure, Kubernetes, IIS etc. Das Deployment einer
Stage kann an verschiedene Pre- und Post-Conditions
geknüpft werden. Hierbei kann es sich beispielsweise Kevin Gerndt arbeitet als Lead Consultant im Bereich
um ein automatisch ausgelöstes Event oder eine benut- Microsoft .NET Client und Web Technologies und hat
zergetriebene Aktion handeln. Gates ermöglichen eine während seiner beruflichen Laufbahn schon eine Viel-
zahl an Projekten begleitet. Er gilt als Experte auf dem
Integration von REST APIs, Azure Monitor Alerts oder Gebiet der modernen Web- und Softwarearchitektur
Azure Functions. Sollte beim Deployment doch mal et- und ist darüber hinaus als freiberuflicher Autor tätig, sowie re-
was schieflaufen, erlaubt die History eine transparente gelmäßig auf namhaften Konferenzen vertreten. Schwerpunkte
Einsicht in Änderungen sowie ein kontrolliertes Zu- seiner Tätigkeit bilden die Analyse und Implementation von Ge-
rückrollen des Release. schäftsprozessen sowie das Konzipieren und Entwickeln moder-
ner Softwarelösungen.
Fazit
In Zeiten zunehmenden Wettbewerbsdrucks ist es
wichtiger denn je, der Konkurrenz immer einen Schritt
voraus zu sein. Dies trifft auf die Entwicklung phy-
sischer Güter, aber vor allem immer stärker auf di-
gitale Services und Produkte zu. Mit der klassischen
Unternehmensorganisation fällt es jedoch vor allem
großen Konzernen mit ihrer Silostruktur schwer, mit
dem vorherrschenden Tempo mitzuhalten. Doch im-
mer mehr Unternehmen passen sich an und vollziehen
einen Strukturwandel oder gründen Start-ups aus, um
der heutzutage geforderten Agilität gerecht zu werden. Links & Literatur
Ein gutes Beispiel ist der Automobilkonzern BMW,
dessen Vorstand einen radikalen Wandel in Richtung [1] https://12factor.net
www.basta.net 9
DOSSIER Microservices & APIs
Entwicklung von Microservices mit Microsoft .NET
Warum einfach? Es
geht auch komplex!
Wie zu erwarten zieht das heißdiskutierte Thema Microservices auch an Microsoft nicht
vorüber. Grund genug, einmal näher zu betrachten, wie man als .NET-Entwickler bei der
Entwicklung von Microservices mit Docker von technischer Seite unterstützt wird.
von Dr. Felix Nendzig Entwicklung kann in kleinen, unabhängigen Teams
mit geringem Kommunikationsbedarf untereinander
Mit „.NET Microservices: Architecture for Contain stattfinden. Um einen Vorteil gegenüber einer monoli-
erized .NET Applications“ hat Microsoft nun ein mehr thischen Anwendung zu erreichen, sollten die Microser-
als dreihundertseitiges E-Book veröffentlicht, in dem vices jeweils folgende Bedingungen erfüllen:
das Unternehmen seine Sicht auf das Thema umfassend
vorstellt und insbesondere die Benutzung von Docker • Ein Service erfüllt genau einen fachlichen Zweck und
bei der Entwicklung von Anwendungen mit Microser- diesen vollständig
vices-Architektur empfiehlt [1]. • Jeder Service umfasst sämtliche benötigte Schichten,
In diesem Beitrag soll Microsofts Sicht auf das Thema Teams arbeiten unabhängig voneinander (vertikaler
Microservices näher beleuchtet und mit Blick auf unsere Schnitt)
eigene Erfahrung kommentiert werden. Weiterhin wer- • Asynchrone Kommunikation zwischen Services (kei-
den wir darauf eingehen, wie Docker bei der Entwick- ne zentral steuernde Einheit)
lung von Microservices genutzt werden kann. • Keine gemeinsamen Daten oder Code (shared
Nothing)
Was ist eine Microservices-Architektur? • Jeder Service ist unabhängig deploybar
Das zentrale Erkennungsmerkmal einer Microservices- • Unabhängige Datenmodelle und minimale APIs zur
Architektur ist, dass sich die gesamte Anwendung aus Gewährleistung eigenständiger Entwicklungszyklen
einzelnen, voneinander unabhängigen Services zusam-
mensetzt. Durch Dezentralisierung und Autonomiema- Der Name „Microservices“ impliziert, dass die ein-
ximierung soll auch bei komplexen Anwendungen eine zelnen Services klein sein sollen. Diese Charakteri-
gute Skalierbarkeit in der Entwicklung – gegenüber ei- sierung bezieht sich aber nicht auf die Lines of Code
ner monolithischen Architektur – erreicht werden. Die oder die Anzahl der Klassen je Service. Stattdessen
www.basta.net 10DOSSIER Microservices & APIs Abb. 1: Illustration zweier Bounded Contexts (Quelle: [2]) bedeutet es, dass ein Service nur genau eine sinnvolle „2-Pizza-Regel“ liegt die maximale Teamgröße bei fünf Funktion im Sinne der fachlichen Logik erfüllen soll. bis neun Personen [4]. Diese Idee folgt dem Konzept des Bounded Context Eine verteilte Anwendung bringt allerdings auch aus dem Domain-driven Design [2]. Danach wird ein zusätzliche Schwierigkeiten mit sich, die bei falscher großer fachlicher Themenbereich in kleinere Bereiche, Vorgehensweise zu einer Verschlechterung gegen- die Bounded Contexts (Abb. 1), aufgeteilt, die jeweils über einem Monolith führen können: Es gibt keine ihre eigenen, eindeutigen Fachbegriffe benutzen (Ubi- zentrale Steuerung, sodass querschnittliche Aufgaben quitous Language). Ein Microservice überschreitet wie Service-übergreifendes Monitoring oder Logging keinesfalls die Grenzen eines Bounded Contexts. Er zusätzlichen Entwicklungsaufwand mit sich bringen. implementiert maximal den gesamten Bounded Con- Externe Tools wie der ELK-Stack [5], Zipkin [6], Jae- text, typischerweise aber nur einen Teilbereich. ger [7] und AppDynamics [8] können hier Abhilfe Man sollte die kleinsten Microservices implemen- schaffen. Die Durchführung von Service-übergreifen- tieren, die die oben genannten Bedingung erfüllen. den Integrationstests oder Refactorings wird schwie- Wird die optimale Größe unterschritten, wachsen riger. Transaktionen sind auf einzelne Microservices die Abhängigkeiten der Services untereinander. Das begrenzt. Das Prinzip des „shared Nothing“ erzwingt, verschlechtert die Performance der Anwendung zur dass jeder Service seine benötigten Daten replizieren Laufzeit und während der Entwicklung durch erhöh- oder über Schnittstellen von anderen Services abfragen ten Kommunikationsbedarf über Service- und Team- muss. Jedes Entwicklerteam hat zusätzlichen Aufwand grenzen hinweg. Der Schnitt der Microservices sollte durch erschwertes Debugging, eine eigene Fehlerbe- deren innere Kohäsion maximieren und die Abhän- handlung je Microservice, die Bereitstellung einer gigkeiten nach außen minimieren. Gemäß dem Gesetz Delivery Pipeline etc. Ein ungünstiger Service-Schnitt von Conway [3] sollten sich die Service-Grenzen hier- führt zu ständigen Schnittstellenanpassungen, gemein- bei an der Organisationsstruktur des Unternehmens samen Releases mehrerer Services oder der Auslastung orientieren. Es kann sich auch lohnen, dieses Prinzip mehrerer Services durch eine einzige Anfrage. umzukehren, und die Organisation so anzupassen, dass man den aus Softwaresicht sinnvollsten Service- Stateful oder stateless Microservices? Schnitt wählen kann. In einer verteilten Anwendung kann eine variierende An- Bei richtiger Umsetzung erhält man ein skalierba- zahl von Service-Instanzen simultan laufen. Der Orchest- res System lose gekoppelter Services, die unabhängig rator (mehr dazu etwas später) kann jederzeit Instanzen voneinander entwickelt und ausgeliefert werden kön- auf einen anderen Knoten schieben oder die Anzahl lau- nen. Releasezyklus, Entwicklungs- und Betriebsumge- fender Instanzen an die momentane Auslastung anpassen. bung können je Service passend gewählt werden. Der Man kann sich nicht darauf verlassen, dass eine spezielle Testaufwand je Service sinkt, da er nicht übermäßig Service-Instanz dauerhaft existiert. Das spricht gegen die komplex ist und nur über Schnittstellen kommuniziert. Implementierung von stateful Services, deren Zustand im Die Entwicklung in kleinen Teams erzeugt nur geringen Arbeitsspeicher gehalten und jederzeit repliziert werden organisatorischen Aufwand. Ausgehend von Amazons können muss. Für stateless Services stellt das kein Problem www.basta.net 11
DOSSIER Microservices & APIs
Abb. 2: Möglichkeiten zur Strukturierung des GUI in einer Microservices-Architektur (Quelle: [10])
dar, da sie die Daten in eine externe Datenbank schrei- direkt auf aufrufende Services auswirken. Auf diese
ben oder im Client oder einem Cachetool wie bspw. Redis Weise wird schnell die Performance der Gesamtan-
cachen. Die externe Datenquelle wird je Service passend wendung beeinträchtigt. Das Problem potenziert sich
zu dessen Anforderungen gewählt. noch, wenn mehrere synchrone Aufrufe in Reihe statt-
Was ist aber mit Anwendungsfällen, in denen man finden. Bei asynchroner Kommunikation wirkt sich der
Daten von verschiedenen Microservices sammeln oder Ausfall eines einzelnen Microservice dagegen nicht so
anzeigen muss? Tritt ein solcher Fall auf, sollte man verheerend auf seine Nachbarn aus. Sie fördert zudem
sich gut überlegen, ob der Service-Schnitt passend ge- die Autonomie der einzelnen Microservices.
wählt wurde und ob nicht eine Verschmelzung von Da an der Verarbeitung eines Geschäftsprozesses im
Microservices die beste Lösung darstellt. Lässt es sich Allgemeinen mehrere asynchron kommunizierende, un-
jedoch nicht vermeiden, muss man bei der Implemen- abhängige Microservices beteiligt sind, ist es nicht mög-
tierung besonders darauf achten, dass die Autonomie lich, stets Konsistenz im Sinne einer ACID-Transaktion
der betroffen Microservices dadurch nicht einge- sicherzustellen. Latenzen, Teilausfälle und unterschied-
schränkt wird. Zudem kann sich die Aggregation von liche Verarbeitungsdauern können zwischenzeitlich
Daten verschiedener Services aufgrund erhöhter Kom- Service-übergreifende, inkonsistente Zustände erzeugen
munikation negativ auf die Performance des Systems (Eventual Consistency), deren Behandlung zusätzlichen
auswirken. Aufwand, z. B. in Form von Timeouts, Circuit Breakers
Microsoft nennt als Alternative noch eine auf den An- und Bulkheads, erfordert [9].
wendungsfall zugeschnittene, denormalisierte Tabelle
in einer separaten Datenbank, in die die Microservices Das GUI
jeweils ihre Daten schreiben. Aus Konsistenzgründen Sollten Clients direkt mit den Microservices kommu-
dürfen die abfragenden Services auf diese nur lesend zu- nizieren oder den Umweg über ein vorgeschaltetes
greifen. Mit Blick auf die geforderte Autonomie ist diese API-Gateway nehmen? In der ersten Variante kann der
Lösung allerdings kritisch zu sehen. Client über einen URL direkt den betreffenden Service
(bzw. einen vorgeschalteten Load Balancer) anfragen.
Inter-Service-Kommunikation Jeder Microservice besitzt sein eigenes GUI oder ist in
Wie jede verteilte Anwendung muss auch eine Micro- einem Plug-in-Ansatz für einen Teil des GUI innerhalb
services-Anwendung mit Teilausfällen des Systems eines allgemeinen Rahmens verantwortlich.
umgehen können. Wie gut die Gesamtanwendung Für kleine Anwendungen mit geringem Aufwand in
solche Ausfälle verkraftet, hängt maßgeblich von der der GUI-Entwicklung kann diese Variante ausreichen.
Inter-Service-Kommunikation ab. Synchrone Kom- Man bekommt jedoch schnell Probleme, wenn die
munikation, bei der der Aufrufer abwarten muss, bis Entwicklung der Benutzeroberfläche in mehreren Mi-
eine Antwort zurückgeliefert wird, kann bei lesendem croservices gleichzeitig stattfindet und zudem noch für
Zugriff gegebenenfalls eine Lösung für die Kommuni- verschiedene Endgeräte entwickelt werden muss. Sind
kation zwischen Front- und Backend sein. Innerhalb zum Aufbau einer Oberfläche mehrere unabhängige
des Backends ist sie allerdings zu vermeiden, da sich Abfragen nötig, erhöht das die Latenz. Ein besseres Er-
Verzögerungen und Ausfälle des angefragten Service gebnis erhält man, wenn die Daten zuvor serverseitig
www.basta.net 12DOSSIER Microservices & APIs
Ein Orchestrator ermöglicht eine einfache Steuerung
der Anwendung inklusive Scheduling, Load Balancing
und Gewährleistung von Verfügbarkeit und Robustheit.
aggregiert werden. Auch querschnittliche Anforderun- Anwendungen, die in Docker-Containern laufen sollen.
gen wie Sicherheit, Autorisierung, Logging und Caching Unterstützt wird die Entwicklung mit .NET Frame-
möchte man nicht individuell für jeden Microservice, work, .NET Core und Mono in den Sprachen C#, F#
sondern gerne zentral implementieren. und VB. Mit .NET Core entwickelte Microservices sind
Schaltet man ein API-Gateway zwischen die Clients auf unterschiedlichen Plattformen lauffähig. Das mo-
und die Microservices-Landschaft, kann es das Routing dulare .NET Core ist zudem sehr leichtgewichtig und
sowie weitere querschnittliche Aufgaben übernehmen. damit besser geeignet, containerbasierte Anwendungen
Der Aufbau einer Oberfläche erfordert keine mehrfa- mit möglichst kleinen Microservices zu entwickeln. Das
chen Roundtrips und Sicherheitsthemen können zentral klassische .NET Framework ist vorzuziehen, wenn die
implementiert und verwaltet werden. Die Weiterent- bereits bestehende Anwendung oder andere Abhängig-
wicklung der Anwendung wird erleichtert, da die Cli- keiten das erfordern. Darunter würden zum Beispiel
ents nicht mehr über die Existenz bzw. Aufteilung der dringend benötigte Pakete oder Technologien wie ASP.
Microservices Bescheid wissen müssen. NET Web Forms oder WCF fallen, die nicht in .NET
Man sollte jedoch nicht einfach ein einzelnes „monoli- Core verfügbar sind. Ab Visual Studio 2017 ist die Un-
thisches“ Gateway implementieren, sondern muss auch terstützung für Docker bereits standardmäßig enthalten.
hier sowohl die Separation nach Geschäftsprozessen als Für ältere Versionen können die Docker Tools nachins-
auch nach Client-Apps einhalten (Abb. 2). Anderenfalls talliert werden [16].
erzeugt man ungewünschte Kopplungen zwischen den Beim Anlegen eines neuen Projekts mit Docker Sup-
Microservices. port wird ein passendes Dockerfile erzeugt. Zusätzlich
Im Falle eines Web-UI mit dem Browser als Inte muss man noch „Container Orchestrator Support“
grationskomponente, dürfte der direkte Ansatz am aktivieren, um für das Projekt ein Docker Compose
einfachsten umzusetzen sein. Die Entwicklung nativer anzulegen bzw. zu aktualisieren. Es enthält mit der
Apps für diverse Endgeräte erzwingt dagegen den API- Datei docker-compose.yml die Konfigurationsdaten
Gateway-Ansatz, bei der die Microservices im Backend der Container und Deployment-Umgebung. So kann
einer übergeordneten Präsentationsschicht arbeiten später für jeden Service ein separates Docker Image
(Backend for Frontend). Dieses Muster ist auch dann erstellt werden. Der Entwicklungsworkflow in Visu-
zu bevorzugen, wenn man besonders viel ausgeklügelte al Studio bleibt sonst größtenteils unverändert. Beim
Logik in der Oberfläche unterbringen will. Zwar sind
die Microservices ohne eigenes GUI nicht mehr unbe-
dingt als vollständige Anwendungen zu betrachten,
dennoch stellt das API-Gateway-Pattern keine Ver-
letzung der Microservices-Philosophie dar. Die Unab- Microservices (Teil 1): Pragmati-
hängigkeit der Services untereinander, einschließlich sche Architekturen mit .NET Core
ihrer Datenhoheit, bleibt bei richtiger Umsetzung er-
halten [11].
– Patterns & Code
Christian Weyer (Thinktecture)
Entwicklung mit Visual Studio und Docker Angetrieben von möglichen Nachtei-
Microsoft empfiehlt, die Vorteile von Docker bei Ent- len einer monolithischen Architektur
wicklung, Deployment und Betrieb von Anwendungen sollen Microservices und damit verbun-
mit Microservices-Architektur zu nutzen. Für jeden Mi- dene Designpatterns und -ideen das
scheinbare Allheilmittel sein. In diesem Vortrag erklärt
croservice wird ein eigenes Docker Image erstellt, sodass
Christian Weyer, was Microservices sind, was sie nicht
zur Laufzeit schnell beliebig viele Instanzen in Form von sind, wann man sie einsetzt und vor allem: Wie man
Docker-Containern erstellt werden können. Für diesen Microservices in der .NET-Core-Welt baut. Sehen Sie
Ansatz mit allen damit verbundenen Fragestellungen Architekturansätze und Patterns in Aktion und erleben
existiert eine umfangreiche Dokumentation [1], [12]- Sie Technologien wie Service Discovery, Web-APIs,
[15]. Docker-Container passen gut in das Konzept der Push Messaging, Message Queuing und Co. im
Microservices, da sie unabhängiges Deployment und praktischen Einsatz. Versuchen wir also gemeinsam,
langweilige Architekturthemen spannend zu machen –
Skalieren unterstützen.
auf pragmatische Weise.
Microsoft bietet in Visual Studio und Visual Studio
Code integrierte Unterstützung für die Entwicklung von
www.basta.net 13DOSSIER Sicherheit
Abb. 3: Containerclusters abstrahiert und so das Management
Auswirkung
von Auto-
einer Multicontaineranwendung ermöglicht. Er er-
nomie und laubt eine einfache Steuerung der Anwendung inklu-
Komplexi- sive Scheduling, Load Balancing und Gewährleistung
tät bei der von Verfügbarkeit und Robustheit. Plattformen, die
Entwick-
lung von
als Orchestrator agieren können, sind beispielsweise
Monolithen Azure Service Fabric, Kubernetes, Docker Swarm und
und Micro- Mesosphere DC/OS [18]-[22].
services
(Quel-
le: [26])
Wann verwendet man Microservices?
So lange die Prozesse eines Unternehmens oder eines
Geschäftsbereichs durch eine Anwendung mit mo-
nolithischer Architektur abgebildet werden können,
besteht kein Handlungsbedarf. Auch wenn die Anwen-
dung schnell auf schwankende Last reagieren können
muss, ist es nicht unbedingt nötig, den Flaschenhals
Starten der Anwendung werden die Docker Images im System als eigenen Service auszulagern. Nutzt man
automatisch gebaut und direkt in Docker gestartet. Docker, kann man einfach den gesamten Monolith in
Auch eine Multicontaineranwendung kann in Visual einem Container deployen und bei Bedarf zusätzliche
Studio debuggt werden. In Microsofts Visual-Studio- Instanzen hochfahren. Wird das System aber zu kom-
Dokumentation [17] wird erläutert, wie man eine plex und steigt der Organisationsaufwand, dann wird
Containeranwendung direkt in die Azure Container es zunehmend schwerer, die Weiterentwickelung voran-
Registry deployen kann. Das Deployen und Testen zutreiben, dabei das System wartbar zu halten und den
sollte so früh wie möglich in Docker geschehen, da Qualitätsanforderungen gerecht zu werden. Dann lohnt
so die Produktivumgebung exakt reproduziert werden sich der Übergang zu einer Microservices-Architektur,
kann. um der Komplexität Herr zu werden.
Um das System skalierbar zu machen, muss man Während komplizierte – aber nicht komplexe –
eine Vielzahl Container gebündelt als Cluster mana- Fachlichkeit gut durch monolithische Systeme abge-
gen und je nach Last die Anzahl der Service-Instan- bildet werden kann, lassen sich komplexe Systeme
zen automatisch anpassen. Das wird erst durch einen aufgrund einer Vielzahl wechselwirkender Teilsys-
Orchestrator ermöglicht, der die Komplexität eines teme nicht vollständig analysieren und nur teilweise
steuern. Es ist daher nicht möglich, die optimale Ar-
chitektur eines komplexen Systems vorab zu bestim-
men. Diese muss viel mehr iterativ entwickelt werden,
wobei praktische Erfahrungswerte einfließen können.
Damit das möglichst unkompliziert vonstattengehen
Microservices (Teil 2): Serverless-
kann, sind z. B. kurze Releasezyklen, eine effektive
Architekturen – Event-basiert mit Delivery Pipeline und geringer Kommunikationsbe-
Azure Functions und Co. darf durch kleine Teams nötig, wie es eine Micro-
Christian Weyer (Thinktecture) services-Architektur ermöglicht [23].Daraus folgt
Wie bitte? Ohne Server? Ähm … Ja, allerdings auch, dass es gefährlich ist, Microservices
in der Tat. Der Serverless-Ansatz auf der grünen Wiese zu entwickeln. Wählt man an
verspricht mit niedrigen Hürden den kritischen Stellen den falschen Service-Schnitt, kann
Einstieg in Microservices zu finden. In das folgenschwere Konsequenzen nach sich ziehen. Je
diesem Vortrag zeigt Christian Weyer die Grundla- besser man die Geschäftsprozesse und das Verhalten
gen von Serverless mit Azure und .NET Core anhand einer funktionierenden (aber schwer erweiterbaren)
praktischer Anwendungsfälle. Auf Basis erprobter
monolithischen Anwendung studieren kann, desto
Designpatterns können Sie mit Azure Functions, Azure
Service Bus und Co. in kurzer Zeit sowohl einfache besser kann man einschätzen, wo der optimale Schnitt
als auch komplexe Services-Anwendungen designen zu setzen ist. Es ist allerdings anzumerken, dass diese
und implementieren – lokal und in der Cloud. Einer Frage in der Literatur [24], [25] kontrovers diskutiert
der Schlüssel ist hierbei das Denken in Events, über wird (Abb. 3) .
die Daten übertragen, verarbeitet und weitergeleitet
werden. Kommen Sie vorbei – eventuell lernen Sie die Fazit
Basis für Ihr neues Businesssoftware-Backend kennen.
Der Einsatz von Microservices zielt darauf ab, kom-
plexe Anwendungen, die als Monolith nur schwer zu
HINWEIS: Dieser 2. Teil setzt Grundwissen aus Teil 1 managen wären, durch Dezentralisierung und Auto-
voraus! nomiemaximierung skalierbar, wartbar und leicht er-
weiterbar zu machen. Jeder Microservice erfüllt dabei
www.basta.net 14DOSSIER Microservices & APIs
genau eine Funktion im Sinne der fachlichen Logik. [7] https://www.jaegertracing.io
Die wichtigsten Treiber in Richtung Microservices sind [8] https://www.appdynamics.com
hohe Komplexität, hoher Innovationsbedarf sowie [9] https://www.informatik-aktuell.de/entwicklung/methoden/
Leidensdruck bei der Skalierung. Microservices erben microservices-sind-verteilte-systeme-asynchronitaet-und-eventual-
allerdings alle Probleme, die aus verteilten Anwendun- consistency.html
gen bekannt sind. Service-übergreifendes Monitoring [10] https://www.embarc.de/wp-content/uploads/2016/06/Architektur-
und Logging aber auch Refactoring und Testen stellen Spicker3-Microservices.pdf
eine Herausforderung dar. Zudem muss das System [11] https://www.informatik-aktuell.de/entwicklung/methoden/der-
mit Eventual Consistency und Teilausfällen zurecht- fachliche-schnitt-von-microservices-was-ist-das-was.html
kommen. [12] https://www.docker.com/community-edition
Auf der technischen Seite bringt Docker bei Entwick- [13] https://docs.docker.com/docker-for-windows/
lung und Betrieb von Microservices viele Vorteile wie
[14] de la Torre, Cesar; Microsoft: „Containerized Docker Application Lifecycle
etwa schnelles Deployment und einfache Skalierbarkeit
with Microsoft Platform and Tools“: https://azure.microsoft.com/de-de/
mit sich. Die nahtlose Integration in den Entwicklungs- resources/containerized-docker-application-lifecycle-with-microsoft-
workflow stellt besonders für den .NET-Entwickler ei- platform-and-tools/
nen großen Vorteil dar.
[15] Lasker, Steve: „.NET Docker Development with Visual Studio 2017“:
https://www.youtube.com/watch?v=hFCwfHo_Kbc
[16] https://docs.microsoft.com/aspnet/core/publishing/visual-studio-
Dr. Felix Nendzig studierte Physik am KIT und der Uni-
tools-for-docker/
versität Heidelberg, wo er auch promovierte. Der Wech-
sel in die IT-Branche führte ihn zur Accso – Accelerated [17] https://docs.microsoft.com/en-us/azure/vs-azure-tools-docker-
Solutions GmbH, wo er als erfahrener Senior Software hosting-web-apps-in-docker/
Engineer tätig ist. [18] https://azure.microsoft.com/documentation/articles/container-service-
intro/
[19] https://docs.docker.com/swarm/overview/
Links & Literatur
[20] https://docs.docker.com/engine/swarm/
[1] https://docs.microsoft.com/de-de/dotnet/standard/microservices- [21] https://docs.mesosphere.com/1.10/overview/
architecture/ [22] http://kubernetes.io
[2] https://martinfowler.com/bliki/BoundedContext.html [23] https://www.informatik-aktuell.de/entwicklung/methoden/
[3] https://de.wikipedia.org/wiki/Gesetz_von_Conway microservices-nur-bei-ausreichender-komplexitaet.html
[4] https://www.informatik-aktuell.de/entwicklung/methoden/wie-gross- [24] https://martinfowler.com/bliki/MonolithFirst.html
darf-ein-microservice-sein-und-ist-das-ueberhaupt-wichtig.html [25] https://martinfowler.com/articles/dont-start-monolith.html
[5] https://www.elastic.co/de/elk-stack [26] https://www.informatik-aktuell.de/entwicklung/methoden/wann-und-
[6] https://zipkin.io fuer-wen-eignen-sich-microservices.html
www.basta.net 15DOSSIER Microservices & APIs
Git erobert die Entwicklerwelt
Go Git!
Git ist „hip“ und gilt als Star unter den Versionskontrollsystemen. Der Grund dafür ist
einfach: Git ist schnell, leistungsfähig und plattformunabhängig. Kein Wunder, dass im-
mer mehr Teams, vor allem auch aus der Microsoft-Welt, den Umstieg planen. Doch um
Git optimal zu nutzen, ist fundiertes Hintergrundwissen nötig – denn Git arbeitet von
Grund auf anders als die bekannten „klassischen“ Systeme. Richtig eingesetzt macht Git
aber ordentlich Spaß – durch mehr Performance, Produktivität und Flexibilität im Ent-
wicklungsalltag.
von Uwe Baumann stands, zum Abrufen früherer Versionen sowie zum
Verwalten von Varianten mittels Branching und Mer-
Eigentlich – so schien es – war das Thema Versions- ging.
kontrolle in der Microsoft-Welt abgehakt: Team Aber der Schein trügt: Git funktioniert intern kom-
Foundation Version Control (TFVC) als ausgereif- plett anders, denn es ist als dezentrales System aus-
tes, stabiles System war gesetzt – als Open-Source- gelegt. Das bedeutet: Während TFVC und Subversion
Alternative stand Apache Subversion bereit –, um den auf eine zentral verwaltete Datenbank setzen (Abb. 1),
Rest des Kuchens stritten sich Systeme wie Perforce kommt Git auch gut ohne zentrale Datenbank aus. Je-
und Rational ClearCase. Doch dann kam Git und er- der Nutzer hat vielmehr seine eigene Datenbank, unter
oberte die Welt im Sturm: Nach der aktuellen Umfra- Git „Repository“ oder kurz „Repo“ genannt (Abb. 2).
ge des Entwicklerportals Stack Overflow nutzen rund Unter Git arbeitet man die meiste Zeit mit dieser lo-
87 Prozent der Entwickler Git; Subversion und TFVC kalen Datenbank und kann dann die erzeugten Ände-
landen mit 16,1 und 10,9 Prozent abgeschlagen auf rungen (Commits) mit den anderen Projektbeteiligten
den Plätzen zwei und drei [1]. austauschen. Obwohl Git dies nicht erfordert, wird
Was ist der Grund für den kometenhaften Aufstieg hier dann doch wieder auf die bewährte Architektur
von Git? Was macht Git anders als die etablierten mit einem Zentralserver (Blessed Repository) zurück-
Platzhirsche? Und was gibt es zu beachten, wenn man gegriffen.
das eigene Team auf Git migrieren will? Die wichtigs-
ten Antworten auf diese Fragen möchte ich Ihnen im Schnell, sicher, flexibel
Folgenden liefern. Das lokale Arbeiten bringt einige Vorteile mit sich: Git
reagiert generell extrem schnell auf Benutzereingaben –
Zentral versus dezentral es müssen ja nicht für jede Aktion langsame Netzwerk-
Wer sich ein Git Cheat Sheet (wie es diesem Heft bei- zugriffe durchgeführt werden. Diese gute Performance
liegt) besorgt, könnte den Eindruck bekommen, dass ist in der täglichen Praxis deutlich spürbar.
Git eigentlich nur eine Variante des bereits bekannten „Völlig losgelöst“ vom Server arbeiten zu kön-
Musters darstellt: Befehle zum Sichern des Versions- nen, erhöht auch die Flexibilität bei der Arbeit mit
www.basta.net 16Sie können auch lesen
