Wie man Applikationen nicht bauen sollte...

maketechsimple.wordpress.com@atsticks
Wie man Applikationen NICHT bauen
sollte…
Anatole Tresch, Principal Consultant ZH AD

2 2019 – Wie man Applikationen nicht bauen sollte...
Anatole Tresch
Principal Consultant, Trivadis AG (Switzerland)
Spec Lead JSR 352 (Money and Currency)
JSR 382 EG Member
PPMC Member Apache Tamaya
@atsticks
anatole@apache.org
anatole.tresch@trivadis.com
About me

Agenda
▪ Warum dieser Vortrag?
▪ Was so alles "schiefgehen" kann...
Bauplanung
Modularisierung
Know How
Management
Mensch
Organisation
▪ Das Resultat...

Warum dieser Vortrag?
• Immer wieder angetroffene Muster:
Erzeugen enorme unnötige Kosten
Beeinflussen die Qualität der IT-Leistung und damit die
Konkurrenzfähigkeit
Verhindern Innovation und Fortschritt
Erhöhen den Kaffeekonsum beträchtlich

Ziele des Vortrages?
• Ich wünsche mir, dass Sie am Ende des Vortrages
Gewisse Muster in Ihrem Arbeitsumfeld erkennen
Ideen haben, wie sie diese verbessern können
Einfache Lösungen suchen
Oder sich wenigstens wohlgefühlt haben

Bauplanung

Software-Architektur
• Komponenten/Bausteine mit Schnittstellen und Beziehungen
• Strukturen und übergreifende Konzepte
• Nutzen und Ziele
Langlebigkeit, Wartbarkeit, Änderbarkeit, Robustheit
Unterstützung Erstellung und Wartung von Software
Erreichung von Qualitätsanforderungen
Softwarearchitektur unterstützt das Verständnis über das System, bezogen auf
sämtliche relevanten Stakeholder

Wichtige Fragen
• Sind die Projektziele klar?
• Sind die Architekturziele definiert?
• Kennen die Architekten die Technologien?
• Ist das Entwicklungsteam qualifiziert?
• Sind übergreifende Aspekte gelöst?
• Passt die Projekt-Planung und Organisation zu den Zielen & Voraussetzungen?

Ziele?
• Beispiele:
Verbessern unseres Online-Auftrittes
Einführung von Kubernetes
Ablösen eines bestehenden Legacy-Systems.
24/7 Betrieb mit 97.7% Verfügbarkeit
«Cloud Native» Applikation

Module

Module
• Fundamentales Prinzip für die Konstruktion von Software-Systemen:
Wahl der Modularisierungs-Ebene
Bestimmung der dominanten Modularisierungs-Dimension
Berücksichtigung von Conways' Gesetz
Einsatz von Zerlegungskriterien

Modularisierungsebenen
• Methode
• Klasse (ohne Interface).
• Interface
• Package
• Bibliotheken
• Java-Module
• Anwendung (JVM)
• Container
• Pod
• Applikation (mehrere Pods)
• Cloud
• Multi-Cloud

Modularisierungsdimensionen
• Primäre Dimension meistens der Business Context (DDD)
• Sekundäre Dimensionen möglich, z.B. Aufteilung in internals, beans, api
• Bei mehreren gleichberechtigten Dimensionen kommen klassische Konzepte an
ihre Grenzen:
Aspekt-Orientierung
Interzeptoren
…

Das Gesetz von Conway
"Organisationen, die Systeme modellieren, […] sind auf Modelle
festgelegt, welche die Kommunikationsstrukturen dieser
Organisationen abbilden." [Conway1968]

Zerlegungskriterien
• Geheimnisprinzip
• Hohe Kohäsion
• Lose Kopplung
• Single-Responsibility
• Separation of Concerns
• "Don't Repeat Yourself!"
Ursprung: [Parnas1972] – On the Criteria To Be Used in Decomposing Systems into
Modules, David L. Parnas, in: Communications of the ACM, 1972

Know How

Know How
https://landscape.cncf.io/

Hmmm...

"Es macht keinen Sinn, kluge Köpfe einzustellen und ihnen
dann zu sagen, was sie zu tun haben. Wir stellen kluge
Köpfe ein, damit sie uns sagen, was wir tun können."
Stephe Jobs, CEO, Apple

Management

Probleme im Management
Fehlende/unpassende Skills
Unrealistische Zeitvorgaben und fehlende Ressourcen
Replanning und Micromanagement
Hohe Fluktuation
Unklarer Aufträge («Agiles Projekt»)
Unklare Verantwortlichkeiten, fehlende Prozesse
Fehlende Anreize

Faktor Mensch

Faktor Mensch
• Gute Programmierer sind faul
• Gute Programmierer schätzen und fordern Qualität
• Gute Programmierer sind 10-100 Mal effizienter als schlechte
• Gute Programmierer sind manchmal auch kleine Diven
• Gute Programmierer sind … ?
• Gute Manager sind...?
• Gute Leader sind...?
• Gute Menschen sind...?

Faktor Mensch
String reportType;
reportType = VERTRAGSSTADIUM.$1.equals(vertrag.getStadium()) ? Report.VORS : null;
reportType = VERTRAGSSTADIUM.$2.equals(vertrag.getStadium()) ? Report.ANTRAG : null;
switch (vertrag.getStadium()) {
case VERTRAGSSTADIUM.$1:
reportType = Report.VORS;
Break;
case VERTRAGSSTADIUM.$2:
reportType = Report.ANTRAG;
break;
}

Faktor Mensch
return bo.getDokument() != null && bo.getArchivDetail() != null
&& DOKUMENTABLAGE_ART.C.equals(bo.getDokument().getDokablart())
? new Blob(FilenetClient.getInstance().retrieveDocument(DocumentClass.GFB,
bo.getSession().getUserId(),
bo.getArchivDetail().toString()))
:
bo.extractBlob();

Organisation

Organisation
Können wir morgen einen Release bauen?
Da muss ich mal mit dem Buildmanagement
reden.
Und sind die Übersetzungen nun durch das
Backend-Team gefixt?
Können wir denn auch
deployen Ende Woche.
Ja, ich glaube, wir haben eine
Lieferung erhalten, ich muss testen, ob es
nun funktioniert.
Wohl kaum, es ist kein Slot reserviert
worden bei Operations und
das Buidmanagement ist eh überlastet.

Organisation
Können wir nicht einfach bei Azure einen
private Cluster bestellen?
Nein das geht nicht, wir müssen die Systeme
des Mutterhauses benützen.
Aber die funktionieren nicht richtig, oder
hast du schon mal was zum Laufen
gekriegt?
Ist totmühsam, ja, aber wir müssen diese
benutzen: ist einfach so.

Organisation
Können wir nicht einfach einen Kubernetes
Cluster hinstellen, statt uns täglich bis zum
Umfallen manuell zu deployen.
Nein das geht nicht, du weisst ja, dass Hans
unser IT-Leiter Mitgründer ist, und halt auch
noch von der alten Schule. Der hält nichts
von dem neuen Kram...

Organisation
Können wir nicht einfach das RAM auf den
Servern erhöhen? Das wäre eine kleine
Sache und die Probleme wären gelöst...
Ich befürchte, dass mit den Prozessen hier,
wohl zuerst noch das Wasser aufwärts
fliessen wird...
...könnt ihr das nicht bei Euch in der Software
fixen?

Organisation
Wo ist den Beni heute?
Keine Ahnung. Wir werden das wohl
eskalieren müssen. Sonst wir das nichts mit
dem Release nächste Woche...
Und Bea und Remo?
OK, und wer kann den jetzt unsere Backend-
Bugs analysieren?
Der ist nicht mehr im Projekt, arbeitet jetzt
oben bei den Betriebskollegen...
Die kommen später, sind aber auch nur noch
heute da...

Das Resultat...

Ein Beispiel
• Applikation zur Ablösung eines bestehenden Fat Client im Versicherungsumfeld
• Benutzer Makler, Vermittler, Partner und Direktions-MA
-> Max. 40 parallele Benutzer
• Mehrstufiger Ausbau, Start mit Motorfahrzeug-Sparte

Architekturziel
• «Moderne» browser-basierte Applikation
• Basis Java
• Bestehendes Backend-System muss verwendet werden
• Betrieb auf eigener Infrastruktur
• Performanz nicht schlechter oder besser als bestehendes System
• "Blueprint" auch für andere Applikationen

System-Kontext

Architekturentscheide
• Angular-basiertes Single-Page-UI
• SpringBoot/Java 8
• Maven Build
• Versionsverwaltung mit Subversion
• Laufzeit: Bestehende JBoss-Server
• "Stateless": State wird im UI verwaltet
• UI/Business Layer benutzt eigenen ValueObject-Layer
• Generalisierte Funktionen als Microservices
• Projekt soll auch wiederverwendbare Artifakte für andere Projekte liefern

Reality-Check
• SpringBoot/Java 8
• Laufzeit: Bestehende JBoss-Server
-> Spring Boot verhält sich Standalone, in Tomcat und in JBoss nicht immer gleich
-> Deployment durch eigenes (überlastetes) Build-Management Team
-> Keine clean deployments, marginale Prozesskontrollen
-> Kein Applikationsmonitoring
-> Intrasparente Security Mechanismen

Reality-Check
• Projekt soll auch wiederverwandbare Artifakte für andere Projekte liefern
-> Generalisierte Funktionalität, Bibliotheken und Applikationsartifakte in einem
einzigen Maven-Multimodule-Projekt/Repository
-> Vermischung mit Deployment-Artifakten des Build-Management
-> Keine Architekturvision
• -> keine separate Versionierung generalisierter Artifakte und Applikationen

Reality-Check
• "Stateless": State wird im UI verwaltet
• UI benutzt eigenen ValueObject-Layer
-> Alle Benutzerdaten gehen bei UI-Absturz verloren
-> Legacy Backend verlangt Vorhalten des ganzen Arbeitskontextes
-> Hohe Komplexität im UI
-> RPC-artige Schnittstelle zum Business-Tier
-> Duplizierung der Backend Logik auf dem Business-Tier

Reality-Check
• Angular-basiertes Single-Page-UI
-> eigenes UI Team/UI Projekt
-> höhere Komplexität und Kommunikationsaufwendungen
-> bei 40 parallelen Benutzern technisch nicht nötig

Reality-Check
• Versionsverwaltung: Subversion
-> Mehrere Projekt-Teams auf demselben Repository
-> Qualitäts- und Stabilitätsprobleme
-> Enorme Merge-Aufwendungen

Problembereich Backend

Backend - Database
• Versionierung Datenbank ausserhalb Kontrolle des Projektteams
• Regelmässige Updates
• Oft mit unvorhergesehenen Verhaltensänderungen verbunden
• Termine nur sehr eingeschränkt beeinflussbar
• Update-Zwang

Backend – Legacy-Server
• Komplexe Eclipse OSGI basierte Installation
• Intransparente Architektur
• Regelmässige Serverupdates (parallel zu DB) mit Verhaltensänderungen und
gebrochenen Schnittstellen
• Erweiterungen/Anpassungen unter Kontrolle des Server-Teams (Antrags-gesteuert)
• Eingeschränkt skalierfähig (pro 5 Benutzer = 1 Instanz)
• Nur spezifische Bereiche unter Kontrolle Applikations-Projektteam

Das Resultat...

Erreichte Verbesserungen

• Vereinfachung/Entkopplung des Maven Build-Baums, Minimalisierung der
Querabhängigkeiten, Entfernung von Redundanzen
• Halbierung der benötigten Deployments
• Einführung eines Spring-basierten Modulkonzeptes
• Definition von Service-Schnittstellen
• Reduktion des manuell zu wartenden Codes durch
• Entfernen eines VO-Layers
• Generierung Swagger Client-API

49 2019 – Wie man Applikationen nicht bauen sollte... 49
⚫ Recap!

50 2019 – Wie man Applikationen nicht bauen sollte... 50
Recap
• Managementprobleme potenzieren sich in der IT-Entwicklung
• Overengineering und funktionale Zersplitterung sind des Teufels
• Falsche Anreize wirken extrem demotivierend
• Trotzdem ist vieles möglich mit
Entsprechendem Know How
Ein wenig Durchsetzungsvermögen
Und Mut!

DANKE!
Q&A
@atsticks
Anatole.tresch@trivadis.com

Wie man Applikationen nicht bauen sollte...

Recomendados

Recomendados

Mais conteúdo relacionado

Semelhante a Wie man Applikationen nicht bauen sollte...

Semelhante a Wie man Applikationen nicht bauen sollte... (20)

Mais de Anatole Tresch

Mais de Anatole Tresch (20)

Wie man Applikationen nicht bauen sollte...