Logo der codecentric AG, einem in Deutschland führenden IT-Consulting Unternehmen

Logo der codecentric AG einem in Deutschland führenden IT-Consulting Unternehmen

Data Effectiveness

Digitale Produkte & Lösungen

Digitale Souveränität

IT-Security

Künstliche Intelligenz

Software-Modernisierung

Leistungen von A bis Z ...

Leistungen

Arbeitsweise

Referenzen

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Events

Fachmedien

Softwerker

Webinare

Wissens-Hub

Jobs

Unsere Kultur

Karriere

Über uns

Aktuelles

Kontakt

Alle Standorte

Du hast Fragen oder möchtest dich mit mir austauschen? Gern – trag einfach deine Kontaktdaten ein.

Contact Us | Sub-Navi-Kontakt oder Zero Search Hits

Kontakt aufnehmen

Marketing & Community Management

Konntest du keine Einträge zu deinem Thema finden?  

STANDORT-TEAM

codecentric München

codecentric Team München

Willkommen im Team München

Jana Pfisterer, People Solutions Business Partnerin Bayern, codecentric AG

People Solutions Partnerin Bayern

Media Technology Expert

Wer in der Wicket-Community unterwegs ist, hat mitbekommen, dass es etwas länger gedauert hat, aber im Mai 2018 war es endlich soweit: <a href="https://wicket.apache.org/start/wicket-8.x.html" target="_blank">Wicket 8</a> wurde released.Klar, Wicket ist nicht mehr der „letzte Schrei“, ist aber schon lange ein stabiles und gut gewartetes Framework – Qualitäten, die in Webentwicklungsframeworks nicht immer selbstverständlich sind, und seit Wicket 6 ist auch die Dokumentation endlich so hilfreich, wie sie sein sollte. Außerdem bleiben wir von großen „Breaking Changes“ wie denen von Wicket 1.5 auf Wicket 6 verschont. Nicht zuletzt wegen dieser Stabilität wird Apache Wicket in Systemen mit höheren Sicherheitsanforderungen und klassischen Web-Frontends, wie zum Beispiel von Banken und Versicherungen, verwendet.Wir werden in einer Reihe kurzer Blogartikel die wichtigsten Wicket-Features noch einmal kurz zeigen und die interessantesten Änderungen in Wicket 8 erklären. Zuerst widmen wir uns der Änderung, die zumindest auf unsere Projektarbeit den größten Einfluss hat: Models und wie die Arbeit mit ihnen durch Lambdas erleichtert wird:<h2>Models allgemein</h2>Erst einmal ein paar Worte zu Wicket im Allgemeinen: Apache Wicket ist ein auf Java aufsetzendes, komponentenbasiertes Webframework, in dem eine Pageklasse der Controller ist. Diese Page enthält einen Komponentenbaum, der aus Wicket-eigenen Komponenten, wie Links, Labels, Panels, Markupcontainer etc. bestehen kann, aber ebenso aus selbstgeschriebenen Komponenten.Das Data-Binding in diesem Komponentenbaum wird mit sogenannten Models gemacht. Ein Model ist erstmal nur ein Interface, das zwei Methoden enthält: <code>getObject()</code> und <code>setObject(T data)</code> zum Lesen und Schreiben der Daten.Im einfachsten Fall ist ein Model also eine herumreichbare, schreibbare Objektreferenz. Durch diese Abstraktion können sich mehrere Komponenten dieselbe Datenquelle teilen, ohne sich untereinander zu kennen – Abhängigkeiten und mögliche Seiteneffekte werden reduziert. Durch Auslagerung dieser Logik in Models muss auch nicht jede Komponente von Hand geupdated werden, sondern die Komponenten selbst holen sich den aktuellen Stand aus ihrem Model.<div>

```java8
HomePage.java:
IModel model = Model.of("Hello World!");
add(new Label("output1", model));
add(new Label("output2", model));
```

</div><div>

```html
HomePage.html:


```

</div>Hinter diesem schmalen Interface kann beliebige Logik abstrahiert werden, so dass die Daten auf jede beliebige Art und Weise beschafft und geschrieben werden können. <h2>ResourceModel</h2>Ein häufiger Anwendungsfall ist, auszugebende Strings nicht direkt im Code zu haben, sondern über Java Resource-Bundles zu laden, typischerweise aus <code>.properties</code>-Dateien. Hier hilft das <code>ResourceModel</code>. Diese Model-Implementierung übernimmt das Laden des Strings. Im Code wird nur das <code>Model</code> aus dem vorherigen Beispiel durch ein <code>ResourceModel</code> ersetzt.<div>

```java5
IModel model = new ResourceModel("greeting");
```

</div> <h2>PropertyModel</h2>Was aber, wenn die Daten nicht über Ressourcen geliefert werden, sondern über Objekte, auf die wir eine Referenz haben? Hierfür gibt es das <code>PropertyModel</code>, das Attribute von Objekten mittels Reflection ausliest.<div>

```java5
Greetable greetable = new Greetable();
IModel model = new PropertyModel<>(greetable, "greeting");
```

</div><div>

```java5
Greetable.java:
private String greeting;
 
public String getGreeting() {
 return greeting;
}
```

</div>Das <code>PropertyModel</code> ist sehr komfortabel zu benutzen, aber nicht alle fühlen sich wohl damit, Reflection einzusetzen und dadurch ein Stück weit die durch Java gewährleistete Typsicherheit zu verlieren. <h2>IModel</h2>Stattdessen kann man ein <code>IModel</code> direkt implementieren. Hierfür müssen drei Methoden geschrieben werden, die weiter oben genannten <code>setObject(T data)</code> und <code>getObject()</code>, und <code>detach()</code>. <code>detach()</code> wird am Requestende aufgerufen, räumt gegebenenfalls auf und gibt Ressourcen frei. Für ein rein lesendes Model würden wir hier also zwei Methoden „leer“ lassen und nur <code>getObject()</code> implementieren.<div>

```java8
 IModel<String> model = new IModel() {
 @Override
 public String getObject() {
 return greetable.getGreeting();
 }
 
 @Override
 public void setObject(String object) {
 // NOP
 }
 
 @Override
 public void detach() {
 // NOP
 }
 };
```

</div>Das ist natürlich für den täglichen Gebrauch etwas unhandlich. Für diesen häufigen Fall gab es bisher das <code>AbstractReadOnlyModel</code>, das <code>setObject</code> und <code>detach</code> bereit stellt. Es muss also nur noch <code>getObject</code> implementiert werden:<div>

```java5
IModel; model = new AbstractReadOnlyModel() {
 @Override
 public String getObject() {
 return greetable.getGreeting();
 }
 };
```

</div> <h2>Read-only Models mit Lambdas</h2>Mit dem auf Java 8 ausgerichteten Wicket 8 können wir diesen Anwendungsfall jetzt noch etwas einfacher umsetzen:In Wicket 8 sind <code>detach()</code> und <code>setObject()</code> Default-Methoden geworden, müssen also nicht mehr implementiert werden. Das heißt, <code>AbstractReadOnlyModel</code>s werden jetzt durch einfach <code>IModel</code>s ersetzt, in denen nur die <code>getObject</code> Methode implementiert wird.<div>

```java5
 IModel<String> model = new IModel() {
 @Override
 public String getObject() {
 return greetable.getGreeting();
 }
 };
```

</div> Da es jetzt aber nur noch eine einzige abstrakte Methode gibt, können wir nach dem SAM (Single Abstract Method) Pattern einfach ein Lambda verwenden:<div>

```java5
IModel<String> model = () -> greetable.getGreeting();
```

</div>Fazit: Typsichere Read-Only Models sind mit Wicket 8 jetzt Einzeiler. Übrigens: Wer in 4 Tagen so richtig viel über Apache Wicket lernen will – uns gibt es auch als Workshop, meldet euch bei Interesse einfach per Mail!

Fancy stuff in Wicket 8: Models mit Lambda

<h2>Security-Stress in npm</h2>Die <a href="/wissens-hub/blog/ein-blick-auf-npm-und-package-json">npm</a> Registry ist DIE öffentliche Registry der JavaScript-Sphäre. Die beiden wichtigsten Paketmanager npm und <a href="https://yarnpkg.com/" target="_blank">yarn</a> setzen beide auf ihr auf. Dementsprechend groß war der Aufschrei, als Mitte Oktober 2021 bekannt wurde, dass im Paket <a href="https://github.com/advisories/GHSA-pjwm-rvh2-c87w" target="_blank">ua-parser,</a> einer Bibliothek mit wöchentlich mehreren Millionen Downloads, unbemerkt eine Schadsoftware eingeschleust wurde.Nur zwei Wochen später wurde ein weiterer Fall bekannt, diesmal in den noch weiter verbreiteten Bibliotheken <a href="https://github.com/advisories/GHSA-73qr-pfmq-6rp8" target="_blank">coa</a> und <a href="https://github.com/advisories/GHSA-g2q5-5433-rhrf" target="_blank">rc</a> . Die Schwachstellen sind inzwischen behoben, die betroffenen Systeme hoffentlich bekannt und der Schaden begrenzt. Doch die Verunsicherung war groß und die Häufung dieser Angriffsart („Supplychain Attack“) zeigt, dass schneller Umgang mit npm-Paketversionen auch in Zukunft wichtig werden kann. In diesem Artikel wollen wir erste Diagnose-Hilfestellung geben. Wir zeigen, wie es möglich ist, herauszufinden, ob Systeme betroffen sind, und geben Tipps, wie dann weiter vorzugehen ist.Die Codebeispiele in diesem Artikel sind in bash-Syntax, können jedoch recht einfach auf andere Kommandozeileninterpreter adaptiert werden. Kommentiert gerne Übertragungen, oder schreibt auch einen Kommentar, wenn Unterstützung benötigt wird.<h2>Was für Angriffe fanden statt?</h2>Die Angriffe auf die npm-Pakete fanden zwar zu unterschiedlichen Zeitpunkten statt, aber verliefen nach ähnlichen Mustern: In den betroffenen Versionen wurden zusätzliche ausführbare Dateien zugefügt und über einen neuen Schritt im build-Skript installiert.Auf den betroffenen Systemen wurde die Schadsoftware installiert. Für ua-parser ist inzwischen bekannt, dass <a href="https://www.bleepingcomputer.com/news/security/popular-npm-library-hijacked-to-install-password-stealers-miners/" target="_blank">Passwortdiebstahlsoftware und Crypto-Miner</a> installiert wurden, ebenso für <a href="https://www.bleepingcomputer.com/news/security/popular-coa-npm-library-hijacked-to-steal-user-passwords/" target="_blank">coa</a> . Über diese Methode kann ein:e Angreifer:in allerdings quasi beliebige Schadsoftware installieren. Dies führt dazu, dass betroffene Systeme als vollständig kompromittiert zu betrachten sind. Das ist das gleiche Gefahrenlevel, als wäre ein Hacker direkt in das System eingebrochen. Es können Passwörter gestohlen worden sein, wichtige Geschäftsdaten, Kundendaten, … Der Angriff ist also sehr ernst zu nehmen.<h2>Erste Hilfe: Bin ich betroffen?</h2>Sowohl für die bekannten Schwachstellen als auch für zukünftige Schwachstellen sollte der erste Schritt sein, zu überprüfen, ob die eigenen Systeme betroffen sind. Dazu gibt es verschiedene Möglichkeiten.<h3>Paket-Dependencies überprüfen</h3>npm verfügt bereits über Möglichkeiten, installierte Pakete, inklusive aller Abhängigkeiten, anzeigen zu lassen. Der Befehl hierfür ist <code>npm ls</code>. Als Optionen für den Befehl können auch einzelne Pakete verwendet werden, also für eine Überprüfung der Installation von rc <code>npm ls rc</code>. Die globale Installation kann mit <code>npm ls -g rc</code> überprüft werden. Analog kann der Befehl auch für andere Pakete wie ua-parser, coa oder andere zukünftig betroffene Pakete verwendet werden.Hier sehen wir eine Ausgabe für ein Projekt, das rc benutzt, allerdings eine der „guten“ Versionen.

```

```

Hier sehen wir eine Ausgabe für ein Projekt, in dem das Paket coa nicht installiert wurde. Die Ausgabe zeigt „empty“, also „leer“.<img loading="lazy" width="1024" height="110" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/sCgkjUoHRjCloQLwjSss" alt="Kommandozeilenausgabe für npm ls coa" />Besteht das Projekt aus vielen Repositories, kann auch einfach via Skript der Befehl in allen Unterordnern ausgeführt werden:

```
for d in */ ; do
 cd $d
 npm ls rc
 npm ls coa
 cd ..
done

```

Das Skript führt für alle Elemente in dem Ordner, die selbst Unterordner sind, die Befehle aus, in den Ordner zu springen, auf rc und goa zu prüfen und dann wieder in den Überordner zu wechseln.<code>yarn list</code> verwendet unter der Haube <code>npm list</code>, deswegen können die Befehle auch für yarn verwendet werden.<h3>Package lock nach den betroffenen Versionen scannen</h3>Eine andere Möglichkeit ist es, die package-lock-Dateien auf dem System nach den betroffenen Versionen zu durchsuchen. Package-lock-Dateien sind automatisch generierte Dateien, die unter anderem den kompletten Abhängigkeitsbaum der Installation zeigen. So sind die Pakete auch zu finden, wenn sie nicht direkt verwendet wurden, aber als Abhängigkeit installiert wurden.Für coa, rc und ua-parser überprüft das folgende Skript die bekannten schadhaften Versionen:

```
# coa
find . -name "package-lock.json" -exec grep --color -EHni "coa-(2.0.3|2.0.4|2.1.1|2.1.3|3.0.1|3.1.3)" {} \; 2>/dev/null
find . -name "yarn.lock" -exec grep --color -EHni "coa-(2.0.3|2.0.4|2.1.1|2.1.3|3.0.1|3.1.3)" {} \; 2>/dev/null

# rc
find . -name "package-lock.json" -exec grep --color -EHni "rc-(1.2.9|1.3.9|2.3.9)" {} \; 2>/dev/null
find . -name "yarn.lock" -exec grep --color -EHni "rc-(1.2.9|1.3.9|2.3.9)" {} \; 2>/dev/null

# ua-parser
find / -name "package-lock.json" -exec grep --color -EHni "ua-parser-js-(0.7.29|0.8.0|1.0.0)" {} \; 2>/dev/null
find / -name "yarn.lock" -exec grep --color -EHni "ua-parser-js-(0.7.29|0.8.0|1.0.0)" {} \; 2>/dev/null

```

Die Liste der Versionen kann sich natürlich ändern, wenn mehr über den Angriff bekannt wird.<h3>npm audit</h3>Länger bekannte Schwachstellen lassen sich auch gut über <code>npm audit</code> bzw. <code>yarn audit</code> aufspüren. Ein großer Vorteil dieser Variante ist, dass sie alle bekannten Schwachstellen abdeckt und nicht nur einzelne Pakete. Außerdem ist die Ausgabe übersichtlicher. Neben Anzahl und Ernsthaftigkeit der Schwachstellen gibt es für jede Angabe über die gepatchten Versionen und Abhängigkeiten eine Referenz auf den Eintrag in der GitHub-Advisory-Datenbank.<img loading="lazy" width="1024" height="406" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/iPPSzogTGK18DFbeY182" alt="Kommandozeilenausgabe für npm audit" /><h2>Nach Artefakten des Schadcodes durchsuchen</h2>Sowohl im ua-parser als auch in coa und rc wurden zusätzliche Dateien und Befehle installiert. Auf Spuren dieser Zufügungen kannst du nun prüfen. Auch diese Variante bezieht sich auf bereits ausgeführte Installationen.Diese Variante erkennt auch, ob die schadhaften Versionen in der Vergangenheit installiert waren. Zumindest wenn der Schadcode nicht gelöscht oder extra deinstalliert wurde, was auch durch einen Angreifer passiert sein könnte. Auch diese Methode gibt also keine absolute Sicherheit.Die in ua-parser zugefügten Dateien heißen „jsextension“, folgender Befehl sucht danach (der Zusatz <code>2>/dev/null</code> verwirft Fehlermeldungen wie, dass der Befehl nicht auf dem root Ordner ausgeführt werden kann – was wir auch nicht wollen oder erwarten):

```
find / -iname "jsextension" 2>/dev/null
ps -ef | grep -i jsextension 2>/dev/null

```

In rc wurde eine Datei namens <a href="https://github.com/dominictarr/rc/issues/131" target="_blank">compile.bat installiert</a> . Auch danach kannst du suchen:

```
find / -iname "compile.bat"
```

Zukünftige Angriffe können natürlich ganz anders aussehen und vielleicht auch nicht über zusätzliche Softwarekomponenten („Payload“) so einfach identifizierbar sein.<h3>Ein paar Hinweise für alle Varianten</h3>Für alle Varianten achte darauf, dass du die aktuelle Version des Projekts überprüfst. Es könnte zum Beispiel sein, dass du lokal auf einer veralteten Version prüfst, während auf dem zentralen Repository der verwendeten Versionskontrolle vielleicht eine Version mit anderen Abhängigkeiten liegt.Auch kann es sein, dass auf anderen Umgebungen bei einer Installation weitere Schritte gemacht werden. Das sollte überprüft werden, um sicherzustellen, dass nicht zum Beispiel die lokalen Versionen in Ordnung sind, aber durch ein automatisches Upgrade auf der Produktionsumgebung diese betroffen ist.<h2>Schadecode in npm-Paketen: Nächste Schritte</h2>Sind die eigenen Systeme nicht betroffen, ist erstmal alles gut. Gib trotzdem deinen Teams Bescheid, und zeige ihnen vielleicht auch, was du gemacht habst, um zu überprüfen, welche Versionen auf dem System sind. Den Vorfall zu nutzen, um mehr über Sicherheit in der Entwicklung zu reden, schadet auch nicht. 😉Sind Systeme, für die du mitverantwortlich bist, betroffen, musst du handeln. Der beste und sicherste Umgang mit dieser Situation ist, sich so schnell wie möglich an die IT-Sicherheitsfachleute deiner Firma zu wenden. Es sind einige Tutorials im Umlauf, die erklären, wie man Paketversionen herabstufen und den Schadcode deinstallieren kann. Doch die Schadsoftware kann dritten Personen vollständige Kontrolle über das betroffene System gewährt haben, so dass eine einfache Deinstallation, oder sogar das Neuaufsetzen des Systems, in diesem Fall nicht ausreichen.<h3>Keine Angst vor Sicherheits-Expert:innen!</h3>Ähnlich wie bei einem gesundheitlichen Erste-Hilfe-Fall hilft es, wenn du klar und präzise die Randdaten kommunizieren kannst: Um welchen Vorfall geht es? Welche Systeme sind betroffen? Was hast du oder haben andere bereits unternommen? Das gilt auch und besonders, wenn du glaubst, einen Fehler gemacht zu haben. Vielleicht hast du versehentlich das install-Skript ausgeführt, obwohl du gesehen hast, dass etwas nicht stimmt. Oder du hast „Spuren vernichtet“, indem du Daten gelöscht hast. Damit bist du sicher nicht alleine und je mehr die Expert:innen wissen, desto besser können sie die Situation einschätzen und in den Griff bekommen.Das weitere Vorgehen werden die Expert:innen dann mit dir besprechen. Sie können verschiedene Maßnahmen vorschlagen, je nach eurem Setup. Für diesen Vorfall beinhalten die Maßnahmen vermutlich eine Neuinstallation der betroffenen Systeme, das Ändern aller Passwörter von einer nicht betroffenen Maschine aus sowie eine Analyse der Situation. Also welche Daten wurden eventuell gestohlen, und welche Systeme kompromittiert? So können sie die Schwere des Vorfalls einschätzen.Ganz wichtig ist, dass du für diesen Prozess offen und ehrlich bist. Wahrscheinlich hast du nichts falsch gemacht, und es ist wichtig, IT-Spezialist:innen mit einzubeziehen, um den Schaden zu begrenzen.<h2>Ein paar ermutigende Worte zum Abschluss</h2>Security Incidents sind unangenehm, besonders wenn man sich zum ersten Mal tiefer damit auseinandersetzt. Hoffentlich konnte dieser Artikel dir ein paar erste Werkzeuge zur Hand geben und auch zeigen, dass zumindest „Erste Hilfe“ kein Hexenwerk ist.An dieser Stelle sei auch nochmal erwähnt, dass es über die „Erste Hilfe“ hinaus wichtig ist, IT-Security-Expert:innen hinzuzuziehen. Dies gilt besonders im Zweifelsfall und wenn man mit einer Kompromittierung rechnet. Expert:innen sind darauf spezialisiert, die Auswirkungen einzuschätzen, die Angriffvektoren zu ermitteln (Digital Forensic and Incident Response) und geeignete Maßnahmen (Threat Hunting) zu ergreifen. So können sie die Situation angemessen handhaben.Darüber hinaus sind Security Incidents auch immer eine Möglichkeit, etwas zu lernen und die Systeme zu verbessern. Vielleicht können wir dir mit diesem Artikel einen guten Einstieg bieten, sich weiter mit dem Thema auseinanderzusetzen? Viel Erfolg auf jeden Fall, du hast den ersten Schritt gemacht!

Schadcode in npm-Paketen – Was tun?

IT Consultant

## Introduction
This article will help you understand the importance of zero-trust architecture and why it is the state of the art to protect your organization from cyberattacks. We see it as fundamental knowledge for solution and system architects to consider zero-trust architecture in distributed systems.

In the past, companies could rely on firewalls and other perimeter-based security tools to prevent attackers from accessing the internal network and thus reducing the attack surface. However, with the rise of cloud computing, remote work, and the Internet of Things (IoT), the network perimeter has become increasingly porous. The misconception that perimeter-based security can be applied to modern distributed systems makes it easier for attackers to gain access to corporate networks and systems.
<figure>
 <img
 src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YsbLTMbTSHm4RddJlLKZ"
 alt="Comparison of perimeter-based network architecture in on-premise and cloud scenario. Source: https://spiffe.io/pdf/Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf.">
 <figcaption>Comparison of perimeter-based network architecture in on-premise and cloud scenario. Source: https://spiffe.io/pdf/Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf</figcaption>
</figure>

Historically, companies fortified their networks using measures like VPNs, firewalls, and ACLs. This is not possible with ubiquitous hyper scalers, managed services, and SaaS offerings. Therefore, trust placed in these traditional tools can now create a false sense of security, potentially leading to major security incidents with significant business impacts. To effectively navigate this changing landscape, it's crucial to explore modern security strategies that align with the evolving nature of technology and remote operations. 

In this article, we will discuss the challenges of perimeter-based security and the benefits of zero-trust architecture. The concept of zero-trust architecture was initially conceptualized in the mid-90s and is now in high demand due to requirements from governments and companies in regulated fields. We will also provide a hacker's perspective on traditional and modern security architectures. If you are not interested in the story, simply skip the indented text. 

>```John <gr4v3d1gg3r> Doe finds an old WordPress installation running at Valuable Inc. from the time when the business was starting out. The installation reveals that the company has experimented with a lot of different things in the early days.``` 

>```John quickly finds a known vulnerability in the old product, which allows him to execute code on the machine. The installation is supposed to be accessible from outside the company's network only, but the PostgreSQL database has been moved to the intranet at some point. The administrator has allowed all connections that exist on the database in the firewall, which means that John can now connect to the PostgreSQL database on the intranet using the WordPress server as a jump host.```

## Perimeter-based security architecture and challenges
The traditional approach to network security is a DMZ architecture. The network is constructed with a well-defined perimeter that should protect an organization’s assets. Hereby, the internal network is protected so that traffic inside the network can be trusted. The borders of the network are fortified with firewalls, access-control lists and other security measures in order to ensure that threats cannot access the internal network. 

>```Fortunately for John, it is a policy that primarily servers outside the perimeter must be patched with the latest security updates. This is where the evil hackers are known to attack. Unfortunately for the company, John is already inside the intranet and the database server has unpatched known vulnerabilities. This means that it is easy for John to exploit the vulnerability and gain control of the database server. John then uses the Metasploit framework to execute code on the host within the intranet. Metasploit is a powerful tool that makes hacking almost as easy as it is portrayed in movies.```

>```John knows his next steps. He scans the intranet for valuable data. There is nothing to stop him now. He uses the ransomware he wrote himself to blackmail his new "client"... He hopes that the bug is fixed that prevented the customer from decrypting the data after payment last time. He almost feels a bit sorry about that.```

Once inside the network, traffic is often generally trusted. Activity is mainly monitored on an ingress basis so that suspicious behavior on edge nodes will alert the administrators. This gives intruders the option of lateral movement inside the network. Gaining access to other services and manipulating, accessing or extracting data are examples of actions undertaken once the network security has been breached.

As initially mentioned, securing and defining the perimeter faces a growing number of challenges due to the evolution of network architectures. The adoption of cloud services and remote work gives less control over the network to the administrators and leaves more surface area for threats. The network perimeter is often maintained by third parties in scenarios that integrate cloud services into customer premises. Additionally, remote work will expose user devices to unknown threats that can make a penetration of the perimeter more likely.
## Understanding zero-trust architecture
Zero-trust architecture eliminates the conventional security perimeter. It takes into account that there is no 100% secure system. The goal is to build a network that has resilience if any of the hosts is compromised. It does so by requiring all network entities to possess short-living verifiable identities. The system design seeks to minimize the potential scope of compromise on any host. To grasp how this ambitious goal can be achieved, a thorough understanding of the three core pillars in the architecture is essential. 

The logical consequences are expressed in the main ideas of the model: “never trust, always verify” and "principle of least privileges". 
Below we define zero-trust architecture in three pillars that aim to minimize actions of penetrators and limit the spread of a security breach. 

>```John feels the itch in his fingers again. The last time had worked well. He had been lucky that the two servers had old vulnerabilities, configuration errors, and access to the intranet with no additional security boundaries. But it was no luck. This is something you are likely to find often in productive systems.```

>```The admins just couldn't keep up with the changes in business demands, no matter how good they were. And there was no well-defined strategy other than "It's your job to keep it safe."```

>``` John selects a new target. The attack surface seems promising after a preliminary enumeration. The services used by the target are spread across cloud providers. There is no firewall that must be evaded. He quickly discovers a small service where URL parameters are not properly validated, allowing for simple command injection leading to code execution.```

>```The goal is clear: locate and tamper with valuable data storage again. The plan is straightforward: use one of the known services as a tunnel to gain access to the storage.```

>```The system uses TLS to encrypt communication between all services. This is not unusual. However, John realizes that mTLS, which provides client identity validation, is enabled on non-public APIs. This is a major setback because he can only communicate with previously defined endpoints from the compromised service.```

### Pillar I: Assume breach
‘Assume breach’ is the assumption that a security breach is inevitable or has already occurred. With this assumption in mind, the effect or blast radius of a breach is minimized. This is achieved through measures in software development and identity management. The following two pillars leverage this assumption and build a more secure network in an organization.

### Pillar II: Never trust, always verify
Implicit trust is omnipresent in a perimeter-based network. Zero-trust removes the differentiation between traffic coming from outside and inside the network so that no request is implicitly trusted. To carry out an action inside the network, a verification of the actor is always necessary. In practice this is often realized by mTLS connections between all services combined with a white list approach for allowed communication paths.

Users can be identified by an Identity and Access Management (IAM) system. Machine identities must be managed separately. Machine-to-machine identity verification, through white lists, is vital in a zero-trust system. This effectively limits lateral movement through well-defined paths and allows identifying suspicious behavior through a Security Incident & Event Management (SIEM) system.

### Pillar III: Least privileges
Every actor should be given the least privileges needed to fulfill a given task. This further limits the blast radius of a security incident. By assigning the minimal set of rights to a user the possibility for harmful actions is significantly limited for penetrators.

Aside from using this minimal set of rights, the validity of those rights should be as short-lived as possible. Through a refresh of the verification the rights remain intact. If an actor fails to refresh the verification, the right will automatically be detracted. The concept of an active revocation is not needed if the validity of an identity is short enough.

>```John cannot use the next low-hanging fruit to make his way further into the network, as he did last time. He can only move along defined paths. He takes a closer look at the service he compromised and finds that he can capture access tokens for machine-to-machine communication there. Jackpot, he'll try to use the tokens to move on.```

>```What he doesn't know is that the token can't be used everywhere and even if it could, it is only valid for a few minutes.```

>```Trying to get further, John uses the token at a service that it was not issued for. The fact that a valid token is used in the wrong place, triggers a SIEM event and alerts an admin who quickly finds the breach and detracts its trust from the system. Due to the short validity of the tokens, the compromised host is isolated from the rest of the system within a few minutes. John realizes he is at a dead end. His compromised host loses connectivity to other services due to the missing trust. His attack ends here.```

## Zero-trust architecture in software engineering
It is possible to include the principles of zero-trust architecture at various levels of software engineering. 

- Create machine identities by using certificates, for example through <a href="https://spiffe.io/" target="_blank" rel="noopener noreferrer">SPIFFE / SPIRE</a>.
- Send events to SIEM in case of abnormal behavior from identities
- Integrate user identification, authentication, and authorization with a multi-factor approach can pave the way for increased security and leveraging principles of zero-trust. Limit rights to minimal required sets and only allow sessions to last as long as technically required. Refresh sessions when necessary.
- Use mTLS to enforce bilateral verification and whitelisting of identities in all communication between microservices, APIs, and other software components.

## Conclusion
Zero-trust is established as the answer to the challenge of implementing network security in cloud environments. Governments and corporations have set the goal to establish zero trust as a standard for themselves.

Establishing zero-trust is not trivial. The whole architecture of the network has to be built upon the aforementioned pillars. The identity management of machines and humans in particular can be a challenge.

Zero-trust architecture – Why we need to end perimeter-based security

IT Consultant Digital Integration

Große Sprachmodelle (Large Language Models oder **LLM**) haben in den letzten Jahren enorme Fortschritte gemacht und spielen eine entscheidende Rolle in verschiedenen Anwendungen. Aber was ist ein LLM?

Es ist sinnvoll zu erklären, was ein „einfaches“ Sprachmodell generell ist. Ein Sprachmodell ist eine Wahrscheinlichkeitsverteilung über Wortfolgen. Sprachen können eine unendlich lange Sequenz an validen Sätzen haben, was für ein Sprachmodell ein Problem ist. Das heißt, ein Sprachmodell kann Sequenzen, die nie in dem Trainings-Datensatz vorgekommen sind, immer noch eine gewisse (nicht 0 %) Wahrscheinlichkeit zuweisen. Verschiedene Modell-Ansätze wurden entwickelt, um dieses Problem zu überwinden, z. B. die Anwendung der *Markov-Annahme*, die Verwendung *neuronaler Netzwerke* wie rekurrente neuronale Netze (RNNs) oder *Transformer* (die Architektur hinter ChatGPT).

Ein LLM (großes Sprachmodell) ist ein Sprachmodell, das auf einer neuronalen Netzwerk-Architektur basiert (meistens ist das eine Transformer-Architektur). Ein besonders wichtiges Merkmal dabei ist, dass diese Modelle Milliarden von Parametern haben. Diese Parameter werden während des sog. Modell-Trainings aus großen Datenmengen gelernt und bilden somit die Wissensbasis des Modells. Früher wurde ein Modell für eine spezifische Aufgabe entwickelt. LLMs haben diese Richtung geändert – ein LLM kann meistens mehrere Aufgaben erledigen. Die Bandbreite der Aufgaben und generelle Leistung hängt in erster Linie von den zur Verfügung gestellten Ressourcen (Datensätzen, Rechenleistung) ab und nicht vom Architektur-Design.

Ein bekanntes Beispiel eines LLM ist ChatGPT. ChatGPT basiert auf der GPT-Architektur, die für *Generative Pre-trained Transformer* steht. Leider veröffentlicht OpenAI wenige bis kaum Informationen zum Training und den verwendeten Daten. Wir können allerdings anhand der offiziellen Veröffentlichungen vermuten, wie das Modell aufgebaut und trainiert wurde. 

## Schritt 1: Generatives Pre-Training

In diesem Schritt wird ein Sprachmodell auf Texten trainiert, ohne dass eine spezifische Aufgabe dabei zu lösen wäre. Allerdings ist das nicht genug, um damit sinnvolle Ergebnisse zu produzieren – das Modell „versteht“ immer noch nichts von Nutzer-Anweisungen und kann bspw. auf eine Frage mit einer anderen Frage antworten, weil diese Frage in demselben Kontext im Training aufgetaucht ist.

## Schritt 2: überwachtes Nachtrainieren (Supervised fine-tuning)

Ab dem Schritt 2 wird das sog. *Nachtrainieren* (Engl. *fine-tuning)* eingesetzt. Nachtrainieren bedeutet, wir wollen unser Modell auf spezifische Aufgaben vorbereiten und das Modell-Wissen spezifizieren. In dem ChatGPT-Beispiel wollen wir das Modell so trainieren, dass es ein Chatbot möglichst gut imitieren sollte. Das wird dadurch erreicht, dass dem Modell beim Training eine große Anzahl an Beispiel-Konversationen in einem Frage-Antwort-Format gezeigt wird. Allerdings gibt es hier ein großes Problem: Während des Trainings wird das Modell hauptsächlich von dem Experten-Wissen beeinflusst. Basierend auf diesem Wissen kann das Modell während des Trainings seine Entscheidungen verbessern. Wichtig zu bemerken ist, dass sich das Modell dem Experten-Wissen nur annähert und versucht, sein Verhalten daran anzupassen. Fehler sind daher nicht selten, vor allem, wenn das Modell nach dem Training getestet/angewendet wird. In der Inferenz-Zeit kann nur das Modell selber seine Entscheidungen beeinflussen. Falls währenddessen das Modell einmal eine falsche Entscheidung getroffen hat (was zuvor im Training mit menschlicher Überwachung nicht passiert ist), wird diese Entscheidung weitere falsche Entscheidungen nach sich ziehen. Dieses Problem wird in der Literatur als *Compounding-Error-*Problem bezeichnet. Frühere Fehler des Modells bei der Inferenz resultieren später oftmals in übermütigen Behauptungen oder Halluzinationen (erfundene Informationen). Um diesen negativen Effekt zu minimieren, sollte unser Modell selber Ausgaben während des Trainings produzieren und nicht nur passiv Eingabedaten konsumieren. Dabei hilft uns Reinforcement Learning (RL).

## Schritt 3: Reinforcement Learning from Human Feedback

*Disclaimer:* Wir werden nicht genau auf RL eingehen und erklären nur, welche Konzepte aus RL im ChatGPT-Training verwendet wurden. Mehr über RL <a href="https://www.geeksforgeeks.org/what-is-reinforcement-learning/" target="_blank">hier</a>.

Im Prinzip haben KI-Trainer eine Konversation mit der aktuellen ChatGPT-Version, die gerade im Trainingsprozess ist. Für eine Frage produziert das Modell eine Antwort und weitere mögliche Antworten. Diese möglichen Alternativen werden von dem KI-Trainer als mehr oder weniger passend zur Frage bewertet. Wir müssen allerdings diese Informationen in einen Skalarwert de­s­til­lie­ren. Dafür wird ein neues Modell von dem bestehenden abgeleitet und auf diesen Bewertungen trainiert. Das abgeleitete „Hilfsmodell“ lernt, eine möglichst passende Antwort aus allen Alternativen der Frage zuzuweisen. Wenn das „Hilfsmodell“ trainiert ist, können die Wahrscheinlichkeiten für mögliche alternative Antworten als Belohnung im Training verwendet werden, was ein interaktiveres Training ermöglicht.

## Ausblick: Die Zukunft von ChatGPT und LLM
ChatGPT wird kontinuierlich verbessert. Da das Training solch eines LLM mehrere Millionen Dollar kosten kann, versucht OpenAI, das Modell auf anderen Wegen zu optimieren. Immerhin produziert das Modell nicht selten ausgedachte Informationen, falsche Fakten und kann nicht zu den expliziten Ressourcen verlinken.

Zum Glück ist die Open Source Community auch fleißig dabei, die Welt der LLMs zugänglicher zu machen. Dabei ist es wichtig die jeweilige Lizenz zu beachten, vor allem im Business-Kontext. Eine Auflistung der bekanntesten Open Source LLMs findet man <a href="https://github.com/eugeneyan/open-llms" target="_blank">hier</a>. LLMs brauchen allerdings große Rechenressourcen und Rechenleistung. Das kann schnell teuer werden. Das Preis-Leistungs-Verhältnis, das man mit einem Open Source LLM hat, ist dabei wichtig zu beachten.

Die Zukunft der LLMs ist vielversprechend. Mit weiteren Fortschritten in der Forschung und der Berücksichtigung von Themen wie Datenschutz und Voreingenommenheit der Sprachmodelle können wir eine noch leistungsfähigere und vertrauenswürdigere Generation von Sprachmodellen erwarten.

LLMs ermöglichen es uns, neue Horizonte in der Sprachverarbeitung zu erkunden. Wir stehen am Anfang einer aufregenden Reise und können gespannt sein, welche weiteren Innovationen und Anwendungen uns in Zukunft erwarten.

Große Sprachmodelle: Was ist ein LLM?

Machine Learning Engineer

Sales Manager

IT-Consultant

Senior IT Consultant

Meine Kollegen bei codecentric sind nahezu allesamt Informatiker oder ausgebildete IT-Fachkräfte. Als Mathematiker und Quereinsteiger bin ich – zumindest in unserer Firma – trotz des nach wie vor großen Fachkräftemangels in der Branche immer noch eine Ausnahme. Eine Ausnahme stelle ich bei codecentric auch als spezialisierter Tester dar. Und wie sich das für einen Performance-Spezialisten wie die codecentric GmbH gehört, liegt mein Schwerpunkt auf dem spannenden Gebiet der Last- und Performanz-Tests, also im Bereich des nicht-funktionalen Testens.Für mich war es faszinierend festzustellen, dass Testen offenbar ein Sammelbecken für Quereinsteiger in der IT-Branche ist. Das trifft bereits auf den Bereich des funktionalen Testens zu. Natürlich findet man dort noch in reichlicher Zahl die obligatorischen Informatiker und Mitarbeiter aus den jeweiligen Fachabteilungen. Aber es gibt doch schon auch in beachtlicher Anzahl IT-Exoten wie z.B. Juristen. Bei einer Schulung zum Thema Last- und Performance-Tests in Köln Anfang 2008 erlebte ich dann einen wahren Berufe-Zoo: Neben mir als Mathematiker fanden sich dort u.a. eine Germanistin und eine Agrar-Wissenschaftlerin, die Dozentin selbst war Meteorologin. Und nicht wenige waren promoviert.Der Bereich des Testens in der IT ist aus meiner Sicht ideal für Fachfremde geeignet. Natürlich sind IT-Fachkenntnisse gewünscht und nützlich, aber man muss sie nicht in der Spezialisierung und Tiefe meistern und beherrschen wie z.B. als Entwickler. Im Gegenteil, zu tief in den Technologien versunken zu sein, kann einen im klassischen Sinne betriebsblind machen. Oberstes Ziel des Testers ist die Gewährleistung guter Qualität, aber der Maßstab für gute Qualität ist nicht die oft Technologie-verliebte Sichtweise des Software-Entwicklers, sondern der Nutzen des Endprodukts für den Anwender bzw. den Kunden. Und zur Beurteilung dieses Nutzens ist eine gewisse Distanz zur IT oftmals hilfreich. Zumindest aber muss die Fähigkeit vorhanden sein, geistig auf Distanz zu gehen und das Produkt – das Testobjekt, wie der Tester sagt – aus einem anderen Blickwinkel zu betrachten und zu bewerten.Und genau hier kommen die Qualitäten des Quereinsteigers zum Zug, die meiner Überzeugung nach den höheren Schulungsbedarf und die anfangs geringere Produktivität langfristig mehr als wettmachen. Er ist per Definition kein IT-Insider und tut sich daher wesentlich leichter, die Anwendung oder das IT-System nicht als Selbstzweck, sondern im Hinblick auf die Aufgabe zu betrachten, die es zu erfüllen gilt. Der Quereinsteiger kann seine Erfahrungen aus anderen Branchen und Tätigkeiten einbringen. Dadurch hat er nicht nur eine andere Sicht auf die Dinge, sondern er kann aus der Synthese seiner Erfahrungen oft einen echten Mehrwert für das konkrete Projekt schöpfen sowie in anderen oder größeren Zusammenhängen denken. Bei Last- und Performanz-Tests sind diese Fähigkeiten besonders gefragt, da vor allem zur Konzeption entsprechender Tests Anforderungen und Informationen aus den verschiedensten Bereichen zusammengetragen, analysiert und verknüpft werden müssen. Ansprechpartner für den Lasttester sind natürlich die betroffenen Fachabteilungen, die IT-Entwicklung und IT-Infrastruktur, häufig aber auch z.B. Marketing und Vertrieb, Management und sogar externe Dienstleister. Der Quereinsteiger mit seinem breiten Hintergrund ist bei solch einer Aufgabenstellung oft im Vorteil.Mein Studium der Wirtschaftsmathematik an der <a href="https://www.uni-augsburg.de/de/fakultaet/mntf/math/">Universität Augsburg</a> stellte bereits eine solche Synthese verschiedener Fachrichtungen dar – Mathematik, Informatik und Wirtschaftswissenschaften. Und schon in meinem ersten größeren Lasttest-Projekt – bei dem Kunden handelte es sich um ein Kfz-Versicherungs-Unternehmen – fand ich genau diesen Querschnitt fast idealtypisch wieder. In der Folge des Diploms führte mich mein Weg an die Universitäten in <a href="http://math.berkeley.edu/index.php?module=mathfacultyman&MATHFACULTY_MAN_op=sView&MATHFACULTY_id=111">Berkeley</a> und <a href="http://www.minet.uni-jena.de/www/fakultaet/iam/l_althoefer.html">Jena</a> , wo ich mit der (kombinatorischen) Spieltheorie, Optimierung und Operations Research verschiedenste Gebiete der Mathematik und ihre Anwendungsmöglichkeiten auf ganz reale Fragestellungen genauer unter die Lupe nahm.Von diesem Hintergrund aus möchte ich zukünftig im Rahmen dieser Kolumne alle möglichen Aspekte der IT-Branche ansprechen und beleuchten. Dabei sollen aktuelle Entwicklungen bewertet oder einfach Beobachtungen aus dem IT-Tagesgeschäft bei codecentric aufgegriffen werden, wobei ein wesentlicher Fokus sicherlich auf dem Gebiet des (Last- und Performanz-)Testens liegen wird. Vor allem aber möchte ich dies mit dem Blick von außen tun, dem Blick des Quereinsteigers und des Mathematikers.

Aus dem Blickwinkel eines Mathematikers – Quereinsteiger

So ungefähr sieht meines Erachtens nach ein typisches Albtraumszenario eines Performance-Testers aus: Eine neue Version eines Testobjekts findet den Weg in meine Hände. Nach etwas Herumkonfigurieren, um das Ding ans Laufen zu kriegen, führe ich einen kurzen, ersten Testlauf durch. Irgendjemand – Entwicklung, Architektur, Projektmanagement, wer auch immer – bekommt davon Wind und ist neugierig auf die Ergebnisse. Ich versuche es mit einer Verzögerungstaktik: „Es ist der allererste Lauf. Die Testumgebung ist noch gar nicht vollständig aufgebaut. Wir müssen noch mehr Tests durchführen. Erst müssen wir die Zahlen bestätigen, bevor es irgendeinen Sinn ergibt, sie zu diskutieren.“ Mein Gegenüber gibt nicht auf und bohrt weiter. Er sei sich aller meiner Bedenken bewusst und wolle nur seine Neugier befriedigen. Letztendlich gebe ich nach und liefere die Zahlen, was ich schon kurz darauf zutiefst bereue. Mein kleines Fitzelchen an Information hat wie eine Lawine in Null-komma-Nichts eine gigantische Größe erreicht und kommt wie ein Bumerang zu mir zurück. Fälle wie dieser sind oftmals die Folge einer übermäßigen Zahlengläubigkeit. Wenn etwas getestet und quantifiziert ist, vertraut man gerne den Ergebnissen und verlässt sich auf diese, ohne die konkreten Umstände zu berücksichtigen. Selbst ein allererster Messpunkt wird häufig gewichtet und auf eine Art und Weise diskutiert, als läge eine ausgefeilte und vollständige Testserie zugrunde. Sind die Zahlen schlecht, führt dies manchmal zu hektischen und gar sonderlichen Aktivitäten wie z.B. Eskalation, Krisensitzungen und eventuell sogar Maßnahmen seitens des Managements. Sind die Zahlen unerwartet gut, könnte eine voreilige Entwarnung die Folge sein.Sogar der Performance-Tester selbst kann für solche Fehler anfällig sein. Ich kann hier aus eigener Erfahrung sprechen… Entweder, weil er ein bestimmtes Ergebnis wünscht oder erwartet, oder aus schlichter Routine heraus, kann er in Versuchung sein, seine gerade selbst ermittelten Zahlen zu schnell zu glauben. Anwendungssysteme und ihre Konfiguration sind oftmals sehr komplex, so dass man leicht kleine Änderungen mit möglicherweise großen Auswirkungen auf die Testergebnisse vergessen oder übersehen kann.Dieser anscheinend unerschütterliche Glaube an die Gültigkeit von Zahlen kann noch viele andere ungünstige Folgen haben. Oftmals wird schon ein einzelner Datenpunkt hoffnungslos überanalysiert, indem z.B. mögliche  zukünftige Performance-Verbesserungen extrapoliert werden oder die Effekte auf ein n-Mal größeres System und so weiter. Falls dann weitere Tests diese Erwartungen nicht erfüllen, setzt manchmal eine hektische Suche nach der vermuteten versteckten Ursache der „falschen“ Zahlen ein, anstatt zu bedenken, dass man von Anfang an unvergleichbare Dinge verglichen hat. Ebenso werden manchmal bereits korrekt berichtete und archivierte Zahlen wiederentdeckt, aber ihr Kontext vergessen, was zu ebenso falschen Interpretationen, Schlüssen und Maßnahmen führen kann.Meist ist es kaum möglich, erfolgreich gegen diese Zahlengläubigkeit zu argumentieren, darauf zu beharren, dass weitere Tests zur Bestätigung nötig sind und dass große Schwankungen ganz normal sind. Performance-Messungen als Teil der Qualitätssicherung in der Anwendungsentwicklung sind keine exakte Wissenschaft. Da die oberste Priorität normalerweise ist, „etwas ans Laufen zu kriegen“, sind die Vorbedingungen eines kontrollierten Experimentes wie in der akademischen Welt nur selten gegeben. Die Ergebnisse solcher Experimente werden aber oft genau so betrachtet und behandelt.Als Performance-Tester sollte man sich bewusst sein, welche möglichen Auswirkungen die berichteten Testergebnisse haben können. Testen, besonders Performance-Testen, soll Unsicherheit durch Wissen ersetzen, aber der unvorsichtige Umgang mit Testergebnissen kann schnell zum entgegengesetzten Resultat führen. Meines Erachtens sollte die oberste Regel sein, nur Daten zu berichten, die man selbst verstanden hat, zu denen man stehen und die man verteidigen kann. Man sollte sich immer über die Belastbarkeit, Reichweite, Relevanz und Vergleichbarkeit der Zahlen im Klaren sein, die man berichtet, und diese Charakteristika ebenso berichten. Und es ist ratsam, explizit darauf hinzuweisen, falls eine Messung nur für einen bestimmten Testaufbau Aussagekraft besitzt und für weitere Hochrechnungen ungeeignet ist.Falls eine Fehlinterpretation von Testergebnissen passiert, sollte man schnell, deutlich und mit Nachdruck die Sichtweise des Testers auf die Zahlen und ihren Kontext darstellen, um den möglichen Schaden zu begrenzen. Zahlen, die einmal in der Welt sind, nehmen gerne ein Eigenleben an. Wie bei Gerüchten ist es praktisch unmöglich, sie wieder einzufangen. Daher sollte man stets sorgfältig bedenken, was man wann berichtet.Und ein letzter Rat: Als Performance-Tester sollte man sich immer einen skeptischen Blick auf die eigene Arbeit und auch auf die eigenen Instinkte bewahren. Andere Leute sollten Testergebnissen nicht blind glauben – und auch der Tester selbst sollte dies nicht tun.

Zahlengläubigkeit

Hauptthema meiner täglichen Arbeit ist die Performance von IT-Systemen, insbesondere von Java-Anwendungen. Performance-Tests und -Optimierungen haben normalerweise den Zweck, die Einhaltung der nicht-funktionalen Anforderungen an eine Anwendung zu sichern. Die tagtägliche Beschäftigung mit diesen Dingen hat auch das Potential, die Sichtweise des Testers auf ganz andere Bereiche zu prägen, wodurch man ggf. selbst so unangenehmen Angelegenheiten wie einem Krankenhausaufenthalt interessante Aspekte abgewinnen kann. In dieser Kolumne möchte ich von einigen dieser seltsamen gedanklichen Assoziationen berichten – vielleicht können sie sogar dabei helfen, zu verstehen, worum es beim Testen nicht-funktionaler Anforderungen geht und warum es wichtig ist.Das zu testende System (SUT – System under Test) in diesem speziellen Fall ist mir persönlich besonders wichtig: Es handelt sich um meine optischen Rezeptoren – meine Augen. Ihre Funktion ist jedem klar. Mit den technischen Vokabeln von Wikipedia: das Sammeln und Fokussieren von Licht zur Erzeugung von Bildern, deren Transformation in elektrische Signale sowie die Weiterleitung an das Gehirn. Die funktionalen Fähigkeiten meiner Augen sind ein wenig beeinträchtigt, weswegen ich eine Brille trage. Diese hilft mir beim Fokussieren des Lichts und verbessert somit die Funktionalität meiner Augen.Damit meine Augen auch langfristig ihre Aufgaben gut erfüllen können, ist eine nicht-funktionale Anforderung von höchster Wichtigkeit: Der Augendruck. Falls der Druck der Flüssigkeit im Auge dauerhaft zu hoch ist, werden die Nerven geschädigt, was zu einem Verlust an Sehfähigkeit führt – ggf. sogar bis zur vollständigen Blindheit. Ganz grob gesprochen sollte der Augendruck weniger als 20 mmHg betragen. Da mein Augendruck schon länger relativ hoch war, nahm ich entsprechende Augentropfen und ließ meinen Augendruck vier Mal jährlich kontrollieren. Da meinem Augenarzt mein Augendruck jedoch immer noch zu hoch erschien, schickte er mich zur Überprüfung und Einstellung meines Augendrucks in eine Augenklinik.  So wurden meine Augen für vier Tage zu einem wahren SUT.Nicht-funktionale Anforderungen sind kein Selbstzweck. Ohne die eigentliche Basisfunktionalität sind alle nicht-funktionalen Eigenschaften wertlos. Deshalb war die erste Aufgabe nach meiner Ankunft im Testlabor – der Augenklinik – die Überprüfung der Funktionalität meiner Augen. Dazu wurden zwei Tests durchgeführt: Erstens ein Sehschärfetest, in welchem ich immer kleinere Buchstaben lesen sollte, zweitens ein Gesichtsfeldtest, um evtl. Einschränkungen des Gesichtsfeldes zu erkennen. Desweiteren wurden meine Sehnerven untersucht. Erst nachdem auf diese Weise der aktuelle Stand der Funktionalität des SUT festgestellt wurde, begann die Untersuchung der nicht-funktionalen Eigenschaften des SUT.In einem ersten Schritt wurde die Korrektheit der Augendruck-Messungen überprüft. Wie ich bereits in meinem letzten Blog „Zahlengläubigkeit“ geschrieben habe, ist es sehr einfach, sich mit fehlerhaften Zahlen selbst zu betrügen – mit eventuell schwerwiegenden Konsequenzen. Insbesondere wenn man bereits mögliche Ursachen für Messfehler kennt, wäre es unverantwortlich, ihr Vorliegen nicht zu überprüfen. So weiß man in Sachen Augendruck, dass die Hornhautdicke die Messergebnisse beeinflussen kann. Folglich wurde die Dicke meiner Hornhaut durch Messungen ermittelt, wobei sie sich als sehr groß herausstellte, so dass ein entsprechend großer Korrekturwert von den Ergebnissen meiner Augendruck-Messungen abgezogen werden muss. Ohne die Überprüfung meiner Hornhautdicke hätte man aus den Messwerten meines Augendrucks wahrscheinlich die falschen Schlüsse gezogen.Allerdings haben die Tester – die Ärzte – beim Test der Hornhautdicke das SUT beschädigt und so dessen Basisfunktionalität erheblich beeinträchtigt – die Ärzte bezeichneten es lediglich als Irritation. Da es sich beim SUT um meine Augen handelte war ich in der Tat nicht nur irritiert, sondern auch ziemlich wütend. Glücklicherweise hat sich die Irritation nach einem Tag wieder gelegt und meine Augen funktionierten wieder normal. Wegen solcher Gefahren werden in der IT wann immer möglich keine Tests auf produktiven Systemen durchgeführt, sondern auf dedizierten Test-Systemen. Demoliert der Tester dann das Test-System, kann wenigstens die Produktion weiterlaufen.Nach all diesen vorausgehenden Tests und Messungen begann endlich der Standard-Test-Zyklus, d.h. für drei Tage wurde fünf Mal täglich mein Augendruck gemessen. Durch diese wiederholten Messungen erhält man neben verlässlicheren Zahlen auch ein Profil für die Veränderung des Augendrucks im Tagesverlauf. Denn wie jeder Performance-Tester weiß, ist die Last auf einem typischen SUT stark von der Tageszeit abhängig – um 11 Uhr vormittags sind einfach mehr Nutzer im System als um 6 Uhr abends.Da die Ergebnisse meiner Augendruck-Messungen ermutigend waren – nach Abzug des Korrekturwertes lagen sie alle im grünen Bereich – wurde beschlossen, das SUT einem speziellen Stress-Test zu unterziehen. Bei einem Stress-Test untersucht man das Verhalten des SUT unter extremen Bedingungen, in der IT z.B. eine besonders große Zahl an gleichzeitigen Benutzern oder Ähnliches. Im konkreten Fall meiner Augen wurden durch Augentropfen die Pupillen geweitet, da hierdurch evtl. der Abfluss der Flüssigkeit im Auge blockiert wird, was ein umgehendes Ansteigen des Augendrucks provozieren würde. Glücklicherweise blieb mein Augendruck aber selbst unter diesen erschwerten Umständen stabil.Nach vier Tagen im Testlabor lautete daher das erleichternde Ergebnis der Testserie, dass von der nicht-funktionalen Eigenschaft “Augendruck“ keine akute Gefahr für meine Augen ausgeht. Damit das so bleibt, muss ich aber auch in Zukunft entsprechende Augentropfen nehmen und regelmäßige Regressions-Tests meines Augendrucks bei meinem Augenarzt vor Ort durchführen lassen. Was ohnehin für jeden verantwortungsbewussten System- oder Anwendungsadministrator zu empfehlen ist.

Aus dem Blickwinkel eines Mathematikers – Die Augen des Testers

Zwischen den großen Nachrichten dieses Novembers wie der irischen Finanzkrise und dem Konflikt in Korea gingen zwei kleine Nachrichten aus dem Bereich des bayerischen Schulwesens weitgehend unter: <a href="http://www.merkur-online.de/lokales/stadt-muenchen/computer-chaos-berufsschulen-1009592.html">„Computer-Chaos an den Berufsschulen“</a> vom 16. und <a href="http://www.nordbayern.de/nuernberger-nachrichten/region-bayern/technik-stoppt-abi-umfrage-1.320697">„Technik stoppt Abi-Umfrage“</a> vom 17. November, jeweils aus bayerischen Regionalzeitungen. Beide Meldungen zeigen beispielhaft die Bandbreite und die manchmal verheerenden Auswirkungen von Last- und Performance-Problemen bei modernen Computer-Systemen – eine Thematik, die nur selten in die Schlagzeilen der Mainstream-Medien gelangt.„Computer-Chaos an den Berufsschulen” handelt von der Modernisierung des sogenannten Pädagogischen Netzes der Stadt München. Nach der Modernisierung wird das System langsamer, wenn sich nur zwei oder drei Schüler einloggen, „irgendwann geht gar nichts mehr“. Ungefähr 7.500 Schüler nutzen das System zum Training mit verschiedenster professioneller Software, es wird sogar für die Abschlussprüfungen benötigt. Daher überlegt man sogar, im Notfall auf das alte System zurückzustellen.„Technik stoppt Abi-Umfrage” beschreibt die Überlastung einer öffentlichen Webseite, die als Plattform einer Umfrage unter allen bayerischen Abiturienten über deren Studienpläne dienen sollte. Nach nur wenigen Tagen brach die Webseite unter dem Ansturm von ca. 95.000 Besuchern zusammen. Jetzt wird geplant, statt einer vollständigen Erhebung nur Stichproben durchzuführen.Diese beiden Nachrichten zeigen, dass Last- und Performance-Probleme unter sehr verschiedenen Rahmenbedingungen auftreten können: Ein Mal in einem großen, aber lokalen, Anwendungs-Netzwerk, das andere Mal bei einer Webseite. In beiden Fällen führt eine zu hohe Last zu Performance-Problemen oder sogar kompletten System-Ausfällen. Weiterhin gefährden in beiden Fällen die aufgetretenen Probleme das Erreichen des jeweiligen Unternehmens- bzw. Aktions-Zieles – und als öffentlich wahrgenommene Fehlschläge sind sie zusätzlich besonders peinlich. Schnelle Lösungen sind jeweils entweder teuer oder gar nicht verfügbar.Da keine tieferen Details in den beiden Meldungen erwähnt werden, will ich nicht über die konkreten Gründe für die jeweiligen Performance-Probleme spekulieren, sondern stattdessen einige allgemeine Bemerkungen über mögliche Ursachen von Last- oder Performance-Problemen machen. Der größte und offensichtlichste Fehler ist, erst gar keine Last- oder Performance-Tests vorzusehen. Angesichts der potentiell katastrophalen Auswirkungen von Last- und Performance-Problemen scheint es verantwortungslos, diese Risiken zu ignorieren. Theoretische Überlegungen zu diesen Problemen sind ein guter Anfang, aber Überraschungen und noch unerkannte Zusammenhänge in der späteren produktiven Praxis sind eher die Norm als die Ausnahme. Daher sind meiner Meinung nach praktische Last- und Performance-Tests ein unverzichtbarer Bestandteil eines jeden IT-Projekts.Sind Last- und Performance-Tests vorgesehen, so werden sie oft erst zum Ende des Projekts eingeplant; nach dem Abschluss der Entwicklungsphase oder sogar erst nach den funktionalen Tests. Nicht selten werden diese Tests dann aus Budgetgründen oder wegen zeitlicher Verzögerungen gekürzt oder gar ganz gestrichen, was erneut enorme Risiken in das Projekt hineinträgt. Nach unseren Erfahrungen bei codecentric ist es ohnehin am besten, mit Performance-Tests gleich zu Anfang eines Projektes zu beginnen. Sobald lauffähiger Code vorliegt, kann man ihn testen und auf Performance-Auffälligkeiten hin untersuchen. Und sobald der erste Geschäftsvorfall (GeVo) in auch nur rudimentärer Form vorliegt, kann mit Lasttests begonnen werden.Da es letztendlich auf den realen Ernstfall ankommt – die Produktion – ist ein falsches Test-Konzept ein weiteres großes Risiko. Die getestete Last sowie die getesteten Geschäftsvorfälle müssen so realitätsnah wie möglich sein, um spätere böse Überraschungen zu vermeiden. Das Gleiche gilt für die Test-Umgebung – Hardware, Software und deren Konfiguration – die so produktionsnah wie möglich sein sollte. Im Idealfall kann man die Last- und Performance-Tests auf der späteren Produktionsumgebung durchführen.In einigen Fällen kann es sehr schwierig bis unmöglich sein, eine realistische Last-Prognose zu erstellen, z.B. bei neuen Webseiten ohne vorhergehende Erfahrungen bzgl. Kunden- oder Nutzer-Verhalten. Dann muss man in den Tests einen umso größeren Bereich an möglichen Last-Szenarien bzw. Last-Verteilungen abdecken. Außerdem sollte das System flexibel und skalierbar sein, was ebenfalls getestet werden sollte. Wobei ausführliche Stress-Tests und ein flexibles, skalierbares System immer gute Ideen sind, selbst wenn man über konkrete Last-Vorhersagen verfügt.Was auch immer die Ursachen für die Probleme in den geschilderten Fällen aus Bayern sein mögen, erst durch schlechte Erfahrungen in der Produktion auf Performance-Probleme aufmerksam zu werden, ist in jedem Fall sehr kostspielig. Ausreichend Zeit und Ressourcen in vorgelagerte Last- und Performance-Tests zu investieren, kann helfen, solche Risiken zu minimieren und mit ihnen umzugehen.

Aus dem Blickwinkel eines Mathematikers – Last- und Performance-Themen in den Nachrichten

Bei der codecentric AG setzen wir schon immer bevorzugt auf Open-Source-Werkzeuge und –Lösungen. Folgerichtig ist für mich als Java-Performance-Spezialist JMeter von Apache das Lasttest-Werkzeug der Wahl.Eine kurze Bemerkung zu Beginn: Dieser Blog-Artikel ist kein umfassender Überblick über JMeter, seine Möglichkeiten und Beschränkungen, sondern stattdessen ein sehr persönlicher Blick auf dieses Werkzeug. Man könnte auch sagen: eine längst überfällige Abrechnung. Nach einigen Jahren, in denen ich im Wesentlichen in den Bereichen Performance-Optimierung und –Monitoring beschäftigt war, arbeitete ich im letzten Projekt wieder mit JMeter. Während ich früher hauptsächlich den HTTP-Sampler von JMeter benutzt habe, war diesmal der JUnit-Sampler das wichtigste Interface zur Last-Erzeugung.Mit JMeter Lasttests zu schreiben und durchzuführen ist eigentlich ganz einfach. Im bereits erwähnten Projekt sollten die reichlich vorhandenen funktionalen JUnit-Tests zur Lasterzeugung genutzt werden. Dazu müssen diese Tests lediglich JMeter in Form einer jar-Datei zur Verfügung gestellt werden. Im JUnit-Sampler von JMeter werden anschließend die gewünschte Test-Klasse und die darin enthaltene, auszuführende Test-Methode ausgewählt. Als Klammer um einen oder mehrere JUnit-Sampler fungiert bei JMeter eine sog. Thread-Gruppe, in der die Last (die Anzahl der parallelen Threads) eingestellt wird und die Dauer des Tests. Im Großen und Ganzen war’s das, der Lasttest (oder „Testplan“ im JMeter-Jargon) ist definiert. Man muss nur noch auf den Start-Knopf drücken und der Test wird ausgeführt. Wer weitere Details wünscht, findet diese im in leicht verständlicher Form. Man würde sich etwas mehr explizite Beispiele wünschen, insb. zum Thema Regex, aber insgesamt gesehen handelt es sich um eine exzellente Doku.Irgendwie ist es mir gelungen, das Gefühl zu verdrängen, das sich bei der Arbeit mit JMeter typischerweise einstellt. Allerdings hat JMeter dieses Gefühl sehr, sehr schnell wieder zurückgebracht. Ich hatte vergessen, dass JMeter – wie jeder von seiner Tagesform abhängige andere Mensch auch – sich richtig launisch aufführen kann, manchmal sogar zickig.Beispiele gefällig?<ul><li>Die Fehlermeldungen des JUnit-Samplers sind recht aussagekräftig – normalerweise. Aber man hüte sich vor auch nur den geringsten Abweichungen zu dem, was JMeter von den Konstruktoren der JUnit-Test-Klasse erwartet. Man kriegt ein knappes „failed to create an instance of the class” an den Kopf geworfen und wird ansonsten von JMeter in seinem Elend alleine gelassen. Auch Google hilft einem in diesem Fall nicht weiter. Vielleicht helfen ja unsere Erfahrungen: JMeter scheint sowohl den Standard-Konstruktor als auch den Konstruktor mit einem einzelnen String-Parameter zu erwarten. Und falls in den Konstruktoren bereits irgendwelche Libraries zum Einsatz kommen (z.B. log4j), benötigt JMeter auch diese.</li><li>Völlig rätselhaft war mir das Verhalten des „Regular Expression Extractor“-Controllers, mit dem man Variablen mittels Regex aus dem Ergebnis des letzten Samplers definieren kann. Der Inhalt dieser Variablen war flüchtig wie eine Seifenblase. Im direkt folgenden Sampler konnte man ihn noch verwenden, danach war er wie vom Winde verweht. Es ist mir nicht gelungen, den Variableninhalt in andere Variablen oder Strukturen zu transferieren und auch kein anderer der vielen denkbaren Workarounds funktionierte.</li><li>Besondere Spannung kommt auf, wenn ein JMeter-Testplan mehrere JUnit-Sampler enthält. Manchmal ändert JMeter die Test-Klassen und Test-Methoden aller Sampler auf die entsprechende Klasse und Methode des aktuellen Samplers ab. Bisher habe ich den Auslöser für diesen Bug noch nicht gefunden.</li></ul>Nette Features wie diese helfen dabei, die Aufmerksamkeit bei der Arbeit mit JMeter hoch zu halten. Anders ausgedrückt: Ich entwickelte eine handfeste Paranoia gegenüber JMeter, da ich nie sicher war, dass es wirklich das tut, was es soll. Außerdem hat dieses Verhalten den Effekt, den Fehler immer zuerst bei JMeter zu suchen, sobald irgendwo etwas schief geht.Einige andere Dinge sind lediglich unpraktisch, z.B. die Verzeichnis-Pfade. JMeter liest und schreibt viele Dateien: Testpläne, Testparameter, Ergebnis-Dateien. Die Default-Verzeichnisse für diese Dateien sind aber unterschiedlich: Manchmal ist es das Verzeichnis, in dem der Testplan liegt; ein anderes Mal das JMeter-bin-Verzeichnis. Eine Logik habe ich dabei noch nicht entdeckt.Führt man Tests über die JMeter-GUI durch und nicht über die Kommandozeile oder ein Skript, so spürt man schnell das dringende Verlangen, nach jedem Testlauf die GUI durchzustarten. Oftmals kann man nur dadurch sicherstellen, dass nicht irgendwelche Artefakte des letzten Tests noch in JMeter aktiv sind. Außerdem ist dies notwendig, um eine frische JVM zu kreieren, wenn – wie z.B. in einem typischen JUnit-Test-Szenario – alles in einer einzelnen JMeter-JVM läuft: JMeter, die JUnit-Test-Klassen und manchmal sogar auch noch das zu testende Java-System selbst.So weit, so schlecht. JMeter ist also ein Dreckstool. Warum liebe ich es dennoch? Nun – JMeter hat praktisch keine Abhängigkeiten, ist schnell installiert, Open Source und kostenlos. Und zu all dem bietet es eine erstaunliche Flexibilität. Am häufigsten findet wahrscheinlich der HTTP-Sampler Verwendung, da er die ideale Schnittstelle ist, um Web-Anwendungen aus Anwendersicht zu testen. Andere Sampler, wie z.B. der hier beschriebene JUnit-Sampler, setzen auf einer tieferen, technischen Ebene an. Zur Zeit bietet JMeter ca. 20 verschiedene Sampler, die auf vielen unterschiedlichen Protokollen operieren.Eine weitere nützliche Zugabe ist das sogenannte Performance-Plugin für Jenkins, das de facto ein JMeter-Plugin ist. Bei codecentric möchten wir so viel automatisieren wie nur irgend möglich und mit dem Performance-Plugin gelingt dies sogar mit JMeter-Performance-Tests.Und wem das noch nicht reicht, der kann direkt den JMeter-Testplan hacken (der nur eine XML-Datei ist) – aber auch dabei muss man sich vor den Launen JMeters hüten, da nicht alle Modifikationen funktionieren, die logisch betrachtet möglich sein sollten – oder auch seinen eigenen Zusatz-Code schreiben.JMeter erinnert mich an den Spruch eines alten Freundes, der mir über sein erstes Auto – einen kleinen Franzosen – Folgendes erzählt hat: „Ich wollte immer ein Auto mit Charakter. Und dieses Auto hat einen Charakter: Einen miesen zwar, aber es hat Charakter.“ Er liebte sein Auto.Insgesamt gesehen: Werde ich JMeter wieder benutzen? Ganz gewiss. JMeter hilft einem, den Job zu erledigen, trainiert die Stressresistenz und nicht zu vergessen: Man lernt Demut.

Aus dem Blickwinkel eines Mathematikers:  JMeter – Geliebtes Dreckstool

Mensch gegen ComputerDiesen Herbst kommt es im Computer Go zu etwas, das es in dieser Form noch nie gegeben hat: einem Duell zwischen einem Go-Programm und einem europäischen Spitzenspieler ohne Vorgabe bzw. Handicap – und codecentric ist der Sponsor dieses Duells. Dies ist diesmal kein typischer codecentric-Blog-Artikel. Es geht nicht um Tipps oder Strategien zu Java, agiler Entwicklung, Software-Qualität oder ähnlichen Themen. Statt dessen möchte ich über das Spiel Go sowie Computer Go schreiben – einerseits das vielleicht älteste Brettspiel der Welt, andererseits ein Feld hochmoderner Technologie und Forschung. Go, die letzte BastionDas ostasiatische Brettspiel Go gilt als eine der letzten offenen Herausforderungen der Spielprogrammierung, als das eine klassische Spiel, bei dem Menschen noch immer selbst gegen die stärksten Programme gewinnen. Im Schach hat der Mensch das Duell gegen den Computer bereits 1997 verloren, als IBMs Deep Blue den damaligen Schachweltmeister Garry Kasparow bezwingen konnte. Heutzutage kann wahrscheinlich ein normales Schachprogramm auf einem durchschnittlichen Notebook den Schachweltmeister besiegen. In Dame und Backgammon haben Menschen auch längst keine Chance mehr.Nicht so in Go. Die Spielmechanik ist ausgesprochen einfach, wie ein Blick in die Regeln zeigt (<a href="http://www.dgob.de">www.dgob.de</a> ). Aber wenn man Go noch nie gespielt und lediglich die Regeln durchgelesen hat, fragt man sich wahrscheinlich ziemlich ratlos, wann das Spiel eigentlich zu Ende ist und wie der Sieger ermittelt wird. Diese Verwirrung liefert einen ersten Hinweis auf die Komplexität von Go: Es ist ausgesprochen schwierig, gute Heuristiken zu finden, um eine Go-Stellung zu bewerten – welcher Spieler liegt in Front und wie weit? Ein anderer Grund, warum es so schwierig ist, die traditionelle Spielbaum-Suche in Go zu nutzen, mit der man in Schach große Erfolge gefeiert hat, ist die schiere Größe des Go-Brettes mit seinen 19 x 19 Schnittpunkten. Im Schach gibt es durchschnittlich ca. 25 verschiedene Zugmöglichkeiten in einer Stellung. Bei Go sind es zu Beginn 361 und bei Spielende immer noch zwischen 50 und 100. Ein Schachspiel dauert durchschnittlich 80 (Halb-)Züge, eine Partie Go zwischen 200 und 300. Bei Go müssen folglich ganz andere Größenordnungen an Daten durchgewälzt werden als bei Schach, so dass die Programme entsprechend deutlich weniger weit vorausrechnen können. Daher konnte bis vor wenigen Jahren selbst ein durchschnittlicher Go-Spieler jedes Go-Programm schlagen.Monte-Carlo-AlgorithmenDann kamen Monte-Carlo-Methoden auf. Eine Alternative, sich dem riesigen Spielbaum von Go zu nähern, ist, die wissensbasierte, klassische Baumsuche durch Nutzung des Zufalls zu erweitern. Mittels Zufallszügen werden Spielpositionen vielfach durchgespielt, um auf diese Weise die vielversprechendsten Züge zu ermitteln. Dieser Ansatz wurde lange Zeit weitgehend ignoriert, da er der menschlichen Herangehensweise an ein Spiel wie Go völlig zuwider läuft. Aber in den letzten Jahren haben Go-Programme mit Monte-Carlo-Methoden rasante Fortschritte gemacht. Die stärksten Programme nähern sich inzwischen dem Top-Amateur-Niveau.Duelle gegen SpitzenspielerSeit 2007 richtet die Universität für Elektro-Kommunikation in Japan den „UEC Cup Computer Go“ aus, eine Art inoffizielle Weltmeisterschaft der Go-Programme. Bis zu den Fortschritten durch Monte-Carlo-Methoden wurde Computer Go in der Go-Welt nicht sonderlich ernst genommen. Aber 2013 hat der Nihon Ki-in, die bedeutendste japanische Organisation von Go-Profis, eine Vereinbarung getroffen, dass die stärksten Programme des UEC Cups gegen Go-Profis antreten dürfen. In den letzten Jahren waren die zwei stärksten Go-Programme regelmäßig das japanische Programm „Zen“ und das Programm „Crazy Stone“ des französischen Entwicklers Rémi Coulom. In den Spielen gegen Go-Profis 2013 und 2014 haben die Programme jeweils eine Vorgabe von vier Steinen bekommen. Um das besser Einschätzen zu können: Nur ein bereits sehr starker Amateur kann hoffen, mit einer solchen Vorgabe gegen einen Profi zu gewinnen. Während Zen in beiden Jahren verlor, schaffte es Crazy Stone, seine Partien gegen die Profis zu gewinnen, so dass die Frage letztlich offen blieb, wie groß der Spielstärke-Unterschied zwischen den stärksten Go-Programmen und professionellen Go-Spielern tatsächlich ist.codecentric challenge 2014In wenigen Wochen nun wird in der „codecentric challenge 2014“ Crazy Stone in einem fünf-Partien-Match gegen Franz-Josef Dickhut antreten. Dickhut ist Amateur-6-Dan und elfmaliger deutscher Go-Meister. Im Amateur-Bereich geht es nicht mehr viel besser. Kein stärkerer Go-Spieler hat sich jemals zu einem ernsthaften Wettkampf gegen ein Go-Programm ohne Vorgabe bereit erklärt. Dass der Gewinner nicht in einer einzigen Partie, sondern in einem Best-of-five-Match ermittelt wird, verleiht dem Wettbewerb zusätzliches Gewicht. Gespielt wird online auf dem KGS Go-Server. Die erste Partie wird am Samstag, dem 4. Oktober gespielt. Jede Woche folgt ein weiteres Spiel, bis eine Seite drei Mal gewonnen hat.Vorgeschlagen und organisiert wurde der Wettkampf von Prof. Ingo Althöfer von der Universität Jena, der seit Jahrzehnten im Bereich der Spiel-Programmierung und der Spiel-Mathematik forscht. codecentric wiederum hat sich bereit erklärt, als Sponsor aufzutreten und die Webseite des Wettkampfes zur Verfügung zu stellen. Der entsprechende Link wird hier rechtzeitig vor der ersten Partie veröffentlicht.Ich hoffe, es ist mir gelungen, ein wenig Interesse für dieses faszinierende Spiel und das kommende Mensch-Computer-Duell zu wecken. Bleiben Sie dran!

codecentric challenge 2014

Seit vielen Jahren arbeite ich mit Application Performance Management (APM) Werkzeugen im Java-Umfeld. Im Vergleich zu anderen Performance-Optimierungs-Werkzeugen wie z.B. Profilern, erfüllen APM-Werkzeuge sowohl Monitoring- als auch Analyse-Aufgaben. Sie bieten einen besseren Überblick über verteilte Anwendungen und können eine direkte Verbindung zwischen Anwender-Aktionen, den Performance-Erfahrungen der Anwender und den zugrunde liegenden technischen Prozessen liefern. Meiner Erfahrung nach gibt es einige häufigere Fehlwahrnehmungen darüber, was an vorbereitenden aber auch dauerhaft anfallenden Arbeiten vor einem liegt, um möglichst vollständig von einem APM-Werkzeug zu profitieren. In diesem Blog möchte ich diese Fehlwahrnehmungen und die Aufgaben illustrieren, die mit einem APM-Werkzeug verbunden sind.Meine Erfahrungen beruhen hauptsächlich auf der Arbeit mit AppDynamics, aber auch mit Dynatrace, im Monitoring, der Analyse und Optimierung der Performanz von Java Anwendungen. Während beide Werkzeuge zumindest teilweise auf fundamental unterschiedlichen Konzepten basieren, ist ihr Erscheinungsbild, ihr Nutzen und ihre Benutzung aus Sicht der Anwender ähnlich. Während ich mich im Folgenden auf AppDynamics beziehe und entsprechende Beispiele wähle, gelten die besprochenen Themen ebenso für Dynatrace und höchstwahrscheinlich auch weitere APM-Werkzeuge.1. Einrichtung der InfrastrukturUm mit AppDynamics zu arbeiten, muss der sog. „Controller“ installiert werden, die zentrale Einheit, die die Performanz-Daten sammelt, analysiert und darstellt. Entsprechend der Anzahl der Systeme, die überwacht werden sollen, und der Menge an Transaktionen, die von ihnen erzeugt werden, muss der Controller dimensioniert werden, d.h. es muss ausreichend ausgestattete Hardware bereitgestellt werden, damit der Controller seine Pflichten ordentlich erfüllen kann. AppDynamics-Agenten müssen auf den zu überwachenden Systemen installiert werden und die Kommunikation zwischen allen Komponenten muss eingerichtet werden.Da all dies notwendige Voraussetzungen sind, um mir einem APM-Werkzeug arbeiten zu können, ist es offensichtlich, dass Arbeitskraft, Zeit und Hardware investiert werden müssen, um das neue APM-Werkzeug aufzusetzen und in Betrieb nehmen zu können.Im Fall von AppDynamics ist dies auch schon alles, das gemacht werden muss, um dieses schicke – und in der Tat auch äußerst nützliche – zentrale Dashboard sehen zu können, die sog. „Flow Map“:<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/SwmH8NaDQmep7yDW2D1k"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/SwmH8NaDQmep7yDW2D1k" alt="anon Flow Map" width="640" height="322" /></a> AppDynamics Main Application Dashboard</div> Die Architektur der Anwendung, die zuvor oft eher mysteriös war, liegt nun offen und transparent vor einem, und das einzige, was dazu nötig gewesen ist, war, das APM-Werkzeug zu installieren. Fast scheint es, als sei die Arbeit bereits halb erledigt. Das Einzige, das noch zu tun bleibt, ist…3. Dashboards und AlarmierungDer Haupt-Einsatzzweck eines APM-Werkzeuges ist die Performanz-Überwachung einer Anwendung. Gewünscht sind umfassende Dashboards, die auf einen Blick zeigen, wie es um die Performanz einer Anwendung steht. AppDynamics bietet exzellente Dashboards „out of the box“, die genau dies tun. Ein Beispiel ist erneut das zentrale Dashboard im obenstehenden Bild. Rechts und unterhalb der Flow Map findet man Graphen und Tabellen, die übersichtlich die wesentlichen Performance-Daten abbilden. Desweiteren bietet AppDynamics viele Möglichkeiten, spezielle, nach den eigenen Wünschen und Bedürfnissen maßgeschneiderte Dashboards zu entwerfen.AppDynamics bringt weiterhin einen Satz an sehr nützlichen Regeln mit, um Auffälligkeiten im Performanz-Bereich zu melden. Die meisten Nutzer werden diese Regeln feintunen und ergänzen wollen, um sich ein für sie passendes Alarmierungssystem zu schaffen.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/EM3qKOf3Tw6lyMctuYuN"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/EM3qKOf3Tw6lyMctuYuN" alt="Health Rules" width="525" height="381" /></a> AppDynamics Health Rules</div> Hat man auch diesen Schritt erledigt, kann man leicht annehmen, man habe alle notwendigen Arbeiten durchgeführt: Das APM-Werkzeug läuft und versorgt einen mit allen notwendigen Informationen zur Performanz der überwachten Anwendung und man wird alarmiert, falls entsprechende Schwierigkeiten auftreten.Falsch. Ganz falsch. An dieser Stelle aufzuhören bedeutete, auf den Großteil des Mehrwerts zu verzichten, den ein APM-Werkzeug liefern kann. Um z.B. die Hauptstärken von AppDynamics nutzen zu können, darf man Folgendes nicht vergessen…2. Definition von Business TransactionsDie Nummerierung ist Absicht. Die Definition und Konfiguration von Business Transactions sollte vor der Einrichtung eigener Dashboards und einer eigenen Alarmierung erfolgen, da man sehr wahrscheinlich dabei auf Business Transactions zurückgreifen wollen wird.Meiner Meinung nach sind Business Transaction das eigentliche Herzstück von AppDynamics und wahrscheinlich der meisten APM-Werkzeuge. Eine Business Transaction ist eine Aktion eines Nutzers der überwachten Anwendung, also ein Request an diese Anwendung, der verfolgt und aufgezeichnet wird, während er sich auf seinem verschlungenen Pfad durch die überwachte, verteilte Anwendung schlängelt. Als Ergebnis erhält man eine durchgehende Performance-Messung dieses Requests, in der die Java-Systeme aufgeführt sind, durch die er gelaufen ist, sowie die entfernten Services und Systeme die aufgerufen wurden.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/K9ZQz2c9QD255YvoIj1L"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/K9ZQz2c9QD255YvoIj1L" alt="anon Business Transaction" width="640" height="311" /></a> AppDynamics Snapshot of a Business Transaction</div> AppDynamics bietet eine Erkennung von Business Transactions out of the box, aber für viele produktive verteilte Anwendungen wird dies nur ein erster Ansatz sein. Oft sieht man zu viele Business Transactions und dennoch nicht diejenigen, die man konkreten Nutzer-Aktionen zuordnen kann. Je nach der zugrunde liegenden Architektur kann es einiges an Arbeit bedeuten, die richtigen Business Transaktionen zu identifizieren und sie geeignet einzurichten – manchmal benötigt man dafür die Kooperation sowohl von den Nutzern der Anwendung als auch von der Entwicklungsseite. Aber als Ergebnis der Mühen erhält man einen zuvor nicht gekannten Einblick in die innere Mechanik einer Anwendung – und eine direkte Verknüpfung zur Performance-Erfahrung der Anwender.Genau darauf möchte ich aufmerksam machen: Auf den Nutzen von Business Transactions sowie auf den notwendigen Aufwand, sie aufzuspüren und einzurichten. Die Definition sinnvoller Business Transactions ist auch eine Voraussetzung, um im folgenden Schritt den vollen Nutzen aus einem APM-Werkzeug zu ziehen:4. Performance Fehlersuche und Performance OptimierungEine der wichtigsten Eigenschaften von Business Transactions – und von APM-Werkzeugen insgesamt – ist ihre Unterstützung bei der Identifikation der Ursachen von Performance-Problemen. Wenn Nutzer einer Anwendung z.B. lange Antwortzeiten bei bestimmten ihrer Aktionen bemerken, ist es ohne APM häufig so, dass man bzgl. der Ursache im Dunkeln tappt und eigentlich nur raten kann. Kennt man dagegen die Business Transaction, die zu der betreffenden Nutzer-Aktion gehört, hat man einen direkten Ansatz, das Problem zu analysieren. Sehr oft kann man in wenigen Schritten zu der Java-Methode oder dem Aufruf eines entfernten Systems (Datenbank, Webservice etc.) gelangen, die die Performance-Schwierigkeiten verursacht.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YSlkREPhRgWHUv3kr4Mg"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YSlkREPhRgWHUv3kr4Mg" alt width="640" height="312" /></a> AppDynamics Waterfall View</div> <div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/I8zGqgdkRIKkzXbIuY2Q"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/I8zGqgdkRIKkzXbIuY2Q" alt="anon Hot Spots" width="640" height="312" /></a> AppDynamics Hot Spots</div> Dies ist eine recht technische Aufgabe. Man muss die Anwendung und die Systeme wirklich gut kennen und ein wenig Erfahrung in der Entwicklung von Java-Anwendungen ist ebenfalls hilfreich. Daher kann es durchaus eine Herausforderung sein, qualifiziertes Personal hierfür zur Verfügung zu stellen. Aber diesen Bereich von APM zu ignorieren, würde bedeuten, auch auf mit den größten Nutzen zu verzichten, den ein APM-Werkzeug bieten kann.Um alles zusammenzufassen: Nutzen Sie APM! Es wird Ihnen einen enormen Einblick in ihre verteilten Anwendungen verschaffen und kann die Verbindung zwischen Technik und Anwender-Erfahrung herstellen. APM ist wahrscheinlich sogar mächtiger, als Sie es sich zuvor vorgestellt haben. Aber dieses Potenzial hat seinen Preis. Höchstwahrscheinlich müssen mehr Zeit, Arbeitskraft und andere Ressourcen investiert werden und mehr Aufgaben erledigt werden, als anfangs geschätzt. Seien Sie sich dessen einfach bewusst!

Was es bedeutet, mit AppDynamics zu arbeiten – und anderen APM Werkzeugen

Nearly all of my 
colleagues at codecentric are either IT scientists or trained IT specialists. Despite the still severe shortage of skilled IT people in general, as a mathematician and career changer I remain an exception in our company. I am an exception at codecentric as a specialized tester, too. As is fitting for a performance-specialist like codecentric GmbH, my emphasis is on the exciting area of load and performance testing, a branch of non-functional testing.For me it was fascinating to realize that actually quite a lot of career changers can be found in IT testing. This is true already for functional testing. Naturally there are a lot of the usual IT people and department personnel at functional testing, but you can already find quite a few exotic professions, too, e.g. jurists. At a training course for load and performance testing in early spring 2008 in Cologne, a real zoo of professions was gathered: Besides me – a mathematician – there were a specialist in German studies, an agricultural scientist and the lecturer was a meteorologist. All women, by the way, and many had a PhD.In my eyes, IT testing is ideally suited for career changers. Certainly, specialized IT knowledge is desired and useful, but it is not necessary to have so deep and thorough a grasp of it as e.g. software developers. On the contrary, being sunk too deeply within the technologies can make one blind for other concerns. The main goal for any tester is to guarantee high quality. Now the adequate benchmark for high quality is not the blurred view of a software developer smitten with technology but the usefulness of the product for the user or the customer. To assess this usefulness, a certain distance to IT can be helpful. At least, one must be able to distance oneself mentally to look at and evaluate the product – the test object, as the tester says – from another point of view.At this point the qualities of the career changer come into play. I am convinced that these qualities more than compensate for the higher need for trainings and the initially slightly lower productivity of a career changer. As non-IT-insider it is easier for him to view the application or IT system not as an end in itself but in light of the task it is designed to fulfill. The career changer can draw on his experiences from other roles in other sectors. Because of that, he not only has another 
point of view and can think along other and broader lines, but he may even be able to create an extra value for a project out of the synthesis of his experiences. These capabilities are especially valuable for load and performance testing, as for the conception of such tests requirements and information from very different areas have to be collected, analyzed and connected. In this process, the load tester has to deal with the concerned departments, IT development and IT infrastructure, but quite often with marketing, sales, management and even external service providers, too. Here the career changer with his broad and diverse background clearly has an advantage.My studies of economathematics at the <a href="https://www.uni-augsburg.de/de/fakultaet/mntf/math/">University of Augsburg</a> were also a synthesis of different fields – mathematics, computer sciences and economics. And already in my first larger load testing project for an automobile insurance company I could make good use of exactly this same cross section of different fields. For my 
post graduate studies I went to the universities in <a href="http://math.berkeley.edu/index.php?module=mathfacultyman&MATHFACULTY_MAN_op=sView&MATHFACULTY_id=111">Berkeley</a> and <a href="http://www.minet.uni-jena.de/www/fakultaet/iam/l_althoefer.html">Jena</a> for further research in (combinatorial) game theory, optimization and operations research and the application of these sciences to real world problems.This is the background on which I want to write about and examine different aspects and topics of IT within this column. I plan to evaluate current developments or simply pick up what I observe in the day-to-day business here at codecentric. One large focus will surely be on the area of load and performance testing. But above all, I want to write from the outside – from the point of view of a career changer and mathematician.

From a Mathematician’s Point of View – Career Changers

What follows is in my view a typical scenario of one of the common curses of the performance tester. A new version of a test object finds its way into my hands. After some twiddling with it to get it running, I do a first quick test run. Somebody – development, architecture, project management, whoever – gets wind of it and is curious about the results. Defensively, I try a delaying tactic: “It’s the very first run. The test environment wasn’t completely built up. We have to do more tests. We must at first confirm the numbers before it makes any sense to discuss them.” My counterpart is getting more inquisitive. He insists to be aware of all of my objections and that he just wants to satisfy his curiosity. I finally give in and tell the numbers. Shortly thereafter, I regret it deeply. Like an avalanche, my little piece of information has gathered a gigantic mass in no time and like a boomerang it is coming full circle, heading straight back at me. What happens in cases such as this is often the result of an excessive believe in numbers. When something has been tested and quantified, there is a tendency to trust and rely on the results regardless of the circumstances.  A first quick measurement point is frequently discussed and given weight as if a complete and elaborate test series has been conducted. If the numbers are bad, this sometimes leads to hectic and strange activities like escalation, crisis meetings and maybe even management action. If they are unexpectedly good, a premature all-clear may be given.Even the performance tester himself may be prone to this type of mistake. I can speak out of my own experience here… Either because he wishes for or expects a certain result or simply because of routine he might be seduced to accept his own numbers as valid too quickly. Application systems and their configuration are often very complex, so it is easy to overlook or forget little changes with possibly large effects on the performance test’s results.The unshakable belief in the validity of numeric data can lead to many other inappropriate follow-ups. There is often a tendency to overanalyze a single data point, e.g. projecting possible future performance improvements or extrapolating the effects on a system n-times the size of the test system and so on. If later tests don’t confirm these projections, sometimes a frantic search for an assumed hidden cause of the “wrong” numbers is started, instead of realizing that incomparable things were compared in the first place. Also sometimes earlier numbers – correctly reported and documented – are rediscovered, but their context forgotten, resulting in similar wrong interpretations, conclusions and activities.Most of the time it is very hard to argue against this firm belief in numbers, to state that other tests are necessary to confirm them and that rather large variations are typical. Performance measurements as part of QA in software development are definitely not an exact science. As “getting things done” is normally the topmost priority, the preconditions for a controlled experiment as in the academic world are rarely fulfilled. Yet the results of such experiments are often handled as if they are fulfilled.As a performance tester, one has to be aware of the possible ramifications of the reported test results. Testing – especially performance testing – is done to replace uncertainty with knowledge, but careless handling of test results can easily lead to the opposite outcome. In my opinion, the foremost rule should be to only report data that one understands, can stick by and defend. One should always be aware of the reliability, scope, relevance and comparability of the numbers reported and should document these characteristics and attach them to the report. It is often a good idea to explicitly remark if a measurement is just a statement about one particular test-setup and not suitable for further projections.If a misinterpretation of test results occurs, one should act swiftly, clearly and forcefully to present the tester’s view of the numbers and their context in order to contain the possible damage. Numbers, once reported, tend to acquire a life of their own. Like a genie, it’s practically impossible to get them back into the bottle. Therefore, one should be very careful what to report and when to report.One final advice: As a performance tester, always remain skeptical about your own work and your own instincts. Other people should not blindly believe in test results and numbers and neither should the tester.

Believing in Numbers

My daily business is the performance of IT systems, java applications in particular. Performance testing and optimizing is done normally to assure compliance to the non functional requirements set for an application. Working on these topics day-in and day-out has the power to change the perspective of the tester on a lot of other things, too, and can make even such unpleasant affairs like a hospital stay quite interesting. In this column I want to share some of the strange associations I had – maybe it even helps to understand what the testing of non functional requirements is all about and why it is important.The system under test (SUT) in this particular case is of special importance to me: my optical receptors – my eyes. Their function should be obvious to all readers. In the technical words of wikipedia: Collecting and focusing light to form images, transforming them into electrical signals and transmitting them to the brain. The functional abilities of my eyes are already a little bit impaired, that’s why I carry glasses to aid in the focusing of light, thus enhancing my eyes’ functionality.But for my eyes to work properly in the long term, a non functional requirement is of prime importance: eye pressure or intraocular pressure (IOP). If the pressure of the fluid in the eye is too high for a longer period of time, the nerves get damaged, leading to a loss of eyesight-functionality – even unto complete blindness. Very roughly speaking, the eye pressure should be below 20 mmHg. As my eye pressure was always relatively high, I was using corresponding medication and had to check my eye pressure every three months. Fearing that my IOP might still be too high, my oculist sent me to an ophthalmic clinic to check and adjust my eye pressure. Thus my eyes became a true SUT for four days.Non functional requirements are not an end in itself. Without the functionality proper, any non functional glory is useless. Thus the first thing after I arrived at the test lab – the ophthalmic clinic – was to check the raw functionality of my eyes. For this end two tests were performed: First, my visual acuity was tested by letting me read ever smaller characters. Second, my visual field was tested to check if it was still as broad as it should be. Additionally, my eye-nerves were examined. Only after thus the actual state of the functionality of the SUT had been determined, the investigation of the non functional requirements could begin.The first step was to validate the IOP measurements. As I have written in my last blog “Believing in Numbers”, it is all too easy to delude oneself with phony numbers and the consequences can be grave. Especially when possible reasons are known that can invalidate measurement results, it would be irresponsible not to check for them. In the case of IOP, it is known that corneal thickness can influence the results of eye pressure measurements. Therefore my corneal thickness was measured, which revealed that in my case a rather large correcting subtrahend has to be subtracted from the basic IOP measurement results. Without this measurement validation and correction false conclusions would possibly have been drawn.Unfortunately, the testers – the doctors – managed to damage the SUT during the test for corneal thickness – the doctors called it just an “irritation” – impairing the basic functionality tremendously. As the SUT in question were my eyes I was indeed rather irritated and actually quite angry. Luckily the “irritation” dissolved after one day, restoring the basic functionality of my eyes back to normal. That’s why in IT whenever possible, we do not perform tests on the actual systems in production. We always try to build a separate test system. If the tester damages this system, production can still go on.After all these preliminary tests and measurements, the SUT finally entered the standard test-cycle, i.e. the IOP of my eyes was measured five times a day for three days in a row, This way one gets reliable numbers by repeating the measurements over and over again and one also gets a profile for eye pressure variations during the day. As every application performance tester knows: the load on the typical SUT is heavily different between 11 am and 6 pm.As the results of my IOP measurements were encouraging – not too high, especially when considering the correcting subtrahend – it was decided to perform a special stress test on the SUT. In a stress test you examine the behavior of the SUT under extreme conditions, in IT typically an especially huge load of simultaneous users or similar things. In the case of my eyes, I received some drops to widen the pupils of my eyes, which could result in a blockade of the outflow of the eye fluid, thus provoking a jump in the IOP. This didn’t happen, proving that my eye pressure remains within bounds even under certain exacerbated circumstances.Thus after four days in the test lab I was released with the relieving result of the test series that there is no acute danger for my eyes from the non-functional area of eye pressure. But for that state to remain, I have to continue my medication and do regular regression testing of the IOP at my local oculist. Something, which is advisable to every responsible system or application administrator.

From a Mathematician’s Point of View – The Eyes of the Tester

In between big news like the Irish financial crisis and the conflict on the Korean peninsula, two little news from the realm of the Bavarian school system went mostly unnoticed by the public. <a href="http://www.merkur-online.de/lokales/stadt-muenchen/computer-chaos-berufsschulen-1009592.html">“Computer-Chaos an den Berufsschulen”</a> from November 16th and <a href="http://www.nordbayern.de/nuernberger-nachrichten/region-bayern/technik-stoppt-abi-umfrage-1.320697">“Technik stoppt Abi-Umfrage”</a> from November 17th, both from local Bavarian newspapers. Both messages demonstrate the scope and the possibly crushing effects of load and performance problems in modern computer systems, a topic that finds its way into the headlines of the mainstream media only very rarely.“Computer-Chaos an den Berufsschulen” (“Computer Chaos at Berufsschulen (~tertiary colleges)”) tells about the modernization of the “pedagogical network” of the city of Munich that went terribly wrong. After the upgrading, the systems starts slowing down after just two or three students log in and sometime thereafter stops working altogether. Some 7.500 students depend on this system for their training with a variety of professional software, it will even be used for their examination tests. If nothing else works, a return to the old system will be necessary.“Technik stoppt Abi-Umfrage” (“Technology stops examination survey”) covers the breakdown of a public website to survey the study plans of Bavarian high-school graduates. The site crashed under the onslaught of some 95.000 students within a couple of days. Now the idea is to abandon the plan of a complete survey and to do just some random sampling.These short news messages demonstrate that load and performance problems can occur in very different setups: a large, but local application-network in one case, a website in the other one. In both cases a load that is too high leads to performance problems or outright system failure. Also in both cases, the load induced problems are mission-critical and – as publicly visible failures – especially painful. Quick solutions are costly or even unavailable.As no more details about these two cases are given, it is of no use to speculate about the concrete reasons for these performance issues. Thus I want to share some general thoughts about possible acts and omissions that can lead to performance or load problems. The biggest and most obvious mistake is not to plan any load and performance tests at all. Given the possibly devastating effects of load and performance problems, it is plainly irresponsible not to address these risks. While theoretical considerations about load and performance can be a useful first step, unknown relations and surprises in practice are rather the norm than the exception. Therefore, in my opinion, practical load and performance testing is an indispensible part of every IT project.Even if load and performance tests are planned, they are often scheduled towards the very end of the project, after the completion of the development phase and maybe even after functional testing. Quite frequently then, due to budget limitations or time delays, performance testing is reduced or even cancelled, thus re-inserting enormous risks into the project. Anyway, the best course of action, according to the experiences we have made at codecentric, is to incorporate performance testing from the very start of a project. As soon as there is some runnable chunk of code, it can be checked and tested for performance issues. As soon as even rudimentary use-case functionality is available, it can be load tested.In the end it is production that matters. Thus another huge risk is a wrong test concept. The test cases and the load should be as realistic as possible to prevent unwelcome surprises. The same holds true for the test environment – testing hardware, software and their configuration – which has to be as near to the production environment as possible. Ideally, the environment for load and performance testing will be the later production environment itself.In some cases it can be very hard to come up with a realistic load prognosis, for example for new websites with no previous experiences about customer or user attraction. Then the tests have to cover wide ranges of possible loads and their distribution over time. Additionally, the system should be flexible and scalable. These properties have to be tested, too. Of course, extensive stress testing and a flexible, scalable system are good ideas anyway, even if concrete load prognoses do exist.Whatever the reasons for the performance problems in these recent Bavarian cases may have been, it is always costly to gain this knowledge by real-life experience. Investing the necessary time and resources into preliminary load and performance tests can help to minimize and handle these risks.

From a Mathematician’s Point of View – Load and Performance Issues in the News

My company, codecentric AG, has a strong disposition towards open source tools and solutions. Therefore, it is quite natural that for me as a Java performance specialist, the load testing tool of choice is <a href="http://jmeter.apache.org/" target="_blank">Apache’s JMeter</a> .Let me just state something right at the beginnig of this blog post: This is no comprehensive overview over JMeter, its features and limitations. Instead, this is a very personal view on this tool. A settlement of an overdue account, if you want to call it so. After some years in which I was mainly involved in performance optimizing and performance monitoring, I was working with JMeter in my latest customer project again. This time, JMeters JUnit-sampler was the main interface for load generation whereas before I was mainly working with the HTTP sampler.In principle, to write and execute load tests is an easy task with JMeter. When – as in our recent project – you want to use already existing functional JUnit tests to generate load, you just have to provide these JUnit tests as a jar-file to JMeter. After this you use JMeter’s JUnit sampler to choose the corresponding test class and test method. A JMeter thread group serves as bracket around the JUnit samplers. Within the thread group you configure the load (number of parallel threads) and the duration of the test. By and large, this is it. Press “run” and execute your test, called a “testplan” in JMeter. If you want more details, the <a href="http://jmeter.apache.org/usermanual/index.html" target="_blank">user manual</a> will provide plenty of them in easily understandable form. It is lacking some explicit examples especially in the regex section, but all in all it is an excellent documentation.Somehow I had forgotten about the typical feeling of working with JMeter. But JMeter brought back this feeling very, very fast. What I had forgotten was that JMeter – as any other human being depending on its form of the day – can and does behave really moody, sometimes even bitchy.Want some examples?<ul><li>The error-messages of the JUnit sampler are quite expressive – normally. But beware of any discrepancy to what JMeter expects of the constructors of the JUnit test class. You just get a scant “failed to create an instance of the class” message, then JMeter snaps shut and leaves you alone in your misery. Neither JMeter (nor Google in this case) will help you at all. Well, maybe this can help: JMeter seems to expect the standard constructor as well as a constructor with a single String argument. Additionally, if any libraries are used within the constructors (e.g. jlog), JMeter needs them, too.</li><li>Completely incomprehensible behavior happened when I used JMeter’s “Regular Expression Extractor” to extract variables from the response of the last sampler. The content of these variables was as fleeting as a bubble in a thunderstorm. I was able to use it in the very next sampler. The content was already gone with the wind in the next sampler thereafter, It also was not transferable to other variables or structures. I tried a whole bunch of different workarounds, none was working.</li><li>If a JMeter testplan contains several JUnit samplers, JMeter adds suspense to your work by sometimes changing the test classes and test methods of the other samplers to the class and method of the current JUnit sampler. I still have no idea what triggers this particular bug.</li></ul>Pretty features like these help to keep your awareness up while working with JMeter. In other words: I developed some sort of paranoia, never trusting JMeter to do what it ought to do. They also have the side effect of making JMeter the default suspect if something goes wrong.Some other points are merely impractical, e.g. directory paths. JMeter has to read and write many files: testplans, test parameters, result files. The default directories for these files are different, though. Sometimes it is the same directory as the testplan, sometimes the JMeter-bin directory, with no apparent logic behind it. Also, when running tests through the JMeter GUI instead of scripts or the command line, one often encounters the urge to restart the GUI for every test run. This is necessary to ensure that JMeter does not remember anything from the last test and also to restart the JVM in a typical JUnit test scenario, where everything is running in just the JMeter-JVM: JMeter, the JUnit test classes and sometimes even the Java system under test.O.k. – so JMeter is a crap tool. But why do I love it, nevertheless? Well, JMeter is dependent on next to nothing, is installed easily, open source and free of charge. And on top of all that it offers an astounding flexibility. The HTTP sampler is probably the most widely used, as it is best suited to test web applications from the user’s point of view. Other samplers like the JUnit sampler described in this blog operate at a much lower, technical level. At this time, there are about twenty different samplers in JMeter for a lot of various protocols.Another useful little bonus is the so called performance plugin for Jenkins, which is de facto a JMeter plugin. At codecentric, we want to automate as much as possible, performance tests not excepted. With the performance plugin, JMeter is suitable even for that.And if all this is not enough for your taste, you can directly hack the JMeter testplan (which is just an xml-file) – but beware of JMeter’s moods: not all seemingly obvious modifications are accepted – or even write your own add-on code.JMeter reminds me of something a friend told me about his first car – a little French one. “I always wanted a car with a character. And this car has a character: A mean one, indeed, but it has character!” He loved his car.All in all, will I use JMeter again? Most definitively. JMeter helps you to get the job done, trains your stress resistance potential and finally: it teaches humbleness.

From a Mathematician’s Point of View: JMeter – Beloved Crap Tool

Man vs. MachineThis fall will see a first in the realm of computer go – a match between a go program and a top European go player on even terms, i.e. without a handicap. And codecentric will be the sponsor of this event. So this will not be your typical codecentric blog post – no hints or strategy around java, agile development, software quality or similar topics. Instead I want to speak about the game of go and computer go – the one topic about as ancient as it gets for games, the other one from the forefront of technology. Go, the Last FortressYou may have heard of the east asian board game go being something like the last frontier in computer gaming, the one classic game where humans still outplay even the strongest computer programs. In a certain sense this is true. Chess was conquered in 1997 by the epochal win of IBM’s Deep Blue against then world champion Garry Kasparov. Today, a standard chess program on a typical notebook can probably beat the human world champion. In checkers and backgammon humans are hopeless contenders, too.For go it is another matter. The game mechanics are extremely simple, as a look at the rules reveals (<a href="http://www.usgo.org">www.usgo.org</a> ). But if you have never played go before and just read the rules, you are probably baffled at the question when the game ends and how to discern the winner. This gives a first hint about the complexity of go: It is quite hard to come up with a good, heuristic algorithm to evaluate a go position – who is ahead and by how much? Another reason why it is so difficult to apply the traditional game tree search algorithms to go that work so well for chess is the sheer size of the go board with its 19×19 intersections. On average, there are 25 different possible moves in a given chess position. In go, you start with 361 and drop slowly down to say 100 or 50. A game of chess lasts for something like 80 (half) moves on average, a game of go for 200 to 300. All this means that there are a lot more numbers to crunch in go than in chess. Accordingly, go programs could look ahead far less than their chess relatives, and up to a few years ago the average go player could easily defeat any go program.Monte Carlo AlgorithmsEnter Monte Carlo methods. One other possible way to come to grips with the vast game tree of go is to replace the knowledge-based classical game-tree search with chance, using random moves to play out certain positions multiple times and determine this way which move might be most promising. As this is completely contrary to the way we humans play and think about go, this approach was largely neglected for a long time. But in the last couple of years, go programming has made enormous progress using Monte Carlo methods. The best programs begin to approach top amateur level.Challenging Top Human PlayersSince 2007 the University of Electro-Communications in Japan hosts the “UEC Cup Computer Go”, something like an inofficial world championship of go programs. Until the recent advances with Monte Carlo methods, computer go was not taken very seriously in the go world. But since 2013, the Nihon Ki-in, the most prominent Japanese professional go players association, agreed that professional go players will play against the strongest contenders of the UEC Cup. For the last few years, the two strongest go programs have consistently been the Japanese program “Zen” and French programmer Rémi Coulom’s “Crazy Stone”. In the play-offs against professional go players in 2013 and 2014, the programs were given a four stone handicap. To offer some perspective: Only an already really strong amateur could hope to beat a professional go player with such a handicap. While Zen was defeated both years, Crazy Stone managed to eke out wins against the professionals, leaving open the question how big the gap in strength between the best go programs and the professional level really is.codecentric challenge 2014In a few weeks, the “codecentric challenge 2014” will pit Crazy Stone against Franz-Josef Dickhut in a five game match, played online on the KGS go server. Dickhut is an amateur 6 dan and eleven times German go champion. In the realm of amateur go, it doesn’t get much stronger than this. No stronger player has ever before agreed to play a serious competition against a go program on even terms, without a handicap. That the winner will not be decided in a single game but in a best-of-five match, gives the challenge additional weight. The first game will be played on Saturday, October 4th, with the other games following on a weekly schedule until one side has registered three wins.The match was proposed and organized by Prof. Ingo Althöfer of the University of Jena, Germany, who is active in researching the mathematics of games and game programming for some decades now. codecentric on the other hand has agreed to sponsor the event and host the website of the competition. The link to the website will be published here in time before the match begins.I hope I have been able to awaken your interest in this fascinating game and the oncoming human-computer duel. Stay tuned!

For many years now I have been working with Application Performance Management (APM) tools in the Java realm. Compared to other performance analyzing tools as for example profilers, APM tools are monitoring as well as analyzing tools. They provide a better overview over distributed applications and can offer a direct connection between user actions, users’ performance experiences and technical processes. From my experience I believe there are some frequent misperceptions about what lies ahead in terms of preparatory work and how to best use an APM tool in order to fully benefit from it. In this blog I want to illustrate these misperceptions as well as the tasks connected with an APM tool.My experience is foremost with AppDynamics, but also with Dynatrace, monitoring, analyzing and optimizing the performance of Java applications. While both tools use at least in part fundamentally different concepts, their appearance, use and value from the user’s point of view is similar. So while I will be referring to AppDynamics – and using examples from it – for the rest of this article, the issues are valid for Dynatrace and most likely for other APM tools, too.1. Set up the InfrastructureIn order to work with AppDynamics, you have to install a controller, the central unit that collects, analyzes and displays all data. Depending upon the number of systems you want to monitor and the traffic they generate, you have to size the controller accordingly, i.e. supply sufficiently sized hardware for the controller to fulfill its duties. AppDynamics agents must be deployed on the systems under supervision and all components must be configured to communicate with each other.As these processes are necessary prerequisites before one can start working with an APM tool, it is obvious that manpower, time and hardware have to be invested to get the new tool up and running.In the case of AppDynamics, this is all you have to do in order to see this shiny and flashy – and indeed immensely useful – central dashboard, the flow map:<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/SwmH8NaDQmep7yDW2D1k"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/SwmH8NaDQmep7yDW2D1k" alt width="640" height="322" /></a> AppDynamics Main Dashboard</div> Just after installing the APM tool, most of the architecture of your application, often something of a mystery beforehand, lies transparently before your eyes. It seems as if the work is already halfway done. The only thing left to do is…3. Dashboards and AlarmsThe main use case of an APM tool is to monitor the performance of an application. You want comprehensive dashboards that show you at a glance how your application is performing. AppDynamics provides excellent dashboards out of the box which do just this. One example is the dashboard above, just focus on the graphs and tables on the right and bottom sides of the screen which provide the most relevant performance information. Additionally, AppDynamics offers many possibilities to construct custom dashboards according to your own needs and wishes.AppDynamics also comes with a very useful set of rules to throw events in case of performance issues. Most users will want to fine-tune these and add their own rules to implement a fitting alerting system.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/EM3qKOf3Tw6lyMctuYuN"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/EM3qKOf3Tw6lyMctuYuN" alt="Health Rules" width="525" height="381" /></a> AppDynamics Health Rules</div> After this it’s easy to think that everything is set and done – the APM tool is up, running and providing all the performance information about the application one needs to know and warns when things are going astray.Very wrong. Stopping here, means to ignore most of the value an APM tool can provide. In order to unlock the main powers of e.g. AppDynamics, you have to…2. Define Business TransactionsThe numbering, by the way, is no error. This step should be undertaken before you build your custom dashboards and define your alerting rules as you will most likely want to incorporate Business Transactions in your dashboards and alarms.From my point of view, Business Transactions are the true centerpiece of AppDynamics and probably most APM tools. A Business Transaction is the action of a user of an application, a request against the application, which is traced and tracked as it follows along its winding path, meandering through the systems under surveillance within a distributed application. As result you get an end-to-end performance measurement of the request, listing the Java-systems it went through including the exit points where remote systems and services were contacted.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/K9ZQz2c9QD255YvoIj1L"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/K9ZQz2c9QD255YvoIj1L" alt width="640" height="311" /></a> AppDynamics Snapshot of a Business Transaction</div> AppDynamics offers Business Transaction detection out of the box, but in many productive distributed applications this out of the box detection will be just a starting point. It is quite normal that one sees too many Business Transactions but at the same time not the right ones that can be connected to user actions. Depending on the architecture, identifying useful Business Transactions and configuring them properly can be some work, sometimes necessitating cooperation from the application users as well as of development. But the result will be an unprecedented insight into the inner mechanics of one’s application – and its connection to the performance experiences of the application users.Therefore I want to enhance the awareness – of the benefits of Business Transactions as well as of the effort necessary to detect and configure them.Having defined good Business Transactions is also a prerequisite to make full use of your APM tool in the following tasks:4. Performance Troubleshooting and Performance OptimizationOne of the most important benefits of Business Transactions – and APM tools as a whole – is their support in pinpointing the real causes of performance problems. Without APM, it is rather common that when application users note performance problems with certain of their user actions, the only available option is to guess the causes as one is simply left in the dark. With AppDynamics, if you know the Business Transaction that corresponds to the user action in question, you have a direct handle to the problem. Very often you can drill down straight to the Java method or the call to a remote system (database, web service, etc.) that is the root of the performance troubles.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YSlkREPhRgWHUv3kr4Mg"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/YSlkREPhRgWHUv3kr4Mg" alt width="640" height="312" /></a> AppDynamics Waterfall View</div> <div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/I8zGqgdkRIKkzXbIuY2Q"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/I8zGqgdkRIKkzXbIuY2Q" alt="anon Hot Spots" width="640" height="312" /></a> AppDynamics Hot Spots</div> This is a rather technical task. One must know his application and systems quite well and at least some experience with developing Java applications is helpful as well, so providing qualified personnel may not be that easy. But ignoring this area of APM just means to forego one of the biggest profits an APM tool can offer.To sum it up: By all means, go and use APM! It will give you an enormous insight into your distributed applications, including the connection between the technical side and the user experience. It is probably even more powerful as you have imagined beforehand. But this power comes at a price, as perhaps more time, manpower and resources have to be invested and more tasks have to be accomplished than estimated beforehand. Just be aware of it!

What you have to deal with when you work with AppDynamics – or other APM tools

<a href="http://senseis.xmp.net/?EuropeanGoCongress" target="_blank">The European Go Congress (EGC)</a> is by far the largest Go event in Europe. It has been held yearly since 1957, usually in a different country every year. <a href="http://www.egc2017.eu/" target="_blank"> In 2017, the EGC</a> came to Germany once more, organized by the <a href="http://dgob.de/" target="_blank">DGoB, the German Go Federation</a> . The venue was located in Oberhof in Thuringia in the midst of a beautiful landscape best known for winter sports, especially ski jumping and biathlon.The main parts of the EGC are the European Go Championship tournament and an open main tournament. These two principal competitions are flanked by numerous smaller tournaments and side events, e.g. lectures by Go professionals. The EGC 2017 was the largest in history with well over 1.000 attendees. As codecentric was sponsoring this year’s EGC, in particular the Rengo tournament (more about this later), I attended as official representative of the sponsor. My codecentric colleague Thomas Jaspers was at Oberhof, too, and has written down his own impressions of the EGC <a href="/wissens-hub/blog/besuch-beim-europaeischen-go-kongress-oberhof" target="_blank">in this blog post</a> – German only.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Te2CbDYS4KSRpJHSu8Nv"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/Te2CbDYS4KSRpJHSu8Nv" alt="European Go Congress 2017" width="700" height="646" /></a> Georg Snatzke, Dr. Michael Marz, president of the DGoB, Thomas Jaspers</div>Where now, one might ask, is the connection to codecentric and the world of IT? Well, Go and IT are sort of natural companions. For both, one needs clear, logical and combinatorial thinking and discipline. Thus it is not surprising that many Go players work in IT. Add to this that Go used to be a supreme challenge for AI. Just two years ago the seemingly unshakable truth was human superiority over AI in Go. My old boss at the University of Jena, Prof. Ingo Althöfer, had the idea to document the progress of computer Go to a professional level – expected to be long and slow back then – by means of a yearly competition. Ingo suggested a best of five matchup between strong German amateur players and powerful Go programs and asked if codecentric would sponsor such an event. Thus, in 2014, the codecentric Go challenge was born.But DeepMind aka Google had other, more immediate plans for computer Go. In spring 2016, DeepMind’s program AlphaGo smashed old certainties about human predominance in Go to bits and pieces with its victory over 9 dan professional and Go legend Lee Sedol. Since this historic event nothing is as it was before in the world of Go. The Go-world-shattering hand of AlphaGo permeated the EGC 2017 thoroughly. Books, lectures, talks – AlphaGo was omnipresent. The organizers even managed to win Fan Hui to give two talks about the games of AlphaGo. Fan Hui is a multiple European Go champion, the first victim of AlphaGo in fall 2015 and now a representative for DeepMind.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/aJViQOYSkynwhnOrfIjA"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/aJViQOYSkynwhnOrfIjA" alt="Fan Hui presenting AlphaGo" width="700" height="394" /></a> Fan Hui presenting games of AlphaGo against itself</div>But the EGC 2017 demonstrated another, much more profound influence of AlphaGo. It changed the way Go players – amateurs and professionals alike – think about their game. Literally centuries of knowledge what constitutes good and bad play went straight to the trash can. But in many cases the moves of AlphaGo are simply beyond human comprehension. Even professionals just look look baffled at them and can only utter “I don’t understand this”. One could witness this countless times in Oberhof.But not understanding why AlphaGo’s moves work does not prevent human players from trying and experimenting with them. The “AlphaGo style” of playing Go has conquered the Go boards everywhere and Oberhof was no exception. Moves that would have made strong players cringe or been attributed to bloody amateurs just two years ago were seen at all levels.In the wake of AlphaGo, two exhibition matches between strong computer Go programs and professionals were played at Oberhof. They were organized by Prof. Althöfer, and it was Ingo, too, who asked codecentric to sponsor the EGC in Oberhof. codecentric decided to sponsor the Rengo tournament of the EGC and thus I got my ticket to visit another European Go Congress.<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jTczCc3QIGU44OrJZzKQ"><img src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/jTczCc3QIGU44OrJZzKQ" alt="Prof. Dr. Ingo Althöfer, Georg Snatzke" width="700" /></a> Prof. Dr. Ingo Althöfer, Georg Snatzke</div>Rengo is a team variant of Go, in this case three players per team. They take turns in making their moves and are not allowed to discuss their plans or communicate in any way except with their moves on the Go board. Naturally, this leads to a completely different type of game. The Go skills of single players are still important, but to cooperate successfully as a team, other faculties are needed, too. As the Rengo tournament of EGC 2017 was played with full handicap (adjusted by certain bonus and minus points), all teams had in principle the same chance to win the competition. Being in harmony as a team was the deciding factor, not mere playing strength.Fitting to the size of the EGC itself, the Rengo tournament with 69 participating teams also was the biggest one anyone could remember. Therefore the five planned rounds did not suffice to determine a winner. A final, sixth game between the two teams, KLT and SAT, with 5 wins and no losses was necessary. Team KLT, consisting of a 7 dan, a 5 dan and a 1 dan player, had a 4 dan rating on average and had to give three handicap stones to 1 Kyu rated team SAT, consisting of a 5 dan professional, a 7 dan and a 15 kyu.This final game was fascinating to watch. It was not the professional player Zhang Tao, who by the way won the open main tournament of the EGC, or the other high dan players who dominated this final match. Instead, it revolved around the weakest player, Team SAT’s 15 Kyu Anna Razymova from Ukraine. Team KLT tried to exploit her weakness by posing difficult problems for her on the Go board to solve when it was her turn to play. Her SAT team mates, on the other hand, tried to keep the game simple and calm. Sometimes they even sacrificed something by playing actually bad forcing moves just not to give team KLT the time to pose hard problems to Anna. In the end, team SAT’s strategy paid off as team KLT was unable to overcome the three stone handicap.At the end of the game I raised to applaud both teams. As representative of the sponsor I also had the privilege to hand over the cups and medals at the central prize-giving ceremony.I hope that codecentric’s commitment to Go will continue for many years to come. Nevertheless its format needs to be revised: See you at the next codecentric Go challenge!<div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1aO6j2zRK268DbWnj19A"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/1aO6j2zRK268DbWnj19A" alt="The Rengo final" width="700" height="394" /></a> The Rengo final, KLT vs. SAT.</div><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wLk1QRtSLWQu8kShcVuA"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/wLk1QRtSLWQu8kShcVuA" alt="Team KLT, Team SAT" width="700" height="394" /></a> Team KLT (left; from back to front: Kim Do Hyup, 7 dan, Korea, Lee Heng-Cheng, 1 dan, China, Thomas Danel, 5 Dan, France) vs. Team SAT (right; from back to front: Zhang Tao, 5 dan professional, China, Sun Peifang, 7 dan, China, Anna Razymova, 15 Kyu, Ukraine)</div><div><a href="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/5jsA9dKbS8aPBHr8jQtM"><img loading="lazy" src="https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/5jsA9dKbS8aPBHr8jQtM" alt="Winners of the codecentric Rengo tournament" width="700" height="485" /></a> The winners of the codecentric Rengo tournament: Sun Peifang, Anna Razymova, Zhang Tao.</div>

codecentric at the European Go Congress 2017

Delivery Managerin

Head of Services

Location & Event Manager

Agile Coach 

Haustechnik

## *Wie wir unsere Anwendung in einem Bruchteil der Zeit bereitgestellt und dabei 100 % der Kosten eingespart haben.*

Unser Team, bestehend aus einer Gruppe erfahrener Software-Entwickler ohne Cloud Vorkenntnisse, wollte unseren OCPP-konformen EV-Ladesäulen-Simulator (*Electric Vehicle Charging Station Simulator, EVCSS*) öffentlich bereitstellen, damit Erstanwender und andere Interessensgruppen ihn problemlos testen können.
Klingt einfach genug, oder? Das haben wir uns auch gedacht. Und wir haben das Ticket „Cloud-Deployment“ optimistisch in unseren aktuellen Sprint gezogen, weil wir ein paar zusätzliche Tage hatten, um daran zu arbeiten.

## Größe M sollte passen, oder?

Bei unserer ersten Einführung in AWS wurden wir mit einem Admin-Panel und einer beträchtlichen Auswahl an Diensten begrüßt und befanden uns mitten in der Paralyse durch Analyse. Was brauchen wir eigentlich? Es war schwierig, die Beste oder überhaupt eine Möglichkeit zu finden, unsere einfache Client-Server-Anwendung bereitzustellen. Also haben wir einen Spezialisten engagiert, jemanden mit AWS-Erfahrung, der uns möglicherweise dabei helfen sollte, etwas Licht in den Tunnel voller Akronyme und ähnlich klingender Dienste (*similar sounding services*, steht S3 etwa dafür?) zu bringen.

## Bei Risiken und Nebenwirkungen, wenden Sie sich an den Cloud-Spezialisten.

Wir haben ein paar Stunden damit verbracht, unsere Anforderungen zusammenzufassen und die verschiedenen Kompromisse zwischen einem Service und dem anderen besprochen. Wir haben Kästchen und Pfeile gezeichnet, um zu visualisieren, wie unser künftiges Deployment aussehen und sich verhalten sollte. Die ganze Zeit jedoch hatte ich einen Gedanken im Hinterkopf: Muss das wirklich alles so kompliziert sein?

Wir haben keine hohen Anforderungen. Wir möchten lediglich, dass unsere Web Anwendung für unsere Stakeholder erreichbar ist. Bonus: Ein öffentlicher Zugang, um weitere Interessenten dafür zu gewinnen. Warum sind wir also am Ende bei rund zehn Diensten gelandet, die auf nichttriviale Weise miteinander verbunden sind? Ist AWS für uns hier wirklich die beste Wahl, wenn das Ergebnis eine hochkomplexe und wahrscheinlich teure Infrastruktur ist, nur um ein paar Leuten unsere Anwendung zu zeigen?

## fly.io zur Rettung

Ich bin fest davon überzeugt, dass gute Produkte und Dienstleistungen ihre Nutzer dort abholen sollten, wo sie sind. Als Cloud-Neuling hatte ich nicht das Gefühl, dass AWS mich dort abholt, wo ich aktuell stehe. Ich habe mich also nach etwas anderem umgesehen. In [einem Podcast](https://podcasts.apple.com/de/podcast/xe-iaso-on-fly-io/id120906714?i=1000659542270) habe ich das erste Mal von fly.io gehört. Deren Slogan:


> A Public Cloud Built For Developers Who Ship
>
> …
>
> Deploy your App in 5 minutes.


Hey, das bin ich! Und genau das hatte ich im Sinn, als wir unsere Cloud-Deployment Story geschätzt haben. Wie kann ich loslegen? Nun, natürlich mit dem Getting Started Kapitel in der Dokumentation! Und da ich auf der Suche nach einem schnellen Einstieg war, um herauszufinden, ob wir statt AWS doch etwas einfacheres verwenden konnten, habe ich mich an den [Quickstart](https://fly.io/docs/getting-started/launch/) Guide gehalten.

## Nur 4 Schritte bis zum Abflug

1. Installiere das `flyctl` Befehlszeilentool
2. Erstelle ein Konto mit `fly auth signup`
3. Konfiguriere das Deployment mit `fly launch` aus dem aktuellen Projekt heraus
4. Stelle die Anwendung mit `fly deploy` bereit

Das war alles, was zur Bereitstellung unserer Anwendung auf fly.io erforderlich war. Ich war begeistert. Konnte es wirklich so einfach sein?

## Kannst du mich hören?

Es stellt sich heraus, dass `flyctl` unsere Client-Server-Anwendung zwar erkannt und den Docker-Container gefunden hat, jedoch keine WebSocket Verbindung zwischen Client und Server konfiguriert hat. Außerdem haben wir noch keinen API-Endpunkt, mit dem sich überprüfen lässt, ob unser Server tatsächlich betriebsbereit ist. Nach kurzer Recherche in der Dokumentation (was eine äußerst befriedigende Erfahrung war) und der Implementierung des notwendigen Endpunkts zur Überprüfung der korrekten Bereitstellung unseres Servers funktionierte alles wie es sollte. Und das Beste daran: Es war noch nicht einmal Mittag.

## Endlich Glückseligkeit.

Die Bereitstellung dauerte weniger als 4 Stunden und das Arbeiten mit der Dokumentation hat wirklich Spaß gemacht. Ich hatte immer das Gefühl, auf dem richtigen Weg zu sein, was ich nach der kurzen Begegnung mit dem Angebot von AWS nicht sagen konnte. Meine Kollegen haben währenddessen in den sauren Apfel gebissen und die Bereitstellung auf AWS weiter verfolgt. Wir haben jetzt also zwei Instanzen unserer Anwendung. Eine davon läuft netterweise kostenlos (da fly.io keine Rechnungen für Deployments stellt, die Kosten von weniger als 5 Euro pro Monat verursachen). Für die andere Instanz mussten wir uns eine Genehmigung einholen, da die anfallenden monatlichen Kosten bereits am Anfang über 100 Euro lagen, ohne dass nur ein Benutzer die Anwendung je gesehen hatte.

Ich bin mir sicher, dass unsere AWS-Instanz noch nicht kostenoptimal ist. Außerdem bin ich mir bewusst, dass AWS die reifere und flexiblere Plattform ist. Es gibt schließlich Gründe, warum sie der Marktführer in diesem Segment sind (und das schon seit geraumer Zeit). *Aber wenn ich meine nächste Anwendung entwickle und sie potenziellen Nutzern so früh wie möglich im Entwicklungs-Lebenszyklus zeigen möchte, werde ich auf jeden Fall wieder auf fly.io zurückgreifen.*

Wir haben unsere SaaS-Anwendung auf fly.io deployed (und dabei richtig gute Erfahrungen gemacht).

## *How we deployed our application in a fraction of the time while saving 100% of the cost.*

Our team, a bunch of experienced software engineers without prior contact to cloud deployments, wanted to deploy our OCPP-compliant EV Charging Station Simulator (EVCSS) publicly, so that early users and other stakeholders can easily test it.

Sounds simple enough, right? That's what we thought. And optimistically pulled the “Cloud Deployment” Issue in our current Sprint because we had a couple of additional days to work on it.

## Let's make it a size M, just to be sure…

On our first introduction to AWS, we were greeted with an admin panel, a considerable selection of services and found ourselves right in the middle of choice paralysis. What do we actually need? It was difficult to find the best or even any way to deploy our simple client server application. So we enlisted a specialist, someone with prior experience with AWS and cloud deployments, who may shed some light on the path we couldn't see in the haze of three-letter acronyms and similar-sounding services (is that what S3 stands for?).

## When in Doubt, Ask the Cloud Whisperer

And we spent a couple of hours communicating our needs and discussing the tradeoffs of one service vs. the other. We drew boxes and arrows to try to visualize how our future deployment would look and behave. All the while, a thought crept up in the back of my mind: Does it have to be so complicated?

We don't have complicated needs. We just want our static single-page application to be available to our stakeholders. Bonus: A public address we can direct potential users to. So why did we end up with around 10 services that interconnect in intricate ways that no one, apart from the cloud engineer, knew anything about? Is AWS really the best choice if the result is a highly complex and likely expensive infrastructure, just so we can invite a couple of people to test our app?

## Enter fly.io

I have the deep-seated belief that good products and services meet their users where they are. As a cloud novice, I did not see AWS meeting me where I am. So I tried something different. I remembered hearing about fly.io on [a podcast](https://podcasts.apple.com/de/podcast/xe-iaso-on-fly-io/id120906714?i=1000659542270) and visited their site. Their tagline:

> A Public Cloud Built For Developers Who Ship
> ...
> Deploy your App in 5 minutes.

Hey, that's me! And that's precisely what I had in mind when estimating our cloud deployment story. So how to get started? Well, with the Getting Started docs, of course! And as I was looking for a quick start to find out whether this could replace our plans for AWS, I started with the [Quickstart](https://fly.io/docs/getting-started/launch/) guide.

## Only 4 steps until take-off

1. Install the `flyctl` command-line tool  
2. Create an account using `fly auth signup`  
3. Configure your deployment using `fly launch` from inside your project  
4. Deploy the application using `fly deploy`

That was everything required to deploy our application on fly.io. My mind was blown. Could it really be that easy?

## Can you hear me?

It turns out that `flyctl` was able to detect our client and server application and found our docker container, but wasn't able to configure the WebSocket connection between client and server correctly. Also, we didn't have a health-endpoint yet to validate our server is indeed up and running. So after a bit of reading through their documentation (which is a highly rewarding experience, as far as reading documentation goes) and implementing the necessary endpoint to validate our app is deployed correctly, everything was working as it should. And the best part, it was not even lunchtime yet.

## Finally, Bliss.

The deployment took less than 4 hours and working through the documentation was actually enjoyable. I always felt like I was on the right track, something I never experienced in the brief encounter with AWS and its offerings. Meanwhile, my colleagues bit the bullet and powered through the deployment on AWS. So we now have two instances of our application. One is basically free (as fly.io doesn't charge for deployments that stay below 5 Euros per month), the other one needed approval from Finance, as the accrued monthly cost was already above 100 Euros without any users actually visiting it yet.

I'm sure our AWS deployment is not really cost-optimal yet. Also, I acknowledge that AWS is the more mature and flexible platform. There are certainly reasons why they are the dominant player (and have been for quite some time). *But when I'm building my next application and want to show it to potential users as early as possible in the development lifecycle, I will definitely go with fly.io again.*

We deployed our SaaS Application on fly.io (and it was great).

Senior Software Engineer & GenAI Consultant

People Lead / Service Lane Lead 

Der Wiedereinstieg ins Berufsleben nach der Elternzeit kann eine gewaltige Hürde sein, besonders wenn man, wie ich, eine 100% alleinerziehende Mutter mit einem Krippenkind ist und das vorherige Unternehmen in der Zwischenzeit abgewickelt wurde. Die Jobsuche fühlte sich an wie eine Zeitreise: Ich interviewte mit den Vorstellungen aus der Zeit vor meinem Kind, um dann schnell festzustellen, dass sich meine Möglichkeiten und Prioritäten verschoben hatten. 

### Auf was es plötzlich auch ankam

Natürlich waren mir auch nach meiner Elternzeit eine anspruchsvolle Aufgabe und eine Unternehmenskultur, die zu mir passt, sehr wichtig.  

Doch plötzlich musste ich aber bei der Jobsuche eine Reihe weiterer Faktoren bedenken, z.B.:  “Wie lange dauert der Weg zwischen Krippe und Arbeitsplatz? Schaffe ich es rechtzeitig, vor der Schließzeit das Kind aus der Krippe zu holen? Gibt es Parkplätze am Büro, sodass ich nicht auf öffentliche Verkehrsmittel angewiesen bin und schneller von A nach B komme? Gibt es Möglichkeiten, Home Office zu machen? Wie viele Stunden kann ich wöchentlich arbeiten? Wie offen sind Arbeitgeber, jemanden in Teilzeit anzustellen? Was kosten zusätzliche Betreuungsstunden in der Krippe? Wie überbrücke ich Krippenschließtage? Was, wenn das Kind krank ist?”

Diese Fragen stellen sich sicher viele Eltern, die sich aus der Elternzeit heraus neu bewerben müssen. Alleinerziehenden bereiten sie zusätzlich Kopfzerbrechen, da sie oft kein “Backup” in Form einer zweiten Person haben, mit der sie sich die logistischen Herausforderungen von Elternschaft und Arbeitsleben teilen können. 

Die Frage war also, welcher attraktive Arbeitgeber würde zu mir und meinen komplexer gewordenen Lebensumständen passen?

### Ein Arbeitgeber, der mehr hält als er verspricht

Inmitten dieser Unsicherheit kam die codecentric ins Spiel. Meine Online-Recherche hatte die codecentric als familienfreundlichen Arbeitgeber identifiziert, mit einem Büro, das nur 8 km von meiner Wohnung entfernt lag. Ich kannte bereits einige codecentricer von Meetups aus früheren Zeiten und hatte sie als sehr offen und kommunikativ wahrgenommen. Auch die kununu-Bewertungen vervollständigten mein durchweg positives Bild der codecentric.

Fast forward im Bewerbungsprozess: Die codecentric bot mir die Teilzeitstelle als Recruiterin an. Das Büro bot Parkplätze und eine günstige Lage zur Krippe. Weiterhin bekam die Möglichkeit, flexibel im Home Office zu arbeiten. Für mich heißt das, dass ich z.B. bei Krippenschließtagen von meinen Eltern aus arbeiten kann, die in dieser Zeit mein Kind betreuen. 

Aber die codecentric bietet noch viel mehr, was den Wiedereinstieg ins Arbeitsleben für mich erleichtert hat:

- **Inklusive Unternehmenskultur:** Es gibt nicht nur viele Eltern im Unternehmen, sondern sogar ein Spiel- und Stillzimmer im Münchner Büro. Als ich meinen Kleinen einmal mit ins Büro bringen musste, haben meine Kolleg:innen sofort und liebevoll (z.B. mit einem Babyccino für Söhnchen) unterstützt. Die Unternehmenskultur ist unglaublich entgegenkommend. 
- **Flexible Arbeitszeiten:** Keine Kernarbeitszeit ist ein Game-Changer. Wenn morgens ein Kinderarzttermin ansteht, kann ich meine Arbeitszeit flexibel gestalten und die Arbeit zu einem anderen Zeitpunkt erledigen.
- **Verständnis und Unterstützung:** Wenn das Kind oder ich mit einer Krippenseuche flachliegen, stoße ich auf großes Verständnis. Es ist so beruhigend zu wissen, dass man nicht schief angesehen wird, wenn das Leben mit Kind mal wieder dazwischenkommt.
- **Zusätzliche Kindkranktage:** Als Alleinerziehende stehen mir bei der codecentric 10 bezahlte Kindkranktage zur Verfügung, ohne dass ich die Krankenkasse bemühen oder Einkommenseinbußen hinnehmen muss. Das ist eine enorme Entlastung.
- **Menschlichkeit im Alltag:** Ob eine OP ansteht oder andere private Herausforderungen – meine Kolleg:innen nehmen Anteil und bieten ihre Unterstützung an. Dieses menschliche Miteinander ist Gold wert.
- **Hilfe bei der Babysittersuche:** Über unser Unternehmenskonto bei Heycare habe ich eine neue Babysitterin gefunden - ein Punkt weniger auf “Mamas Mental Load To Do Liste”. Das zeigt, wie umfassend die codecentric seine Mitarbeiter:innen entlasten möchte.

### Mehr als nur eine glänzende Employer Brand

Die codecentric hat es mir als alleinerziehende Mutter mit Kleinkind ermöglicht, vollwertig am Arbeitsleben teilzuhaben. Diese Wertschätzung und Loyalität, die ich empfinde, ist immens. Aus meiner Erfahrung halte ich dieses positive Menschenbild, das sich auch in vielen anderen Bereichen von codecentrics Diversity und Inclusion zeigt, für etwas Seltenes in der heutigen Arbeitswelt.

Leider ist es eine traurige Realität, dass viele Arbeitgeber zwar mit einer hochpolierten Employer Brand werben und mit Fotos von diversen Mitarbeiter:innen ihre Offenheit und Vielfalt betonen, die Realität im Unternehmen aber oft anders aussieht. Klar, Kinder sind kein Problem – solange man Vollzeit arbeiten kann, selbstverständlich gern mehr als die vereinbarten 40 Wochenstunden investiert und bei jedem Company Event ganz vorn mit dabei ist. 

Die Realität für Eltern, insbesondere für Frauen, die nach einer Schwangerschaft ins Berufsleben zurückkehren möchten, ist oft ernüchternd. Studien und Artikel beleuchten immer wieder die Herausforderungen (vgl. z.B. Stepstone 2024). Viele Unternehmen sind noch weit davon entfernt, wirklich unterstützende Strukturen zu bieten. Es gäbe an dieser Stelle sicher auch noch die “Baustelle” der ungleichen Verteilung der Care- und Erwerbsarbeit bei Vätern und Müttern zu besprechen, was allerdings an dieser Stelle zu weit führen würde.

### Politik und Arbeitgeber sind gefragt

Wirtschaft und Politik wünschen sich, dass Eltern und insbesondere Frauen nach der Geburt ihrer Kinder schnell und umfänglich in die Arbeitswelt zurückkehren um unser Fachkräftedefizit auszugleichen. Das ist ein hehres Ziel, das aber nur erreicht werden kann, wenn Offenheit für alternative Arbeitsmodelle und eine echte Kultur der Inklusion geschaffen werden.

Es ist an der Zeit, dass Politik und Arbeitgeber sich dazu aufgefordert fühlen, hierfür die notwendigen Grundlagen zu schaffen. Nur so können wir sicherstellen, dass die Potenziale von Eltern nicht ungenutzt bleiben und Familien die Unterstützung erhalten, die sie verdienen.

Wenn auch Ihr tolle Arbeitgeber habt, die Euch als Eltern unterstützen, freue ich mich über Austausch darüber, was Euch besonders geholfen hat!


Wieder durchstarten nach der Elternzeit: Mein Weg zur codecentric

In 2024, I embarked on the journey to become a recruiter for an IT Security Consulting team. I thought, “How hard can it be?” I had already been a recruiter for over 10 years, focusing predominantly on software developers, and I imagined my new task would be fairly similar. However, I quickly realized that my established methods wouldn't be as effective in this domain.

**Why?**

IT Security professionals (and particularly DFIR colleagues) are notoriously hard to find, much harder than, let’s say, Kotlin developers. They keep a very low profile on business platforms and the internet in general. In many cases, even the most sophisticated keyword searches fail to uncover their profiles, unless they actively desire to be found. So, what’s the cause?

Firstly, these professionals are acutely aware of the risks associated with personal information exposure and exploitation, given the nature of their work. Secondly, they often distrust the data collection practices of large corporations, fearing the misuse of their information for marketing or political purposes. Finally, publicly displaying their professional information online can inadvertently make them targets for “the bad guys”: hackers, attackers and malicious actors of all sorts.

So, where does this leave the eager recruiter? How do you “catch the good guys”?
###  My learnings

**Proactive Engagement:**
Even with minimal profiles, I initiated contact to gain insights within the industry. While my approach may not have always been highly tailored, I emphasized engaging with wit and curiosity. This allowed me to generate responses from fantastic future candidates and gather valuable industry insights. As much as I appreciate speaking with potential candidates, I am equally thrilled to connect with professionals who may not be looking for a new role but are happy to chat. Over the past year, this strategy has significantly enhanced my understanding of the cybersecurity community in Germany.

**Community Immersion:**
Speaking of the community and their members who often fly under the radar of classic recruitment methods, I found it to be essential to go where they are. Our team members regularly attend and speak at meetups and conferences, which I joined as often as possible to mingle with the crowd. We also exhibit at IT:SA, which has proven to be an outstanding networking opportunity. It goes without saying that this is a relatively indirect and long-term approach. 
While active recruiting efforts are generally unwelcome at dedicated industry events, my presence has allowed me to network organically and build relationships. I’ve also successfully scheduled meetings with prospective candidates at events we both attended. Added benefit: I had colleagues from the IT Security team around to help me make “the pitch”.

**Online Visibility:**
As the saying goes, "The best place to hide a dead body is on the second page of Google search results." Since IT security professionals are so difficult to locate, we wanted to make sure that they could find us. This was a collaborative effort involving leadership, marketing, the IT Security team, and HR.

We launched a dedicated sub-brand homepage for IT security, the team started publishing more blog articles, and I optimized my recruiter profile with relevant keywords. This stronger online presence has been crucial in attracting passive candidates who were quietly looking for their next professional opportunity.

**Employee Referrals:**
People referred by existing employees are far more likely to be hired than applicants coming through any other channels (direct search, job boards, events, etc.). Good people know good people. While they will still take part in the official recruitment process, these candidates have automatically undergone an “informal vetting process”. Team members wouldn’t recommend a new colleague who they don’t believe to have a suitable skillset or be a team fit, right? This approach is even more important for IT security professionals whose networks are often not openly accessible. And yes, we have been successful in hiring new colleagues through team members’ referrals over the last year. 

**Niche Platforms:**
IT Security professionals often have a deep passion for their work that extends far beyond their daily tasks. You'll find them actively involved in organizations like the Chaos Computer Club (CCC) and honing their skills on online platforms such as TryHackMe or Hack The Box – these are essentially online hacking playgrounds and vibrant cybersecurity communities.

Interestingly, some of these platforms allow you to post job roles directly and even anonymously approach members who've indicated they're "open for opportunities." While you won't know the individual's name you're reaching out to, their scores on these platforms can offer valuable insights into their technical skills and areas of expertise. (I haven't personally tried this approach yet, so if you have, I'd love to hear about your experiences!)

These are the most successful strategies I've used over the past year to grow our IT Security team, along with an outlook of what I'm still eager to try in the future. While the core approaches aren't revolutionary, adapting them for the unique challenge of finding IT security specialists was absolutely key.

Do you have any other ideas on how to find and recruit "the good guys"? I'd love to hear them!

How to Catch the Good Guys: My Learnings on Recruiting IT Security Professionals One Year In

Recruiterin

Recruiter

Vom simplen USB-Gerät zur Sicherheitslücke - BadUSB

Daten trotz Ransomware retten

IT-Security Consultant

YAML ist die gängige Konfigurationssprache im Container- und Kubernetes-Umfeld.  Das hat zum einen Vorteile, denn YAML besitzt wenige Konstrukte und spezielles Markup, das man sich merken muss. Andererseits wirft die Arbeit mit YAML auch einige Probleme auf, die andere Konfigurationssprachen lösen.

So kommt es bei YAML auf die Einrückungstiefe an, und wenn YAML-Dateien über String-Templates verarbeitet werden, führt das zu dem Effekt, der sich in vielen Helm-Charts wiederfindet: YAML wird in ein anderes YAML-File eingesetzt und die Helm-Commands "indent" oder "nindent" müssen für die richtige Einrückungstiefe sorgen:

```
apiVersion: v1
kind: Service
metadata:
  name: {{ service_name }}
  labels:
    {{- include "service.labels" . | nindent 4 }}
```

Ändert sich die Struktur der YAML-Dateien, müssen gegebenenfalls alle solchen Werte angepasst werden – das ist weder schön, noch sonderlich wartungsfreundlich. Ähnliche Probleme bringen Conditionals und andere Konstrukte mit sich, die String Templates bieten. Letzten Endes ist die ganze Herangehensweise fehleranfällig und reduziert die Möglichkeiten für Wiederverwendung und Modularität von Kubernetes-Konfiguration.

## Jsonnet fördert die Wiederverwendbarkeit

Einen Ausweg aus dem Dilemma eröffnen Konfigurationssprachen wie Jsonnet [1], die Konfiguration auf funktionale Weise managen und damit beispielsweise die Wiederverwendung von Config-Snippets ohne die oben beschriebenen Klimmzüge ermöglichen. Jsonnet ist eine Übermenge von JSON und bietet über die Markup-Funktionen hinaus einige wenige Merkmale einer richtigen Programmiersprache, zum Beispiel Funktionsaufrufe, Variablen und Conditionals. 

Ein Projekt, das auf Jsonnet aufbaut und mit Wissen über Kubernetes-Objekte ausstattet, ist Tanka [2] von den Grafana Labs. Tanka bietet insbesondere bei Kubernetes-Projekten gegenüber YAML etliche Vorteile, zum Beispiele deutlich kürzere und damit besser lesbare Konfigurationsdateien. Wer als Team auf Tanka setzt, kann sich eine eigene Bibliothek bauen, um den Grad an Wiederverwendung noch zu steigern. 

Ist das Tool installiert, lässt sich mit einem Aufruf ein Verzeichnis für Tanka initialisieren:
```
tk init
```
Damit werden diverse Dateien angelegt und auch die k8-libsonnet-Bibliothek installiert, um einfacher mit Kubernetes-Ressourcen zu arbeiten. Tanka unterstützt Environments, um etwa für Development und Production unterschiedliche Manifeste oder Werte zu verwenden. Standardmäßig installiert "tk init" ein Default-Environment, das sich in "environment/default" wiederfindet, wo wiederum die Datei "main.jsonnet" liegt, die den Einstiegspunkt darstellt – dazu muss übrigens das Binary von "jsonnet-bundler" installiert sein.  

Diese JSON-Datei (und somit Jsonnet-Datei) startet im Kubernetes-Cluster einen Pod, wenn sie mit "tk apply" angewendet wird.
```
{
  "apiVersion": "v1",
  "kind": "Pod",
  "metadata": {
    "name": "nginx-pod",
    "labels": {
      "app": "nginx"
    }
  },
  "spec": {
    "containers": [
      {
        "name": "nginx",
        "image": "nginx:latest",
        "ports": [
          {
            "containerPort": 80
          }
        ]
      }
    ]
  }
}
```
Die folgenden Zeilen importieren den Pod in das Main-Manifest "main.jsonnet":
```
local pod = import 'pod.jsonnet';
{
  data: pod
}
```
Wenn alle Dateien korrekt sind, zeigt "tk show" das aus den Jsonnet-Dateien erzeugte YAML an. "tk diff" zeigt (wie kubectl) die potenziellen Änderungen, wenn das Tanka-Projekt auf einem Kubernetes-Cluster umgesetzt werden soll.

Natürlich ist an dieser Stelle noch nichts gewonnen, denn die Jsonnet-Datei des Pod ist sogar länger als ihr YAML-Gegenstück, aber etwas Refactoring vereinfacht die Jsonnet-Pod-Definition drastisch. Wir werden hier nicht alle Refactoring-Schritte reproduzieren, die das Tanka-Tutorial ausführlich durchgeht. Zum einen geht es dabei darum, aus den Kubernetes-Manifesten Funktionen zu machen, die es erlauben, Parameter zu übergeben; zum anderen vereinfacht die Library k8-libsonnet die Konfiguration. Am Ende steht die in Jsonnet mit wenigen Zeilen formulierte Definition eines kompletten Service (Beispiel aus dem Tanka-Tutorial)
```
local k = import "github.com/grafana/jsonnet-libs/ksonnet-util/kausal.libsonnet";

{
  local deploy = k.apps.v1.deployment,
  local container = k.core.v1.container,
  local port = k.core.v1.containerPort,
  local service = k.core.v1.service,

  new(name, port):: {
    deployment: deploy.new(name, replicas=1, containers=[
      container.new("grafana/grafana")
      + container.withPorts(
          [port.new("ui", 3000)]
        ),
    ]),

    // Helper, um automatisch einen Service für ein Deployment anzulegen
    service: k.util.serv.util.serviceFor(self.deployment)
             + service.mixin.spec.withType("NodePort"),
  }
}
```

## Helm-Support

Manche werden sich vielleicht fragen, was jetzt mit den schönen Helm-Charts passieren soll, die bekanntlich in YAML abgefasst sind. Die gute Nachricht ist: Sie lassen sich mit Tanka weiter nutzen und sogar besser parametrisieren als mit dem Helm-Tool selbst. Dazu ist es nötig, die Jsonnet-Helm-Bibliothek zu installieren. Anschließend können in einer Jsonnet-Datei das Helm-Chart geladen und anschließend die Helm-Values geändert werden, etwa so:
```
  grafana: helm.template("grafana", "./charts/grafana", {
    namespace: "monitoring",
    values: {
      persistence: { enabled: true }
    }
  })
```
Ein Wermutstropfen ist dabei, dass das nur funktioniert, wenn die Helm-Charts im Jsonnet-Projektverzeichnis installiert sind. Hierbei hilft das Tanka-Subcommand "tk tool charts", das die Charts an der passenden Stelle installiert.

Alternativ zu Tanka existieren noch weitere Tools wie Kubecfg, die auf der Jsonnet-Homepage zu finden sind. Daneben gibt es Jsonnet-Bindings für verschiedene Programmiersprachen/Umgebungen, angefangen bei Python, das vom Core-Projekt bereitgestellt wird, über Go, PHP, Ruby, Node.js und Rust als Community-Projekte. 

Wer sich ohne irgendwelche Tools zu installieren mit Jsonnet vertraut machen möchte, findet einen interaktiven Playground mit praktischen Übungen auf der Jsonnet-Seite.

## Fazit

Neben Tanka/Jsonnet gibt es noch weitere Ansätze, das "YAML-Problem" beim Management von Cloud-Konfiguration zu lösen, beispielsweise CUE [3], das aber etwas komplexer ist. Ansätze wie Pulumi gehen noch einen Schritt weiter und erlauben die Erstellung und Konfiguration von Kubernetes-Ressourcen mit verbreiteten Programmiersprachen wie Python, Java oder Go – mit der entsprechenden Freiheit für jeden Entwickler, damit sein eigenes Süppchen zu kochen. Tanka/Jsonnet trifft demgegenüber den Sweet Spot zwischen absoluter Freiheit, die leicht ins Chaos führt, und dem engen YAML-Korsett. 

Einen Styleguide zu Jsonnet [4] bietet die KI-Firma Databricks, die nach eigenen Angaben über 1000 Jsonnet-Templates verwendet. Sie setzt dazu allerdings nicht auf Tanka, sondern auf einen eigenen Jsonnet-Compiler [5], der als Open Source verfügbar ist.

## Links

[1] [Jsonnet](https://jsonnet.org)

[2] [Tanka](https://tanka.dev)

[3] [CUE](https://cuelang.org)

[4] [Jsonnet Style Guide](https://github.com/databricks/jsonnet-style-guide)

[5] [Writing a fast Jsonnet compiler](https://www.databricks.com/blog/2018/10/12/writing-a-faster-jsonnet-compiler.html)


Kubernetes-Konfiguration mit Jsonnet

Senior IT-Consultant & People Lead

CSV-Dateien sind der ewige Klassiker im Datenaustausch. Auch wenn modernere Formate wie JSON und Parquet ihren Platz erobern, bleiben die einfachen, aber robusten Comma Separated Values das Rückgrat vieler Daten-Workflows. Aber Hand aufs Herz: Wer hat sich nicht schon mal gequält, als ein riesiger Datensatz das Lieblings-Tool wie Excel in die Knie zwang? Genau hier kommen [DuckDB](https://duckdb.org) und [MotherDuck](https://motherduck.com) ins Spiel.

Dieser Post zeigt dir, wie du mit dieser Power-Kombination selbst gigantische CSV-Dateien blitzschnell analysierst. Das Beste daran? Du brauchst keine aufwändige Server-Infrastruktur. Einfach SQL, direkter Zugriff auf deine Dateien und schon hast du aus rohen Daten wertvolle Erkenntnisse gewonnen. Bereit für eine neue Art der Datenanalyse?

## Vom Gigabyte zu Insights: CSVs parsen mit DuckDB

### Setup

Falls du DuckDB noch nicht installiert hast, installiere bitte die DuckDB CLI auf deinem Rechner. Die Anleitung findest du hier: [DuckDB Installation](https://duckdb.org/docs/stable/installation/index).

### Der Datensatz

Wir nutzen den bekannten [New York City Taxi-Datensatz](https://www.nyc.gov/site/tlc/about/tlc-trip-record-data.page), genauer die Daten der Yellow Taxis von 2023, die [hier](https://data.cityofnewyork.us/Transportation/2023-Yellow-Taxi-Trip-Data/4b4i-vvec/about_data) verfügbar sind. Mit rund 38,3 Millionen Einträgen und einer Größe von 3,78 GB ist er der perfekte Testfall. Eine solche Dateigröße ist für Tools wie Microsoft Excel meist viel zu groß und genau hier kommt die Power von DuckDB und MotherDuck ins Spiel.

> [!NOTE]  
In MotherDuck gibt es eine `sample_data` Datenbank, die New York City Taxidaten für Dezember 2022 enthält, was ungefähr 10 % des Datenvolumens darstellt, welches wir in diesem Post verwenden.

### Den Datensatz laden

DuckDB unterstützt zwei Modi: In-Memory und Persistent. Um den Datensatz in eine dauerhafte DuckDB-Datenbank zu laden, erstelle zuerst die `nyc_taxi.duckdb` Datenbank. Führe dazu folgenden Befehl aus:

```sh
duckdb nyc_taxi.duckdb
```

Sobald die Datenbank erstellt ist, lade den Datensatz mit dem nächsten Befehl innerhalb der DuckDB CLI.

```sql
.timer on
CREATE TABLE nyc_yellow_taxi_trips AS FROM '2023_Yellow_Taxi_Trip_Data_20250903.csv';
```

Je nach Rechner-Power dauert das nur wenige Sekunden. Auf einem Mac M3 wird der gesamte 3,78 GB große Datensatz mit über 38 Millionen Einträgen in ungefähr 3,5 Sekunden geladen, was die beeindruckende Performance von DuckDB unterstreicht.

```sql
Run Time (s): real 3.540 user 38.143785 sys 1.770184
```

### Erste Abfrage: Die Fahrtdauer berechnen

Sobald die Daten geladen sind, können wir unsere erste Abfrage starten. Wir berechnen die Fahrtdauer, also die Differenz zwischen `tpep_dropoff_datetime` und `tpep_pickup_datetime`.

```sql
.timer on
SELECT *, (tpep_dropoff_datetime - tpep_pickup_datetime) AS trip_duration 
FROM nyc_yellow_taxi_trips;
```

Das Ergebnis? Die Fahrtdauer für alle 38,3 Millionen Einträge ist in nur etwa einer Sekunde berechnet.

```sql
Run Time (s): real 1.304 user 1.268312 sys 2.229287
```

### Daten anreichern - die Fahrtdauer als neue Spalte speichern

Um für spätere Abfragen, die die Fahrtdauer nutzen, zu vereinfachen, speichern wir diese Werte in einer neuen Spalte. Das geht mit einem einfachen Befehl, der eine neue Spalte namens `trip_duration` anlegt.

```sql
ALTER TABLE nyc_yellow_taxi_trips
ADD COLUMN trip_duration INTERVAL;
UPDATE nyc_yellow_taxi_trips
SET trip_duration = tpep_dropoff_datetime - tpep_pickup_datetime;
```

Jetzt nutzen wir die neue Spalte, um die durchschnittliche Fahrtdauer zu berechnen.

```sql
.timer on
SELECT AVG(trip_duration) FROM nyc_yellow_taxi_trips;
```

## MotherDuck: DuckDB in der Cloud

Die lokale Performance von DuckDB ist beeindruckend, aber wie wäre es, wenn du diese Power mit deinem Team teilen und von überall darauf zugreifen könntest? Das ist der Moment, in dem MotherDuck ins Spiel kommt. Es kombiniert DuckDBs In-Process-Performance mit der Skalierbarkeit und dem Komfort der Cloud.

> [!NOTE]  
> Dafür brauchst du einen MotherDuck Account, den du ganz einfach auf [https://motherduck.com](https://motherduck.com) erstellen kannst.

Um die CSV-Daten in MotherDuck zu laden, öffne eine neue DuckDB CLI Session mit diesem Befehl:

```sh
duckdb
```

Anschließend führe die folgenden Befehle in der DuckDB CLI-Shell aus.

> [!NOTE]  
Wenn du die Umgebungsvariable `motherduck_token` noch nicht gesetzt hast (wie in der [MotherDuck-Doku](https://motherduck.com/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck) beschrieben), öffnet sich ein Browserfenster, in dem du den Zugriff der DuckDB CLI auf MotherDuck bestätigen musst.

```sql
ATTACH 'md:';
CREATE OR REPLACE DATABASE nyc_yellow_taxi_trips;
USE nyc_yellow_taxi_trips;
CREATE OR REPLACE TABLE nyc_yellow_taxi_trips AS FROM '2023_Yellow_Taxi_Trip_Data_20250903.csv';
```

Diese Befehle erstellen eine neue Datenbank `nyc_yellow_taxi_trips` erstellt und eine neue Tabelle gleichen Namens und lädt die Daten in die neue Tabelle. Dieser Schritt kann je nach Internet-Upload-Geschwindigkeit zwischen zwei und drei Minuten dauern.

> [!NOTE]  
Dieser Post konzentriert sich auf lokale CSV-Dateien, aber DuckDB/MotherDuck unterstützt auch den Import von CSV-Daten aus verschiedenen Object Storage Systemen, wie AWS S3, Azure Blob Storage und Google Cloud Storage.

### Durchschnittliche Fahrtdauer in Abhängigkeit der Passagierzahl

Jetzt kannst du die Daten direkt im Browser analysieren. Gehe in deinem Browser zu [https://app.motherduck.com](https://app.motherduck.com) und erstelle ein neues Notebook mit dem Titel `nyc_yellow_taxi_trips`. Füge in die erste Zelle die SQL-Anweisung aus dem folgenden Block ein und führe sie aus, indem du auf den kleinen Dreieck-Button klickst.

```sql
SELECT passenger_count, AVG(tpep_dropoff_datetime - tpep_pickup_datetime) AS avg_trip_duration 
FROM nyc_yellow_taxi_trips 
GROUP BY passenger_count
ORDER BY passenger_count;
```

### Hängt die Höhe des Trinkgeldes von der Distanz ab?

Für einen Taxifahrer ist das eine entscheidende Frage: Hängt das Trinkgeld von der Länge der Fahrt ab? Dies können wir mit dem folgenden SQL Statement evaluieren:

```sql
SELECT 
 CASE WHEN trip_distance BETWEEN 0 AND 4 THEN 'short'
      WHEN trip_distance BETWEEN 4 AND 9 THEN 'medium'
      WHEN trip_distance > 9 THEN 'long' 
      END AS trip_length,
 AVG(fare_amount) AS fare, 
 AVG(tip_amount) AS tip
 FROM nyc_yellow_taxi_trips
 GROUP BY trip_length
 ORDER BY tip DESC;
```

Wie du siehst, gilt: Je länger die Fahrt, desto höher das Trinkgeld für den Taxifahrer.

|trip_length|fare|tip|
|-----------|---:|--:|
|long|60.66741257482049|9.713919128310547|
|medium|29.65654459738106|5.005007720056084|
|short|12.775505292438215|2.5128599942576764|


### Die Abholorte mit den längsten Fahrten

Da wir gesehen haben, dass längere Fahrten lukrativer sind (das Trinkgeld ist fast viermal so hoch!), finden wir jetzt die 20 interessantesten Abholorte mit den längsten Durchschnittsfahrten und dem höchsten Durchschnittstrinkgeld. Wir berücksichtigen weiterhin nur Orte mit mehr als 1000 Fahrten.

Führe dasu bitte folgendes SQL-Statement aus:

```sql
SELECT
    PULocationID,
    COUNT(*) AS trip_count,
    AVG(trip_distance) AS avg_trip_distance,
    AVG(total_amount) AS avg_total_amount,
    AVG(tip_amount) AS avg_tip_amount
FROM
    nyc_yellow_taxi_trips
GROUP BY
    PULocationID
HAVING
    trip_count > 1000
ORDER BY
    avg_tip_amount DESC
LIMIT 20;
```

In nur wenigen Millisekunden haben wir die Info aus über 38,3 Millionen Einträgen welches die lukrativsten Standorte sind. Mit diesen Daten kann ein Taxifahrer seinen Gewinn optimieren, indem er sich strategisch in der Nähe der profitabelsten Abholorte positioniert.

### Sind Fahrten vom Flughafen profitabler?

Zum Schluss wollen wir herausfinden, ob Fahrten vom Flughafen profitabler sind als andere.

Wir vergleichen dazu das durchschnittliche Trinkgeld für Fahrten vom Flughafen mit dem von anderen Startorten. Zur Vereinfachung betrachten wir nur den Durchschnittspreis, ohne Fahrtdauer oder andere Faktoren. Der Zielort kann das Trinkgeld ebenfalls beeinflussen, was wir hierbei aus Verenfachungsgründen nicht weiter betrachten. Die `PULocationID` für die drei Flughäfen sind 1, 132, 138.

```sql
SELECT
    CASE
        WHEN PULocationID IN (1, 132, 138) THEN 'airport'
        ELSE 'not_airport'
    END AS pickup_type,
    AVG(tip_amount) AS avg_tip_amount,
    COUNT(*) AS trip_count
FROM
    nyc_yellow_taxi_trips
GROUP BY
    pickup_type;
```

Auch hier bekommen wir das Ergebnis in Millisekunden zurück und unsere Annahme erweist sich als korrekt: Das Trinkgeld für Flughafen-Fahrten ist fast dreimal so hoch!

## Fazit

DuckDB und MotherDuck revolutionieren die Datenanalyse durch eine hohe Geschwindigkeit und Effizienz, besonders bei großen Datensätzen. Die typischen Hürden von Big Data - wie zeitraubendes Laden und der Bedarf an komplexer Infrastruktur - werden praktisch eliminiert.

### Der DuckDB-Vorteil: Schnell und simpel

Mit DuckDB ist das Laden von Gigabytes an Daten keine stundenlange Tortur mehr, sondern eine Sache von Sekunden. Dieser Geschwindigkeitsvorteil gilt auch für Abfragen, die _extrem schnell_ ausgeführt werden und Einblicke in Echtzeit ermöglichen, die früher unerreichbar waren. Das ist ein großer Unterschied zu herkömmlichen CSV-Tools, die unter der Last großer Datensätze oft zusammenbrechen oder lange Zeit brauchen, um große Datenmengen zu verarbeiten.

Traditionelle Data Warehouse-Lösungen sind zwar mächtig, verlangen aber oft eine erhebliche Vorabinvestition in Zeit und Ressourcen. Sie benötigen komplexe Daten-Pipelines, um Daten zu laden, gefolgt von der Bereitstellung und Skalierung von Rechenressourcen, bevor überhaupt die erste Abfrage ausgeführt werden kann. Dieses aufwendige Setup führt oft zu Tagen oder sogar Wochen der Vorbereitung, bevor die eigentliche Analyse beginnen kann.

### MotherDuck: Der Cloud-Native-Partner

MotherDuck ergänzt DuckDB, indem es dieses in die Cloud bringt und eine serverless Variante bereitstellt, welche die Datenanalyse weiter vereinfacht. Diese Kombination erlaubt es, dass Nutzer die Power von DuckDBs Engine mit der Skalierbarkeit und Zugänglichkeit einer Cloud-Plattform nutzen können, ohne den operativen Overhead.

### Das "First Query" Rennen

Die Stärke von DuckDB und MotherDuck zeigt sich im sogenannten _First Query_ Rennen. Während andere Lösungen noch konfiguriert werden oder gerade erst mit dem Laden der Daten beginnen, haben Nutzer von DuckDB und MotherDuck ihre Analyse oft schon abgeschlossen, entscheidende Einblicke gewonnen und können datengestützte Entscheidungen treffen. Diese Agilität verschafft einen erheblichen Vorteil und ermöglicht schnellere Iterationen und Entscheidungen.

Kurz gesagt, DuckDB und MotherDuck sind nicht nur Tools, sie sind ein Paradigmenwechsel in der Datenanalyse. Sie machen diese zugänglicher, schneller und deutlich unkomplizierter um aus Daten wertvolle Informationen zu extrahieren.

Melde dich zu unserem [Hands-on Workshop: Einstieg in MotherDuck](https://www.codecentric.de/leistungen/data-effectiveness/workshop-einstieg-in-motherduck) an, um die Möglichkeiten von MotherDuck live zu erleben.

Datenanalyse mit MotherDuck und DuckDB: Aus CSV zu Insights in 5 Minuten

In this post, we'll explore how [MotherDuck](https://motherduck.com), powered by [DuckDB](https://duckdb.org), revolutionizes the way you interact with your data, particularly when dealing with CSV files. You'll learn how to quickly parse and filter even large datasets directly from your local machine, using familiar SQL syntax, and without the need for a dedicated server or extensive configuration. Get ready to transform your raw CSV data into valuable insights in a matter of minutes!

CSV (Comma Separated Values) files remain a ubiquitous format for exchanging data, despite the emergence of newer, more structured formats like JSON and Parquet. Their simplicity and widespread compatibility ensure their continued relevance in various data workflows. However, working with large CSV files can sometimes be cumbersome, especially when you need to quickly extract insights without the overhead of complex setups.

## From Gigabytes to Insights: Parsing CSVs with DuckDB

### Setup

If you haven't set up the DuckDB CLI head over to [DuckDB Installation](https://duckdb.org/docs/stable/installation/index) and select your preferred option to install the DuckDB CLI.

### About the dataset
We are using the well-known [New York City Taxi dataset](https://www.nyc.gov/site/tlc/about/tlc-trip-record-data.page), specifically the Yellow Taxi Trip data from 2023 which is available [here](https://data.cityofnewyork.us/Transportation/2023-Yellow-Taxi-Trip-Data/4b4i-vvec/about_data). This dataset contains approximately 38.3 million (38,310,226) records, and the CSV file size is 3.78 GB. This size is typically too large to manage effectively with tools like Microsoft Excel and we leverage the power of DuckDB and MotherDuck

> [!NOTE]  
In MotherDuck there is a `sample_data` database which contains the taxi data for December 2022 which is about 10% of the data volume we use in this blog post. You can also use this dataset if your upload link is limited.

### Loading the dataset
DuckDB supports two persistence modes, in-memory and persistent. To load the dataset into a permanent DuckDB database, begin by creating the `nyc_taxi.duckdb` database. Execute the following command:

```sh
duckdb nyc_taxi.duckdb  
```
Once the database is created, load the dataset by executing the subsequent command within the DuckDB CLI.

```sql
.timer on
CREATE TABLE nyc_yellow_taxi_trips AS FROM '2023_Yellow_Taxi_Trip_Data_20250903.csv';
```

Depending on your machine, the dataset should load in mere seconds. For instance, on a Mac M3 the entire 3.78GB dataset, containing over 38.3 million records, loads in approximately 3.5 seconds, highlighting DuckDB's impressive performance capabilities.

```sql
Run Time (s): real 3.540 user 38.143785 sys 1.770184
```

### Our first query - calculate the trip duration for each trip
Once the data is loaded, a process that happens incredibly quickly, we can run our first query. We'll start by calculating the trip duration, which is the difference between `tpep_dropoff_datetime` and `tpep_pickup_datetime`, using the commands below.


```sql
.timer on
SELECT *, (tpep_dropoff_datetime - tpep_pickup_datetime) AS trip_duration 
FROM nyc_yellow_taxi_trips;
```
You should see the following output

```sql
Run Time (s): real 1.304 user 1.268312 sys 2.229287
```

As you can see the trip_duration is calculated in just a second or all 38.3 million records which is pretty awesome.

### Enriching the data - store the trip duration as a new column

To facilitate further queries involving trip duration, we will store these values in a new column. This can be achieved by executing a simple command that creates a new column called trip_duration.

```sql
ALTER TABLE nyc_yellow_taxi_trips
ADD COLUMN trip_duration INTERVAL;
UPDATE nyc_yellow_taxi_trips
SET trip_duration = tpep_dropoff_datetime - tpep_pickup_datetime;
```

Now let's use the newly created column to calculate the average trip duration. For this execute the following command and you get the result again in milliseconds.

```sql
.timer on
SELECT AVG(trip_duration) FROM nyc_yellow_taxi_trips;
```

## Moving to MotherDuck

We've explored DuckDB locally using its CLI, witnessing its remarkable speed with large CSV datasets. Now, let's transition to MotherDuck to share your data with your team, enabling them to leverage the combined power of DuckDB and MotherDuck.

> [!NOTE]  
For this you need a MotherDuck account which you can easily create on [https://motherduck.com](https://motherduck.com)

To load the CSV data into MotherDuck, open a new DuckDB CLI session execute the following command:

```sh
duckdb
```

Afterwards run the following commands in the DuckDB CLI shell.

> [!NOTE]  
If you haven't set the environment variable `motherduck_token` as documented in the [MotherDuck documentation](https://motherduck.com/docs/key-tasks/authenticating-and-connecting-to-motherduck/authenticating-to-motherduck) a browser window will open where you need to confirm the access to MotherDuck from your DuckDB CLI shell.

```sql
ATTACH 'md:';
CREATE OR REPLACE DATABASE nyc_yellow_taxi_trips;
use nyc_yellow_taxi_trips;
create or replace table nyc_yellow_taxi_trips as from '2023_Yellow_Taxi_Trip_Data_20250903.csv';
```

This generates a new database `nyc_yellow_taxi_trips`, and populates a table of the same name with the loaded data. The duration of this step can range from two to three minutes, contingent on your internet upload speed.

> [!NOTE]  
While this post focuses on CSV file stored on a local storage, it's worth noting that DuckDB/MotherDuck also supports importing CSV data from various object storage systems, including AWS S3, Azure Blob Storage, and Google Cloud Storage.

Let's advance to more complex queries using MotherDuck. We'll be executing these queries within the MotherDuck UI.

### Average trip duration depending the number of passengers

To begin, navigate to [https://app.motherduck.com](https://app.motherduck.com) and create a new notebook titled `nyc_yellow_taxi_trips`. In the initial cell, insert the SQL statement shown in the block below and execute it by clicking the small triangle button.

```sql
SELECT passenger_count, AVG(tpep_dropoff_datetime - tpep_pickup_datetime) AS avg_trip_duration 
FROM nyc_yellow_taxi_trips 
GROUP BY passenger_count
ORDER BY passenger_count;
```

### Does the amount of tip depend on the trip distance?

For a taxi driver it would be interesting to know if there is a correlation between the amount of the tip and the length of the trip. For this we can execute the following query:

```sql
SELECT 
 CASE WHEN trip_distance BETWEEN 0 AND 4 THEN 'short'
      WHEN trip_distance BETWEEN 4 AND 9 THEN 'medium'
      WHEN trip_distance > 9 THEN 'long' 
      END AS trip_length,
 AVG(fare_amount) AS fare, 
 AVG(tip_amount) AS tip
 FROM nyc_yellow_taxi_trips
 GROUP BY trip_length
 ORDER BY tip DESC;
```

|trip_length|fare|tip|
|-----------|---:|--:|
|long|60.66741257482049|9.713919128310547|
|medium|29.65654459738106|5.005007720056084|
|short|12.775505292438215|2.5128599942576764|

As you can see from the results, the longer the trip the higher the amount of tip for the taxi driver. 

### Find the pickup locations which have the longest trip distance

As we have seen it is beneficial to look for longer trips as the amount of the tip is almost 4 times higher for longer trips compared to shorter trips.

Therefore let's find out which are the 20 most interesting pickup locations which have on average the longest trips and on average the highest tip. Only consider pickup locations with more than 1000 trips.

For this execute the following sql statement:

```sql
SELECT
    PULocationID,
    COUNT(*) AS trip_count,
    AVG(trip_distance) AS avg_trip_distance,
    AVG(total_amount) AS avg_total_amount,
    AVG(tip_amount) AS avg_tip_amount
FROM
    nyc_yellow_taxi_trips
GROUP BY
    PULocationID
HAVING
    trip_count > 1000
ORDER BY
    avg_tip_amount DESC
LIMIT 20;
```

In just milliseconds calculating over 38.3 million records we have the information and with this information a taxi driver can try to optimize his income by strategically positioning himself in the vicinity of the most profitable pickup locations.

### Are airport trips more profitable?

The last example we want to look at is if trips from the airport are more profitable than other trips.

We want to find out if the average tip is higher for trips from the airport compared to trips starting somewhere else. To simplify the example, we just take the average price without considering trip duration or other factors. Note that drop-off location may actually affect the amount of tip. The `PULocationID` for the three commercial airports are 1, 132, 138.

```sql
SELECT
    CASE
        WHEN PULocationID IN (1, 132, 138) THEN 'airport'
        ELSE 'not_airport'
    END AS pickup_type,
    AVG(tip_amount) AS avg_tip_amount,
    COUNT(*) AS trip_count
FROM
    nyc_yellow_taxi_trips
GROUP BY
    pickup_type;
```

Again, the result is returned in milliseconds, confirming that tips for airport trips are nearly three times higher.

## Conclusion
DuckDB and MotherDuck revolutionize data analysis by offering unparalleled speed and efficiency, especially when dealing with large datasets. The traditional hurdles associated with big data — such as the time-consuming loading processes and the need for complex infrastructure — are virtually eliminated.

### The DuckDB Advantage: Speed and Simplicity

With DuckDB, loading gigabytes of data is no longer a multi-hour ordeal but a matter of seconds. This incredible speed extends to query execution, which is _extremely fast_, allowing for real-time insights that were previously unattainable. This marks a significant departure from conventional CSV tools like Microsoft Excel, which buckle under the weight of large datasets, often becoming unresponsive or taking an eternity to process.

Traditional data warehouse solutions, while powerful, often demand a significant upfront investment in time and resources. They typically require intricate data pipeline mechanisms to ingest data, followed by the provisioning and scaling of compute resources before even the first query can be executed. This elaborate setup often translates to days or even weeks of preparation before any meaningful analysis can begin.

### MotherDuck: The Cloud-Native Companion

MotherDuck complements DuckDB by extending its capabilities to the cloud, offering a serverless experience that further simplifies data analysis. This combination means that users can leverage the power of DuckDB's in-process OLAP engine with the scalability and accessibility of a cloud platform, without the operational overhead.

### The "First Query" Race

The true power of DuckDB and MotherDuck becomes evident in what can be called the _first query_ race. In many scenarios, by the time other solutions are still being configured or are just beginning the data loading process, users of DuckDB and MotherDuck have already completed their analysis, extracted critical insights, and are ready to make data-driven decisions. This agility provides a significant competitive advantage, enabling faster iterations and more responsive business strategies.

In essence, DuckDB and MotherDuck are not just tools; they represent a paradigm shift in how data analysis is approached, making it more accessible, faster, and significantly less cumbersome for anyone looking to transform raw data into actionable intelligence.

To see these concepts in action, enroll in our on-demand [Hands-on Workshop: Introduction to MotherDuck](https://www.codecentric.de/en/services/data-effectiveness/workshop-introduction-to-motherduck) for a complete practical walkthrough.

Your First Data Analysis with MotherDuck and DuckDB: From CSV to Insights in 5 Minutes

Principle Consultant + People Lead

### TL;DR:
Wie viel lässt sich aus einem fünfminütigen Gespräch herausholen? Wir haben es ausprobiert: Mit einem kurzen Interview, einem Transkript und AI-unterstützten Coding nach der [BMAD-Methode](https://github.com/bmad-code-org/BMAD-METHOD) entstand in kürzester Zeit ein nutzbarer Proof of Concept (PoC) – inklusive Roadmap, Feature-Liste, Risikoregister und Timeline. In diesem Beitrag teilen wir unsere Erfahrungen, Learnings und Gedanken dazu, wie AI-Tools wie Claude Code und BMAD den Weg von der ersten Idee bis zur lauffähigen Software radikal abkürzen - und warum wir davon fachlich begeistert sind.

___
### Ausgangslage: Von der Idee zur Struktur in Minuten
Wer kennt es nicht? Ein neues Projekt startet, die Anforderungen sind noch diffus, die Zeit knapp und die Erwartungshaltung hoch. Gerade in Greenfield-Projekten - wenn wirklich alles auf der sprichwörtlichen „grünen Wiese“ beginnt - ist der Weg von der ersten Idee bis zu einer belastbaren Spezifikation oft lang und voller Schleifen.
Unser Ziel: Diesen Prozess radikal abkürzen und zeigen, wie AI und Spec-Driven Development nach BMAD Unternehmen dabei unterstützen, in kürzester Zeit von einer groben Idee zu einer strukturierten, diskutierbaren Lösung zu kommen.

### Das Setting:
Wir haben ein typisches Erstgespräch simuliert, wie es in der Anforderungsaufnahme üblich ist. In nur fünf Minuten schilderte unser „Kunde“ ein konkretes Problem:

*“Der Kunde möchte einen digitalen Kalender als Produkt für Eltern von Babys entwickeln, der später kommerziell vermarktet werden soll. Die Hauptfunktion ist die Dokumentation von Babybezogenen Terminen, gesundheitlichen Ereignissen (Krankheiten, Impfungen, Vitamin Einnahmen etc.) und anderen wichtigen Meilensteinen. Das Ziel ist, dass Eltern bei Arztbesuchen schnell auf den vollständigen Verlauf zugreifen können, um relevante Informationen zu teilen. Die App soll sowohl Text- als auch Spracheingabe unterstützen, da Eltern oft in Situationen sind, wo entweder nur Schreiben oder Sprechen möglich ist. Einträge können Anhänge wie Fotos und PDF-Dokumente enthalten und sollten durch verschiedene farbcodierte Kategorien/Labels organisiert werden. Die Usability ist kritisch - die Bedienung muss extrem einfach und schnell sein, da Eltern unter Zeitdruck stehen. Die Lösung soll unkompliziert an ca. 100 Beta-Testern (Eltern) ausgerollt werden. Mehrere Kinder pro Familie müssen unterstützt werden, wobei jedes Kind seinen eigenen Verlauf haben soll.”*

---
### Der Prozess: BMAD, AI und menschliche Validierung
Unser Ansatz bestand aus vier Schritten:

1. **Transkript als Ausgangspunkt:**  
   Das Gespräch wurde aufgenommen und diente als Input für die AI.

2. **Spec-Driven Development mit BMAD:**  
   Mithilfe der [BMAD-Methode](https://github.com/bmad-code-org/BMAD-METHOD) und AI-Unterstützung (Claude Code) haben wir aus dem Transkript vier zentrale Artefakte generieren lassen:

    * Implementation Roadmap: Schritt-für-Schritt-Plan zur Umsetzung
    * Feature-Liste: Aufteilung in Core- und optionale Features
    * Risikoregister: Identifikation und Bewertung potenzieller Risiken
    * Timeline: Grobe Zeitplanung für die Umsetzung

3. **Human in the Loop:**  
   Die generierten Artefakte wurden von uns manuell geprüft, bewertet und mit dem Kunden (bzw. in unserem Fall: dem fiktiven Auftraggeber) durchgesprochen.

4. **Umsetzung:**  
   Auf Basis der validierten Artefakte wurde ein lauffähiger Proof of Concept generiert – inklusive Benutzerhandbuch.


**Auszug aus KI-generierter Feature-Liste**
```
Must-Have Features (POC)

Core Features

✅ Calendar interface (month view, date navigation)
✅ Create/edit/delete entries with date/time
✅ Text-based entries
✅ Category system (5 categories with color coding):
    - Doctor visits (Arztbesuch)
    - Illness/Health issues (Krankheit)
    - Development milestones (Entwicklung)
    - Vitamins/Medication (Vitamine)
    - Other (Sonstiges)
    - Attachments
✅ Photo uploads (JPEG, PNG)
✅ PDF document attachments
✅ ~10 attachments per child limit

Multi-Child Support
✅ Support for multiple children
✅ Separate calendars per child
✅ Easy child switching interface

Data & Storage
✅ Local storage (browser-based)
✅ Export/backup functionality
✅ Data persists across sessions
  
```
---
### Was uns beeindruckt hat

* **Präzision und Kontextverständnis:**  
  Die AI hat nicht nur explizite Anforderungen wie den Multi-Kind-Support oder die Lokalisierung auf Deutsch erkannt, sondern auch überraschend implizite Wünsche umgesetzt – etwa die Integration von Datensicherung und Wiederherstellung.

* **Konsistenz über alle Artefakte:**  
  Anforderungen wurden stringent in Roadmap, Feature-Liste und Code abgebildet.

* **Schnelligkeit und Struktur:**  
  Innerhalb kürzester Zeit entstand eine vollständige Dokumentation, die als Diskussionsgrundlage und Entscheidungsbasis dient.

* **Auswahl des Tech Stacks:**  
  Auf Basis der generierten Risikofaktoren hat die KI eigenständig einen Tech Stack ausgewählt, der maßgeblich zum einfachen Setup und zur hohen Benutzerfreundlichkeit des PoCs beigetragen hat.

* **Fachliche Tiefe und Pragmatismus:**  
  Die AI priorisiert Features, trennt Must-Haves von Nice-to-Haves und begründet Entscheidungen nachvollziehbar. Das hilft Product Ownern, Entscheidern und Entwicklungsteams, sich auf das Wesentliche zu konzentrieren.

---
### Learnings

Der größte Mehrwert dieses Ansatzes liegt darin, dass mit minimalem Initialaufwand greifbare Anforderungen an einen POC entstehen. 
Das hilft,
* Ideen schnell zu konkretisieren und zu strukturieren,
* die Machbarkeit eines Produkts frühzeitig zu prüfen,
* und bereits in der Frühphase Aufwand und Risiken besser abzuschätzen.

---
### Fazit
Unser KI-Experiment war ein voller Erfolg. Aus einem einfachen fünfminütigen Gespräch entstand in wenigen Stunden ein PoC, den wir direkt an bis zu 100 Testuser ausrollen könnten, um wertvolles Feedback aus der Praxis zu erhalten.

---
### Ergebnis
**Startbildschirm**
![1. PoC_Startbildschirm.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmkwps2k02ozh06rs94o71b75)

**Testkind "Emma" wurde mit drei Kalendereinträgen angelegt**
![2. PoC_Testkind_angelegt.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmkwpthop2ry906rsrq11yhgs)

**Emma's Kalendereinträge**
![3. PoC_Emmas_Einträge.png](https://eu-central-1.graphassets.com/AiE4QoWSSiIQO3k152ugkz/cmkwpwki12zsp07tb6nglmfz7)

**Backup Datenexport**
```
{
  "version": "1.0",
  "exportDate": "2026-01-27T14:39:37.307Z",
  "children": [
    {
      "id": "1769524202165",
      "name": "Mein Baby",
      "birthdate": ""
    },
    {
      "id": "1769524383134",
      "name": "Emma",
      "birthdate": ""
    }
  ],
  "entries": [
    {
      "id": "1769524481737",
      "childId": "1769524383134",
      "date": "2026-01-15",
      "time": "15:33",
      "category": "vitamins",
      "text": "Nimmt ab jetzt Vitamin D",
      "attachments": []
    },
    {
      "id": "1769524643820",
      "childId": "1769524383134",
      "date": "2026-01-14",
      "time": "15:34",
      "category": "doctor",
      "text": "Blutuntersuchung",
      "attachments": [
        {
          "type": "pdf",
          "name": "Blutergebnisse.pdf",
          "data": "data:[…]"
        }
      ]
    },
    {
      "id": "1769524669820",
      "childId": "1769524383134",
      "date": "2026-01-14",
      "time": "15:34",
      "category": "doctor",
      "text": "Blutergebnis: Vitamin D mangel",
      "attachments": []
    }
  ]
}
```
---
### Für wen ist das spannend?
Vor allem für Entscheider:innen, die in einem dynamischen Marktumfeld schnell und fundiert handeln müssen. Spec-Driven Development mit BMAD und AI-Unterstützung ermöglicht es,
* Projekte effizient zu konkretisieren,
* Machbarkeit und Aufwand frühzeitig zu bewerten,
* und Wettbewerbsvorteile durch Geschwindigkeit und Agilität zu sichern.

Gerade wenn Produktlebenszyklen immer kürzer werden und Trends sich schnell ändern, ist die Fähigkeit, aus einer Idee in kürzester Zeit einen PoC samt Roadmap zu generieren, ein echter Game Changer.

---
### Neugierig geworden?
Wir freuen uns über Feedback, Austausch und spannende Diskussionen - und natürlich über alle, die Lust haben, diesen Ansatz in einem Workshop selbst auszuprobieren.


Sven Heinz & Teoman Kinaci, codecentric AG

5 Minuten reden, ein Proof of Concept - unser KI-Experiment mit AI-Assisted Coding und Spec Driven Development

München | Team

Vielen Dank für deine Anfrage. Ich melde mich bei dir.

Vielen Dank für deine Anmeldung. Eine E-Mail zur Bestätigung ist zu dir unterwegs.

Diese Seite ist eine Vorschau. \nKlicken Sie hier\n, um den Vorschaumodus zu verlassen.

Zu deiner Suche haben wir leider keine passenden Blogartikel gefunden. 

Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.

Du hast Fragen oder möchtest dich mit mir austauschen? Gern - trag einfach deine Kontaktdaten ein.

Die \nDatenschutzerklärung\n der codecentric AG habe ich zur Kenntnis genommen und bestätige das mit der Absendung des Formulars.*

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

Ich möchte eure Inhalte abonnieren. Diese Einwilligung kann ich jederzeit widerrufen bzw. den Blog Newsletter abbestellen. Die Datenschutzerklärung habe ich gelesen. Ich bin damit einverstanden, dass die codecentric AG, Hochstr. 11, 42697 Solingen, mich über eigene Dienstleistungen, branchenrelevante Events, Webinare und Publikationen der codecentric AG über die von mir angegebene E-Mail-Adresse informiert. Meine Einwilligung ist freiwillig. Ich kann meine Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (z.B. über den hierfür vorgesehenen Abmeldelink in unserem Newsletter, per E-Mail an datenschutz@codecentric.de oder per Post an die oben genannte Adresse der codecentric AG) erklären. Weitere Hinweise zur Verarbeitung meiner personenbezogenen Daten und zu meinen Rechten als betroffene Person finde ich hier: \nhttps://www.codecentric.de/datenschutzerklaerung\n

Bitte wähle deine/n gewünschte/n Standort/e aus.

Wir möchten dich als Mensch kennenlernen. Erzähle uns, wer du bist, worauf du Wert legst, wie du gerne arbeitest und was du von uns als Arbeitgeber erwartest.

Bitte füge deine Bewerbungsunterlagen ​(mind. Lebenslauf, gerne auch mehr)​​ ​als eine ​PDF-​Datei ​hinzu.

Es gilt die Datenschutzerklärung der codecentric AG, abrufbar unter \nDatenschutzbestimmungen\n. Mit dem Absenden des Formulars bestätige ich, dass ich diese zur Kenntnis genommen habe.

Job application form field placeholder 10

Keine passende Rolle gefunden? Bewirb dich bitte trotzdem initiativ! Jenseits von starren Schubladen zählen für uns vielmehr Motivation, Kompetenz und der Cultural Fit.

Job application form field placeholder 11

Dies ist ein Pflichtfeld, bitte fülle es aus.

Willkommen im Team München

Jetzt für unseren Newsletter anmelden