Successfully reported this slideshow.

Wer braucht eigentlich Microservices - Aktuelle Trends der Softwareentwicklung in der Praxis

1

Share

1 of 56
1 of 56

More Related Content

Related Books

Free with a 14 day trial from Scribd

See all

Related Audiobooks

Free with a 14 day trial from Scribd

See all

Wer braucht eigentlich Microservices - Aktuelle Trends der Softwareentwicklung in der Praxis

  1. 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. 2. …und dann erzählte er mir, dass er einen Monolithen entwickelt. Copyright 1997 New Line Cinema
  3. 3. Copyright 2015 Scott Adams - http://dilbert.com/strip/2015-12-20
  4. 4. mgkaya - Copyright 2008 - http://www.istockphoto.com/de/foto/verzweifelt-geschäftsmann-gm483617735-7529059
  5. 5. Stefan Macke http://soa.rocks anwendungsentwickler podcast.de @StefanMacke
  6. 6. BarnImages - CC0 Public Domain - https://pixabay.com/de/apple-geschäft-cafe-kaffee-971117/
  7. 7. BRAIN_PAIN - CC0 Public Domain - https://pixabay.com/de/stehende-kugel-kugel-munition-1138905/
  8. 8. Monam - CC0 Public Domain - https://pixabay.com/de/gerechtigkeit-waage-gleichgewicht-423446/
  9. 9. Budzlife - creativecommons.org/licenses/by/2.0/ - www.flickr.com/photos/budslife/1771179517/ katja - CC0 Public Domain - https://pixabay.com/de/faultier-zweizehenfaultier-regenwald-1448822/ kikatani - CC0 Public Domain - https://pixabay.com/de/elefant-afrika-afrikanischer-elefant-111695/lostmaxi - CC0 Public Domain - https://pixabay.com/de/roter-panda-zoo-tier-1434921/ Microservices REST Single Page Apps NoSQL
  10. 10. Redis Elixir Mongo DB Node.js Neo4j Groovy REST Microservices SPAs
  11. 11. Microservices Hans - CC0 Public Domain - https://pixabay.com/de/ameisen-waldameisen-hand-gefahr-4239/
  12. 12. 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
  13. 13. SOA done right!
  14. 14. Unsplash - CC0 Public Domain - https://pixabay.com/de/bergsteigen-bergsteiger-berg-802099/
  15. 15. 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/
  16. 16. 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
  17. 17. REST REST Pipsimv - CC0 Public Domain - https://pixabay.com/de/faultier-tier-faul-schlafen-359217/
  18. 18. Geek & Poke - http://geek-and-poke.com/geekandpoke/2013/6/14/insulting-made-easy
  19. 19. 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
  20. 20. 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/
  21. 21. POST /users? POST /sessions? GET /login? PUT /user/1/login? User Login
  22. 22. Wert ist zu lang? Parameter fehlt? Falsches Format? Wert ist null? 400 Bad Request
  23. 23. Geek & Poke - http://geek-and-poke.com/geekandpoke/2016/10/18/simply-explained
  24. 24. http://my-api/v4 http://my-api/v1 http://my-api/v2 http://my-api/v3 http://knowyourmeme.com/memes/facepalm
  25. 25. {"Herausgeber":"Xema","Nummer":"1234 -5678-9012-3456","Deckung":2e+6,"Wae hrung":"EURO","Inhaber":{"Name":"Must ermann","Vorname":"Max","maennlich":t rue,"Hobbys":["Reiten","Golfen","Lesen"] ,"Alter":42,"Kinder":[],"Partner":null}}
  26. 26. SPAs SPAs atuweb - CC0 Public Domain - https://pixabay.com/de/roter-panda-zoo-hübsch-970798/
  27. 27. <body> <div ng-app="my-app" /> <script src="myapp.js" /> </body>
  28. 28. NoSQL baluda - CC0 Public Domain - https://pixabay.com/de/afrika-elefant-text-tier-savanne-466602/
  29. 29. Jenn Vargas - https://creativecommons.org/licenses/by-nc-nd/2.0/ - https://www.flickr.com/photos/foreverdigital/3375076856/
  30. 30. Thaliesin - CC0 Public Domain - https://pixabay.com/de/bauklötze-steine-bunt-spielzeug-1563961/
  31. 31. Fazit PDPics - CC0 Public Domain - https://pixabay.com/de/rückspiegel-spiegel-fahrrad-167054/
  32. 32. O’Reilly - https://www.oreilly.com/people/35c9606b-5b03-45c2-b4a8-aa3df4910c95 Quelle: https://www.oreilly.com/ideas/are-microservices-for-you- you-might-be-asking-the-wrong-question Should I use microservices? Why do you want to change? What isn’t working for you? Sam Newman
  33. 33. Geek & Poke - http://geek-and-poke.com/geekandpoke/2014/11/8/frameworks
  34. 34. Glen Jeffreys - FreeImages.com License - http://de.freeimages.com/photo/the-end-1517690
  35. 35. Microservices? Wer braucht eigentlich http://soa.rocks anwendungsentwickler podcast.de @StefanMacke

Editor's Notes

  • 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.
  • ×