Sicherheitsbetrachtung der Cloudifizierung von Smart- Devices
Wer braucht eigentlich Microservices - Aktuelle Trends der Softwareentwicklung in der Praxis
1. Microservices?
hbieser - CC0 Public Domain - https://pixabay.com/de/termitenhügel-ameisen-landschaft-695209/
Wer braucht eigentlich
Aktuelle Trends der Softwareentwicklung in der Praxis
2.
3. …und dann erzählte er mir,
dass er einen Monolithen entwickelt.
Copyright 1997 New Line Cinema
19. Microservices
Hans - CC0 Public Domain - https://pixabay.com/de/ameisen-waldameisen-hand-gefahr-4239/
20. Ade Oshineye - Martin tells it like it is, CC BY 2.0, https://commons.wikimedia.org/w/index.php?curid=2938441
Quelle: http://www.martinfowler.com/articles/microservices.html
• Architekturstil
• mehrere kleine Prozesse
• leichtgewichtige Kommunikation
• individuell deploybar
• unterschiedliche Sprachen
• unterschiedliche Persistenz
Martin Fowler
22. Unsplash - CC0 Public Domain - https://pixabay.com/de/bergsteigen-bergsteiger-berg-802099/
23. Activedia - CC0 Public Domain - https://pixabay.com/de/schildkröte-natur-grün-wild-1309900/ Unsplash - CC0 Public Domain - https://pixabay.com/de/gepard-jagd-leopard-tierwelt-tier-731293/
24.
25. Arnon Rotem-Gal-Oz - https://twitter.com/arnonrgo
Quelle: http://arnon.me/2014/03/services-microservices-nanoservices/
A nanoservice is a service whose
overhead (communications,
maintenance, and so on) outweighs
its utility.
Arnon
Rotem-Gal-Oz
26.
27. REST
REST
Pipsimv - CC0 Public Domain - https://pixabay.com/de/faultier-tier-faul-schlafen-359217/
29. Roy Fielding - https://twitter.com/fielding
Quelle: https://www.ics.uci.edu/~fielding/pubs/
dissertation/rest_arch_style.htm
Representational State Transfer
• ressourcenorientiert
• zustandslos
• einheitliche Schnittstelle
Roy Fielding
30.
31. yunjeong - CC0 Public Domain - https://pixabay.com/de/rubber-duck-ente-puppe-546253/bykst - CC0 Public Domain - https://pixabay.com/de/speckstein-stein-grabstein-material-447299/
Herzlich Willkommen zum ersten Vortrag der SEROM 2016! :-D
Im Sinne des Konferenzthemas möchte ich über die Alltagstauglichkeit moderner Technologien im Mittelstand sprechen.
Auf den „großen“ Konferenzen (z.B. JAX, BASTA, RubyConf) findet man aktuelle Beispiele für Vorträge zu allerlei modernen Themen.
Da kann man sich schon komisch vorkommen, wenn man nicht die neusten Technologien einsetzt.
Manchmal denke ich, dass der Einsatz der Technologien um ihrer selbst Willen erfolgt und eigentlich gar kein Problem löst.
Also ist das alles auch relevant für mittelständische Betriebe im Oldenburger Münsterland?
Ich arbeite in genau solch einem Unternehmen.
Ich bin Softwarearchitekt und -entwickler in einem mittelständischen Unternehmen (ca. 2km Luftlinie vom Fizz entfernt).
Und wir entwickeln weniger „moderne“ Webanwendungen, sondern „klassische“ Enterprise-Software.
Bei uns wird noch „richtig“ gearbeitet!
Das ist übrigens mein Arbeitsplatz.
Unser Kernprodukt ist VERSIS…
…auf Basis von Adabas/Natural.
Und VERSIS ist kein moderner Web-Hipster, sondern eher der Linux-Greybeard.
VERSIS dürfte sogar schon Auto fahren ;-)
Das bedeutet nicht, dass ich etwas gegen moderne Themen habe! Im Gegenteil: Ich finde sie richtig spannend!
Ich bin nur der Meinung, dass man nicht jeden Trend mitmachen sollte ohne nachzudenken.
Es gibt keine Silver Bullet, die alle Probleme löst.
Jede Technologie hat Vor- und Nachteile. Und ich fokussiere heute mal die Nachteile der aktuellen Trends.
Ich habe 20 Minuten Zeit, daher kann ich leider nicht alle Trends „bashen“, sondern muss eine Auswahl treffen.
Es gibt zu jedem Thema immer eine kurze Erklärung, dann werden mögliche Alternativen/Vorgänger genannt und zum Schluss werden einige Nachteile gezeigt.
Dies ist eine Architekturskizze mit den genannten Technologien (REST, Microservices, SPA, NoSQL).
Fangen wir an mit dem aktuellen Ober-Hype-Thema Microservices.
Was sind eigentlich Microservices? Martin Fowler fasst in seinem Artikel die zentralen Eigenschaften zusammen.
Und hier noch eine kurze und knackige Zusammenfassung!
I guess it is easier to use a new name (Microservices) rather than say that this is what SOA actually meant (http://arnon.me/2014/03/services-microservices-nanoservices/)
Die „klassische“ Alternative zu Microservices wäre der gute alte Monolith.
Im Vergleich zu direkten Methodenaufrufen (1ns) im Monolithen sind Aufrufe per HTTP enorm langsam (10.000ns).
Das spielt für einzelne Benutzer wahrscheinlich keine Rolle, aber für Massenprozesse sicherlich.
Siehe auch:
https://gist.github.com/jboner/2841832
http://java-is-the-new-c.blogspot.de/2015/06/dont-rest-revisiting-rpc-performance.html
http://stackoverflow.com/questions/27248559/does-java-take-time-to-call-a-method
https://plumbr.eu/blog/performance-blog/how-expensive-is-a-method-call-in-java
Die Option, Microservices in unterschiedlichen Technologien zu entwickeln, mag sich für Entwickler spannend anhören, aber welches Unternehmen will das wirklich? Außerdem sind technische Hilfen (wie z.B. automatische Refactorings) ggfs. technologieübergreifend nicht möglich.
Durch die mehreren Sprachen wird eine komplexere Infrastruktur nötig, z.B. mehrere Build-Tools, Deployment-Pipelines, API-Versionierung.
Das geht bei sog. „Nanoservices“ noch weiter. Das gezeigte Zitat fasst die Sinnhaftigkeit dieses Ansatzs gut zusammen.
Ein häufiges Beispiel für Vorteile von Microservices ist der mögliche Ausfall einzelner Systemteile.
Beispiel Netflix: Empfehlungen sind weg -> Rest der Anwendung läuft weiter.
Das ist nett, aber was ist in einer Enterprise-Anwendung, wenn ein zentraler Service fehlt? Welche echte Anwendung besteht aus hauptsächlich optionalen Komponenten?
Weiter geht‘s mit dem nächsten großen Thema: Representational State Transfer.
Heutzutage ist es schon fast eine Beleidigung, wenn man nicht „restful“ entwickelt.
Doch was ist REST eigentlich genau? REST ist ein Architekturprinzip für verteilte Systeme, das die Grundlage des WWW bildet.
Häufig wird JSON als Format für den Datenaustausch verwendet.
Die Alternative zu REST ist „klassisches“ SOAP mit XML-Nachrichten.
Ich vergleiche SOAP mit statischer Typisierung und REST mit dynamischer. Bei REST gibt es so gut wie keine Validierung der Nachrichten, Services sind schlecht dokumentierbar und eine Codegenerierung wie bei SOAP ist praktisch nicht möglich.
Das „Uniform Interface“ ist eine tolle Idee, doch nicht jede Aktion lässt sich sinnvoll als CRUD-Operation abbilden. Bitte nicht einfach alle Entitäten komplett über REST freigeben -> Geheimnisprinzip verletzt!
Die Kennzeichnung von Fehlersituationen ist auch schwierig, da sich nicht alle Situationen auf HTTP-Statuscodes abbilden lassen.
Die angeblich so tolle „lose Kopplung“ wird in der Praxis auch selten benötigt.
Wann werden z.B. Server und Client unabhängig voneinander weiterentwickelt?
Stattdessen landet man meistens in der API-Versionierungshölle.
Exkurs: JSON (das häufig als Austauschformat verwendet wird) kann im Vergleich zu XML nicht spezifiziert/validiert werden.
Es sind (aufwändige) dynamische Tests nötig, um Änderungen mitzubekommen.
Das nächste Thema sind die „Single Page Apps“.
Single Page Apps sind Webanwendungen, die aus einer einzigen HTML-Datei bestehen und den eigentlich Inhalt dynamisch nachladen.
So könnte eine Seite aussehen, die gerade vom Browser geöffnet wurde.
Erst ein paar Sekunden später sind die eigentlichen Inhalte (inkl. Menüeinträge) sichtbar.
Die Alternative zu SPAs sind „klassische“ serverbasierte Webanwendungen, die den Browser nur zur Darstellung der Inhalte nutzen.
Da die Logik im Client abläuft, hat dieser vollen Zugriff auf den Code.
Das könnte ein Sicherheitsproblem sein.
Zumindest bei der Validierung kommt man nicht drum herum, diese doppelt zu implementieren: im Server und im Client.
Außerdem ist meist ein „Polyglot Programming“ nötig, da die Backends oft in anderen Sprachen entwickelt werden (z.B. Java, C#).
Ggfs. führt der intensive Einsatz von JavaScript noch zu anderen Problemen:
Performanceprobleme im lokalen Browser
Browser-Controls funktionieren nicht mehr
Seite läuft gar nicht ohne JavaScript
Suchmaschinen „sehen“ den Inhalt nicht
Und das letzte Thema ist der große Bereich der NoSQL-Datenbanken.
Unter NoSQL werden verschiedene Konzepte bei der Datenhaltung zusammengefasst:
Key-Value-Stores (Redis)
Spaltenorientierte Datenbanken (Cassandra)
Objektorientierte Datenbanken (db4o)
Dokumentendatenbanken (MongoDB)
Graphendatenbanken (neo4j)
Die Alternative sind die guten alten relationalen Datenbanken wie Oracle, SQL Server etc.
Ein zentraler Nachteil der verschiedenen nicht-relationalen Datenbanken ist, dass es keine einheitliche Abfragesprache gibt.
Ggfs. muss man für jedes System eine individuelle Sprache lernen.
Die meisten NoSQL-Datenbanken unterstützen keine Transaktionen. Die werden in vielen Anwendungen aber benötigt.
Bei vielen NoSQL-Datenbanken ist der Vorteil der Schemalosigkeit gleichzeitig ein Nachteil, weil die Toolunterstützung nicht so gut ist.
Außerdem können Unsicherheit bzgl. der tatsächlichen Daten, mangelnde Integrität und schlechte Performance die Folge sein.
Siehe auch: http://de.slideshare.net/infinitegraph/schema-meetupfeb2014key
Damit komme ich auch schon zum Fazit des Vortrags.
Die vorgestellten Technologien bieten viele neue Chancen und eröffnen ganz neue Möglichkeiten bei der Softwareentwicklung.
Nicht umsonst setzen sie viele Top-Unternehmen ein.
Anstatt einfach so auf den Trend-Zug aufzuspringen, sollte man sich zunächst überlegen, was man sich dadurch erhofft.
Und das heißt nicht, dass man jeden Trend mitmachen und seine Software alle 2 Jahre runderneuern muss.
