 Hallo Computer. Geht es jetzt hin oder darf ich anfangen? Okay. Ja. Hallo und herzlich willkommen zu dieser Session. Ich versuch, dass wir mal so ein bisschen improvisiert mit diesem Mikrofon zu machen, der Rohr und ich werden das noch ein bisschen abwechseln. Ja, machst du mal eine vorgeweite? Sehr gut, danke. Vielleicht so, so besser. Okay. Können wir das vielleicht weglassen? Wir haben nur noch dritte Personen zum Mikrofon halten. Bescheuert. Okay. Ja, ich fange einfach an mich vorzustellen. Ich stehe rechts. Mein Name ist Dennis Hermsmeyer. Ich arbeite als Systementwickler bei Mitwald und du stehst im Bild. Bin heute hier mit dem Robot. Ja, wir haben uns einfach mal gedacht, wir könnten euch mal vorstellen, wie wir quasi als Agentur arbeiten, also wie wir quasi Projekte ausrollen, wie wir quasi Dinge tun. Und da haben wir uns gedacht, das wäre ziemlich langweilig und wir das einfach nur aus Agentursicht machen, sondern deswegen war der Gedanke, wir schließen uns damit Mitwald zusammen und machen einfach mal so die Sicht quasi von einer Agentur und die Sicht von einem Host, wie man quasi das umsetzen kann, wenn man Webseiten ausrollt. Deswegen würde ich mal weitergehen auf die nächste Folie. Früher wollten wir Kultspieler einbauen. Genau, der Hintergrund ist, wie wir früher gearbeitet haben, war wie ihr das auch alle kennt, dass man quasi einfach sich irgendwie kurz zusammenschiebt, dann quasi mit der Heck-PAP im WordPress früher gearbeitet hat und dann direkt einfach im Haupt-Seam quasi Dinger verändert hat und genau, die Plugins eben auch im Seam hatte. So wie halt heute auch noch manche arbeiten, aber so haben wir so haben wir früher quasi auch angefangen, das zu tun. Und deswegen würde ich quasi das einfach mal weitergeben, wie das quasi dann aus Hostersicht war. Jo, der Robert hat es gerade schon schön verdeutlicht. Also früher war eigentlich alles einfacher. Man hat, man brauchte kein Staging, man braucht auch nicht so komische Sachen wie Verschlüsselung oder SSH, dieses Voodoo Zeugs. Also man hat einfach alles, plain FTP und HTP-mäßig so durch die Gegend geschoben, das war cool, das war hip und Verschlüsselung war eigentlich so überhaupt nicht gegeben an der Stelle. Und ja, deshalb haben wir hier dieses wunderschöne Schloss gewählt, weil es war halt früher, hat man da nicht mit dem gleichen Blickabind darauf geschaut, wie heute es gab, diesen ganzen DSG-VO-Thema nicht. Verschlüsselung war einfach nicht so wichtig, es war nicht so schwierig, Daten auszulesen und deshalb haben früher einfach die meisten Leute ja und verschlüsselt per FTP vermutlich auf ihren Live-Projekten gearbeitet und sind dann auf den Live-Web-Seiten rumgehüpft. Und... Machst du noch mal weiter? Die Präsentation geht auf Robert's Kappe. Genau. Und zwar das, was glaube ich jedem schon mal wahrscheinlich heute auch noch passiert, aber früher ist es umso häufiger passiert. Das Risiko, mit dem man leben muss, wenn man auf Live-Web-Seiten arbeitet, ist einfach, dass auf einmal alles kaputt ist, weil man versehentlich irgendwo, weiß nicht, das von PRP das Open Tech rausgelöscht hat und hat man auch immer Plain PRP auf der Seite stehen oder solche Dinge. Und ja, ich denke, das war früher, es dreht heute immer noch auf. Ja, aber früher war es deutlich häufiger, weil mittlerweile gibt es coolere Lösungen, die einem an einfacher Staging ermöglichen. Und wenn man sich mal überlegt, warum das früher so war, natürlich zum einen, weil das der Anwender, der, ja, ich sage mal, der Entwickler, in dem Sinne, es war nicht so einfach, damals ist es so einfach, sich Wissen anzueignen, wie es heute ist, aber auch aus Haus, dass ich gab, ist da so ein paar Herausforderungen, so ein paar Schwierigkeiten. Eigentlich war es so, dass es früher, man weiß nicht, es gab keinen wirklichen Standard wie heute, es gab keinen Open Source, es gab weiß nicht so, Standards waren doof, Standards waren total langweilig und blöd, jeder wollte so einen eigenen Kram machen und da hat jeder so einfach sein eigenes Süppchen gekocht. Ich kann das mal mit uns z.B. sehen, wir haben früher angefangen mit Config-Servern, also bei Mitwalter haben wir Config-Server verkauft und haben dann irgendwann gemerkt, okay, irgendwie hat das Ganze jetzt nicht so richtig geilen Komfort für den Kunden, das ist irgendwie ein bisschen doof und skalieren konnte man auch so wirklich, dann haben wir angefangen, diese Config-Server abzulösen, haben eben geschaut, okay, welche Lösungen nutzt man da am besten, haben dann angefangen uns selbst Lösungen zu schreiben, haben, schön guten Tag, haben uns angefangen, selbst Lösungen zu schreiben, haben eigene Skripte geschrieben, eigene Anwendungen, haben eines Kundencenter programmiert und kamen dann im Zuge dieser, dieses Weg ist bis heute an verschiedene Punkte, wo wir dann so, ich sage mal, Make or Buy Entscheidung treffen mussten. Das heißt, wir müssen so belegen, entwickeln wir jetzt noch etwas selber und binden uns in Anführungszeichen noch ein Klotz an Spine oder kaufen wir fertige Lösungen ein, schräg-schräg nutzen wir fertige Lösungen. Und wir haben uns dann nicht direkt fürs Buy entschieden, sondern wir haben uns dafür entschieden, auf Open Source zu setzen. Das heißt, die Dinge, die man Open Source beziehen konnte, haben wir Open Source bezogen. Zum Beispiel, klassisch, zum Beispiel Typ 3, also unser Kundencenter ist in Typ 3 gebaut. Wir haben dann angefangen auf Typ 3 das Kundencenter aufzusetzen, haben wir Typ 3 größtenteils alles gemacht und haben dann mit der Zeit aber auch gemerkt, dass dieses Open Source Thema einfach, das ist das Ding. Und wir wollten einfach auch ein bisschen was zurückgeben und nicht nur was nehmen, weil davon lebt dieses ganze Open Source und haben dann auch selbst angefangen, Dinge auf GitHub, zum Beispiel, ist glaube ich so die klassische Plattform für Open Source Themen, haben dort angefangen, selbst Dinge zu publizieren. Das heißt, wir haben Code, den wir beschrieben haben, den wir für Probleme geschrieben haben. Wir haben gesagt, okay, vielleicht hilft den, hilft dieser Code auch anderen Leuten, hilft dieses Programm anderen Leuten und haben es dann eben auf GitHub, auf unserem GitHub Account veröffentlicht, um da einfach der Open Source Community einfach ein Stück weit zurück zu geben und da auch ein bisschen weit voranzugehen und dort einfach Dinge zu publizieren. Und dieses ganze Open Source Thema kann man noch viel weiterspinnen. Ich denke hier bis alle, das wird bis auch Open Source mäßig unterwegs ist. Das muss ich glaube ich nicht erzählen. Und ja, der Robert arbeitet ganz viel damit und ich denke, jetzt ist deine Zeit gekommen. Ja, genau. Das ist das Gute, wenn du Leute hast, die quasi Dinge machen können. Das ist quasi, so arbeiten wir am liebsten auf Projekten. Das heißt, wir haben als Basis, haben wir quasi Repositories. Das heißt, wir haben auf Bitbucket aktuell ca. 800 Repositories liegen. Oder auf Bitbucket haben wir 800 Repositories liegen, wo quasi jedes, jedes Plugin, jedes Seam und die Webseite selber sind jeweils ein eigenes Repository, weil man eben dann Dinge wieder verwenden kann. Zum Beispiel sowas wie Yoast benutzen wir auf mehreren Instanzen, sowas wie eigene Plugins von uns werden auf mehreren Instanzen benutzt. Zum Beispiel Multilingualpress benutzen wir auf sehr vielen Instanzen. Und deswegen haben wir das quasi, haben wir einen Repository und eben dann Packages, die da drum herum sind. Das Ganze wird bei uns dann über Codeship ausgerollt. Das heißt, wir haben eine Codeship-Instanz, auf der dann das ganze Paket gebaut wird. Und das wird dann, wie ihr seht quasi hier drüben, wird dort quasi Composer ausgeführt auf dem, auf dem Codeship wird alles zusammengebaut. Und dann, wenn das fertig ist, wird das quasi ausgerollt auf die Instanz. Da haben wir gleich noch genau dazu bieten, wie das quasi dann einzeln dort passiert. Und dort werden wir quasi dann, wird bei New Relic ein neues Event angelegt, dass wir auch wissen, ob das Release quasi gut durchlief. Und dann wird das ganze Ding auf dem Web-Soft ausgerollt und wir bekommen per Slack eine Information. So, das ist quasi jetzt unser aktueller Workflow, auf den ich jetzt im Einzelnen nochmal eingehe. Das heißt, für uns zum Beispiel benutzen wir Composer als Basis. Habt ihr heute schon mal irgendwo bei hier eine Session gehabt zu Composer? Wir benutzen das als Abhängigkeits-Tool. Das heißt, wir können quasi sagen, dass das Plug-in Multilingual-Press von verschiedenen anderen Plug-ins und anderen Paketen quasi abhängt, die sich dann von Composer beim Ausrollen auf dem Server automatisch geholt werden. Das heißt, wir haben immer genau definiert, welche Plug-in-Version hängt von welcher Plug-in-Version ab und welches Modul wird noch extra gebraucht und dass wir quasi die Applikation jederzeit auf einem anderen Server wieder herstellen können. Das heißt, wenn ihr zum Beispiel das kennt, ihr habt einen Server, wo ihr per FDP Sachen hochladet, kann es halt sein, dass ihr dort quasi in dem WordPress ein Update macht. Dann könnt ihr quasi diese Installation nicht ohne Weiteres auf einem anderen Server wieder herstellen. Ihr könnt nicht quasi, wenn euch ein Server flöten geht und ihr habt nur ein Backup-Datenbank, wisst ihr halt nicht mehr genau, welche Version von welchem Plug-in liegt da drauf. Das heißt, für uns ist immer um, ist immer quasi Composer die Basis von allem. Das heißt, wir wissen ganz genau, was liegt auf dem Server, weil wir quasi das Deployen machen wir mit der genau exakten Version. Das heißt, wir wissen exakt, was auf dem Server drauf ist. Das sieht quasi aus über unser eigenes Tool WP-Starter, was wir erzeugt haben. Ihr seht hier hinten die URL-Struktur. Das sieht ein bisschen anders als ein normales WordPress, weil wir trennen quasi WP-Content mit allem, was speziell ist, mit allem, was Plug-in Seams trennen wir quasi vom WordPress Core, weil der WordPress Core ist quasi was, was wir nicht anfassen. Aber alles, was in WP-Content drin liegt, fassen wir an. Das heißt, wir benutzen WP-Starter, was eben auf Composer aufbaut. Das heißt, wir können damit auch definieren, dass bei einem Release auf einem Server vorher ein Backup gemacht wird, was irgendwo hingelegt wird. Dann wird das Composer quasi, baut sich über WP-Starter quasi alles zusammen. Wir können WP-Starter auch definieren, welche WordPress-Version wir exakt haben wollen auf der Instanz. Wir können neue auswählen, wir können alte auswählen. Wir können definieren eben exakt genau, was wir auf der Zielinstanz haben wollen. Und das Besondere bei WP-Starter ist, dass wir Environment-Files haben. Das heißt, in der professionellen Entwicklungsform existieren sowas wie WP-Config. Da dahin existieren da nicht, sondern da existieren quasi Environment-Files. Das heißt, man definiert quasi eine Konstante, die quasi im Environment-File drin ist. Darüber können wir zum Beispiel definieren, dass wir Updates ausschalten. Das heißt, wir schreiben nicht in die WP-Config rein. Updates funktionieren nicht, oder wir schreiben nicht in WP-Config rein, sondern wir haben Environment-Variablen, die man eben auch über das Environment selbst und nicht über die Environmental-Teile setzen kann, die von WP-Starter ausgelesen werden und dann auf die Instanz quasi ausgerollt werden. Das heißt, wir haben keine WP-Content, wir haben ein Environment-File, und das ist für jedes Environment eindeutig und einzeln und wird bei jedem Deployment quasi gesümmelingt. Da kommen wir schon auch zum nächsten Punkt. Und zwar unser Zero-Down-Time-Deployment. Das heißt, wenn ihr quasi auf einer Installation irgendwo was hochladet, kann es halt sein, dass genau zu dem Zeitpunkt, wo ihr Sachen hochladet, wenn es zum Beispiel ein Plug-in-Hochlader ist, das Plug-in hat 200 Files, kann es halt sein, dass ihr quasi die Hauptdatei überspielt hat, die Hauptdatei selber von dem Plug-in greift sich irgendwo hin, lädt sich eine Datei dazu, eine PAP-Datei, aber die habt ihr noch nicht hochgeladen in der neuen Version. Aber das Hauptfeil greift schon quasi auf Funktionen, zu denen ihr noch gar nicht da seid. Das heißt, wenn ihr quasi dort mitten beim Upload seid, kann es halt sein, dass euch quasi euer WordPress kaputt geht, weil ihr ein Plug-in habt, was noch nicht völlig hochgeladen ist. Das ist bei normalen Seiten ist das okay, dass so ein Plug-in ist in einem Upload, quasi wenn es schnell geht, ist das mal in einer Minute oder 30 Sekunden, ist das durch. Das Problem ist nur, das ist halt quasi, so kann man halt nicht professionell arbeiten, wenn man nicht eben 100% nicht sagen kann, dass die Applikation quasi immer funktioniert. Deswegen benutzen wir Zero-Down-Time-Deployment. Das heißt, wir erzeugen einen Ordner-Releases auf dem Server. In dem Ordner-Releases erzeugen wir einen Datumsordner, eben quasi genau die Sekunde. Spielen dort von WP Starter die Composer-Chesen rein, lassen das Composer durchlaufen. Und erst, wenn alles durch ist, erst, wenn alle Pakete da sind, alle quasi Installe, dass alles sich heruntergeladen wurde, alle Artefakte quasi da sind. Und wir wissen, das hat funktioniert. Dann erst werden wir quasi den Symlink, den symbolischen Link auf dem Server, der auf dem, wo der Web-Server quasi drauf zeigt, auf das Verzeichen ist. Das ist bei uns ein symbolischer Link. Und den ändern wir. Und das ändern das Symbol des Linkes dauert es unter einer Sekunde. Das heißt, von jetzt auf gleich ist die neue Instanz quasi live mit allen PAP-Falls, die da liegen. Und deswegen bemerkt halt keiner, dass es quasi, dass gerade ein neues Release ausgeführt wird. So arbeiten quasi auch die großen Agenturen, weil eben genau damit du sicherstellen kannst, dass du halt eine Applikation hast, wo du weißt, was da quasi ist. Die ganz, die noch größeren arbeiten so, dass sie komplette Server wegwerfen. Dass sie quasi virtuelle Server erzeugen, dort alles hinwerfen. Und dann quasi das IP-Routing auf den neuen Server umstellen. Dass es quasi nochmal und nochmal größer, dann schmeißt du quasi komplette Infrastrukturen virtuell weg. Zum Logging benutzen wir, wenn das quasi alles ausgerollt ist, müssen wir wissen, ob die Applikation quasi funktioniert. Aus dem Grund benutzen wir kein Logging im Normalfall, was auf dem Server ist. Das heißt, bei euch ist es so, dass ihr quasi im Normalfall habt ihr einen Arrow-Log vom Server. Das heißt, da schaut ihr rein, wenn zum Beispiel euch der Kunde sagt, ihr ist irgendwas bei mir komisch, kannst du mal nachgucken. Das heißt, dass wir auf den Elkstack aufbauen. Das heißt, wir benutzen, Elkstack ist quasi Elasticsearch, Logstack und Kibana. Was eben ein komplett anderer Ansatz ist, im Sinne von, wir Logging, wir Logging vom Server dorthin und können quasi, in dem Tool, was wir benutzen, in dem Fall Logs.io, können wir quasi einstellen, dass wir per Slack Bescheid wissen. Das heißt, für uns ist quasi der Vorteil, dass wir nicht darauf warten, dass uns der Kunde sagt, ich habe da eine Fehlermeldung gesehen, kannst du mal nachschauen, oder dass wir quasi in einem Rhythmus von einmal pro Woche in den Logfalls gucken, sondern wir, wenn quasi in der Applikation irgendwas ist, wo wir auch selber ein Logging definieren im PHP, wo wir selber sagen können, wenn das Auftritt schmeißt, nicht einfach nur ein Fahrteil Error, sondern macht den Fahrteil Error genauso, dass wir das Logging später innerhalb von Sekunden quasi terabyteweise Logfalls durchsuchen können. Deswegen benutzen wir das und haben uns da für eine extra Weiterung geschrieben, für WordPress, heißt Monologue. Das ist quasi ein System, das basiert auf dem im PHP-Universum bekannten Monologue, was eben andere Logging-Dienste ansprechen kann und wir haben eben eine WordPresser-Weiterung dafür gebaut. Das wäre jetzt quasi der Einblick, wie wir quasi Sachen ausrollen und damit wieder zurück zum Hoster. Klingt so ein bisschen bei der Formel 1. Okay, kannst du? Ach so, alles klar. Damit diese ganze Magic, die Robert gerade erklärt hat, auch einwandweit funktioniert, gibt es natürlich gewisse Software, die Systemseite beziehungsweise vom Hoster in irgendeiner Form bereitgestellt werden muss. Und wenn man als Hoster oder als Systembetreuer in welcher Form man da auch immer auftritt, da dran geht und irgendwie in ein paar Orgäte versucht zu schnüren, ist das immer so eine Herausforderung, wo man sich denkt, okay, welche Software braucht mein Kunde jetzt? Das ist natürlich klar. Also so Evergreens wie Git, Composer, PHP, die sind natürlich immer am Start und das ist klar, die brauche ich. Aber gerade wenn es so an so spezielle Dinge geht wie Robert, das ist erklärt gerade mit dem automatisierten Deployment, mit der ganzen Elasticsearch-Geschichte, gibt es natürlich noch weitere Services, wir haben hier beispielsweise ein paar aufgeführt. Es ist natürlich klar, der X-Deck funktioniert nicht ohne Elasticsearch, das heißt im Idealfall stelle ich als Hoster meinem Kunden auch noch ein Elasticsearch bereit. Wir haben dann natürlich ein Redis, der als Datenbank-Gesch genutscht werden kann, der dazu genutzt werden kann, um die Sessions dort reinzuwerfen, damit ich das über mehrere Server hin auch vernünftig skalieren kann. Vielleicht möchte ich noch ein Warneschnutzen, um dann wirklich richtig schnelle Auslieferungszeiten zu kriegen. Und das sind alles Dinge, die man als Kunde oder bereitstellen sollte, damit man als Kunde wirklich Spaß mit seinem Tarif, mit seinem Paket hat. Das Problem ist natürlich, man kann nicht von Anfang an alles bereitstellen, weil wenn ich sage, ich möchte von Anfang an mit jedes Software einbinden, dann entwickle ich erstmal 2 Jahre lang nur Software und versuche irgendwie mit meine Tarife zu kriegen und dann kann ich erst anfangen meinem Kunden wirklich zu hosten. Das heißt, die nächstgrößte Herausforderung ist zu schauen, wie kriege ich meine Infrastruktur wirklich so, also als Hoster wirklich so modular und so flexibel aufgestellt, dass ich die Möglichkeit habe, im Nachhinein auch Software zu ergänzen. Das heißt, wenn jetzt zum Beispiel Robert kommt und sagt, hey, wir würden da gerne auch bei euch Blackfire nutzen, dass wir nicht sagen müssen, oder dass wir nicht sagen müssen, nee, sorry, ist nicht, weil können wir nicht abbilden, sondern dass wir sagen, ja klar, kein Problem, können wir dir einbauen, nicht jetzt sofort, weil halt logischerweise noch andere Sachen da sind, aber wir können das in einem Zeitraum X, können wir das Problem uns bei uns ergänzen. Das ist ein riesen Thema, über das sich jeder Host auf jeden Fall Gedanken machen muss und was eigentlich in der heutigen Zeit abgedeckt sein muss, weil jeder Kunde andere Anforderungen hat an das System, an die Software, die er anbieten oder die er, die vorhanden sein muss. Jetzt könnte man natürlich auf die Idee kommen, als Entwickler oder als Softwarebude zu sagen, ich weiß ja am besten, was ich so an Software brauche und warum host ich den ganzen Bums nicht einfach selbst, ich habe hier mein Server bei AWS oder irgendwo ein Rootserver, x-beliebiger Anbieter und installieren mir den ganzen Kram selbst. Ich denke, das größte Thema bei dieser ganzen Self-hosting-Geschichte ist jetzt auch gerade seit der DSGVO-Thematik der Security Aspekt. Das heißt, viele Leute sind sich gar nicht bewusst, was es bedeutet, eigene Server zu betreiben, eigene Systeme zu hosten, solche Themen zu warten. Es gibt verschiedene Mailing-Listen, in denen man sich eingetragen haben sollte. Es gibt verschiedene Seiten, auf die man sich regelmäßig rumtreiben sollte, um wirklich dann Sicherheitslücken, kritische Sicherheitslücken mitzukriegen und da meine ich jetzt nicht so Sicherheitslücken wie Dirty Cow, die dann, weiß ich nicht, weltweit überall breitgetreten wurden. Ich meine, wenn so eine Sicherheitslücke im Radio ausgeschraubt, wie mein Radio und Internet, also wenn so eine Sicherheitslücke im Radio bekanntgegeben wird, ist auch schon abgefahren. Wer es vorher nicht mitbekommen hat, der hat schon verloren quasi. Dirty Cow wurde sehr breitgetreten. Aber es gibt fast wöchentlich oder täglich Security-Releases oder Security-Notes von Dingen, die im Linux-Kernel auffallen, die sonst irgendwo auffallen, die so niemand mitbekommen, die man als Hoster, als Zauberbetreiber auf dem Schirm haben muss. Man muss das Know-how haben, diese Lücken auch bewerten zu können. Man kann für gewöhnlich diese Security-Leaks betitelt. Das heißt, man muss wissen, okay, welche Version ist das? Steht meistens drin. Benutzt sich diese Version. Wie kann diese Sicherheitslücke ausgenutzt werden? Kann die Sicherheitslücke bei mir ausgenutzt werden? Fangen wir die zu gehen, wenn falls irgendwo ab. Und im Endeffekt kann es dann tatsächlich passieren, wenn man dort nicht vernünftig aufpasst, dass man wegen einer Sicherheitslücke in einem bestimmten Patch-Level in der Open-SSR-Server-Version, die Open-SSR hat jeder auf seinem Server, weil sonst kann man sich bei SSR verbinden, dass deshalb die ganze Maschine gekapert wird. Und wenn man dann seinen 20-30-40-Kunden erklärt, muss hey, sorry, ein bisschen blöd gelaufen, deine Daten sind jetzt irgendwo sonstwo, ist das nicht ganz so cool. Das heißt, dieses Security-Thema ist ein Riesending, das viel zu sehr unterschätzt wird und wenn man eigene Systeme betreibt, über das man sich auf jeden Fall im Klaren sein sollte, was für eine Lastmandament hat und was für eine Verantwortungmandament hat, da auch vernünftig umzugehen. Das gute Thematik gibt es natürlich noch, die Thematik des technischen Ambalbleibens, habe ich, glaube ich, da oben betitelt, ja. In der IT, ich weiß nicht, wie man das so sagt, so eine Woche sind, ich weiß nicht, im echten Leben ein Jahr. Also es ist sehr, sehr schnelllebig, es kommen viele, viele neue Sachen und ein bestes Beispiel ist zum Beispiel die Geschichte mit Let's Encrypt. Das heißt, es kam so eine Zeit, da war, es war, glaube ich, so letztes Jahr oder wurde es vermehrt stärker, dass man es einfach nicht mal eingesehen hat, für SSL-Zertifikate Geld zu bezahlen und dann wurde dieses Let's Encrypt-Thema ganz stark und es ist halt gerade so, als kleine Softwarebude, mein Hauptthema ist einfach Web-Entwicklung. Ich bin fit im WordPress-Seiten-Gestalt, ich bin fit in JavaScript und so weiter und so fort, was auch gut ist, aber wenn es darum geht, okay, ich muss das machen, ich muss meine Kerngeschäft und muss dann noch meine Server-Infrastruktur betreuen, muss meine Server-Infrastruktur updaten, ich muss dafür sorgen, dass mein Ubuntu, Debian, welches OS auch immer aktualisiert wird, Sicherheitspatches, ich muss gucken, dass ich das vernünftig skalieren kann, ich brauche immer wieder neue Server, die müssen automatisiert eingerichtet werden, das muss alles sofort zack, zack, zack gehen, dann brauchen alle meine Kunden Let's Encrypt, sondern habe ich da 20 Server, die ich updaten muss und da bin ich dann auch mal eben wie es jetzt jetzt Encrypt war, was ja doch nicht plötzlich gekommen ist, aber was automatisch alle meine gesamte Infrastruktur betrifft, dann spätestens dann trennt sich so die Spreu vom Weizen, weil da kommen dann viele kleine Hoster, viele Software-Boon, die ihre eigenen Server betreiben, kommen in Stolpern und denken sich, oh, also irgendwie ist das jetzt doch nicht so einfach, dann habe ich ein Entwickler-Fee-Wochen abgestellt, bis er alle Systeme geupdatet hat, da hätte er halt auch gut andere Aufträge abwickeln können. Was zuwürzlich nicht vernachlässigt werden darf, ist das Monitoring Server natürlich, mit wachsenden Kunden angenommen, ich hause selbst oder als Herausforderung, die Herausforderung des Hoster-Systembetreibers ist, sicherzustellen, dass alle meine Server trotzdem erreichbar sind, dass alle meine Server laufen, dass mein Netzwerk vernünftig funktioniert, dass ich nirgendwo Paketverlust habe, dass meine Web-Server ausliefern, dass ich noch genug Kapazitäten frei habe, wenn ich jetzt, weiß ich nicht, ein Kunde hat viel Traffic und dann ist der ganze Server irgendwie weg oder ist ziemlich stark unterlassend, der auch alles und meine anderen Kunden haben gar nichts mehr. Das sind so Dinge, die auf jeden Fall die berücksichtigt werden müssen, in denen ich auch für dich verantwortlich bin, sobald ich meine eigene Server-Infrastruktur betreibe. Da gibt es so verschiedene Möglichkeiten. Ich habe jetzt hier mal so ein kleines Dashboard, das ist nennst sich Grafana. Grafana ist ein Virtualisierungsdienst für diverse Arten von Metriken und wäre zum Beispiel eine Möglichkeit, da ist eine Möglichkeit, die wir jetzt auch nutzen, um eben Metriken, also Daten über Server zu visualisieren. Damit haben wir die Möglichkeit, verschiedene Dinge zu visualisieren, wie zum Beispiel, in dem Fall sind es jetzt verfügbare Kapazitäten, verbrauchter RAM, Server Auslastung, wo ist die Server Auslastung, größer 1, da kann man ganz verschiedene Dinge mitmachen und wenn man dann, wenn man wirklich hingeht und sagt, ich möchte meine eigene Infrastruktur betreiben, ist das auf jeden Fall ein Thema, um das man sich Gedanken machen sollte und um das man sich kümmern muss. Im Zuge dieser ganzen Monitoring-Geschichte, Server-Infrastruktur betreiben, kommen früher oder später das Thema Skalierung auf den Tisch. Das heißt, das gibt ja dieses Scale up und Scale out. Das heißt, pack ich, schmeiß ich mein Server mit Hardware tot oder stelle ich mehrere Server hin, auf die ich meine Workload verteilen kann und da kriegt das Thema natürlich auch noch mal eine besondere Relevanz. Neben den Systemaspekten, die es beim Scaling gibt, gibt es glaube ich, bei WordPress noch einige Besonderheiten. Genau, wenn jetzt die richtige Slide kommt. Ja, genau, wir haben quasi, also die, das Einfachste, was ihr gerade gesagt habt, eben das Scaling, das heißt, wenn man quasi eine Applikation hat und man hat eben einen Server und der Server reicht, kann man den so aber halt sehr, sehr groß machen, im Sinne von einfach mal quasi einen Terabyte RAM rein und quasi 32 CPUs drauf. Wenn das aber eben nicht mehr reicht, nehmen wir einfach mal das Beispiel WordPress.com. Das sind mehrere Millionen Sites. Gibt es quasi die Möglichkeit in der WordPress Community, die dort einen Ausfall, ein anderes System zu nehmen. Da gab es früher HyperDB, es gab MultiDB von verschiedenen Anbietern. Oder eben jetzt das Ludacris, oder wie sie auch immer ausgesprochen, Ludacros DB. Es sind sich Leute nicht sicher, wie das ausgesprochen wird. Ich werde nochmal den Entwickler davon fragen. Das funktioniert quasi so, dass das eine Basis ist für die Multisite. Das heißt, Multisite funktioniert bei WordPress, sodass auf einer WordPress Installation mehrere Instanzen sind. Und die einzige Instanz, die quasi immer gleich ist, sind die User. Die sind immer über alle Systeme. Gleich deswegen habt ihr quasi mit einem User auf WordPress. Könnt ihr euch quasi auf mehreren Sites einloggen. Die Datenbankverteilung läuft quasi dann so, dass ihr das DB.pap, die quasi in dem Repo beilegt, die legt ihr quasi in das WordPress, in den WordPress-WP-Content Ordner. Sobald die da drin liegt, wird WordPress die automatisch benutzen. Die wer dann quasi benutzt, sobald WordPress neue Datenbankverbindungen aufmacht, schaut ihr zuerst in diese DB.pap rein und würde sich von dort die Datenbankklasse holen. Und im Fall von den Datenbankverteilungssystemen ist es dann quasi so, dass du damit mehrere Datenbanken benutzen kannst. Das heißt, du kannst sagen, dass zum Beispiel du 4096 Datenbanken hast und jede WordPress-Site in der Multisite liegt in einer anderen Datenbank. Das wiederum heißt, wenn man das möchte, zum Beispiel seit Nummer 15, könnte man auf einen eigenen MySQL-Server legen, um halt wirklich Skalierung für die einzelnen Sites zu machen. Wenn da viel Last drauf ist, kann man wirklich da einzelne Sachen machen, einzelne Datenbank-Server dafür extra ausstellen. Zum Beispiel, wenn die Datenbank Nummer 14, wenn die in Japan sehr benutzt wird, könnte man die MySQL-Server zum Beispiel dort in Japan hinlegen und könnte ein global distributiertes System haben, wo eben, wenn sehr viel Last in Japan ist, eben die Datenbank dort auch in Japan steht. So macht es zum Beispiel auch WordPress.com als Basis für die Geschichte. Und das sind quasi Möglichkeiten, wie man WordPress out of the box skalieren kann, um eben dort mit der Applikation schon mehrere Server zu benutzen, ohne eben auf einem Server, den einen Server quasi hoch zu skalieren. Ja, und jetzt wäre quasi wieder dran. Genau, neben der Applikationsseitigen, also neben der Applikationsseitigen Anpassung, die man machen kann, um eine Anwendung zu skalieren. Das heißt, zu schauen, okay, wie kriege ich es jetzt hin, dass meine verschiedene Datenbank-Server, dass meine verschiedenen Datenbank-Server genutzt werden. Das setzt ja schon ein gewisses Skill-Level voraus, was ich mitbringen muss, was meinen Entwicklern mitbringen müssen. Eine gewisse Lust auf Dinge tun voraus, weil wenn ich da, weiß ich nicht, in eine Datei etliche Zeilen Code bretern muss, nur um da so eine unterschiedliche Datenbank-Server anzusprechen, ist es halt nicht mal eben einfach so gemacht. Systemseitig gibt es natürlich auch Herausforderungen, die ich bewältigen muss. Wenn ich sage, okay, ich möchte meine Anwendung jetzt skalieren, ich möchte meine Anwendung über mehrere Servers skalieren, dann gibt es so Dinge wie, okay, wie stelle ich es sicher, dass alle meine Seiten den gleichen Inhalt haben, auf die gleichen Content zugreifen, auf die gleichen Datenbestand. Wie kriege ich es hin, dass meine Sessions, also die User-Sessions, gerade in Shops, besonders spannend, dass die konsistent gehalten werden. Das heißt, Benutzer kommt auf Server 1 raus, beim nächsten Aufruf bist du auf Server 3. Wie schaffe ich es, dass immer noch seine Session von Server 1 hat und nicht auf einmal seinen Warenkopf weggeflogen ist oder sowas? Wie kriege ich es hin, dass ich möglichst, eine möglichst hohe Ausfallsicherheit erreiche? Wie schaffe ich es, wenn man sich an das Thema Scaling geht? Das heißt, angenommen, ich habe ein Low-Benetzer, der fällt weg, dann geht nichts mehr und wie schaffe ich es, dass das eben nicht der Fall ist? Diese Fragen muss man sich immer stellen, bevor man überhaupt anfängt, die Anwendung zu optimieren, wenn es an das Thema Scaling geht. Und relativ schnell, wenn man sich um diese Dinge kümmert, wird man an den Punkt der Orchestrierung kommen. Das heißt, viele von euch haben sicherlich schon mal den Begriff Kubernetes gehört und Docker. Ich weiß, eben war eine Session dazu, da waren, glaube ich, auch ein paar von euch drin. Oh, ich glaube, so bin ich besser. Okay, die Geschichte damit, dass man dann eben schauen muss, okay, wie skaliere ich meine Anwendung jetzt am einfachsten und nach Möglichkeit auch automatisiert über mehrere Server. Das ist halt so ein Ding, was gegeben sein muss, sobald man stark frequentierte Seiten hat. Das heißt, meine Aufrufe gehen hoch. Auf dem einen, eine Auslieferungszeit, die weiß ich nicht, eine Sekunde überschreitet, das finde ich meine Schmerzgrenze, alles klar. Wenn dieser Punkt erreicht ist, müssen jetzt weitere, muss ich skalieren. Das heißt, ich brauche weitere Anwendungs Anwendungsinstanzen, die dann auch meine Besucher bedienen können, damit ich meine Auslieferungszeit wieder runter skalieren kann. Und das alles möchte man natürlich als Hoster oder als Mensch, der Infrastruktur bereitstellt, möchte ich meinem Kunden bieten oder muss ich meinem Kunden bieten, ohne dass er jetzt Anpassung vornehmen muss. Ich denke, das ist dann so der Moment, wo man sagt, okay, dann habe ich es geschafft. Das heißt, wenn der Kunden da einfach hingehen kann, kann sagen, okay, ich möchte die Zimmern WordPress haben, hat dann sein WordPress, baut dort seine Seite auf und weiß ganz genau, alles klar, der Hoster kümmert sich darum, wenn ich jetzt auf einmal, ich komme in der Höhe der Löwen oder so und habe dann 200.000 Aufrufe gleichzeitig, dass ich weiß, alles klar, kein Problem. Mein Hoster kümmert sich darum, dass meine Anwendung automatisch skaliert, dass ich automatisch weitere Server hinzugeschaltet bekomme und die wieder runtergeschaltet werden, sobald der Besucher ansturm eben abflacht. Und das ist eine Herausforderung, die auf jeden Fall bewältigt werden muss, die bewältigt werden kann. Und ja, ich glaube, ich sonst habe ich nichts mehr. Ja. Die kommt später, glaube ich. Kommt sie? Ich habe noch keinen, ich habe es nicht abgedacht. Agenda gesehen, wo sie landet. Ich muss auch einmal Thomas fragen. Also, okay. Ich habe noch irgendjemand. Ah, da hinten, eine Frage. Ja. Beim normalen, beim... Ja, hast du die Frage wieder? Okay. Die Frage fürs Video war, wie weit entfernt Mitwald Hosting von Blackfire und New Relic war es, ne? Ja, genau. Ja, ich hau jetzt einfach mal raus. Also wir arbeiten aktuell oder schon seit Längern am neuen Produkt, deshalb auch dieses wunderschöne T-Shirt, dieses neue Produkt, nennt sich Spaces. Das ist auch das, wo der Robert jetzt zum Beispiel unter anderem darauf entwickelt. Und tatsächlich haben wir bei Spaces von Anfang an eine New Relic Integration. Das heißt, du kannst, wenn du dein Space angelegt hast und in welcher Form auch immer, WordPress oder einfach nur ein Lampstack auch die Möglichkeit besteht, kannst du einfach in die New Relic.ini zum Beispiel gehen und kannst sagen, ich trage jetzt hier, es gibt ja diese Keys da, die du eintragen kannst, den kannst du da eintragen. Aktivierst dann dieses Eni-File, den du es halt im Punkt ini umbenennst und in dem Moment connectiert sich halt deine Anwendung dann direkt mit New Relic. Und das coole ist, dass wir auch tatsächlich die Möglichkeit haben, okay, ihr seid auch so Fans von Blackfire, ich weiß nicht, was das besser macht als New Relic oder was nicht, auf jeden Fall sind wir auch daran, das mit zu integrieren. Das ist ein bisschen herausfordernder, weil die ja diesen Agent haben, der zusätzlich laufen muss, sobald du mehrere Instanzen hast und da sind wir auch daran, das zu implementieren. Es wird auch implementiert, jetzt jedoch nicht zum Release. Das Release kommt bald und aber New Relic ist wie gesagt ab Werk, ab Werk direkt dabei und auch so mit Spaces haben wir auch so Dinge wie automatische Skalierung abgefangen. Wir haben Dinge wie zentrale Datenverwaltung, wie gesagt automatische Skalierung, automatisches zentrale Session Management und alle diese High Enterprise Dinge, die man voraussetzt, die man braucht, sind damit tatsächlich dann auch abgegolden. Ja. Weitere Fragen. Fürs Video es gibt keine weiteren Fragen. Ja, danke.