Testen von Microservices -- Erfahrungsbericht und Umfrage

Keynote zusammen mit Dehla Sokenou auf der TAV 44 (https://fg-tav.gi.de/veranstaltung/44-tav): Wegen der Art und Häufigkeit der Fehler in Microservice-Architekturen sollten wir mehr Tests auf höherer Teststufe durchführen und diese im Gesamtsystem ausführen, woraus sich das Test-Rechteck ergibt. Dies entspricht der Dev/Prod-Parity. Andererseits entstehen im Microservice-Umfeld gerade viele Testwerkzeuge, die einen anderen Ansatz verfolgen: die Tests leichtgewichtiger auszuführen als im Gesamtsystem, und trotzdem möglichst viele Fehler finden. (Wann) wird es diesen Tools gelingen, den Tool-Gap so stark zu verkleinern, dass der Dev/Prod-Parity obsolet wird? Wenn die Tests technisch sauber in Testtreiber und Orakel aufgeteilt werden, können die Orakel für mehrere Testtreiber wiederverwendet werden, z.B. in leichtgewichtigeren Testwerkzeugen, aber auch für passives Testen wie Observability.

Transcript

1. Testen von Microservices Erfahrungsbericht und Umfrage David Faragó, EclipseSource & QPR Dehla Sokenou, GEBIT Solutions GmbH
2. Microservices Architekturprinzip für Software Kleine, unabhängig Einheiten, die Daten und Services kapseln • Klare Entkopplung • Auch keine indirekte Kopplung, bspw. über gemeinsam verwendete Datenbankobjekte • Ein Microservice = eine (möglichst kleine) Aufgabe Kommunikation ausschließlich über sprachunabhängige Schnittstellen Do one thing and do it well.
3. Klassische Systeme vs. Microservices Quelle: Kristijan Arsov. What Are Microservices, Actually? https://dzone.com/articles/what-are-microservices-actually
4. Microservices – Umfeld DevOps Container Cloud
5. Microservices – Eine kurze Bilanz Vorteile • Klare Verantwortlichkeiten für Schnittstellen und Daten • Unabhängige Releasezyklen und Deployment • Unabhängige Teams Herausforderungen • Integration der vielen verschiedenen Microservices • Einheitlichkeit, z.B. in Bezug auf die Benutzerschnittstelle • Testen?
6. Microservices Pro & Contra aus Testersicht Aspekt Pro Contra Team Jeder MS kann von anderen Teams getestet werden Verantwortlichkeit für das Gesamtsystem? Software Kleinere unabhängige Einheiten Verknüpfung der MS zusätzliche Komplexität Verteilung Neben Fehlervermeidung auch Recovery (MTBF & MTTR) Schwieriges Testumfeld durch ständige Änderung Umgebung Replikation der Umgebung für Testzwecke Umgebung komplex
7. Aspekt Pro Contra Team Jeder MS kann von anderen Teams getestet werden Verantwortlichkeit für das Gesamtsystem? Software Kleinere unabhängige Einheiten Verknüpfung der MS zusätzliche Komplexität Verteilung Schwieriges Testumfeld durch ständige Änderung Umgebung Replikation der Umgebung für Testzwecke Umgebung komplex Microservices Pro & Contra aus Testersicht Umfrage: Kommen Sie in Berührung mit der Entwicklung von Microservices?
8. Software-Fehlerklassifizierung Die weitaus meisten Fehler sind nicht funktionaler Art!
9. Software-Fehlerklassifizierung Umfrage: In welche Klassen fallen Ihre Fehler?
10. Teststufen gestern Test-Pyramide
11. Teststufen heute Test-Hut
12. Teststufen morgen Erweiterte Test- Pyramide
13. Teststufen und Werkzeuge xUnit AssertJ Mocking-Frameworks Hoverfly Arquillian testcontainers.org PACT REST-assured Moco Pretender mountebank Cukes in Space! Selenium Arquillian Cube Observatiliby-Tools Serenity BDD Postman Cucumber
14. Teststufen und Werkzeuge Umfrage: Wieviel Prozent testen Sie auf jeder Teststufe?
15. Twelve-Factor-App # Factor Description I Codebase There should be exactly one codebase for a deployed service with the codebase being used for many deployments. II Dependencies All dependencies should be declared, with no implicit reliance on system tools or libraries. III Config Configuration that varies between deployments should be stored in the environment. IV Backing services All backing services are treated as attached resources and attached and detached by the execution environment. V Build, release, run The delivery pipeline should strictly consist of build, release, run. VI Processes Applications should be deployed as one or more stateless processes with persisted data stored on a backing service. VII Port binding Self-contained services should make themselves available to other services by specified ports. VIII Concurrency Concurrency is advocated by scaling individual processes. IX Disposability Fast startup and shutdown are advocated for a more robust and resilient system. X Dev/Prod parity All environments should be as similar as possible. XI Logs Applications should produce logs as event streams and leave the execution environment to aggregate. XII Admin Processes Any needed admin tasks should be kept in source control and packaged with the application.
16. Twelve-Factor-App # Factor Description I Codebase There should be exactly one codebase for a deployed service with the codebase being used for many deployments. II Dependencies All dependencies should be declared, with no implicit reliance on system tools or libraries. III Config Configuration that varies between deployments should be stored in the environment. IV Backing services All backing services are treated as attached resources and attached and detached by the execution environment. V Build, release, run The delivery pipeline should strictly consist of build, release, run. VI Processes Applications should be deployed as one or more stateless processes with persisted data stored on a backing service. VII Port binding Self-contained services should make themselves available to other services by specified ports. VIII Concurrency Concurrency is advocated by scaling individual processes. IX Disposability Fast startup and shutdown are advocated for a more robust and resilient system. X Dev/Prod parity All environments should be as similar as possible. XI Logs Applications should produce logs as event streams and leave the execution environment to aggregate. XII Admin Processes Any needed admin tasks should be kept in source control and packaged with the application. Umfrage: Wie wichtig ist für Sie Dev/Prod-Parity?
17. Teststufen morgen (2) so niedrig wie möglich (Shift Left) Test-Rechteck
19. Staging Green/Blue bzw. Red/Black-Deployment Quelle: Jason Skowronski. Intro to deployment strategies: blue-green, canary, and more. https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
20. Staging Green/Blue bzw. Red/Black-Deployment Quelle: Jason Skowronski. Intro to deployment strategies: blue-green, canary, and more. https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
21. Staging Canary-Deployment Quelle: Jason Skowronski. Intro to deployment strategies: blue-green, canary, and more. https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
22. Staging Canary-Deployment Quelle: Jason Skowronski. Intro to deployment strategies: blue-green, canary, and more. https://dev.to/mostlyjason/intro-to-deployment-strategies-blue-green-canary-and-more-3a3
23. Testtreiber
24. Testtreiber FAULT INJECTION
25. CHAOS MONKEY TESTING Testtreiber FAULT INJECTION
26. Observability / Fehleranalyse ELK-Stack Leichtgewichtige Alternative: Graylog & Grafana LOG Process Store Visualize
27. Observability / Fehleranalyse ELK-Stack Leichtgewichtige Alternative: Graylog & Grafana LOG Process Store Visualize Umfrage: Verwenden Sie Observability/Monitoring?
28. Fazit Dev/Prod-Parity Shift left (niedrigere Teststufe) möglich?
29. Diskussion und Fragen Umfrage: Wieviel Prozent testen Sie auf jeder Teststufe? Umfrage: In welche Klassen fallen Ihre Fehler? Umfrage: Kommen Sie in Berührung mit der Entwicklung von Microservices? Umfrage: Wie wichtig ist für Sie Dev/Prod-Parity? Umfrage: Verwenden Sie Observability/Monitoring?