Folge 15

Von eins bis eine Million – wie man Software skalierbar macht.

„In der Softwareentwicklung kann man Dinge beschleunigen oder parallelisieren, man kann Sachen abstrahieren oder das Problem abstrahieren um dadurch besser zu werden. Oder man kann überlegen: Welche Dinge kann ich vorbereiten?“

Hallo und herzlich willkommen zu unserer neuen Staffel „Informatiker erklären die Welt“. Mein Name ist Marie und ich begrüße euch zu diesem neuen Format innerhalb unseres Gigabit Podcasts. Für unsere Technikfans haben wir ab heute die erste Folge unserer neuen Staffel am Start, von Software-Interessierten für Software-Interessierte. Dieser Podcast richtet sich an alle, die mehr über Software-Technologien und wie man sie anwendet, wissen wollen. Die neue Staffel eröffnen Dirk und Matthias. Beide sind Softwareentwickler bei consistec. Wir sprechen heute über das Thema Skalierung von Softwaresystemen. Warum braucht man skalierbare Software? Wir zeigen anhand von einigen Beispielen aus dem alltäglichen Leben, warum Software skalierbar sein muss. Viel Spaß beim Hören!

Transkription

Dirk Leinenbach: Hi! Willkommen zu unserem neuen Format im Podcast von der consistec. Ich bin Dirk und ich bin bei der consistec für die Softwareentwicklung so im Großen zuständig. Wenn ich technisch arbeiten darf, was ich sehr gerne mache, dann bezieht sich das meistens so auf den C++ Bereich oder Low-Level-, High-Performance-Lösungen. Heute sitze ich hier zusammen mit dem Matthias. Matthias, vielleicht magst du dich mal kurz vorstellen.

Matthias Höschele: Hallo! Mein Name ist Matthias Höschele, ich bin Senior Software Engineer bei der consistec im Bereich Backend-, Skala- Entwicklung. Das heutige Thema ist Skalierung. Dirk, was ist denn Skalierung, was machen wir den ganzen Tag?

Dirk Leinenbach: Ich würde sagen, Skalierung, so mal von der IT weggesehen, ist Skalierung, dass man eine Lösung, die man für ein kleines Problem hat, dass man die umsetzen kann für riesige Probleme. So Beispiel, nehmen wir mal Autoherstellung: Du bist in der Lage mit ein, zwei Leuten ein Auto in ein paar Wochen herzustellen. Und jetzt willst du VW werden oder du bist Tesla und willst das jetzt in die Produktion kriegen für richtig große Stückzahlen. Du willst nicht ein Auto im Monat bauen, sondern du willst hunderttausende Autos in der Woche bauen. Das ist genau das Thema. Und dass das nicht trivial ist, sieht man gerade bei Tesla auch immer wieder, wie spannend das sein kann. Das ist ein Problem, das haben wir in der Softwareentwicklung auch oder da hat man das ganz oft. Da gibt’s sehr viele Buzzwords. Wir wollen heute mal so ein bisschen beleuchten, welche Wege man da hat, um das anzugehen. Was kann man da tun? Was sind Fallstricke, in die man gerne läuft? Ich weiß nicht, aber ich glaube, allzu technisch sollten wir heute nicht werden. Also lass uns da mal versuchen, so ein bisschen von der IT weg zu bleiben, wenn es irgendwie geht.

Matthias Höschele: Ja genau! Wir wollen viel gerade jetzt aus den Bereichen Produktion und Logistik ein bisschen mit Bildern und Metaphern und Beispielen arbeiten, die sehr nahe sind an den Problemen, die wir bei der Softwareentwicklung auch ähnlich haben und deren Lösungen auch ähnlich sind in unserem Bereich. Vielleicht, um das zurückzubringen auf unsere Arbeit und unsere Lösungen bei consistec. Wenn wir eine Lösung entwickeln, um von zum Beispiel einer Megabit-Leitung für 10 Minuten die Daten mit zu speichern für eine Analyse zum Beispiel für einen potenziellen Angriff oder irgendwie Fehler im Netzwerk.

Dirk Leinenbach: Also quasi Daten nehmen und eins zu eins irgendwohin speichern und da mal durchgucken.

Matthias Höschele: Genau! Eins zu eins hin speichern. Wenn man sich überlegt, wie viel Speicher brauchen wir dafür, für eine 1-Mbit-Leitung in 10 Minuten, dann sind das überschaubare 75 Megabyte. Das hat jeder heutzutage irgendwie am Schlüsselbund wahrscheinlich am USB-Stick hängen, der ein Vielfaches hat. Das ist absolut unspektakulär. Wenn man aber sich überlegt, das Problem skaliert man hoch für eine große Lösung, eine Firma mit einem großen Netz, die das machen und vielleicht nicht nur für 10 Minuten, sondern 2 Wochen. Und die haben nicht nur einen Standort, die haben 10 Standorte, und nicht für 1-Megabit-Leitungen, sondern für 1-Gigabit-Leitungen.

Dirk Leinenbach: Aber klingt jetzt erst mal nicht so spannend, da ein Faktor 10 für die 10 Leitungen, gut, Faktor 1000 vielleicht, aber ja, ist das dann so tragisch?

Matthias Höschele: Das ist tragisch, wenn man die Faktoren mal aufmultipliziert, kommt man halt dann plötzlich bei diesen größerem Problem auf gut 15 Petabyte. Das ist ein Faktor von doch beträchtlichen gut 200 Millionen.

Dirk Leinenbach: Gut, jetzt könnte ich natürlich sagen, 15 Petabyte, so rein vom Speicherplatz, dann stelle ich mir halt ein sauberes Rack hin, gebe ein bisschen Geld an Dell oder HP, und dann kann ich das auch speichern. Aber da ist noch nicht die Grenze gesetzt, du hast jetzt relativ beliebige Faktoren da genannt. Da könnte genauso gut einer davon hundertmal größer sein, dann habe ich halt ein paar Standorte mehr oder statt 1 Gigabit 10 Gigabit, oder statt 2 Wochen ein bisschen länger, und schon bin ich halt ein paar 10er-Potenzen höher. Spätestens dann wird es irgendwann sehr, sehr spannend.

Matthias Höschele: Genau! In diesem sehr vereinfachten Beispiel lassen wir noch außer Acht, dass man nicht einfach irgendwie mehr Hardware auf ein Problem werfen kann und das funktioniert dann einfach, sondern oft benötigt man dann ein bisschen andere Architektur, braucht noch viele Engineering-Aufwand, damit es überhaupt irgendwie auf so viele Maschinenkerne, was auch immer, verteilt werden kann.

Dirk Leinenbach: Ja, das erinnert mich so ein bisschen an dieses Beispiel mit Festplatten. Du hast heutzutage Festplatten, die sind gefühlt riesig groß, aber es dauert allein, wenn du die am Stück beschreibst oder liest, Tage, um die einmal auszulesen. Das ist so etwas, das bringt mich immer wieder auf den Punkt, dass es heutzutage gar nicht mehr hilft, die Festplatten einfach größer zu machen, weil du da überhaupt nicht in realistischer Zeit mit arbeiten kannst mit diesen Daten. Ich glaube, das ist hier auch so ein bisschen der Knackpunkt. Es nützt nichts, die Sachen irgendwohin zu schreiben und dann nie wieder anzugucken, sondern du musst auch wieder was finden können. Das sind Aspekte, die dann spannend werden. Aber lass uns das nochmal ein bisschen auf die andere Ebene bringen, auf die Nicht-IT-Seite, damit wir da ein bisschen plakativer heute reden können. Wir hatten eben das Beispiel mit Autoherstellung. Ich glaube, das ist auch eine ganz gute Domäne, um da so ein paar Konzepte irgendwo klarzumachen. Weil, was glaube ich schon klar ist, man kann das Problem nicht völlig trivial lösen oder es gibt nicht so den einen Ansatz Lösungen zu skalieren, also kleine Lösungen auf große Probleme anzuwenden, sondern man muss da auch in vielen Schritten vorgehen. Du hattest eben diese vielen Faktoren, die reinkommen bei den Problemen, hier mal ein Faktor 10, da noch ein Faktor 10, da ein Faktor 1000 und all das. Und bei der Lösung gibt’s glaube ich auch viele kleine Verbesserungen, die man macht. Hier ein Faktor 2, da ein bisschen mehr, hier doppelt so viel Hardware. Im Endeffekt muss das Ziel sein, dass all diese Faktoren das dann genauso beschleunigen, wie es halt am Anfang schwieriger geworden ist. Ich glaube, das ist auch so aus meiner Sicht der Knackpunkt an Skalierung, nicht irgendwie ein bisschen schneller werden, sondern Möglichkeiten zu haben, dass man im Prinzip beliebig viel schneller werden kann.

Matthias Höschele: Genau! Man hat sehr viele Werkzeuge zur Hand, die auch oft ihre eigenen Vor- und Nachteile mit sich bringen und natürlich auch im realen Sinne kosten. Das muss alles auf jeden Fall gegeneinander abgewogen werden. Aber vielleicht gehen wir mal bei diesen beschleunigenden Faktoren ins ein bisschen Konkretere und versuchen da an Lösungsansätze ranzugehen.

Dirk Leinenbach: Sagen wir mal, wir wollen jetzt unsere Autoherstellung, wir sind hier, der neueste coole Elektroflitzer gebaut und den wollen wir jetzt in Millionenstückzahlen produzieren. Was können wir da machen, um das zu erreichen?

Matthias Höschele: Vielleicht nicht nur in Millionenstückzahl, sondern vielleicht generell die Produktion auch zu beschleunigen für ein einzelnes Auto, zum Beispiel. Also beide Sachen auf einmal. Wir sind ambitioniert, wir wollen das jetzt einfach mal.

Dirk Leinenbach: Und auch noch günstig und bezahlbar und mit weniger Umweltschäden.

Matthias Höschele: Genau, genau, genau! Der ganze Wunschtraum, der uns unsere grüne Energieutopie sehr schnell liefern kann. Der erste Ansatz wäre: Wir müssen irgendwie die Produktion von dem einzelnen Auto schnellermachen. Wenn wir die schnellermachen, dann geht alles viel schneller. Das heißt, wir könnten zum Beispiel die Arbeiter in der Fertigung besser ausbilden, trainieren, dass die schneller sind. Wir können ihnen bessere Werkzeuge geben, dass ihnen die einzelnen Arbeitsschritte schneller von der Hand gehen. Also Optimierung einfach von den einzelnen Arbeitsschritten, um das so zu beschleunigen.

Dirk Leinenbach: Das heißt, wir haben quasi den ersten Prototypen noch von Hand aus Holz geschnitzt und das Metall gehämmert et cetera und jetzt kaufen wir uns coole Maschinen, die das alles out of the box machen. Wir üben das tausendmal und jeder von uns wird Faktor 5 schneller, oder …

Matthias Höschele: Genau!

Dirk Leinenbach: So in der Richtung werden wir das Auto bauen und dann sind wir nachher sehr viel besser. Haben aber doch das Problem, dass es da irgendwo Grenzen gibt. Egal, wie gut ich trainiere und wie schnell ich arbeite als Einzelperson, werde ich nie mehr als ein, zwei Autos am Tag produzieren können, selbst wenn ich da Super-Super-Zeugs habe.

Matthias Höschele: Genau! Da gibt’s einfach so eine natürliche Grenze, ab der vielleicht ein einzelner Arbeitsschritt oder ein einzelner Ablauf nicht mehr weiter zu optimieren ist. Das zeigt, dass unser eigentliches Ziel, was wir vorher hatten, wir wollen mehr oder weniger eine beliebige Größe skalieren können, unser Problem. Eine Sache, die nur bis zu einem gewissen festen Faktor eine Sache schnellermachen kann, kann dann inhärent natürlich nicht die Lösung sein, mit der wir sowas erreichen können.

Dirk Leinenbach: Es hilft natürlich, aber es löst das Problem nicht komplett. Also ein schönes, ich glaube, ein Aspekt in der Informatik, würde ich sagen, ich habe gewisse sequenzielle Anteile, die ich nicht mehr beschleunigen kann. Jetzt im Autobeispiel könnte das zum Beispiel sein, wenn ich so eine Windschutzscheibe ins Auto reinklebe, der Kleber muss dann einfach eine gewisse Zeit lang abbinden, bis der fest ist. In der Zeit kann ich vielleicht sonst mit dem Auto nicht viel machen. Oder wenn der Lack trocknet, da habe ich einfach eine gewisse Totzeit, da muss ich warten und schneller kann ich das Auto da nicht bauen, das eine Auto. Was kann man denn dann noch machen, Matthias?

Matthias Höschele: Natürlich, wenn man wieder in unserem Beispiel bei der Autoherstellung ist, wir würden natürlich nicht in unserer tollen neuen Firma nur an einem Auto arbeiten und dann, wenn wir damit fertig sind, mit dem nächsten anfangen, sondern wir haben natürlich die Möglichkeit das Ganze zu parallelisieren, also wie wir es natürlich in der Fertigung hatten. Parallele Produktionsstraßen beziehungsweise dass man einzelne Teile wie zum Beispiel die Fertigung und Montage von Türen, läuft unabhängig von Sachen, die man zum Beispiel in der Karosse macht. Und diese Sachen können gleichzeitig passieren und dadurch sind nicht die Arbeitsschritte, die man braucht, um das Auto zu bauen, Stück für Stück alle hintereinander, sondern können gleichzeitig ablaufen und dadurch wird eben die Fertigung von einem also schneller.

Dirk Leinenbach: Also quasi Parallelisierung heißt dann, ich habe jetzt nicht eine Montagelinie für Autos, sondern ich habe fünf davon nebeneinander und kann dann quasi fünf Autos gleichzeitig bauen und bin damit fünfmal so schnell. Und wenn ich zehnmal so schnell werden will, dann brauche ich halt zehn Montagelinien und kann dadurch quasi skalieren. Ich investiere irgendwie mehr Geld und mehr Leute und werde dann schneller. Hat natürlich gewisse Grenzen, irgendwann ist mein Firmengelände voll von lauter Montagelinien und ich komme an der Stelle nicht mehr weiter. Was mir da auch noch einfällt, im Moment haben wir noch die Idee in einer Fertigungslinie, ich schiebe das Auto, fange vorne an und hinten kommt das Auto raus und dann fange ich vorne mit dem nächsten Auto an. Jetzt kann ich die Parallelisierung quasi, in der Informatik würde ich sagen, ich mache eine Pipeline, ich fahre nicht in einer Linie ein Auto, sondern wenn das erste fünf Meter vorgefahren ist und an der nächsten Station ist, fange ich schon mal mit dem zweiten an und mache da die ersten Schritte, brauche ich natürlich mehrere Leute, und kann quasi dann noch in einer Linie parallelisieren.

Matthias Höschele: Genau! Das ist auf jeden Fall eine Sache, die schon sehr lange in der Produktion da ist, natürlich Pipelining ist auch bei uns …

Dirk Leinenbach: War schon beim Ford mit seinem Montageband. Das war genau die Idee. Du machst …

Matthias Höschele: Genau! Das war damals ungefähr so die große Innovation, die dann erlaubt hat, dass das Model T so verhältnismäßig günstig war und erschwinglich war. Und wir hatten schon kurz angerissen, dass die Sache natürlich irgendwie ihre Grenzen hat. Denn die Parallelisierung, du hast gesagt, wir haben die Grenze, die Größe des Firmengeländes und wie viele Leute wir eingestellt bekommen, aber du hast schon vorher von sequenziellen Anteilen gesprochen, von einem Problem. Das ist ein guter Punkt hier bei der Parallelisierung, weil nicht jedes Problem können wir beliebig so aufteilen, dass wir einfach sagen können, ich teile das irgendwie in 10, 20, 50 Schritte irgendwie auf, ich mache die alle parallel und bin dann um eben diesen Faktor schneller. Das funktioniert halt nicht immer und das ist die große Herausforderung und auch die Grenze bei der Parallelisierung. Das hatten wir schon vorher ein bisschen kurz angesprochen, wenn man einzelne Arbeitsschritte hat zum Beispiel in der Fertigung vom Auto, die erledigt werden müssen, bevor man irgendwie einen Folgeschritt machen kann, das sind die klaren Grenzen, wo dann auch eine Parallelisierung von diesen Sachen nicht mehr möglich wird.

Dirk Leinenbach: Also du meinst sowas wie, ich kann die Türen erst einsetzen, wenn der Rest der Karosse drumherum da ist, oder dass man da so Abhängigkeiten hat?

Matthias Höschele: Genau! Oder ich kann natürlich nicht die Testfahrt zum Abschluss in der Qualitätskontrolle machen, bevor der Motor eingebaut ist. Das sind so triviale Erkenntnisse aus dem Praktischen, die aber, wenn man sie abstrakt sieht, das gehört alles dazu, dass das Auto nachher fertig irgendwo verkauft werden kann. Und das sind alles Schritte, die potenziell voneinander abhängen. Und gerade bei uns im Software Engineering ist es die Herausforderung, irgendwie ein Problem dann so zu zerteilen, so clever zu zerteilen, dass möglichst man auch irgendwelche Abhängigkeiten reduziert in irgendwie einer Berechnung oder sowas, damit man möglichst viel Profit schlagen kann.

Dirk Leinenbach: Ich glaube, der Knackpunkt ist, jeder einzelne Arbeitsschritt muss möglichst unabhängig von den anderen sein. Dass da jeder sein Ding machen kann und macht dann sein Ding am nächsten Auto, ohne dass man gegenseitig auf irgendwas warten muss. Vielleicht, wenn ich das mit dem Auto eins weiter treibe und sage, gut, jetzt haben wir hier unsere Autoschienen und die Baulinien und das ist alles schon gut und wir wollen es noch schnellermachen, wir lassen einfach die Türen in einer ganz anderen Firma herstellen, da haben wir wieder mehr Leute und mehr Platz und können dort parallelisieren und die können das auch vielleicht noch viel mehr optimieren als wir, aber dann haben wir halt ruckzuck das Problem, dass wir uns quasi mit denen abstimmen müssen, dass wir denen erstmal sagen müssen, hey, ich brauche jetzt zehn blaue Türen und dann brauche ich zehn grüne und dann fünf mit Fensterheber und vier davon, und die müssen genau in der richtigen Reihenfolge bei mir ankommen. Und wenn dann mal eine fehlt, dann hakt es bei mir, dann kann ich nicht arbeiten, weil die Türen gerade fehlen oder zu viele sind oder die falschen. Da kommt dann dieser Kommunikations-Overhead so ein bisschen rein, dass man sich gegenseitig synchronisieren muss.

Matthias Höschele: Genau! Das ist eigentlich so gut wie kein Problem, mit dem wir es zu tun haben. Es ist so, dass es sich irgendwie ohne irgendwelche Reste in parallele Einzelteile zerlegen lässt, bei dem man nicht ein bisschen Kommunikation braucht. Und mit diesen Sachen muss man einfach, das ist ein Trade-Off, den man natürlich dann in der Lösung drin hat. Und da gibt’s natürlich auch natürliche Grenzen, wo man dann irgendwann sagt, die zehn Prozessorkerne mehr helfen nicht, wenn nicht das Design aus Software-Engineering-Sicht so ist, dass die Aufteilung in kleinere Einzelprobleme so clever ist, dass es auch möglich ist.

Dirk Leinenbach: Lass mich mal versuchen, das wieder auf das Autobeispiel rüberzubringen. Ich könnte ja sagen, gut, um zu skalieren, zerteile ich mein Auto einfach in 1000 Komponenten. Ich sage, ich habe hier den Schaltknauf, hier habe ich den Fahrersitz, hier habe ich dies, Fensterheber das, Radiokomponente, irgendwie 1000 Boxen, alle 1000 kann ich bauen und dann habe ich mein Auto. Jetzt ist das Problem, ich muss die 1000 Boxen, die ich da hergestellt habe, die 1000 Subkomponenten, muss ich nochmal zusammenschrauben, damit ein Auto draus wird. Das heißt, durch die Produktion von den 1000 Dingen parallel kann ich dabei erstmal einen Faktor 1000 gewinnen, wenn wir mal optimistisch sind. Aber am Schluss muss ich das Ganze noch mal zusammenschrauben. Und wenn das Zusammenschrauben jetzt von der Zeit, die ich für ein Auto, wenn ich das einfach allein am Stück baue, sagen wir mal, das Zusammenschrauben wäre 1 % davon, sehr wenig, ja, Zusammenschrauben geht nachher schnell, 99 % der Zeit ist der andere Teil, dann führt das aber dazu, dass ich selbst hier mit einem Faktor 1000 nachher „nur“, in Anführungszeichen, einen Faktor 100 schneller werde, weil ich immer noch 1 % der Zeit mit Zusammenschrauben verbringe. Dann nützt es mir nichts, wenn ich in dem anderen Teil sehr viel schneller werde oder noch schneller als Faktor 100-mal schneller, weil das Zusammenschrauben dann nachher der beschränkende Faktor ist. Ich kann es nicht schneller zusammenschrauben und damit ist es dann auch egal, ob ich die Komponenten noch mal einen Faktor zwei, drei, vier schneller mache, das bringt mir nichts, das bringt nur mehr Wartezeit. Oder die Komponentenhersteller langweilen sich dann halt irgendwann. Ich glaube, das ist genau das Problem, das wir auch in der Informatik haben. Wenn ich so eine Sache parallelisieren will, ist ja ganz ein Hype, und dann mache ich noch ein paar Cluster mehr dazu und viele Prozessoren und alles parallel …

Matthias Höschele: Alles in die Cloud.

Dirk Leinenbach: Genau!

Matthias Höschele: Dann geht das irgendwie.

Dirk Leinenbach: Und mein Laptop hat mittlerweile sechs Kerne mit Hyper-Threading und alles. Aber irgendwann skaliert es halt nicht mehr, weil am Schluss der sequenzielle Anteil, eben dieses Zusammenschrauben, wo alles zusammenfließt, da wird es dann noch mal langsam. Und da gibt’s auch dieses berühmte Gesetz, das amdahlsche Gesetz, wo das eben einfach mal vorgerechnet wird. Ähnlich wie wir das gerade gemacht haben, mit dem Faktor 1000, wo man dann einfach mal überrascht feststellt, wie schwer so ein kleiner, gefühlt sehr kleiner sequenzieller Anteil in der Arbeit, wie der nachher das Ganze einfach dominiert, weil du dann nicht mehr drum herum kommst.

Matthias Höschele: Und dazu kommt natürlich noch, du hast schon den Vergleich eben zur Kommunikation gebracht, mit dieser Synchronisierung von parallelen Arbeitsschritten, wenn man jetzt wie bei uns nicht nur einzelne Prozessorkerne hat, die parallele Dinge machen, die kommunizieren müssen, sondern wir haben mehrere Standorte, wie wir es vorhin schon gesagt haben, dann kommt auch natürlich noch die Kommunikationsdauer mit dazu. Wenn man jetzt das irgendwie aus der ein bisschen praktischeren Welt nimmt, irgendein globaler Konzern, wo sich irgendwie Gruppen, die über den Globus verteilt sind, Arbeitsgruppen abstimmen müssen, E-Mails schreiben müssen, kommunizieren müssen, allein durch die unterschiedlichen Zeitzonen und so weiter, dauert das viel länger. Und ähnlich haben wir das natürlich auch bei uns im Software Engineering, dass dann solche Kommunikation plötzlich auch ein Faktor werden kann.

Dirk Leinenbach: Einfach, weil die Round Trip Times, wie man so schön sagt, halt zu lange dauern. Im Auto, wenn ich die Türenherstellung in einem anderen Werk habe, eine Änderung der Bestellung dauert halt einfach eine gewisse Zeit, weil selbst, wenn ich den Kollegen anrufe und er dann die Türen direkt herstellt, müssen die erstmal in mein Werk geliefert werden. Das heißt, da habe ich mindestens mal ein paar Stunden Verzug und bin dann einfach nicht mehr so flexibel, muss mich eben besser abstimmen untereinander, dass da möglichst früh feststeht, wer braucht was. Ich muss die Prozesse optimieren, dass ich das dann eben skalieren kann. Es ist nicht damit getan, genauso weiterzumachen wie in der guten alten Zeit, wo alle an einem Ort waren und sich über den Flur zugerufen haben „Hey! Ich brauche jetzt eine grüne Tür“ und dann bringe ich die halt rüber, sondern jetzt muss ich mir mit Vorlauf überlegen, was brauche ich da. Und vielleicht muss ich auch mein Auto oder das, was ich dem Kunden anbiete, einfach ein bisschen anders gestalten, damit die Prozesse nachher in der Herstellung optimiert werden. Dass ich zum Beispiel sage „Wir haben nur grüne Türen“. Egal, welche Farbe das Auto sonst hat, die Tür ist immer grün. Macht vieles einfacher und ich kann auf einmal sehr viel effizienter die Autos herstellen. Wie bei Ford ja auch. Alle Autos, solange sie schwarz sind, sind alle Farben lieferbar.

Matthias Höschele: Natürlich! Und wie du schon vorher gesagt hattest, mit der Aufteilung, die einzelnen Komponenten, wenn irgendwie eine Komponente von dem Auto jetzt oder von der Autoserie standardisiert ist und es gibt nur die einen Spiegel in dieser einen Farbe, dann fällt auch der Aufwand weg, dafür zu sorgen, dass bei jedem Auto der richtige Spiegel landet, weil es ist immer derselbe Spiegel. Und somit können kleine Designentscheidungen oder Einschränkungen, die natürlich irgendwie nicht eine allzu große Folge oder allzu große Einschränkung für den Benutzer oder einen Kunden haben dürfen, aber so kleine Einschränkungen können dann eben sehr viel einsparen und Möglichkeiten bieten Sachen zu optimieren.

Dirk Leinenbach: Geht sogar so weit, dass man stellenweise auch mehr Geld ausgibt als Autohersteller und schon mal Hardware einbaut, die vielleicht niemand braucht. Dass zum Beispiel die Kamera für den Geschwindigkeitsregelautomat schon eingebaut ist, egal ob ich das Feature gekauft habe oder nicht. Einfach weil es billiger ist, in jedes Auto diese Kamera reinzustecken als genau zu gucken, wo muss ich sie denn reinstecken und wo nicht.

Matthias Höschele: Genau! Wenn das irgendwie nur in einem von 1000 Autos in der Fertigung gebraucht wird und das nur einer von 1000 Kunden bestellt, dann lohnt sich das wahrscheinlich noch nicht. Aber irgendwann ab einem gewissen höheren Anteil lohnt es sich dann halt einfach, weil man nur dieselben Arbeitsschritte hat und die Fertigung einfacher wird.

Dirk Leinenbach: Genau! Aber ich glaube, um noch mal die Brücke zu schlagen in die Softwareentwicklung, man muss oft sehr weit zurücktreten, wenn man sich das Problem anschaut, um dann auch das Problem so anzugehen, dass man vielleicht sagen kann, jetzt kann ich das parallelisieren, jetzt habe ich dieses eine Bottleneck weg, dass wenn ich es genauso mache, wie ich es immer gemacht habe, ist das vielleicht unlösbar. Wenn ich mich aber ein bisschen davon löse und vielleicht sogar ein eigentlich größeres Problem angehe, dann kann ich vielleicht auf einmal die Sache besser parallelisieren, besser optimieren, einfach, weil jetzt diese eine Beschränkung nicht mehr da ist, weil ich quasi das gelöst habe, diese Abhängigkeit, die es irgendwo gab. Und ich kann dann einfach parallel unabhängig voneinander die Sache angehen.

Matthias Höschele: Ja. So die Analogien dann, die wir natürlich haben von der Fertigung, mit der wir jetzt viele Beispiele gebracht haben wie, Montage getrennt von einzelnen Komponenten, dann eben parallele Linien für die Fertigung, dann noch mehrere Standorte und so weiter, dieselben Analogien, um zurückzukommen auf unsere Welt der Softwareentwicklung oder IT, haben wir natürlich bei uns mit mehreren Prozessorkernen, mit mehreren Servern im Rechenzentrum, und dann auch wieder mehrere Rechenzentren, ähnliche Skalierungsfaktoren wie man in der Produktion mit diesen Möglichkeiten hat, gibt’s dann natürlich bei uns.

Dirk Leinenbach: Neben Parallelisierung, was wir gerade besprochen hatten, und dieser sequenziellen Verbesserung, dass ich einfache Einzelschritte schnellermache, gibt’s, glaube ich, noch mindestens mal zwei Themen, die wir noch nicht angesprochen hatten, wo man was von der Informatik lernen kann, was wir da machen, was vielleicht auch im realen Leben, wenn ich das mal so sagen darf, uns was weiterbringt. Und das eine ist quasi, dass man versucht, Dinge zu abstrahieren, in dem Sinn, ich mache ein Problem eigentlich auf den ersten Blick vielleicht schwieriger oder ich löse ein größeres Problem, mache das aber so, dass es besser geht. Hast du da vielleicht ein Beispiel?

Matthias Höschele: So ein Beispiel, das irgendwie so ein bisschen in die Richtung geht, eine Abstraktion, können wir vielleicht irgendwie wieder im Bereich von Informationen bleiben wir, also sind noch relativ nah bei uns an der Informatik, aber gehen wir mal ein bisschen in die Politik. Zum Beispiel hat man einen Entscheidungsträger, der basierend auf irgendwelchen erfassten Daten irgendwie nicht nur saarlandweit, deutschlandweit oder weltweit irgendwelche Informationen, irgendwelche Entscheidungen treffen muss.

Dirk Leinenbach: Sowas wie Bundeskanzlerin oder US-Präsident?

Matthias Höschele: Genau, genau! Also wirklich so große Entscheidungsträger. Und wenn die zum Beispiel irgendwelche neuen Gesetze für Verkehr, Klima, wo es wirklich um irgendwelche erfassten Daten, irgendwelche wissenschaftlichen Informationen und Statistiken geht, die können nicht irgendwie Tausende, Millionen an Messpunkten, zum Beispiel im Klimabereich irgendwelche Temperaturmesspunkte oder sowas, das ist nicht die Datenbasis, auf der die entscheiden, sondern was die Leute bekommen, sind aller Regel, ist was Aggregiertes, eine abgeleitete Information, eine Studie, bei denen Experten Sachen ausgewertet, zusammengefasst haben.

Dirk Leinenbach: Das klassische Executive Summary, halbe Seite, und da steht dann drin, was der Stand der 5 Milliarden Forscher weltweit ist, die das Thema bearbeiten.

Matthias Höschele: Ganz genau! Weil in diesem Fall bekommt dann der Entscheidungsträger, der Punkt, wo die Information wichtig ist und wo sie irgendwie die Grundlage ist für einen weiteren Schritt, für eine weitere Aktion, dann eben diese halbe Seite oder diese Seite, wie du gerade gesagt hast, und nicht irgendwie tausende Lkw-Ladungen an Rohdaten, unausgewertet, durch die dann der Politiker durchlesen müsste. Das wäre nicht machbar.

Dirk Leinenbach: Jetzt mal auf unser Beispiel eben mit den Megabit-Leitungen und 15 Petabyte und wie viel auch mehr, wäre das dann quasi die Idee, na gut, als Nutzer interessieren mich vielleicht die ganzen Details, die da drinstecken, nur sehr selektiv. Ich will vielleicht mal den einen Angriff dann gucken, das sind dann vielleicht ein paarhundert Byte oder ein paarhundert Kilobyte, die will ich vielleicht irgendwann sehen, aber in der Regel interessieren mich die ganzen Details gar nicht. Ich will vielleicht wissen, wie viel Traffic hatte ich denn über die Zeit oder von welchen IPs war wieviel Traffic. Das heißt, ich kann mir eine ganze Menge abstrakte Informationen ableiten aus den Details, und das ist nachher das, was mich in der Regel interessiert. Ich male mir ein paar bunte Graphen hin, wo ich irgendwie einen Zeitverlauf von was sehe, vielleicht auch noch eine lustige Weltkarte, wo steht, die Chinesen haben grad 5 Megabit Traffic mit mir und vielleicht ist das gut, vielleicht ist das schlecht, wo ich das visualisiert habe. Aber das ist halt dramatisch viel weniger Information als in den Rohdaten steckt. Und die Rohdaten brauche ich wirklich nur, wenn ich Details wissen will. Da haben gefühlt wir zumindest auch oft den Effekt, dass wir sehr viele Details, die wir mit unserer Lösung mal erfassen, ich würde sagen 99,999 irgendwas Prozent davon werden nie wieder gelesen, die werden einmal gespeichert für den Fall der Fälle und werden in aller Regel ungelesen irgendwann weggeworfen. Damit du aber das andere 0,01 % finden kannst, da brauchst du irgendwie so abstrakte Infos, die dich an die richtige Stelle leiten.

Matthias Höschele: Genau! Das Wichtige ist dann oft irgendwie, und das ist die Entscheidung, die man natürlich irgendwie sowohl jetzt als Software Engineer, als auch jemand, der vielleicht so Abstraktionen in einem anderen Kontext irgendwo einsetzen will, man muss entscheiden, an welchem Punkt, Zeitpunkt man ansetzt, wann werfen wir welche Daten weg oder wann abstrahieren wir auf einen anderen Wert.

Dirk Leinenbach: Und welcher Wert ist das? Was will der Benutzer später überhaupt wissen oder was ist für den Politiker interessant, der die Entscheidung trifft, was sind für den die wichtigen Daten? Dann muss ich das eben vorbereiten.

Matthias Höschele: Genau! Das kann dann schon anfangen mit der Planung und dem Design von irgendwie der Datenerfassung und der Studie am Anfang. Die muss darauf ausgerichtet sein, was für irgendwie Nennwerte zum Schluss für die Entscheidung relevant sind. Das zieht sich dann durch die komplette Kette mit durch. Also quasi so die Idee, ich muss erst mal wissen, was wird nachher mit der Lösung überhaupt gemacht, was sind die täglichen Probleme, bevor ich sie optimieren kann. Also ich kann nicht generell für alle Anwendungsfälle optimieren, sondern ich mache das oft sehr, sehr zielgerichtet auf den einzelnen Fall. Da kommt mir wieder das gute alte Beispiel mit dem Telefonbuch. Wenn ich ein Telefonbuch habe, wer das noch kennt von den Jugendlichen heutzutage, dickes Buch mit allen Namen in einer Stadt drin, wo die Telefonnummer dabeisteht. Wenn ich da jetzt, der Use Case ist halt, ich will von Tante Meier gern die Telefonnummer wissen, damit ich sie anrufen kann. Okay, klar, einfache Lösung: Ich mache das alphabetisch und ich weiß, „M“ kommt irgendwo und dann kann ich die Tante Meier finden. Wenn das jetzt nicht so offensichtlich wäre, dass ich die mit dem Namen finde, oder ich weiß vielleicht nicht, wie ihr Nachname ist, dann habe ich ein Problem. Weil das Telefonbuch ist nicht danach ausgelegt, die Tante Meier nach was anderem als ihrem Nachnamen zu finden. Wenn ich vielleicht deutschlandweit unterwegs bin und nicht mal weiß, in welcher Stadt sie wohnt, habe ich nochmal ein Problem, selbst wenn ich den Nachnamen kenne. Dann ist einfach die Abstraktion, dieses alphabetische Sortieren nützt mir da nichts und ich müsste im Prinzip sämtliche Telefonbücher durchblättern, um meine Tante zu finden.

Matthias Höschele: Genau! Ein anderes Gebiet, was wir noch nicht angesprochen haben, das da sehr nah dran ist, ist die Frage: Wann man gewisse Sachen berechnet? Da hat man immer einen sehr großen Entscheidungs- oder Design-Spielraum, nämlich: Berechne ich einen Wert oder eine Information erst, wenn mich jemand danach fragt oder berechne ich es gegebenenfalls einfach für jeden, für jede Eingabe, die ich bekomme, schon im Voraus?

Dirk Leinenbach: Aber da würde ich doch jetzt sagen: Na gut, warte ich halt, bis mich jemand fragt und dann gebe ich ihm die Antwort. Dann mache ich nichts unnötig.

Matthias Höschele: Ja, aber da ist das Telefonbuch ein wunderbares Beispiel. Wenn man nicht einmal, und für alle Eingaben in diesem Fall, unsere Anschlüsse beziehungsweise die Leute mit ihrer Telefonnummer, das Telefonbuch diese Sortierung vorberechnet, dann wird es plötzlich ganz schwer, schnell zu antworten, was ist die Telefonnummer von der Tante Meier oder wie du sie genannt hast. Weil ohne das Telefonbuch die zu finden, irgendwie einfach einer großen Liste, wo einfach die Leute unsortiert drinstehen, wird es plötzlich ganz schwer.

Dirk Leinenbach: So im Großen und Ganzen läuft‘s wahrscheinlich darauf hinaus, wie oft oder zu welchem Anteil will ich diese Frage stellen. Wenn ich das sehr, sehr, sehr, sehr selten mache, dann lohnt es sich vielleicht, das einfach ad hoc zu berechnen. Im Notfall gehe ich halt die ganze Namensliste nochmal durch, bis ich sie gefunden habe. Wenn aber die Frage halbwegs häufig ist, dann kann es halt irgendwann ein Vorteil sein, es einfach für alle vor zu berechnen oder schon mal vorzubereiten, und dann im Zweifelsfall muss ich nur noch die Lösung aus der Tasche ziehen, wenn ich sie denn schnell finde. Das ist ja dann noch mal der andere Teil.

Matthias Höschele: Genau! Das ist dieser klassische Trade-Off. Und das sind auch die Sachen, bei der wir in der Softwareentwicklung sehr flexibel sein müssen. Weil je nachdem, wenn irgendwie ein neues Feature dazukommt oder sich andere Anforderungen ändern, verschieben sich teilweise diese Abwägungen von Vor- und Nachteilen und man muss da flexibel sein und auch diese Sachen anpassen können. Aber um wieder vielleicht das Beispiel zurückzubringen auf die ein bisschen praktischere Welt, du hast vorhin schon die Kameras oder Komponenten in Autos genannt, die man einfach in jedes Auto einbaut, vielleicht, obwohl sie ein Kunde nicht bestellt hat. Aber es macht das einfach viel, viel effizienter bei der Fertigung, sie trotzdem einzubauen, obwohl man vielleicht ein paar Euro oder ein paar Cent mit dieser Komponente mehr ausgibt, ohne es zu müssen. Und das ist das Äquivalent zu dem Beispiel mit der Vorausberechnung, wie wir es im Software Engineering haben.

Dirk Leinenbach: Genau! Die Idee, wenn 90 % der Leute die Kamera haben wollen, baue ich sie einfach in 100 % der Autos ein und in den 10 %, die sie nicht haben wollen, habe ich dann halt unnötig die Hardware reingesteckt. Spare mir aber eine Menge Konfigurationsaufwand. Okay! Ja, Matthias, jetzt haben wir so ein paar Dinge besprochen, wo man skalieren kann, wo man seine Prozesse oder das, was man erledigen will, schnellermachen kann oder mehr davon in gleicher Zeit oder für weniger Geld mehr. Wie macht man das denn jetzt in der Praxis? Oder was kann der Nichtinformatiker jetzt von uns lernen? Vielleicht kannst du noch mal versuchen, so grob die paar Punkte einmal aufzuzählen, die wir hatten?

Matthias Höschele: Ja, natürlich! Wir haben den einfachsten ersten Schritt, natürlich die Optimierung von den Einzelschritten, mit dem wir Sachen schnellermachen wollten. Dann die Parallelisierung als irgendwie großes Thema. Wozu natürlich bei uns in der Informatik es nötig ist, sowohl zu designen und so zu entwickeln, dass die Einzelschritte möglichst unabhängig sind. Genauso ist es natürlich auch, wenn man das irgendwie im nichtinformatischen Kontext macht, dass dann die Einzelfertigungskomponenten möglichst unabhängig voneinander sind. Dann ging's in das Thema Abstraktion, dass es darum geht, welche Daten sind relevant, lohnt es sich vielleicht, Daten abzuleiten, zusammenzufassen an einem bestimmten Punkt und dann Arbeit zu investieren zum frühen Zeitpunkt, um dann die Datenmenge zu reduzieren und dann später sich nur die relevanten abgeleiteten Informationen zu behalten. Und die Frage: Wann berechnet man …

Dirk Leinenbach: Dass man Dinge schon mal vorbereitet, die man wahrscheinlich gebrauchen kann. Genau! Jetzt ist, ich glaube in der Praxis dann, und das ist auch das Problem, was man nicht generell lösen kann oder generisch, die Frage: Was mache ich zuerst oder was funktioniert jetzt bei mir? Ich habe jetzt irgendwie eine Situation, da funktioniert alles, und jetzt muss ich auf einmal doppelt so viel machen. Oder ich muss es für den halben Preis machen oder doppelt so schnell. Was ist der erste Schritt, was würdest du sagen?

Matthias Höschele: Das kann man leider allgemein nicht so sagen. Denn die ganzen Lösungsmöglichkeiten oder die ganzen Instrumente und Werkzeuge, die wir jetzt so ein bisschen skizziert haben, die sind sehr spezifisch für ein einzelnes Problem, was man löst. Und bei manchen Problemen ist zum Beispiel vielleicht die Kommunikation, die Synchronisierung von einzelnen Arbeitsschritten eine Sache, die für dieses konkrete Problem eine größere Sache ist, wo man sich mehr Gedanken machen muss als bei einem anderen Problem. Und das heißt, man versucht vielleicht ein anderes Werkzeug dann in diesem konkreten Fall zu nehmen, bei dem man diese Synchronisation weiter reduziert. In meinem anderen Problem ist es vielleicht gar keine große Sache und man kann dann ein anderes Werkzeug einsetzen. Und das ist deshalb leider keine One-Size-Fits-All-Lösung, die man einfach draufwirft, um möglichst noch automatisiert irgendwie plötzlich einfach das Problem von 1 auf 1 Million hochskaliert, sondern da braucht man wirklich Leute, die ein bisschen Erfahrung haben und sich wirklich mit dem Problem in der Domäne auch beschäftigen.

Dirk Leinenbach: So die Idee, wenn ich jetzt, ein Airbus, Flugzeug baue, die bauen 100 Stück im Jahr oder 1000, wenn es hochkommt, da ist eine zusätzliche Kamera einfach auf gut Glück reinstecken kostenmäßig völlig egal. Bei VW, die 1 Million oder 10 oder 100 Millionen Autos im Jahr bauen, da ist 10 Cent eine relevante Größe an Hardware, da lohnt es sich vielleicht, ein paar Ingenieure ein paar Monate drüber nachdenken zu lassen, ob das nicht billiger geht.

Matthias Höschele: Und auch die werden sich das genau überlegen, ab einem gewissen Punkt, wenn es genug Leute in ihrem Auto mitbestellen, überlegen die sich, wir bauen es in alle ein, und wenn die Schwelle irgendwo nicht erreicht wird, dann machen sie es nicht. Und das ist bei den einen, die brauchen sich über die Kamera keine Gedanken machen beim Airbus, weil der sowieso Millionen kostet, und die anderen, für die ist es ein Faktor.

Dirk Leinenbach: Ich meine, das habe ich in meinem täglichen Leben im Endeffekt auch. Ich habe irgendein System beim Kunden stehen, das funktioniert jetzt, ist relativ am Limit, aber es tut seinen Job. Und jetzt sagt der Kunde „Ah! Wir kriegen noch hier einen neuen Standort. Da haben wir auf einmal doppelt so viel Traffic. Guck, dass das damit auch funktioniert.“. Dann kann ich natürlich sagen „Gut! Doppelt so viel Traffic, skaliert nicht perfekt, aber wir werfen einmal einfach dreimal so viel Hardware drauf, dann passt das schon.“. Geht vielleicht, ist nur die Frage: Will der Kunde das auch bezahlen? Das hängt dann natürlich von ab, wie teuer ein Stück Hardware ist, ob das schon ein großer Kunde ist oder ein kleiner. Beim kleinen sage ich vielleicht „Mein Gott! Nehme ich halt den größeren Laptop, der kann das dann, der ist dreimal so schnell.“. Beim großen Kunden, der vielleicht schon für 100.000 Hardware da stehen hat, der will vielleicht nicht unbedingt 300.000 in Hardware investieren. Und dann lohnt es sich halt, ein bisschen mehr drüber nachzudenken und erst mal die Software zu optimieren. Was bei dem Kleinen vielleicht völlig unpraktikabel ist, weil das Software optimieren 10.000 EUR kostet und der hat nur Hardware für 50 EUR da stehen.

Matthias Höschele: Exakt!

Dirk Leinenbach: Matthias, um jetzt noch mal den Bogen zu schließen, zu überlegen, wo können wir der Welt helfen als Informatiker, hast du die 4 Punkte erwähnt: Man kann Dinge beschleunigen in Einzelschritte, man kann Dinge parallelisieren, man kann Sachen abstrahieren oder das Problem abstrahiere und dadurch besser werden, oder man kann überlegen, welche Dinge kann ich vorbereiten, kann ich vorberechnen. Das heißt, die Welt ist jetzt glücklich mit uns und alles ist gelöst? Oder wobei können wir nicht helfen?

Matthias Höschele: Die schwierige Sache an der Skalierung ist, dass sie sehr stark abhängig vom konkreten Problem ist. Und das ist eine Sache, wo man als Informatiker den Einzelfall betrachten muss, um dann zu sehen, welches dieser Werkzeuge am besten ist. Das ist dann eine Kosten-Nutzen-Abwägung auch im betriebswirtschaftlichen Sinne oft und deshalb gibt’s dafür leider keine allgemeine Lösung, die wir jetzt jedem einfach liefern können und wir lösen all seine Probleme.

Dirk Leinenbach: Das heißt, da muss ich dann den teuren Consultant Matthias kaufen und muss sagen „Hey! Sag mir doch mal, welcher Schritt passt bei mir jetzt am besten? Du hast die Erfahrung, und lös mir mal mein konkretes Problem.“?

Matthias Höschele: Genau! Dafür braucht man dann Experten, die man dafür anstellt, um hoffentlich mit viel Erfahrung, die viele ähnliche Probleme schon gelöst haben, einem dann einfach aus ihrer Erfahrung und mit ihrem gesammelten Wissen damit helfen können, wie man am besten anfängt.

Dirk Leinenbach: Okay! Dann sind wir, glaube ich, schon am Ende angelangt für heute. Mir hat es Spaß gemacht. Ich hoffe, unser neues Format kommt auch beim Publikum gut an. Wir hören uns dann in einem Monat, dann mit anderer Besetzung, aber hoffentlich genauso interessanten Themen. Und bis dahin erst mal vielen Dank!

Matthias Höschele: Vielen Dank!

 

So! Das war‘s für heute. Wir hoffen, unser neues Format hat euch gefallen. Wir haben für euch weiterführende Links zur aktuellen Folge in den Shownotes. Und wenn ihr Lust auf mehr habt, dann freuen wir uns natürlich, wenn ihr uns abonniert. Außerdem findet ihr auf unserem YouTube Channel viele weitere Infos und Videos zu unseren Podcast-Themen. Reinklicken lohnt sich. In unserer nächsten Folge am 6. Januar haben wir für euch schon den nächsten Entwickler-Talk am Start. Natürlich wieder mit einem spannenden Thema. Lasst euch überraschen! Wir freuen uns auf euch.

Ihre Cookie-Einstellungen

Technisch notwendige (essenzielle) Cookies

Informationen zu den einzelnen Cookies

  • Mehr anzeigen

    Technisch notwendige (essenzielle) Cookies

    Notwendige Cookies helfen dabei, eine Webseite nutzbar zu machen, indem sie Grundfunktionen wie Seitennavigation und Zugriff auf sichere Bereiche der Webseite ermöglichen. Die Webseite kann ohne diese Cookies nicht richtig funktionieren.

    Name fe_typo_user
    Anbieter consistec.de
    Zweck Sichert die Anti-Spam-Maßnahmen bei Benutzen des Kontaktformulars
    Ablauf Session
    Typ HTTP
    Name conCookieSettings
    Anbieter consistec.de
    Zweck Speichert die Zustimmung zu Cookies
    Ablauf 30 Tage
    Typ HTTP
    Name mtm_consent_removed
    Anbieter consistec.de
    Zweck Wird von Piwik Analytics Platform (matomo) genutzt, um festzustellen, dass dem Tracking widersprochen wurde.
    Ablauf 1 Monat
    Typ HTTP
  • Mehr anzeigen

    Statistiken

    Statistik-Cookies helfen Webseiten-Besitzern zu verstehen, wie Besucher mit Webseiten interagieren, indem Informationen anonym gesammelt und gemeldet werden.

    Name matomo.php
    Anbieter consistec.de
    Zweck Erfasst Statistiken über Besuche des Benutzers auf der Website, wie z. B. die Anzahl der Besuche, durchschnittliche Verweildauer auf der Website und welche Seiten gelesen wurden.
    Ablauf Session
    Typ HTTP
    Name _pk_id#
    Anbieter consistec.de
    Zweck Erfasst Statistiken über Besuche des Benutzers auf der Website, wie z. B. die Anzahl der Besuche, durchschnittliche Verweildauer auf der Website und welche Seiten gelesen wurden.
    Ablauf 1 Jahr
    Typ HTTP
    Name _pk_ses#
    Anbieter consistec.de
    Zweck Wird von Piwik Analytics Platform (matomo) genutzt, um Seitenabrufe des Besuchers während der Sitzung nachzuverfolgen.
    Ablauf 1 Tag
    Typ HTTP
    Name _pk_testcookie..undefined
    Anbieter consistec.de
    Zweck Wird von Piwik Analytics Platform (matomo) genutzt, um zu überprüfen, ob der verwendete Browser Cookies unterstützt.
    Ablauf Session
    Typ HTTP
    Name _pk_testcookie.#
    Anbieter consistec.de
    Zweck Wird von Piwik Analytics Platform (matomo) genutzt, um zu überprüfen, ob der verwendete Browser Cookies unterstützt.
    Ablauf Session
    Typ HTTP