Legacy php - Sanieren oder Ablösen?

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.

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 :-)

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.

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.

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.

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.

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.

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.


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.

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.

x


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.


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.

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.

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.

https://en.wikipedia.org/wiki/Gov._Stanford

Wer von Ihnen hat eine Software im Einsatz, die älter als 5 Jahre ist?

https://en.wikipedia.org/wiki/Gov._Stanford

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.

http://www.fotocommunity.de/fotograf/peter-raudenkolb/1039860

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.

http://commons.wikimedia.org/wiki/File:Berrigan_Drummond_Street_Rail_Crossing.JPG

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.

https://en.wikipedia.org/wiki/Road-rail_vehicle

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.

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.

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.

„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“ :-)

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.

Wissen in der Applikation Es finden sich drei Sorten Wissen in der Applikation

CodeWelchen Code gibt es,

wie hängt er zusammen?

Features Welche Features gibt es?

MotivationWarum 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.

Wer von Ihnen ist Software-Entwickler?

Wer von Euch ist Software-Entwickler?

Zeitinvestment bei Softwareentwicklung Im Mittel über die Software Lifetime, Quelle: Microsoft

Neuer CodeBestehenden Code ändernAnalyse 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.

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.

(In Wahrheit debugge ich gerne :-) )

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

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.

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

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?

‚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.

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

‚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?

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.

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

PHP ‚Springy’ DI Age

Wer ist dabei?

Bei uns bei Mayflower ist das der Gros der PHP-Welt. Wer arbeitet mit so einer Applikation?

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.

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?

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.

Kosten

Zeit

Max(Benefit)/FeatureCowboy 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.

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 :-)

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.

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?

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.

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?

Meine Organisation

17.Teamgrösse 18.Vorhandene

Kompetenzen 19.Skill-Level 20.Fähigkeiten in Betrieb 21.Fähigkeiten in Product

ManagementWie 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?

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?

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?

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.

Marktfaktoren

1. aktueller Featuredruck 2. zukünftiger Featuredruck 3. Erwartete Lebenszeit

1. aktueller Featuredruck

Die Businessseite sieht meistens nur diesen Punkt.

Entwicklermarkt

8. Verfügbarkeit heute 9. Verfügbarkeit zukünftig 10.Kompetenzlevel 11.Attraktivität11.Attraktivität

Und wir Entwickler sehen meist nur diesen :-)

x


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.


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.

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!

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.

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.

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.

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!

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.

http://github.com

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.

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.

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.

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.


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.


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.


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 :-)


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


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

„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.

Sanieren: Captain ObviousStrategie Migration nach Symfony 2/3

AusgangspunktCowboy-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-SeiteInfrastruktur 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.

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!

Ursprüngliche Features, Architektur 1

Neue Features/Architektur 2


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.



Neue Features/ Architektur 3


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.






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.

Domain Driven DesignStrategie Migration nach Symfony 2/3+DDD

AusgangspunktCowboy-Style / MVC-Style PHP

Hoher Technical Debt, hohe Komplexität

MotivationWartbarkeit! Saubere Architektur,

Talent Acquisition, Disziplinierung Business


Organisatorische Gründe für Technical Debt, Developer-Fähigkeiten


DDD-Lite


Support & Budget von Business-SeiteKnowhow 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.

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.

MicroService MonokulturStrategie MicroServices mit Standard-Stack

AusgangspunktCowboy/

MVC/DI-Age PHP-Applikation

MotivationSkalieren über Teams, bessere Wartbarkeit, Skalierbarkeit, Robustheit, Sprachwechsel


Komplexität, Cohesion Chaos, Layered Services, Missing Automation


Distributed Monolith


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.

„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?

MicroServicesStrategie

MicroServices mit freier Stack-Wahl, Container

Ausgangspunkt MVC/DI-Age PHP-Applikation

MotivationSkalieren über Teams, bessere Wartbarkeit, Skalierbarkeit, Robustheit, Sprachwechsel


Komplexität, Cohesion Chaos, Missing Automation


MicroService Snowflakes


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.

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.

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?

Domain Driven Design

• Weil wir DDD-Experten in Dev & Business haben

• komplexer & eng verzahnter / optimierter Businesscase

• nachhaltige Wartbarkeit

MicroServices Monokultur

• >20 Entwickler im Team • parallele & schnelle

Entwicklung erforderlich • gute Ops / Cloud /

Monitoring/QA-Struktur • zentrale Org-Struktur

MicroServices

• Maturity Agil & DevOps • CI, CD, QA, Monitoring,

Cloud, IaC, AWS Management gut im Griff

• Crossfunktionale Teams

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.

Und dann klappt es?

Selten wie geplant , es ist praktisch immer teurer

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 :-)

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.

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.

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.

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.


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.


Auch PHP und MicroServices?

Klar, das ist ja quasi der Punkt hinter MicroServices. Da, wo es Sinn macht.


Sonst noch was?

Es wird aufwendiger als erwartet.

Danke! Fragen? Slides mit Volltext:

slideshare.net/johannhartmann Oder: draussen am Stand :-)

http://slideshare.net/johannhartmann

Legacy php - Sanieren oder Ablösen?

Software

Transcript of Legacy php - Sanieren oder Ablösen?