Jeder von uns kennt sie – die alten PHP-Projekte, die vor vielen Jahren entstanden und heute noch eine wichtige Funktion im Unternehmen erfüllen. Und es gibt ebenso viele Ratschläge, mit diesen Applikationen umzugehen: Tests und Continuous Deployment einführen. Kompatibel zu Symfony2 machen oder gleich dahin portieren – oder doch lieber Laravel? Domain-driven Design und Microservices nutzen, durch Node.js, Go, Rust ersetzen. Der Talk zeigt, welche Optionen man hat, welche Probleme sie jeweils mit sich bringen und wie man sich entscheiden kann.

1. Legacy PHP
Projekte
Sanieren
oder
ablösen?
Legacy PHP Projekte - Sanieren oder ablösen?
Leider wieder so viele Slides, aber wie immer alles zum nachlesen mit Fliesstext auf Slideshare. Es tut mir leid, aber da sind einfach so viele Dinge die so wichtig sind.

2. Das bin ich vor 16 Jahren auf der ersten PHP-Konferenz. Da ging es noch darum, PHP auch in Firmen einzusetzen. Und heute rede ich unter anderem darüber, wie man
es wieder los wird :-)
Das mit dem etablieren scheint ja geklappt zu haben :-)

3. Chief Tailwind Officer @ Mayflower
Viele PHP-Lösungen
gebaut & beraten
Dazu: GoLang, Scala, Java, Python,
Rust, Node.JS etc
Mit Björn, der auf dem Bild nicht zu sehen ist, weil er es macht, habe ich dann Mayflower gegründet - mit der Absicht, PHP mit Schulungen, Support etc für
Unternehmen zugänglich zu machen. Das hat, wie man hier an der Konferenz erkennen kann, ja durchaus geklappt. Wir haben da viele grosse PHP-Lösungen mitgebaut
und auch dabei beraten, aber inzwischen machen wir - wie alle anderen auch - auch viele andere Plattformen.

4. Legacy PHP
Projekte
Sanieren
oder
ablösen?
Und weil wir beide Seiten gut kennen dieser Talk. Ich habe selbst keine Ambitionen, was Programmiersprachen, Plattformen etc angeht. Ich habe parallel einen Macbook,
einen Windows 10 und einen Linux-Laptop, und ein iPhone und ein Android-Handy in der Tasche. Ich mag alle Plattformen. Wenn auch alles was OpenSource ist etwas
lieber. Aber warum der Talk.

5. x
Wenn man an der richtigen Stelle nachguckt, ist PHP immer noch Super erfolgreich. 82.2 % aller Websites werden mit PHP betrieben, sogar gestern Abend noch!
Aber: wenn auf Platz 5 Cold Fusion kommt, dann stimmt daran etwas nicht.

6. x
Github & StackOverflow
Gucken wir doch mal andere Quellen an. Mein Lieblings-Popularitätskontest ist Redmonk, weil er nicht wie Tiobe auf dem Google Dance beruht, sondern schlicht die
Anzahlen auf Stackoverflow und Github zählt. Und da ist PHP oben rechts zu sehen.

7. x
Github & StackOverflow
Faktisch befindet sich PHP in der Redmond-Bewertung des vergangenen Quartals auf Platz 3.
Und guck: kein Cold Fusion. Aber PHP trotzdem vorne.

8. x
http://stackoverflow.com/research/developer-survey-2016
Most Popular
Wenn man sich den Developer-Survey von Stackoverflow anschaut, dann sieht das etwas anders aus. Es kommt zwar wieder JavaScript als erstes, aber PHP wurde hier
von SQL und C# überholt.

9. x
Tiobe Index
Wenn man sich den aktuellen Tiobe-Index anschaut, dann rutscht PHP noch weiter nach unten - nämlich auf Platz 7 - im letzten Jahr war es noch auf Platz 6, vor einigen
Jahren lange Zeit auf Platz 3.

10. x
Tiobe Index
Das zeigt auch die Prozentzahl der Tiobe-Marktforschung. Von mehr als 10% des Marktes sind wir auf nunmehr etwas über 5% gerutscht. Die Ursache ist offensichtlich -
es gibt inzwischen viele Alternativen, 2006 sah das nicht so aus. Und nicht nur das, es gibt inzwischen ziemlich viele ziemlich gute Alternativen.

11. x
http://stackoverflow.com/research/developer-survey-2016
Most Loved
Das hat sich auch unter den Entwicklern rumgesprochen, und wenn man sich die „Most Loved“ Sprachen anschaut, dann sieht man, dass man nichts sieht - PHP
befindet sich nicht unter den ersten 11.

12. x
https://github.com/Dobiasd/programming-language-subreddits-and-their-choice-of-words
Community
Bei der Begeisterungsfähigkeit liegt PHP auch eher hinten. Guckt man sich die Wortnutzung auf Reddit an, dann ist nur jedes 7 Wort ein positives - bei Clojure sind die
Leute bei jedem 5ten Wort begeistert.

13. x
https://github.com/Dobiasd/programming-language-subreddits-and-their-choice-of-words
Community
Sobald man aber auf die Schimpfworte guckt, liegen wir weit vorne. Jedes 35 Wort ist ein Crap, Fuck, Hate oder Shit.

14. Der Ø-Entwickler
würde eigentlich gerne
etwas anderes
einsetzen.
Fazit: Der Durchschnittsentwickler würde heute eigentlich gerne eine andere Programmiersprache verwenden. Aber nicht nur da gibt es Probleme.

15. https://en.wikipedia.org/wiki/Gov._Stanford
Wer von Ihnen hat eine Software im Einsatz, die älter als 5 Jahre ist?

16. http://www.fotocommunity.de/fotograf/peter-raudenkolb/1039860
Und wenn Sie bei Ihnen noch in Produktion ist, wieviel wird an Ihr gearbeitet? Gibt es immer noch regelmässig Updates, Veränderungen und Zusätze? Gibt es Bugs, die
korrigiert werden müssen?
So schlimm wir unsere Legacy-Software finden - Legacy-Software ist immer auch erfolgreiche Software. Würde sie keiner brauchen, dann wäre sie nie zu Legacy-
Software geworden.

17. http://commons.wikimedia.org/wiki/
File:Berrigan_Drummond_Street_Rail_Crossing.JPG
Und da kommen wir auch schon zum Problem - unsere Welt ändert sich die ganze Zeit, und während unsere Lösung für die ursprünglichen Rahmenbedingungen noch
perfekt war, sieht es heute grundlegend anders aus. Und wir passen unsere Software an, damit wir sie weiterbenutzten können.

18. https://en.wikipedia.org/wiki/Road-rail_vehicle
Und am Ende haben wir ein Ergebnis, dem zwar noch die ursprüngliche Intention anzusehen ist, das aber nicht 100% wie die optimale Lösung für unser aktuelles
Problem aussieht.

19. Cost / Feature
Die Kosten pro Feature steigen kontinuierlich
Kosten
Zeit
Und nicht nur das beobachtet man, man beobachtet auch, wie die Development-Performance kontinuierlich sinkt.

20. Junge Applikationen
Recherche ist preiswert => Umsetzung auch
Aber warum ist das der Fall? In einer jungen Applikation gibt es nur wenig Komponten, die genau das tun, was
man von ihnen erwarten würde. Wenn ich eine Änderung mache - hier blau - mache ich sie einfach. Die
tangierten Komponenten - rot - sind bekannt - grün - also kostet mich die Recherche wenig.

21. Alte Applikationen
Recherche ist teuer => Umsetzung auch
Bei alten Applikationen sieht das ganze deutlich anders aus. Hier wurde viel angepasst, und viel ursprüngliche Funktion hat sich in der zwischenzeit geändet. Deshalb
weiss ich weder, auf wen sich das auswirken kann - rot - noch kenne ich die möglicherweise betroffenen Komponenten gut genug um diese Entscheidung mit wenig
Aufwand treffen zu können. Im Resultat investiere ich sehr viel Zeit in Recherche, überall da wo ein möglicher Impact stattfindet - rot - aber kein Knowhow vorhanden ist -
also kein grün - entsteht ein Rechercheaufwand. Und weil diese Effekte über Netzwerk wirken multiplizieren sie sich - und daraus resultieren exponentiell steigende
Recherchekosten.

22. „Komponente 3 ändern“
Was muss alles angefasst werden?
Die Frage nach „wie lange dauert es, Komponente 3 zu ändern“ bedeutet für sie: „Welche Komponenten sind alle betroffen, und wieviel Arbeit steckt dahinter“. Das kann
man erst dann seriös beantworten, wenn man tatsächlich alle möglicherweise betroffenen Komponenten angeschaut hat.
Für Vorgesetzte ist das oft unverständlich „Wie kann denn das so lange dauern, Du musst doch nur Komponente 3 ändern“ :-)

23. Accidental
Complexity
Weniger Programmieren
aber: mehr Recherche
Und es gibt nicht nur die Komplexität, die durch den Businesscase selbst eingeführt wurde.
Wir ITler neigen dazu, selbst Komplexität zu erzeugen. Wir führen Generalisierungen ein, die am Ende mehr Aufwand kosten als dass sie nutzen bringen, wir schreiben
Code, der zwar Schreibarbeit spart, aber Recherchenaufwand erzeugt.

24. Wissen in der Applikation
Es finden sich drei Sorten Wissen in der Applikation
Code
Welchen Code gibt es,
wie hängt er zusammen?
Features Welche Features gibt es?
Motivation
Warum gibt es dieses Feature/
diesen Code?
Damit haben wir drei Sorten von fehlenden Knowledge in der Applikation - den Code selbst, die sich dahinter verbergenden Features, und die Motivation, warum es so
ist, wie es ist. Und beim dritten Punkt handelt es sich sogar um unbekannte Unbekannte, ich weiß also dort noch nicht einmal genau, was ich alles nicht weiß. Es kann
sein, dass ein Feature längst nicht mehr gebraucht wird. Es kann sein, dass eine Softwarestruktur völlig unnötig geworden ist.

25. Wer von Ihnen ist Software-Entwickler?
Wer von Euch ist Software-Entwickler?

26. Zeitinvestment bei Softwareentwicklung
Im Mittel über die Software Lifetime, Quelle: Microsoft
Neuer Code
Bestehenden Code ändern
Analyse von bestehendem Code
Software-Durchleser
Schaut man sich die Zeitverwendung in Softwareprojekten an, dann sind wir in Wahrheit Software-Durchleser, nicht Software-Entwickler. Wir schreiben nur 2% unserer
Zeit neuen Code. Die meiste Zeit - fast 80% - verbringen wir mit dem Lesen von Code. Immerhin 20% unserer Zeit verbringen wir noch mit der Modifikation bestehender
Software.

27. Die Wissenschaft vom Lesen
von Code, den eigentlich
keiner Lesen möchte.
Wenn man es ebenso genau wie zynisch betrachtet verbringen wir also unsere Zeit damit, Code zu lesen, den wir eigentlich gar nicht lesen wollten.
Aber ich gehöre ja auch dazu, ich hatte ja schon erwähnt, dass ich das ganz schön lange mache.

28. (In Wahrheit
debugge ich gerne :-) )
In Wahrheit gibt es aber auch Code, den ich gerne debugge, das hat dann fast etwas von Archäologie.

29. PHP Cowboy Coding Age
1995-2005
Phpnuke, Postnuke,
Drupal, Wordpress
Wer kann sich noch an PHP3 erinnern? In dieser Zeit entstanden Lösungen wie PHPnuke, Postnuke, Drupal, Wordpress, osCommerce und viele andere, die bis heute
laufen und das Rückenmark des Internets stellen.

30. • zum Teil objektorientiert
• keine Design Patterns
• Viel Not-Invented-Here
• Accidental Complexity hoch
• Einarbeitung zäh
• schnell!
• Kündigungsschutz++
Diese Lösungen waren zum Teil objektorientiert, hatten damals noch keine Design-Patterns, wenig Libraries und viel eigene Lösungen.
Heute ist die Einarbeitung zäh, weil man so viele eigene Regeln befolgen muss. Aber - sie Antworten erstaunlich schnell, meist deutlich schneller als eine frische
Symfony-Applikation. Und wenn man sich mal mit einer auskennt die noch gebraucht wird, dann kommt das einem Kündigungsschutz gleich.

31. PHP Cowboy Coding Age
Wer war dabei?
Ich habe 1998 mit PHP 3 angefangen. Die erste Applikation, ein Katalogsystem, habe ich in 3 Tagen geschrieben. Und zwar Mit Spaghetti SQL in Spaghetti PHP in
Spaghetti HTML. Aber: ein komplettes Katalogsystem mit Backend, Nutzerverwaltung und Suche, in 3 Tagen - das ist schon cool. Wer von Euch war noch dabei?
Wer hat heute noch solche Applikationen im Einsatz?

32. ‚Struts/Rails’ MVC Age
2005–2011
Zend Framework,
CakePHP,
Code Igniter
Und damit die vernünftig Programmieren konnte, hat Zend für sie das Zend Framework gebaut, andere haben wie CakePHP Rails nachgebaut.

33. • 100% OO und Design-Pattern
• Schnelle Einarbeitung
• Langsamer!
• Wartbarkeit ok
• Accidental Complexity ok
• Kündigungsschutz—
Damit konnte man PHP praktisch so nutzen wie viele andere Sprachen auch, und die Vorhersehbarkeit und Nachvollziehbarkeit von Code wurde deutlich besser. Ich
freue mich bis heute, wenn ich in einer technischen Bewertung Zend Framework 1-Code bekommen, weil ich einfach genau weiss, wo was wohnt. Auf einmal wurden wir
aber deutlich langsamer in den Requests.
Und man konnte uns kündigen, weil andere meist noch am gleichen Tag Bugs in der Software fixen konnten.

34. ‚Struts/Rails’ MVC Age
Wer war/ist dabei?
Wer von Euch hat an so einer Software mitgearbeitet? Wer arbeitet heute noch mit so einer Software? Wer hat solche Software noch im Betrieb?

35. PHP ‚Springy’ DI Age
2011 ff
Symfony 2,
Zend Framework 2
Nachdem wir alle Ideen von Struts geklaut hatten, und es ganz gut funktioniert hat - warum sollte man nicht das gleiche bei Spring machen?
In Folge wurde die nächste Generation Frameworks geschaffen, die auf DI-Konzepte aufgesetzt haben. Und während Laravel etwas von beidem ist, sind Symfony 2 und
Zend Framework 2 gut in dieser Kategorie einzuordnen.

36. • OO, Design-Pattern & DI
• Gute Einarbeitung
• Responsivität schlechter
• Wartbarkeit gut
• Accidental Complexity Mittel
• Kündigungsschutz- -
Da war jetzt nicht nur gute Objektorientierung und Design-Pattern, es ware auch eine gute modulier Zerlegung und Testbarkeit über DI möglich. Und auf einmal konnten
sich nicht nur PHP-Entwickler, sondern auch Leute mit Java-Background schnell in PHP-Plattformen zurechtfinden.
Die Wartbarkeit war gut, die Komplexität im griff, und man ist immer noch gut ersetzbar.

37. PHP ‚Springy’ DI Age
Wer ist dabei?
Bei uns bei Mayflower ist das der Gros der PHP-Welt. Wer arbeitet mit so einer Applikation?

38. PHP ‚Hybrid’ Age
2015 ff
PHP +
node.js +
… etc
Das nächste bleibt noch abzuwarten. Bei uns ist aber zu sehen, dass der Datenbank- wie Sprachzoo deutlich grösser geworden ist, und einem leicht 5-10 Plattformen
aus der Tüte fallen, wann man die Software installieren möchte.

39. Wenn ich eine Symfony2-
Lösung habe, muss ich die
überhaupt modernisieren?
Die meisten hier im Raum werden sich jetzt vermutlich die Frage stellen: warum erwähnt der Johann um Himmels willen Symfony-DI-Lösungen? Die müssen doch auf gar
keinen Fall modernisiert werden?

40. Todsicher.
Kosten
Zeit
Max(Benefit)/Feature
Ich hatte es vorhin schon mit der Accidental Complexity schon einmal auf dem Schirm - es ist keine Frage von Der Basisplattform, sondern eine von Wartbarkeit. Wenn
die Wartbarkeit meiner Software abnimmt, dann gibt es immer weniger Features oder Bugfixes, die den Aufwand der Umsetzung tatsächlich lohnen - und wenn ich die
Linie des maximale Wertes überschritten habe ist meine Software offiziell tot - denn es lohnt sich nicht, irgendetwas an Ihr zu ändern.

41. Kosten
Zeit
Max(Benefit)/Feature
Cowboy PHP
MVC PHP
DI PHP
Und um so näher ich dieser Linie komme, um so wichtiger wird es für mich, die Software zu modernisieren - oder abzulösen. Und während dieser Ablösedruck bei den
Cowboy-PHP-Anwendungen hoch ist, ist es bei den MVC-basierten PHP-Plattformen meist noch gut zu ertragen, und bei den DI-basierten Lösungen.

42. Weg mit der
alten!
Was muss ich bei
der Wahl der
neuen beachten?
Also: weg mit der alten Lösung.
Aber: was mache ich statt dessen? Welche Faktoren muss ich bei der Auswahl der neuen Software beachten? Typischerweise berücksichtig man bei der Wahl der
Architektur die funktionalen und die nonfunktionalen Anforderungen von Software, wie sie zB in den Qualitätskriterien der ISO 9126 dokumentiert sind. Meiner Erfahrung
nach sind das bei Modernisierungen andere, und deshalb liste ich die hier auf :-)

43. Marktfaktoren
1. aktueller Featuredruck
2. zukünftiger Featuredruck
3. erwartete Lebenszeit
Backbone? Angular 1 anyone?
Wie gut ist die neue Software bei der Lieferung von neuen Features, wenn ich jetzt damit beginne? Wie verhält sie sich in Zukunft dabei? Wird sie genauso wieder
langsam und zäh, wie die aktuelle Lösung? Und was ist die erwartete Lebenszeit? Hat jemand hier noch Backbone im Einsatz? Angular 1? Genau, wir haben weniger
Zeit, unsere Software zu verzinsen.

44. Marktfaktoren
4. Cost of Delay
5. Kostenrisiko
6. Vendor-Lock-in
7. Austauschbarkeit
Oft geht man bei einem Rewrite in eine Feature-Freeze - kann ich mir das überhaupt leisten, eine weile weniger Features zu liefern? Viele Rewrites scheitern oder
überziehen ihr Budget deutlich, kann ich mir das als Firma leisten?
Hole ich mir einen Vendor-Lock-in ins Haus? Zb AWS, Apache Beanstalk, Lambda oder die Google Container Engine?
Hat jemand von Euch parse.com eingesetzt? Was passiert, wenn der Vendor auf einmal vom Markt veschwindet?

45. Entwicklermarkt
8. Verfügbarkeit heute
9. Verfügbarkeit zukünftig
10.Kompetenzlevel
11.Attraktivität
„Wer für neue Technologie kommt
geht auch für neue Technologie.“
Und natürlich kennen wir alle den größten Kostenfaktor - die Entwickler. Wie viele finde ich heute für die neue Plattform? Wie sieht das in Zukunft aus? Finde ich Leute
mit guter Kompetenz auf der Plattform? Wie Attraktiv ist die Plattform für Entwickler? Kommen die dann gerne zu mir?
Ein Freund von mir sagt gerne: wer für die hippe Technologie kommt geht auch wegen anderer hipper Technologie.

46. Meine Software
12.Größe des Projektes
13.Komplexität
14.Domain-Wissen
15.Spezialisierung
16.Interagierende Systeme
Und natürlich sollte die neue Plattform der Größe meines Projektes angemessen sein. Welche Komplexität muss ich abbilden können? Wie viel Domainwissen steckt in
meiner Software (das ist in der Regel schlecht dokumentiert :-) ) ? Wieviel spezielle Algorithmen, wieviel besondere Funktionalität ist enthalten?
Mit welchen Schnittstellen muss sie interagieren können? Brauchen wir Datenbankinterfaces?

47. Meine Organisation
17.Teamgrösse
18.Vorhandene
Kompetenzen
19.Skill-Level
20.Fähigkeiten in Betrieb
21.Fähigkeiten in Product
Management
Wie gross ist mein Team? Brauche ich eine Lösung, bei der sich 6 Leute synchronisieren müssen oder 150?
Welche Kompetenzen habe ich jetzt im Team? Welche Sprachen können die, sind funktionale Programmierung bekannt, besteht DevOps-Kompetenz, kennen die sich
schon mit Verteilten Systemen aus? Wenn das CAP-Theorem nicht bekannt ist kann man mit Schwierigkeiten rechnen, wenn man zu MicroServices wechseln möchte :-)
Wie fähig sind wir im Betrieb von Plattformen? Können wir Infrastructure as Code, können wir AWS, können wir Continuous Deployment, können wir Mesos oder
Kubernetes betreiben?
Wie gut läuft die Kooperation, auch in Richtung auf das Product Management? Arbeiten die im gleiche Raum zusammen oder ist das eine ganz andere Abteilung in
meinem Unternehmen?

48. Technische
Anforderungen
22.Reifegrad
23.Zukunftstauglichkeit
24.Erlernbarkeit
25.Ressourcenbedarf
26.Skalierbarkeit
Wie reif ist die neue Lösung? Eher Java-8-reif oder NPM-Package-JavaScript-Reif? Wird sie in 2 Jahren noch existieren, gibt es LTS-Versionen? Wie gut ist sie zu lernen,
gibt es Erfahrungen, Tutorials, Trainings? Was sind Ihre Anforderungen an die Aussenwelt? Wie gut skaliert sie? Wie aufwändig ist es, sie zu skalieren?

49. Ecosystem
27.Libraries / Components
28.Tooling
29.Community
30.Integrierbarkeit
Und, nicht zuletzt - wie sieht das Ecosystem aus? Gibt es Libraries / Komponenten für viele Problemstellungen? Wie gut ist der Tooling-Support? Achtung: das gilt nicht
nur für die Dinge von denen ich schon weiß, dass ich sie brauche, sondern vor allem für die Dinge, von denen ich das noch nicht weiß. Wie gut ist die Community? Sind
viele Probleme schon gelöst und dokumentiert? Wie oft kann ich einfach von Stack Overflow copypasten an stelle es selbst zu programmieren?
Wie gut ist die Software integrierbar in andere Ecosysteme, die bei mir bereits laufen?

50. Alle Faktoren
sind relevant.
Und das gemeine daran ist, man muss tatsächlich alle diese Faktoren im Auge behalten, wenn man Architekturentscheidungen zugunsten oder gegen eine Legacy-
Plattform trifft.

51. Marktfaktoren
1. aktueller Featuredruck
2. zukünftiger Featuredruck
3. Erwartete Lebenszeit
1. aktueller Featuredruck
Die Businessseite sieht meistens nur diesen Punkt.

52. Entwicklermarkt
8. Verfügbarkeit heute
9. Verfügbarkeit zukünftig
10.Kompetenzlevel
11.Attraktivität11.Attraktivität
Und wir Entwickler sehen meist nur diesen :-)

53. x
http://stackoverflow.com/research/developer-survey-2016
Attraktivität
Und das ist ein Problem. Ich nehme noch mal den Survey von vorhin, auf dem die beliebtesten Sprachen geführt wurden. Ganz oben auf der Liste stehen - und ich muss
sagen, zurecht - Rust, Swift, F#, Scala und Go.

54. Sprache Entwickler Jobangebote
Rust 13 1
Swift 351 46
F# 24 2
Scala 286 20
Go 40 3
Java 10000+ 1188
PHP 4031 461
JavaScript 3488 393
C#.net 1812 128
Attraktivität @ München
Schaut man sich das mal konkret in XING für München an dann sieht man recht schnell, welches Problem man hätte, wenn man die Plattform einsetzt. Es gibt ganze 13
Leute, die tatsächlich Rust anbieten, und 1 Jobangebot, das auf Rust fokussiert. Swift gibt es etwas mehr, dito Scala. Aber faktisch sind wir weit weg von den
Dimensionen, in denen zB Java, PHP, JavaScript oder C# zu finden ist.

55. Wenn man das als Entwickler sieht sagt man natürlich: Hey, das ist ja nur, weil das gerade erst anfängt, warte mal ab, das wird sich ziemlich schnell durchsetzen. Hey, es
ist ganz vorne in der Entwicklerpopularität! Klar, dass dann auch viele Firmen aufspringen!

56. OK, aber was
mache ich dann?
… aber nur laaaaaangsam.
Popularität @ Redmonk
So richtig schnell geht das nicht mit der Adaption. Das passiert noch nicht mal bei OpenSource- und Hobby-Projekte. Guckt man sich die Statistik bei Redmond an,
dann ist der letzte relevante Wechsel seit 2014 der Austausch von Swift (grün) und ObjectiveC gewesen.

57. Ok, und was bleibt mir
da übrig?
Also: so schnell geht das nicht. Wir müssen offensichtlich mit den Sprachen arbeiten, für die es ein bisschen Verbreitung gibt.

58. s
1. PHP
2. JavaScript
3. Java
4. Python
5. Ruby
6. Golang
7. Scala
Realistische Plattformen
Wenn man die Sprachen mit Hilfe von Tiobe, Redmonk, StackOverflow und Xing ausdünnt, dann bleiben etwa diese 10 Sprachen übrig.

59. Hey, da fehlt Rust!
Und Elixir!
Und $personalToyLanguage!
Und selbst wenn sich das komplette Entwicklerteam freiwillig meldet, und sagt: Wir haben beschlossen dass wir jetzt alle Rust lernen! Oder Elixir, oder ELM!

60. 0
200000
400000
600000
800000
Java PHP Rust Elixir
Repositories Users
EcoSystem @ github.com
Dann hilft das auch noch nicht wirklich weiter, weil sich das Ecosystem ebenfalls in Abhängigkeit zur Popularität verhält. Ich habe hier mal die Zahlen von Java und PHP
denen von Rust und Elixir entgegen gestellt.

61. Aber es gibt alles, was wir
brauchen in der Sprache!
Von Entwickler-Seite hört man dann gerne das Argument: Hey, es ist aber alles enthalten, was wir brauchen. Guck mal, das MicroService-Framework und die beiden
Libraries, da ist praktisch alle unsere Anforderungen drin.

62. Aber nicht die Sachen, von denen
Du noch nicht weißt, dass Du sie
brauchen wirst.
(Statistisch gesehen)
Das gemeine ist aber: bei einem kleinen EcoSystem sind vermutlich die Dinge, von denen wir noch nicht wissen, dass wir sie brauchen werden, enthalten. Unknown
Unknowns findet man nur da woe schon viel ist, wo die Wahrscheinlichkeit hoch ist, dass andere Leute nicht nur schon das Problem hatten, was wir haben werden,
sondern auch gleich Ihre Lösung auf Github gestellt haben.

63. s
1. PHP
2. JavaScript
3. Java
4. Python
5. Ruby
6. Golang
7. Scala
Realistische Plattformen
Also bleiben wir bei dieser Auswahl, ich glaube, die gibt den Zustand Ende 2016 ganz passabel wieder.

64. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove
PHP
JavaScript
Java
Python
Ruby
GoLang
Scala
Welche Sprache als nächstes?
Wenn ich von einer PHP-Applikation komme, sind meistens zwei Sprachen sehr einfach einzusetzen: PHP und JavaScript, weil ich das ohnehin im Browser schon
eingesetzt habe. Java, Python, Ruby und Golang sind unserer Erfahrung nach ziemlich schnell zu lernen, bei Scala wird es etwas langsamer, das ist unserer normalen
Sprachwelt nicht nahe genug. Wenn ich wenig Zeit zum Lernen neuer Sprachen habe bin ich also gezwungen mit PHP oder JavaScript weiterzumachen.

65. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove
PHP
JavaScript
Java
Python
Ruby
GoLang
Scala
Und das Ecosystem?
Nächster Punkt ist das EcoSystem. Bei PHP, JavaScript, Java, Python und Ruby gibt es für praktisch alle Zwecke Libraries - im konkreten Fall mehr als sechsstellige
Repositories - bei Golang und Scala sind wir jeweils in den 20-Tausendern unterwegs.

66. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove
PHP
JavaScript
Java
Python
Ruby
GoLang
Scala
Gibt es Entwickler?
Entwickler-Verfügbarkeit, hier am Beispiel in München - bei PHP, Javascript, Java und Python 4 stellige Entwicklerzahl, bei Ruby immerhin noch 3stellig, bei Golang und
Scala nur 2stellig.
Also: so richtig viel Angebot an Entwicklern ist nicht vorhanden.

67. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove
PHP
JavaScript
Java
Python
Ruby
GoLang
Scala
Wie reif/stabil ist das?
Das ist jetzt mehr daumengepeilt und aus unserer eigenen Erfahrung - aber: während man bei PHP, Java, Python und Ruby halbwegs zurecht kommt gibt es bei den APIs
in der JavaScript-, in der Golang und in der Scala-Welt noch gelegentliche Probleme. Aber das ist eher Anecdotal Evidence, ich habe keinen Weg gefunden, das mit
richtigen Daten zu hinterlegen. Ich würde mich über Input freuen :-)

68. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove
PHP
JavaScript
Java
Python
Ruby
GoLang
Scala
Wie sieht die Lebenszeit aus?
Die Zukunft habe ich über die Marktdurchdringung und Wachstumsraten bzw. Bedeutungsverlust bewertet. PHP hat immer noch eine gute Verbreitung, sinkt aber
kontinuierlich. Javascript ist weiterhin im Aufwärtstrend. Java hat mit Java 8 den Abwärtstrend etwas gefangen. Python steigt kontinuerlich, Ruby lässt etwas nach,
Golang steigt, Scala sinkt etwas

69. Sprache Umlernen EcoSystem Entwickler Reifegrad Zukunft DevLove
PHP
JavaScript
Java
Python
Ruby
GoLang
Scala
Und die Devs? Mögen die das?
Und Last but noch least - Developer Support. Die Beliebgheit hatten wir schon, weder PHP, noch Java, noch Ruby finden sich da auf den Top-Plätzen

70. „Should I stay or should I go now?
Should I stay or should I go now?
If I go there will be trouble
An’ if I stay it will be double„
Und was machen wir jetzt mit der Frage, die the Clash so schön formuliert?
Should i stay or should i go? Und klar haben sie recht mit der Ansage, dass eine neue Plattform Trouble bringen wird. Und sie haben meist auch recht, dass das
verbleiben bei der Legacy-Software auf jeden Fall schlimmer ist.

71. Sanieren: Captain Obvious
Strategie Migration nach Symfony 2/3
Ausgangspunkt
Cowboy-Style / MVC-Style PHP
Hoher Technical Debt
Motivation
„Moderne“ Plattform, Innovationsfähigkeit,
Domain-Wissen & Kollegen halten
Probleme und
Risiken
PHP-Lock-In, Fluktuation bei hohen Skills,
Schwierige Talent Acquisition
Typische
Antipattern
Multiple Layers of Legacy,
„Tote Modernisierungen“
Voraussetzung
zum Erfolg
Support & Budget von Business-Seite
Infrastruktur zum Knowhowaufbau
Das ist die heute meist offensichtlichste Lösung - ich migriere auf eine nicht-Legacy-PHP-Variante. Meist mache ich das, wenn ich alte Cowboy-Style oder MVC-Style-
PHP-Apps habe, mit einem hohen Technical Debt.

72. 1. aktueller Featuredruck
2. zukünftiger Featuredruck
3. Erwartete Lebenszeit
1. aktueller Featuredruck
Alle neuen Features & Projekte
auf die neue Plattform!
Multiple Layers of Legacy
Der Punkt ist aber: ich bin bei dieser fiesen Software gelandet, weil der Featuredruck so hoch war. Und wenn ich nicht ein neues Business bekommen habe, dann ist das
noch immer so.
Und da kommt immer die clevere Idee: Hey, lass uns doch nur die neuen Features & Projekte mit der neuen Plattform machen! Und wir behalten die alte Plattform!

73. Ursprüngliche Features,
Architektur 1
Neue Features/
Architektur 2
Multiple Layers of Legacy
Und so kommt zu der alten Architektur eine zweite, neuere und bessere. Und weil der Featuredruck so hoch ist komme ich nicht dazu, die Architektur 1 zu renovieren.

74. Ursprüngliche Features,
Architektur 1
Neue Features/
Architektur 2
Neue Features/
Architektur 3
Multiple Layers of Legacy
Und nach zwei Jahren ist auch Architektur 2 nicht mehr das, was man möchte. Also fängt man bei den neuen Features mit Architektur 3 an. Und kommt irgendwie nicht
dazu, Architektur 1 zu refactoren. Und Architektur 2, aber die ist ja auch noch fast neu.

75. Neue Features/
Architektur 2
Neue Features/
Architektur 3
Neue Features/
Architektur 4
Multiple Layers of Legacy
Ursprüngliche Features,
Architektur 1
Und weil der Featuredruck immer noch erhalten bleibt, und wir nicht genug Manpower zum Refactoring haben, machen wir einfach beim nächsten neuen Feature wieder
die Architektur, die heute angesagt ist.
Und so enden wir durch kontinuierliche Innovation und Modernisierung bei einer Software, die deutlich schlechter zu warten ist als wenn wir nur bei Architektur 1
geblieben wären.

76. Domain Driven Design
Strategie Migration nach Symfony 2/3+DDD
Ausgangspunkt
Cowboy-Style / MVC-Style PHP
Hoher Technical Debt, hohe Komplexität
Motivation
Wartbarkeit! Saubere Architektur,
Talent Acquisition, Disziplinierung Business
Probleme und
Risiken
Organisatorische Gründe für Technical Debt,
Developer-Fähigkeiten
Typische
Antipattern
DDD-Lite
Voraussetzung
zum Erfolg
Support & Budget von Business-Seite
Knowhow für Business & Development
Eine weitere Modernisierungsvariante ist die Modernisierung in Richtung DDD. Das ist in der PHP-Welt mit etwas Verspätung eingeschlagen, und wurde vor allem in den
letzten 3-4 Jahren viel diskutiert. Meist geht das einher mit einer Modernisierung in Richtung Symfony, insbesondere dann, wenn die Komplexität der Anwendung hoch
ist - oder für hoch gehalten wird.

77. Alle Tactical Patterns,
Ubiquitous Language,
Bounded Contexts &
Context Maps sind da.
Aber nur die
Entwickler kennen sie.
DDD-Lite
Gerade weil das in unserer Welt meist von den Techies getrieben wird kommt es bei uns oft zu DDD-lite. Wir lieben Design Pattern, und deshalb lieben wir auch die
Tactical Patterns, die Eric Evans und Co uns gegeben haben. Und wir vergessen die ganze Businessseite dabei.
In Folge hat Domains, Entitäten und Value Objects, die sich ganz anders verhalten als die Realität. Mit der Folge, dass mein Domain Model hässlich wird.

78. MicroService Monokultur
Strategie MicroServices mit Standard-Stack
Ausgangspunkt
Cowboy/
MVC/DI-Age PHP-Applikation
Motivation
Skalieren über Teams, bessere Wartbarkeit,
Skalierbarkeit, Robustheit, Sprachwechsel
Probleme und
Risiken
Komplexität, Cohesion Chaos, Layered
Services, Missing Automation
Typische
Antipattern
Distributed Monolith
Voraussetzung
zum Erfolg
Automatisierung in Knowhow &
Infrastruktur: Monitoring, QA, Deployment
Die aktuelle Kuh im Dorf ist auch bei uns aber nicht mehr DDD, sondern wie überall MicroService. Dort sieht man zwei Strategien, und ich stelle hier mal die erste vor -
die MicroService Monokultur. Auch wenn die Flexibilität über Plattformen einer der Kernvorteile von MicroServices ist passiert das in der Praxis häufiger als man denkt -
insbesondere da, wo die Entscheidung zu MicroServices zentral getrieben wurde, zB von CTO oder Architektenrunde. Probleme sind fehlende Automatisierung, und
wenn die Entwickler alle vom Monolithen kommen - das Neudesign eines Monolithens, jetzt nur mit Funktionsaufrufen über HTTP und Queues.

79. „If you can’t build a well-
structured monolith, what
makes you think you can build
a well-structured set of
microservices?“
http://www.codingthearchitecture.com/2014/07/06/
distributed_big_balls_of_mud.html
Richtig populär wurde das mit seinem Monolith First Pattern durch Martin Fowler, aber aus diesem Blogartikel stammt das: Wenn man schon nicht in der Lage war einen
gut strukturierten Monolithen zu machen, wie kann man dann glauben, dass es mit einer verteilten Applikation klappt?

80. MicroServices
Strategie
MicroServices mit freier Stack-Wahl,
Container
Ausgangspunkt MVC/DI-Age PHP-Applikation
Motivation
Skalieren über Teams, bessere Wartbarkeit,
Skalierbarkeit, Robustheit, Sprachwechsel
Probleme und
Risiken
Komplexität, Cohesion Chaos,
Missing Automation
Typische
Antipattern
MicroService Snowflakes
Voraussetzung
zum Erfolg
Automatisierung in Knowhow &
Infrastruktur: Monitoring, QA, Deployment
Das sieht man im Moment eher bei den ganz grossen - oder bei den ganz kleinen, startuppigen PHP-Businesses - klassische MicroServices. Meist ist die technische
Strategie da nur das stellen der Plattform - und die Teams bauen selbst die Mikroservices nach Ihrer Facon.
Besonders Firmen mit dickem Innovationsdruck wollen heute gerne sowas - und sind quasi zum Scheitern verdammt, denn die Anforderungen in Agilen Methoden, in
DevOps-Automatisierung oder Amazon-Knowhow sind gross.

81. Und was mache ich jetzt?
• Captain Obvious
• Domain Driven Design
• MicroService Monokultur
• MicroServices
(Faustformeln to come)
Und natürlich gibt es noch mehr Varianten. Nano und Pico-Services, Serverless Applications, Backend as a Service und vieles mehr. Das hier sind nur die 4 Variante, die
am häufigsten zu sehen sind.

82. Wann Captain Obvious /
PHP Monolith in gut
• Weniger als 15 Entwickler
• Weil das Core-Team PHP
kann und uns treu ist
• Weil die Komplexität ok
geht (CMS, E-Commerce)
Wann mache ich Captain Obvious?

83. Domain Driven Design
• Weil wir DDD-Experten in
Dev & Business haben
• komplexer & eng verzahnter
/ optimierter Businesscase
• nachhaltige Wartbarkeit

84. MicroServices Monokultur
• >20 Entwickler im Team
• parallele & schnelle
Entwicklung erforderlich
• gute Ops / Cloud /
Monitoring/QA-Struktur
• zentrale Org-Struktur

85. MicroServices
• Maturity Agil & DevOps
• CI, CD, QA, Monitoring,
Cloud, IaC, AWS
Management gut im Griff
• Crossfunktionale Teams

86. Architecture TradeOff
Analysis Method
Strategieauswahl auf Basis
der mittelfristigen
Businessanforderungen
Und wie komme ich zu der neuen Architektur?
Wir machen das gerne über einen ATAM - Workshop. ATAM ist die Architecture Tradeoff Analysis Method, und ist eigentlich ein Risikomanagementtool. Weil das Risiko
bei Modernisierungen hoch ist bietet sich das Verfahren an.
Was macht man da? Man dokumentiert die Mittelfristigen Businessanforderungen in Szenarien, priorisiert sie und bewertet die Architekturvarianten, die einem zur Wahl
stehen. Und am Ende kommt eine Decision Matrix nicht nur mit einer Empfehlung, sondern auch mit einem Tradeoff - also den Dingen, die man nicht bekommen wird -
heraus.

87. Und dann klappt es?

88. Selten wie geplant ,
es ist praktisch immer teurer

89. Modernization Burndown
Allen Scope erfassen - wir machen das meist mit einem Story-Mapping über die bestehende Software - und prüfen, wie weit man die Migration bekommen hat, und wie
weit man den alten Kram schon wegwerfen konnte. Am besten allen Code physikalisch entfernen, den man nicht mehr braucht. Das ist quasi die einzig valide Definition
of Done einer Modernisierung :-)

90. Manpower vs. Tempo
Entweder 1.5-2facher Produktivitätsverlust
oder 1.5-2facher Aufwand
für Entwicklung & Knowhowaufbau.
Und man sollte ankündigen, dass es teurer wird. Eine gute Schätzung ist Faktor 1.5 bis 2, wenn man es gut im Griff hat.
Wer kennt Hofstaedters Law? Genau, es dauert länger. Auch wenn man einplant, dass es länger dauert.

91. Kontinuierliche
Modernisierung
• Parallelbetrieb hinter Proxy
• Parallelbetrieb über
Feature Toggles
• Absicherung über
Acceptance-Tests
Das haben wir schon gemacht, das hilft auch. Bevor ich modernisiere etabliere ich einen Gateway oder einen Proxy vor der Applikation, und migriere anhand von Proxy-
Routen. Oder ich nutze Feature-Toggles, um bei manchen Nutzern die neue, bei machen die alte Software auszuliefern.
Wenn ich nicht in Produktion testen möchte kann ich das vorher durch Akzeptanztests absichern. Das ist praktisch der einzige Weg zu echtem Risikomanagement.

92. Infrastruktur zum
Knowhowaufbau
• Team-Rotation Legacy vs. Neu
• Slack time & Lightning Talks
• Pair Programming,
Coding Dojos
• Training on the job
Wir hatten es am Anfang - ich brauche sowohl das Domain-Knowhow als auch die Technologiekompetenz bei den Entwicklern. Das ist offensichtlich mehr Knowhow
während einer Modernisierung, denn ich habe jetzt zwei Plattformen zu verstehen. Diese Methoden helfen dabei.

93. Too long, didn’t listen 1
Soll ich weiter PHP machen?
PHP wird es dank CMS- und E-
Commerce-Plattformen noch lange
geben. Aber immer weniger
Developer, die es mögen.
Wem das einfach zu viel Kram war, hier noch mal ein paar wichtige Aussagen.
Also: kann ich noch PHP machen? Ja, das ist hinreichend verbreitet, das wird es noch lange geben.

94. Too long, didn’t listen 2
Muss ich jetzt MicroServices?
Wenn Ihr Agil, DevOps könnt,
viele seid und parallel arbeiten
wollt - ja, klar.
Muss ich jetzt MicroServices machen? Wenn ich es kann und brauche, dann ja :-)
Aber es gibt nicht viele PHP-Firmen, die das wirklich gut können. Eher die grossen.

95. Too long, didn’t listen 3
Auch PHP und MicroServices?
Klar, das ist ja quasi der Punkt
hinter MicroServices. Da, wo es
Sinn macht.

96. Too long, didn’t listen 4
Sonst noch was?
Es wird aufwendiger als erwartet.

97. Danke! Fragen?
Slides mit Volltext:
slideshare.net/johannhartmann
Oder: draussen am Stand :-)