#1 17. Oktober 2007 Golem.de im Gespräch mit Zend-Gründer Zeev Suraski Zeev Suraski gründete zusammen mit Andi Gutmans das Unternehmen Zend Technologies, das Produkte rund um PHP anbietet, sich aber auch stark an der Entwicklung der freien Scriptsprache beteiligt. Suraski war maßgeblich an der Entwicklung von PHP 4 beteiligt, ist für einige PHP-Erweiterungen verantwortlich und heute zusammen mit Gutmans Co-CTO von Zend. Golem.de sprach in diesem ersten Teil unserer Interviews mit ihm über die Eclipse PHP Development Tools (PDT), Zends Kooperation mit Microsoft und das nahende Ende von PHP 4. Golem.de: Im September 2007 erschienen die Eclipse PHP Development Tools (PDT). Was und wer steckt dahinter? Zeev Suraski: PDT ist ein Eclipse-Projekt. Allerdings ist Zend hier federführend, zumal die Entwicklung bislang zum überwiegenden Teil von Zend kam. Zeev Suraski Golem.de: Welche Konsequenzen wird dies für Zend Studio haben? Suraski: Wir verfolgen hier derzeit drei Ansätze gleichzeitig. Erstens Zend Studio als vorhandenes Produkt, das wir verkaufen und auch in Zukunft verkaufen werden. Wir haben derzeit die Version 5.5 und werden in nicht allzu ferner Zukunft neue Versionen anbieten. Zweitens PDT: Das Produkt wurde vor wenigen Wochen offiziell auf den Markt gebracht, wobei wir nahezu zwei Jahre lang daran gearbeitet haben. Dieses Projekt richtet sich an die Open-Source-Community und an Entwickler, die eine auf Eclipse basierende Lösung wünschen. Drittens gibt es kommerzielle Tools als Überbau zu PDT. Wir werden also der PDT-Infrastruktur weitere übergeordnete Mehrwertangebote hinzufügen und kommerziell vermarkten. Wir haben unsere Planung in dieser Hinsicht aber noch nicht endgültig abgeschlossen. Wie Sie wissen, braucht es für eine kommerzielle Lösung noch mehr: Wie gestalten wir die Preise? Wo stehen wir im Vergleich zu Studio usw. Derzeit sieht die Planung so aus, dass wir beide Produkte vermarkten möchten: Studio und eine Lösung auf Basis von Eclipse - neben dem kostenlosen Tool PDT. Golem.de: Das heißt, Lösungen auf der Basis von Eclipse werden Zend Studio nicht ersetzen. Suraski: Nicht zum jetzigen Zeitpunkt. Sollten wir feststellen, dass alle auf Eclipse umsteigen, werden wir uns darüber Gedanken machen. Eine Entscheidung darüber ist bislang nicht gefallen. Golem.de: Worin liegen die Vorteile einer Lösung auf Basis von Eclipse? Suraski: Ein wesentlicher Vorteil ist, dass es eine Vielzahl von Plug-ins gibt. Plug-ins, mit denen sich fast alles realisieren lässt. So gibt es beispielsweise Tools für AJAX und Java Script. Alle diese Plug-ins wurden entwickelt, getestet und funktionieren. Wir müssen Sie daher nicht neu entwickeln. Auch Entwickler können so ihre eigenen Plug-ins erstellen. Ein weiteres sehr wichtiges Element hat in meinen Augen ganz einfach mit Standardisierung zu tun. Einige Unternehmen haben sich für eine Standardisierung auf Eclipse entschieden. Bei ihnen soll alles unter Eclipse laufen. Sie möchten daher Werkzeuge, die auf Eclipse basieren. Die Tatsache, dass wir Lösungen auf der Basis von Eclipse anbieten, macht PHP in diesen Unternehmen wettbewerbsfähig. Golem.de: Was werden kommerzielle Zend-Produkte gegenüber den freien Versionen mehr bieten? Suraski: Im Grunde genommen alles Mögliche, darunter CVS, Subversion, XML- oder Java-Support. Ein Aspekt wird eine integrierte Lösung sein, die einfach installiert wird und mit der Ihnen dann alle benötigten Plug-ins zur Verfügung stehen. Ein zweiter wichtiger Punkt sind zweifelsohne echte Plug-ins, zusätzliche Plug-ins als Bestandteil des kommerziellen Produkts, die in PDT nicht verfügbar sind. Weiterhin geht es um die Integration in andere Zend Produkte, um die Unterstützung von Webservices, bestimmten Datenbanken. Golem.de: Zend kooperiert mit Microsoft, um PHP für Windows anzubieten. Wie sieht die Kooperation aus, gibt es eine gemeinsame Entwicklung? Was macht Microsoft? Suraski: Die Partnerschaft besteht seit etwa einem Jahr. Microsoft hatte sich zum Ziel gesetzt, Windows als tragfähige Alternative zu anderen Betriebssystemen, insbesondere zu Linux, zu etablieren - als Zielplattform für PHP. Bis dahin war es im Grunde so, dass bei der Entscheidung für PHP in 99 Prozent der Fälle gleichzeitig die Entscheidung gegen Windows fiel, d.h. für Linux oder Solaris. Windows wurde wohl nicht eingesetzt, da es als Produktionssystem für PHP nicht wirklich brauchbar war. Microsoft wollte diesen Zustand ändern. Wir bei Zend wussten damals, dass bei den meisten Entwicklungen, die auf PHP basieren, Windows zur Entwicklung zum Einsatz kommt. Und es gibt eine wachsende Zahl von Unternehmen, die sich intensiv mit Internetumgebungen auf Windows-Basis beschäftigen, um konkurrenzfähig zu bleiben. Diese Unternehmen brauchen eine Lösung. Je mehr PHP in den größeren Unternehmen Einzug hält, desto größer ist der Bedarf dafür. Wir haben das erwartet, da viele Unternehmen bereits eine sehr große Installationsbasis unter Windows innerhalb ihrer Organisation haben. Wenn Sie PHP einsetzen möchten, ist die Wahrscheinlichkeit groß, dass sie dafür ihre bestehende Infrastruktur nutzen. Letzendlich ergibt sich für Zend und Microsoft eine Situation, in der beide nur gewinnen können. Daher sind wir eine Partnerschaft eingegangen, deren wichtigstes Ziel sich - einfach ausgedrückt – so beschreiben lässt: Wir nehmen PHP und sorgen dafür, dass es bestmöglich auf Windows läuft. Wir haben es seitdem geschafft, die Leistungsfähigkeit von PHP drastisch zu steigern. Laut unserer Tests liegen wir irgendwo bei einer Verdoppelung oder Verdreifachung. Auch ist es uns gelungen, die Art und Weise, wie PHP bei Windows eingesetzt wird, zu ändern, denn heute kommt immer häufiger FastCGI zum Einsatz, eine für Windows viel verlässlichere Architektur. Das läuft so erfolgreich, dass Microsoft sich für eine eigene FastCGI-Unterstützung für Windows 2008 Beta entschieden hat. Zudem bieten sie es für ihre älteren Systeme an. So kann jeder die Vorteile von FastCGI und PHP kostenlos nutzen - vorausgesetzt, man arbeitet mit Windows. Golem.de: Ist das ein auf Dauer angelegtes Vorhaben? Suraski: Ja. Vieles wurde bereits abgeschlossen, da wir auch hier den Funktionsumfang beträchtlich erweitern konnten. Ich kann dazu soviel sagen: Bei den meisten Tests ist Windows bei PHP noch immer etwas langsamer als Linux. Und hier sind wir auf bestimmte Hindernisse gestoßen, gewisse funktionale Unterschiede zwischen Windows und Linux. Windows ist bei bestimmten Operationen einfach langsamer als Linux. Wir haben bereits viel geschafft, aber es geht weiter. Wir haben mit Microsoft einen langfristigen Vertrag geschlossen, um so kontinuierlich sicherzustellen, dass PHP auf Windows auch in Zukunft eine Option ist. Wir führen ständig Benchmark-Tests mit der kostenlosen Version durch. Golem.de: Was konkret wurde verändert um PHP unter Windows schneller zu machen? Suraski: Das hatte im Wesentlichen zwei Ursachen. Ein wichtiger Punkt und gleichzeitig eine echte Veränderung war die Tatsache, dass wir uns den Multi-Threaded-Mode vorgeknöpft haben. Noch vor einem Jahr gab es PHP unter Windows nur in der Multi-Threaded-Variante. Ganz gleich ob PHP auf einem Multi-Threaded-Server lief oder nicht. Der Einsatz von FastCGI war einfach sinnlos. Aus diesem Grund haben wir PHP wieder auf den Stand von 2000 gebracht - auf den ersten Portierungsstand für Windows. Bei dem zweiten Punkt geht es einfach um eine hoch optimierte FastCGI-Anbindung. Die erste FastCGI-Anbindung stammte von Zend, die zweite und etwas schnellere wird nun von Microsoft umgesetzt. Dadurch kann die Leistung nochmals erheblich verbessert werden, je nach Anwendung um das Zwei- oder Dreifache. Golem.de: Sie arbeiten nicht nur mit Microsoft, sondern auch mit Oracle und IBM zusammen. Für IBM bietet Zend unter anderem PHP System i / i5 an? Suraski: Ja, das ist ein wesentlicher Punkt unserer Beziehung zu IBM. Golem.de: Wie wird PHP in dieser Umgebung eingesetzt, wozu wird PHP auf solchen Systemen verwendet? Suraski: Bei i5 sind CL und Cobol auch heute noch die gängigsten, wenn auch nicht die neuesten Computersprachen. IBM hat das System modernisiert und Java auf die Plattform portiert. Sie haben das umgesetzt - natürlich mit Erfolg. IBM verfügt über genug Ressourcen, um die Java-Portierung richtig durchzuführen. Es hat gut funktioniert, allerdings gab es ein kleines Problem: Nur wenigen Leuten gefiel das. Nur sehr wenige sind tatsächlich auf Java umgestiegen. Um es kurz zu machen: Meiner Meinung nach sind sich sowohl IBM als auch die i5-Community einig, dass dieser Weg kein Erfolg war. Ich meine irgendwo gelesen zu haben, dass auch heute noch weniger als 10 Prozent der i5-Anwendungen in Java entwickelt wurden. Und dies vor dem Hintergrund, dass die Einführung von Java bei diesem System sechs oder sogar sieben Jahre zurückliegt. Es war also eher ein Reinfall. Vor ein paar Jahren, als sich unsere Beziehung zu IBM entwickelte, setzte sich die i5-Gruppe mit uns in Verbindung. Sie hielten eine Scriptsprache für die richtige Lösung und die passende, erfolgreichste und bekannteste Scriptsprache war dann PHP. So begann unsere Beziehung. Heute stecken wir noch immer mehr oder weniger in den Anfängen. Vor knapp einem Jahr hatten wir den ersten Kontakt zu i5. Es gibt allerdings schon eine Reihe schöner Beispiele für i5 auf Basis von PHP. Bei PHP und i5 gibt es zwei unterschiedliche, aber dennoch gleich wichtige Dinge. Zum einen müssen wir die Infrastruktur für die Entwicklung von Anwendungen, für bestehende, webfähige i5-Applikationen bereitstellen. Das muss reibungsloser und kostengünstiger als mit Java funktionieren. Daher ist es auch sehr wichtig, dass wir am Ball bleiben. Zum anderen müssen wir umfassende Standard-PHP-Anwendungen für i5 zur Verfügung stellen. Wenn Sie ein Content-Management-System benötigen, finden Sie im Open-Source-Bereich viele Lösungen auf Basis von PHP. Plötzlich gibt es da etwas für i5, für eine Community, die in der Regel daran gewöhnt ist, für alles und jedes mehrere Zehntausend Dollar zu zahlen. Das ist der zweite Punkt, weshalb heute viele Unternehmen, die mit i5 arbeiten, nach einer PHP-Lösung suchen. Der Grund ist nicht ihr Interesse an PHP, sondern an den Applikationen, die damit für i5 zur Verfügung stehen. Die Akzeptanz ist wirklich sehr gut. Golem.de: Wie sieht es derzeit bei der PHP-Entwicklung aus? Vor einigen Wochen wurde angekündigt, dass der Support für PHP 4 zum Ende dieses Jahres eingestellt wird. Derzeit nutzen aber noch viele PHP 4. Was ist hinsichtlich der Migration von PHP 4 nach PHP 5 schief gelaufen? Suraski: Das ist meiner Ansicht nach ganz einfach zu beantworten, und ich gehe hier hart mit mir ins Gericht. Bereits ganz früh, noch bevor PHP 5 herauskam, wusste ich, dass es Probleme geben würde. Das Problem von PHP 5 ist kein originäres PHP-Problem. Die Vorgängerversion war recht gut. Wenn wir uns die Entwicklung anschauen, so gab es bei PHP 2 zehn- bis fünfzehntausend Anwender und vermutlich zehn- bis fünfzehntausend Domains im Internet. Als PHP 3 herauskam, war das keine große Sache, Abwärtskompatibilität war nicht so wichtig und wir haben Unterstützung bei der Migration angeboten. Der Übergang von PHP 2 zu PHP 3 war einfach und auch der Umstieg von PHP 3 auf PHP 4 lief relativ problemlos, da erstens die Verbreitung von PHP 3 mit nur einigen hunderttausend Domains relativ gering war - zwar vergleichsweise größer, aber immer noch klein. Und mit PHP 4 konnte auf sehr hohem Niveau die Kompatibilität gewährleistet werden. Bei PHP 5 stellte sich das anders dar. Dafür gibt es zwei Gründe. Der Hauptgrund war, dass die Leute glaubten, der Umstieg von PHP 4 auf PHP 5 sei schwierig. Ihrer Meinung nach war PHP 4 ausreichend. Es ist oft so, dass keine Entwicklung erfolgt, wenn eine Technologie gut genug ist. Das ist nicht nur bei Software so, sondern bei allem. Das ist meine Meinung. Vielleicht ein weiteres Beispiel: Ein drei Jahre altes Telefon ist für mich völlig ausreichend. Ich sehe keinen Grund, warum ich ein neues, schickes Telefon brauchen sollte, auch wenn mein Telefon langsamer oder unhandlicher ist. Für meine Zwecke reicht es und ich bleibe dabei. Aus demselben Grund bleiben die Leute bei PHP 4. Der zweite Grund hatte wieder etwas mit der allgemeinen Wahrnehmung zu tun und der Ansicht, dass es zwischen PHP 4 und PHP 5 riesige Kompatibilitätsprobleme gäbe. Das ist normalerweise nicht der Fall. Aber es ist genau das Problem mit dem Begriff "normalerweise". Wenn Sie von PHP 4 auf PHP 5 umsteigen wollen, müssen Sie im Wesentlichen Qualitätssicherung betreiben, Ihre Anwendung intensiver testen. Sie finden dann tatsächlich gar keine oder kaum Stellen, die Sie beim Übergang von PHP 4 auf PHP 5 ändern müssen. Die Probleme entstehen dadurch, dass man die Objekte von PHP 4 ohne gründliches Testen der Anwendung nicht einfach so speichern kann. Dann kommt der Spruch "Mañana" - das machen wir morgen oder irgendwann. Wir haben jetzt keine Zeit dafür. Nimmt man also diesen beiden Aspekte zusammen - PHP 4 ist gut genug und die vermeintliche Inkompatibilität zwischen PHP 4 und PHP 5 sowie das zwingend notwendige Testen der Anwendungen, so hat man schon die Hauptgründe dafür, dass die Verbreitung von PHP 5 länger dauerte. Der Support für PHP 4 wird übrigens nicht zum Ende des Jahres eingestellt, sondern im August 2008. Dann laufen nämlich die Sicherheitsupdates aus. Und schon heute fließen die meisten neuen Funktionen nicht in PHP 4 ein. Die meisten neuen Funktionen findet man in PHP 5 - und dies schon eine ganze Weile. Golem.de: Warum sollte man jetzt noch auf PHP 5 umsteigen und nicht gleich auf PHP 6 warten? Suraski: Das ist eine gute Frage. Erstens befinden wir uns in einem Zwischenstadium: Der Support für PHP 4 läuft aus und PHP 6 ist noch nicht da. Zweitens - und hier bin ich etwas vorsichtig mit meiner Aussage - wird der Bruch zwischen PHP 5 und PHP 6 im Hinblick auf Kompatibilität wohl viel deutlicher sein. Wegen Unicode und den Änderungen bei grundlegenden Elementen der Sprache sind Inkompatibilitäten weitaus wahrscheinlicher. Wir werden PHP 6 nicht "pushen", sondern ganz im Gegenteil, hart daran arbeiten, die Inkompatibilitäten so gering wie möglich zu halten. Vielleicht bieten wir automatische Migrationstools an. Bis dahin dauert es aber noch. Der Sprung von PHP 4 auf PHP 6 könnte viel schmerzvoller sein, als der von PHP 4 zu PHP 5. Bevor es bei PHP 6 aber zu Problemen kommt, wollen wir reagieren. Wir beschäftigen uns intensiv damit und lernen auch aus unseren Erfahrungen mit PHP 5. Bislang sind wir noch nicht zu einem endgültigen Entschluss gekommen, tun aber unser Möglichstes, um die Migration von 5 auf 6 reibungslos zu gestalten. Zum jetzigen Zeitpunkt macht es aber keinen Sinn, auf PHP 6 zu warten. Es dauert noch mindestens ein Jahr, bis PHP 6 verfügbar sein wird. Golem.de: Ich hatte den Eindruck, dass bei der Veröffentlichung von PHP 5 etwas Unsicherheit in Bezug auf freie OpCode-Caches bestand. Es war immer wieder die Rede davon, diese würden noch nicht gut funktionieren? Suraski: Das könnte sein. Das ist aber in meinen Augen nicht einer der Hauptgründe. Es überrascht Sie vielleicht, aber die meisten Unternehmen, mit denen ich zu tun habe, verwenden keinen OpCode-Cache. Der Einsatz von OpCode-Caches wird zwar immer selbstverständlicher, aber bei der Einführung von PHP 5 im Jahr 2004 arbeiteten die meisten Unternehmen nicht mit einem OpCode-Cache - ob Open Source oder kommerziell. Das war vielleicht ein Teil des Problems. Auch gab es einen Punkt, an dem APC unterstützt wurde, wobei der erste Code für PHP 5 zwar funktionierte, aber nicht ausreichend zuverlässig war und Probleme machte. Die Leute stiegen um, stießen auf Probleme und zogen es vor, bei PHP 4 zu bleiben. In 2005 war es tatsächlich gang und gäbe, dass Unternehmen wieder einen Schritt zurück zu dem PHP taten, das funktionierte. Dann gab es aber plötzlich Probleme und Ausfälle bei hohen Lasten und bei APC. Das war ein anderes Problem. Sie stiegen nicht um und hatten danach Probleme. Ein OpCode-Cache kann ein sehr wesentlicher Teil des ganzen Setups sein. Manchmal braucht man zwei zusätzliche Server, wenn man keinen OpCode-Cache verwendet. Die Tatsache, dass es keinen OpCode-Cache gab - es gab keinen kostenlosen Open Cache als Open Source - ist womöglich ein Grund, weshalb die Entscheidung umzusteigen verschoben wurde. Golem.de: Bei PHP6 wird sich in diesem Punkt aber etwas ändern? Suraski: Ja, sehr wahrscheinlich. Und zwar hinsichtlich der Tatsache, dass APC als Teil von PHP in PHP 6 zur Verfügung gestellt werden wird. Das bedeutet, dass APC wohl zusammen mit PHP 6 erscheinen wird. Neben APC wird es aber auch ein kommerzielles Produkt von Zend geben. quelle: Golem.de + Multi-Zitat Zitieren