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

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

Cloud-Native

Data & Machine Learning

Generative KI

Produktentwicklung

IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Kultur & Karriere Podcast

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

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="https://blog.codecentric.de/2017/09/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://media.graphassets.com/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://media.graphassets.com/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://media.graphassets.com/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

When choosing to follow the [API First](https://opensource.zalando.com/restful-api-guidelines/#api-first) approach, ensuring that the actual implementation follows the defined specification can present a significant challenge. Achieving alignment between the specification and implementation is crucial, as it greatly influences the developer experience and the success of the final product.

This article will guide you through a working example to achieve the aforementioned alignment using Spring Boot, REST Assured, swagger-request-validator and Open API Spec.

The API First approach is a development practice that focuses on the design of the API before implementing the rest of the system. The goal is to introduce a reliable API that can be consumed by multiple parties. It is common practice to use an API description language like the [Open API specification](https://www.openapis.org/).

To verify that the implemented system follows the API spec, accepts requests as specified, and returns the correct responses, a test framework like REST Assured in combination with a filter for the API spec validation can be one approach that offers a reliable system.

Following this article, we will create a Spring Boot application that should implement a predefined API spec and verify that the endpoints behave correctly.

## Definition of the API spec
The latest version of the Open API Spec is version 3.1.0. The OPENAPI initiative offers detailed documentation for every element that can be part of the specification. For our specific example, we will be using the following specification:

```
openapi: "3.1.0"
info:
 version: "1.0.0"
 title: "User API"
 description: "API for retrieving user information"
paths:
 /users/{id}:
 get:
 summary: "Retrieves user information based on the user ID"
 parameters:
 - name: id
 in: path
 description: "ID of the user"
 required: true
 schema:
 type: integer
 format: int64
 responses:
 200:
 description: "Successful operation"
 content:
 application/json:
 schema:
 type: object
 properties:
 id:
 type: integer
 format: int64
 name:
 type: string
 email:
 type: string
 404:
 description: "User not found"

```

This rudimentary User API spec has one endpoint to retrieve user information and will return it in case a user with the given ID is present. Otherwise, it will return an HTTP 404 response.

This spec can be imported as a test resource into our Spring Boot application for later use.

## Implementation
At this point, we can assume that a Spring Boot setup has been initialized and that the API spec is included as a test resource.

First of all, we need to add the dependencies for REST Assured and swagger-request-validator to our pom.xml.

```
[...]
<name>spring-boot-api-spec-validation-rest-assured</name> 
<description>Spring Boot Open API Spec Validation with REST Assured and swagger-request-validator</description> 
<properties> 
 <java.version>21</java.version> 
 <swagger-request-validator.version>2.40.0</swagger-request-validator.version> 
</properties> 
<dependencies> 
 <dependency> 
 <groupId>org.springframework.boot</groupId> 
 <artifactId>spring-boot-starter</artifactId> 
 </dependency> 
 
 <dependency> 
 <groupId>org.springframework.boot</groupId> 
 <artifactId>spring-boot-starter-test</artifactId> 
 <scope>test</scope> 
 </dependency> 
 
 <dependency> 
 <groupId>io.rest-assured</groupId> 
 <artifactId>rest-assured</artifactId> 
 <version>5.4.0</version> 
 <scope>test</scope> 
 </dependency> 
 
 <dependency> 
 <groupId>com.atlassian.oai</groupId> 
 <artifactId>swagger-request-validator-restassured</artifactId> 
 <version>${swagger-request-validator.version}</version> 
 </dependency> 
 
 <dependency> 
 <groupId>com.atlassian.oai</groupId> 
 <artifactId>swagger-request-validator-core</artifactId> 
 <version>${swagger-request-validator.version}</version> 
 </dependency> 
</dependencies>
[...]
```

### The users-endpoint

We are starting off by creating a controller package to contain the REST controller that should implement the `/users/{id}` path of the specification.

Throughout this guide, we will make intentional mistakes to show the advantages of the verification mechanism when implementing the API.

The plain controller can look something like this:

```
@RestController 
public class UsersController { 
 
 @GetMapping("/user") 
 public User getUser() { 
 return new User(); 
 } 
}
```

The dummy user class used for the test can be implemented like this:

```
public class User { 
}
```

### First test
Adding a first test class offers a chance to show what the overall structure to enable the API spec validation looks like in combination with REST assured.

```
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT, 
 classes = {SpringBootApiSpecValidationRestAssuredApplication.class}) 
class UsersControllerIntegrationTest { 
 
 private OpenApiValidationFilter openApiValidationFilter; 
 
 @BeforeEach 
 void setUp() { 
 var validator = OpenApiInteractionValidator.createFor("/api-specs/user-api.yaml") 
 .build(); 
 openApiValidationFilter = new OpenApiValidationFilter(validator); 
 RestAssured.baseURI = "http://localhost/"; 
 RestAssured.port = 8080; 
 } 
 
 @Test 
 void getUser() { 
 RestAssured.given() 
 .filter(openApiValidationFilter) 
 .when() 
 .get("/user") 
 .then() 
 .statusCode(200); 
 } 
}
```

Running the test yields the following error message:

```
com.atlassian.oai.validator.restassured.OpenApiValidationFilter$OpenApiValidationException: {
 "messages" : [ {
 "key" : "validation.request.path.missing",
 "level" : "ERROR",
 "message" : "No API path found that matches request '/user'.",
 "context" : {
 "requestPath" : "/user",
 "requestMethod" : "GET"
 }
 } ]
}
```

This tells us that the specification does not contain a path that is annotated with `/user`.
Changing the request path to `/users/1` as specified in the OAS file causes a new problem:

```
com.atlassian.oai.validator.restassured.OpenApiValidationFilter$OpenApiValidationException: {
 "messages" : [ {
 "key" : "validation.response.body.unexpected",
 "level" : "ERROR",
 "message" : "No response body is expected but one was found.",
 "context" : {
 "requestPath" : "/users/1",
 "responseStatus" : 404,
 "location" : "RESPONSE",
 "requestMethod" : "GET"
 }
 } ]
}
```

Since the controller is not fully implemented and returns the default body for a HTTP 404 response, the validator throws the corresponding error message above.

### Implementing the spec (almost)
Offering the correct paths and returning the right response for a missing user will prevent the validator from throwing an exception.

To show another useful feature of the validator, an almost complete and spec-compliant implementation will be implemented. However, one attribute will differ from the spec, so that the validator will throw another error. For this, `email` is changed to `emailAddress` in the implementation, which returns the following error: 

```
com.atlassian.oai.validator.restassured.OpenApiValidationFilter$OpenApiValidationException: {
 "messages" : [ {
 "key" : "validation.response.body.schema.additionalProperties",
 "level" : "ERROR",
 "message" : "Object instance has properties which are not allowed by the schema: [\"emailAddress\"]",
 "context" : {
 "requestPath" : "/users/1",
 "responseStatus" : 200,
 "location" : "RESPONSE",
 "pointers" : {
 "instance" : "/"
 },
 "requestMethod" : "GET"
 }
 } ]
}
```

Validation of request objects is also taking place: Adding a request object and sending a payload that does not match this specification will throw an exception during the test. 

For brevity, the implementation of request validation will not be discussed in full in this article.

A PUT endpoint will be implemented to offer an option to update an existing user’s information.
The specification demands a payload containing an `email` and a `name` that should replace the existing values. Sending a body containing the field `username` instead will throw the following error:

```
Object instance has properties which are not allowed by the schema: [\"username\"]
```

Thereby, the validator offers a powerful tool to assert that the published API is actually covered by the system implementation.

### Spec Validation
Besides validating the implementation against the specification, the validator can also find errors in the API specification that are nonconforming with the OAS standard.

If the `user-api.yaml` were to specify the `{id}` parameter in the path without describing it in the following specification, the validator would throw an error.

```
com.atlassian.oai.validator.OpenApiInteractionValidator$ApiLoadException: Unable to load API spec from provided URL or payload:
	- paths.'/users/{id}'. Declared path parameter id needs to be defined as a path parameter in path or operation level
```

However, the standard conformity of the implementation should be verified beforehand using a tool like [Redocly](https://redocly.com/) or [vacuum](https://quobix.com/vacuum/).

The built-in validation mechanism is useful to detect errors in the provided specification even if it was imported from an external source and contains formatting issues.

## Summary
As seen above, the combination of REST Assured and the swagger-request-validator can be a useful combination of tools to verify the implementation of an Open API Spec in Spring Boot using an API First approach.

The complete source code is available on [GitHub](https://github.com/hkamp-dev/spring-boot-api-spec-validation-rest-assured).

How to validate your Spring Boot implementation when choosing an API first approach?

Auf den ersten Blick möchte man meinen, dass Continuous Delivery etwas für Web 2.0 Firmen ist. Dort liegt es ja auf der Hand, dass man schnell und häufig Software liefern möchte, da es oft ein Wettrennen um das neueste und hippste Feature gibt und Kunden sich sehr schnell neu orientieren können. Auch klar ist, das Web 2.0 Firmen es sich nicht leisten können, Ihre Plattformen länger vom Netz zu nehmen, da Ihr Geschäftsmodell von der Präsenz per se abhängt und daher Zero Downtime Deployment als eine Ausprägung von Continuous Delivery sehr wichtig ist. Soweit so gut.These: Continuous Delivery ist für fast alle Unternehmenstypen eine wettbewerbsrelevante Fähigkeit.Betrachten wir zum Zwecke der Herleitung zunächst einge Trends in Volkswirtschaften des 21. Jahrhunderts:<ul><li>Kürzere Produktzyklen – In vielen Branchen verkürzen sich die Produktzyklen drastisch. Paradebeispiel sind dabei für jedermann wahrnehmbar mobile elektronische Geräte.</li><li>Optimierte Geschäftsprozesse – Verdrängung findet unter anderen in reiferen Märkten auch durch bessere Geschäftsprozesse statt. Ein Gutes Beispiel ist Amazon bezogen auf den Versandhandel.</li><li>Abhängigkeit von IT -Durch die immer tiefere Durchdringung des Geschäfts mit IT, um effektiver und automatisierter zu sein, ist die Abhängigkeit von funktionierender und robuster IT deutlich gestiegen.</li><li>Globaler Wettbewerb – Die Globalisierung wird für die vorgenannten Trends zum „Brandbeschleuniger“, da jedes Unternehmen mit den Besten global konkurrieren muss.</li></ul>Und nun ein Blick auf Continuous Delivery:Auf den ersten Blick bedeutet Continuous Delivery die Automatisierung des Lieferprozesses der Software in alle relvanten Umgebungen inkl. Produktionsumgebung. Auf den zweiten Blick erfordert diese Automatisierung (damit ich mich das auch traue) einen sehr hohen Reifegrad einer Vielzahl von Disziplinen, wie Architektur (gute Modularisierung), Testautomatisierung (Unit-, Itegrations-, Akzeptanz- und Performancetests), Software Craftmanship (Clean Code, etc.), Requirement Engineering (Abnahmekriterien als Teil des Requirements, Schnitt der Requirements), Entwicklungsprozesse, etc. Continuous Delivery ist also ein fundamentaler Qualitätstreiber für den gesamten Entwicklungsprozess.Selbst wenn es nicht das Ziel ist schnell und häufig zu liefern, erreicht man so doch deutliche Verbesserung, was Produktivität, Qualität und Passgenauigkeit der Software angeht.Und nun der „Merge“:Um IT als Untersützung bzgl. der oben genannten globalen Trends erfolgreich zu betreiben, benötigen wir Qualität, Produktivität und oft auch eine höhere Geschwindigkeit. Alles Faktoren, die sich durch die Umsetzung von Continuous Delivery auch in klassischen Unternehmen verbessern. Was meint Ihr?Thomas

Continuous Delivery – Nur etwas für Web 2.0 Firmen?

Continuous Delivery ist ein Set von agilen Praktiken und Konzepten zur Automatisierung des Software – Lieferprozesses, mit denen häufige und stressfreie Releases möglich werden. Continuous Delivery geht dabei über Continuous Integration und Continuous Deployment hinaus. Es umfasst agiles Testen, hochgradige Automatisierung,  cross-funktionale Teams (Entwickler, Tester, Administratoren) und Lean Thinking.Hört sich einfach an. Ist es aber nicht.Es müssen eine Vielzahl von Themen / Disziplinen und Aspekte in hoher Qualität zusammenwirken, wie nachstehende Übersicht zeigt: <a href="https://media.graphassets.com/PuI1tikKQmDIebTnhw2w"><img title="Continuous_Delivery - Orientierung" src="https://media.graphassets.com/PuI1tikKQmDIebTnhw2w" alt width="640" height="381" /></a> Sie werden sich jetzt nun vielleicht fragen, wie Sie damit zurechtkommen sollen…Für eine erste Standortbestimmung haben wir eine kleine grafische Online Umfrage gebaut, die Ihnen hilft einzuordnen, wo Sie stehen. Wir antworten Ihnen mit unserer Experteneinschätzung als erste Orientierung. Wenn Sie sich die Fähigkeit Continuous Delivery zu betreiben erschliessen wollen, haben Sie wahrscheinlich einiges an Arbeit vor sich. Wir möchten Ihnen dabei bei den Aufgaben helfen, die Sie sich nicht selbst zutrauen.Umfrage: Continuous Delivery – Haben Sie Agilität im Blut?

Continuous Delivery – Haben Sie Agilität im Blut?

Seit ein paar Tagen bieten wir im Kontext von Software-Projekten mit codecentric ein Software Leasing gemeinsam mit einem Partner an. Damit wollen wir unseren Kunden helfen, den Zielkonflikt zwischen „Save your Money“ und „Invest in your Future“ aufzulösen.Einzelheiten dazu <a href="https://hubs.ly/H0tDLrK0" target="_blank">findet ihr hier</a> .Ich möchte in diesem Blogpost aber gar nicht so sehr das Angebot selbst anpreisen, auch wenn ich es sehr gelungen finde und hoffe, dass es angenommen wird. Wir wollen damit unseren Kunden helfen, ihre Zukunft offensiv auch jetzt während der Corona-Pandemie in die Hand zu nehmen. Und genau darum geht es ja als Dienstleister: den Kunden zu bieten, was sie wirklich brauchen. Nur: Zu wissen, was die Kunden brauchen, das ist manchmal gar nicht so einfach.Deswegen möchte ich viel mehr von der Entwicklung des Angebotes berichten, da es sehr schön zeigt, wie aus Ideen Hypothesen werden und dann ein konkretes Produkt – in sechs Wochen.Bei codecentric beraten und helfen wir Kunden regelmäßig bei der Validierung neuer Geschäftsideen. Zum Beispiel im Bereich Smart Data, wie anschaulich in einem <a href="https://blog.codecentric.de/2020/03/wie-man-data-science-projekte-nicht-in-die-poc-sackgasse-manoevriert/">Blogpost von Marcel Mikl</a> beschrieben, in unseren Bereichen <a href="https://www.codecentric.de/leistungen/digital-enablement">Digital Enablement</a> und <a href="https://www.codecentric.de/leistungen/digital-product-development/codecentric-digitization-labs">Digitization Labs</a> . Die aktuelle Situation hat uns dann aber auch selbst vor die Herausforderung gestellt, unser Portfolio zu überdenken und zu überlegen, wie wir unseren Kunden angesichts der neuen – ja eigentlich nie dagewesenen – Herausforderungen ein Mehr an Service und Hilfestellung bieten können – problemorientiert, zielgerichtet und effizient.<h2>Corona hält die Welt in Atem: Innovation oder Sicherheit?</h2>Alles begann Anfang März, als sich die Ereignisse überschlugen. Am 2. März sagten wir die Einweihungsfeier mit 200 Gästen für unsere nagelneue Location in München ab. Ein paar Tage später bildeten wir ein Krisenteam. Mitte März waren wir dann mit über 500 Menschen in 16 Standorten europaweit im Homeoffice.Wir waren erstmal schwer mit uns selbst beschäftigt: Sicherheit für unsere Kolleg/innen schaffen, Kunden beim Übergang in Remote-Arbeit unterstützen, lernen, wo wir Risiken haben, dass uns Projekte wegbrechen, den Vertrieb so aufstellen, dass wir damit umgehen können und uns auf Themen wie Kurzarbeit vorbereiten, falls es noch viel schlimmer wird. Ende April waren wir nach wie vor angespannt, aber schon verhalten optimistisch und wussten, dass wir nicht akut in eine existenzielle Krise geraten sind.<h2>Produktvalidierung in a Nutshell</h2>Ich hatte zum ersten Mal wieder Zeit, ein wenig zu verschnaufen und nutzte sie, um darüber nachzudenken: Was bedeutet die Krise eigentlich für unsere Kunden? Was macht das mit ihnen? Ein erfolgreiches Produkt braucht einen Markt, und es muss ein echtes Problem lösen. Bevor wir ein Produkt entwickeln, entwerfen wir also eine Problemthese.<h2>Problemthese: Cash vs. Innovation</h2>Unsere Kunden müssen – wie auch wir – Liquidität im Unternehmen halten, um durch die Krise zu kommen. Wenn sie aber dann Softwareprojekte stoppen, die in ein bis zwei Jahren eine wichtige Funktion für Markterfolg haben, dann würden sie jedoch ihre Chancen in der Zukunft nach Corona verringern. Denn Innovation benötigt eine gewisse Vorlaufzeit, und Innovation muss zur richtigen Zeit an die richtige Zielgruppe gebracht werden, um erfolgreich zu sein. Innovation benötigt einen Vorsprung – vor tatsächlichem Bedarf, vor Marktbegleitern etc. Auf bessere Zeiten zu warten, um Investitionen zu vermeiden und die Bilanz des Unternehmens stabil zu halten, bedeutet demnach wahrscheinlich gleichzeitig einen Rückstand zu erzeugen, den man schwerlich wieder aufholen kann. Im Angesicht einer wankenden Wirtschaftslage mit ungewissem Ausgang sinkt die Risikobereitschaft natürlich immens. Wahrscheinlich ist es also, erstmal – gefühlt – auf Nummer sicher zu wirtschaften. Gefühlt deswegen, weil diese Sicherheit zwar als Momentaufnahme stimmen mag, doch langfristig das genaue Gegenteil bedeuten kann. Was für eine Zwickmühle, in der sich viele Unternehmen aktuell befinden müssen!Soweit ist das skizzierte Problem aber noch reine Spekulation. Deswegen habe ich Führungskräfte von ein paar Kunden angerufen, die ich gut kenne, und sie gefragt, ob das tatsächlich ein für sie relevantes Problem ist. Unisono wurde mir das bestätigt. Ich hatte also eine erste Validierung der Problemthese. Diese bietet die Grundlage, um an Lösungsansätzen zu arbeiten.Ich erinnerte mich an ein paar Projekte aus den 90ern und 2000ern, bei denen u. a. die edlen und teuren Sun-Hobel über Leasingmodelle in Rechenzentren finanziert wurden. Der Clou dabei: Zwischen Beschaffung und produktiver Nutzung sind viele Monate vergangen. Die Leasingverträge sahen vor, erst bei produktiver Nutzung zu zahlen. So kam ich zur Produkthypothese: das Dilemma „Cash vs. Innovation“ auflösen, indem wir beides möglich machen.<h2>Produkthypothese: Pay-as-you-earn</h2>Die Idee: Wir entwickeln ein Leasingmodell, um Softwareprojekte, die wir mit dem Kunden machen, in ein „Pay-as-you-earn“-Modell umzuwandeln.Wieder rief ich ein paar Kunden an, diesmal aber auch einen Bekannten aus einer Wirtschaftsprüfungsgesellschaft, und bekam positives Feedback, ebenso ein paar Hinweise, dass es sich um ein handelbares Wirtschaftsgut handeln müsse, damit es rechtlich funktioniert. Damit hatte ich also eine erste Validierung meiner Produkthypothese.In unserem Netzwerk fand ich den kompetenten Partner, um die Hypothese weiter auszuarbeiten: die Deutsche Anlagen Leasing ist spezialisiert auf Leasing allgemein, aber auch auf Leasing im IT-Sektor, und zeigte sich interessiert an der Idee. Innerhalb von codecentric konnte ich ebenfalls einige Menschen gewinnen, um ein cross-funktionales Team zusammenzustellen, das eine 360-Grad-Aufbereitung des Themas ermöglichte: aus dem Community Management für die Unterstützung bei der Contenterstellung, aus dem Finance-Team für den Blick auf rechtliche und wirtschaftliche Aspekte sowie zwei Kollegen aus den Bereichen Vertrieb und Consulting, um einerseits die Kundenseite, aber andererseits auch die Perspektive unserer eigenen Projektteams zu vertreten. Auch die Tatsache, die eigenen Kolleg/innen in nur wenigen Tagen für das Thema gewinnen zu können, war eine eine weitere Komponente der Validierung.<h2>Vom Planen ins Umsetzen</h2>Nun mussten alle Beteiligten einmal zusammen an einen (virtuellen) Tisch, um gemeinsam herauszuarbeiten, wie die Zusammenarbeit aussehen soll, was das konkrete Modell beinhaltet und bedeutet und wie wir die richtige Ansprache finden.Gerade einmal zwei Wochen intensive Fleißarbeit und Reviews später – auch hier wieder unter Einbeziehung von Kunden-Feedback – hatten wir unser gemeinsames Angebot marktfähig. Unsere Schnelligkeit war unter anderem auch deshalb möglich, weil wir ein Unternehmen mit flachen Hierarchien und somit wenig Freigabeprozessen sind. Nun noch intern den Vertrieb schulen, und es kann losgehen. Das initiale Team ist schon wieder aufgelöst; die nötige Vorarbeit ist getan. Ich bin jetzt gespannt, wie unsere Kunden darauf reagieren.Was ich euch mit dieser Geschichte gerne einmal kurz und knapp veranschaulichen möchte, ist, dass hypothesengetriebene Ansätze funktionieren, und wie sie funktionieren. Für mich besonders spannend war es, dieses Vorgehen, das wir bei unseren Kunden ja sehr häufig begleiten, mal auf ein uns relativ fremdes Thema anzuwenden und sich nur auf die hochfrequenten Feedback-Loops zu konzentrieren. Spannend auch, wie sich die Kette aus Thesen und Validierungen entwickelt hat. Und wie wir gelernt haben, als cross-funktionales Team zu arbeiten, quasi als Nebeneffekt.Nun bleibt es abzuwarten, ob Software Leasing mit codecentric angenommen wird. Wenn ja, ist diese Produktentwicklung unter Berücksichtigung der investierten Zeit ein voller Erfolg.

Zwischen Innovation und Corona: Trotz Krise an der Zukunft arbeiten

Prokurist

Sales Manager

IT-Consultant

Senior IT Consultant

Überall wird von der Cloud geschwärmt: Grenzenlose Skalierung und unzählige Features sind bereits „out of the box“ verfügbar. Das alles gibt es zu unschlagbar günstigen Preisen. Das Thema Nachhaltigkeit kommt dabei selten zur Sprache. Rechenzentren verbrauchen heute aber schon ähnlich viel Energie wie Kleinstädte und der Energiebedarf <a href="https://www.sueddeutsche.de/wirtschaft/cloud-energieverbrauch-strom-digitalisierung-1.5529289" target="_blank">steigt immer weiter an</a> . Dabei stellen sich in Bezug auf Nachhaltigkeit andere Fragen, als wir es in der IT normalerweise gewohnt sind: Ist der schnellste Server wirklich notwendig? Wie wirkt sich ein kleineres Modell auf den CO2-Ausstoß aus? Können wir unsere Cloud-Emissionen durch die Nutzung von Serverless-Services optimieren oder behalten wir lieber die Zügel in der Hand?Um diese Fragen zu beantworten, müssen wir zunächst eine Idee von unseren aktuellen Cloud-Emissionen bekommen. Erst auf Basis des Ist-Zustands lassen sich mögliche Verbesserungen feststellen und der CO2-Verbrauch optimieren.<h2>Cloud-Emissionen-Analyse der drei großen Anbieter im Vergleich</h2>Mittlerweile haben die großen Cloud-Provider das Thema Nachhaltigkeit für sich entdeckt und werben mit ambitionierten Nachhaltigkeitszielen – egal ob Amazon Web Services (<a href="https://sustainability.aboutamazon.com/environment/the-cloud" target="_blank">AWS</a> ), <a href="https://azure.microsoft.com/de-de/global-infrastructure/sustainability/#overview" target="_blank">Azure</a> von Microsoft oder die Google Cloud Platform (<a href="https://cloud.google.com/sustainability?hl=de" target="_blank">GCP</a> ). Im Folgenden werfen wir einen Blick auf die Tools, die Emissionen unserer Cloud-Architektur messen und aufbereiten.<h3>Emissionen bei Amazon Web Services messen</h3>AWS gibt eigene Best Practices im Well-Architected Framework heraus. Bei der <a href="https://www.youtube.com/watch?v=8_Xs8Ik0h1w&t=5299s" target="_blank">re:Invent 2021</a> hat das Unternehmen die <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sustainability-pillar.html" target="_blank">Sustainability Pillar</a> in die Sammlung aufgenommen. Die Dokumentation ist aktuell aber noch ausbaufähig. Handlungsanweisungen beschreibt AWS oft nur oberflächlich, zum Beispiel folgende Empfehlung: „Choose regions near Amazon renewable energy projects“. Die Information, welche Standorte mit erneuerbaren Energien arbeiten, bleibt Amazon aber schuldig. Das müssen wir uns selbst zusammensuchen.Stichwort erneuerbare Energien: AWS will bis 2025 alle Services zu 100 % mit erneuerbaren Energien betreiben (<a href="https://sustainability.aboutamazon.com/environment/the-cloud?energyType=true" target="_blank">Quelle</a> ). Aktuell werden allerdings einige Regionen lediglich über Zertifikate ausgeglichen. Dazu zählt auch die für die deutschen Datenschutzanforderungen relevante Region eu-central-1 (Europe / Frankfurt).Mit dem kostenlosen <a href="https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/what-is-ccft.html" target="_blank">Carbon Footprint Tool</a> bietet AWS eine Übersicht der Emissionen, die genutzte Services verursachen. Das Tool befindet sich in der AWS Management Console unter Billing – Cost & Usage Reports. Es wird die Berechtigung sustainability:GetCarbonFootprintSummary benötigt, um das Dashboard aufrufen zu können.<div><img src="https://media.graphassets.com/vaA74v6vQOWUw4iaiDnU" alt="AWS - Carbon Footprint Tool – Verschiedene Diagramme der Emissionen nach Regionen, Services und Zeiträumen" width="1024" height="441" />AWS: Verschiedene Diagramme der Emissionen nach Regionen (Mitte) und Services (Rechts).</div>Die Angabe der Emissionen erfolgt in Tonnen CO2-Äquivalente (MTCO2e, metric tons of carbon dioxide-equivalent) und wird monatlich aktualisiert. Amazon benötigt bis zu drei Monate, um die Daten zu sammeln und aufzubereiten. Die gesammelten Daten lassen sich nach Service, Region und in unterschiedlichen Zeiträumen darstellen. Welche Services sich aber in der Gruppe „Other“ verstecken, können wir aktuell nur vermuten. Hier wäre ein höherer Detailgrad hilfreich, um die Emissionen gezielt reduzieren zu können.Besonders interessant ist außerdem die Ansicht „Weg zu 100 % erneuerbarer Energie“, die eine Schätzung der zukünftigen Emissionen ist. Die Berechnung beruht auf den bisher genutzten Services und Regionen im gesamten AWS-Account.<div><img loading="lazy" src="https://media.graphassets.com/ytUHrRzQjO4WjvLXkOEe" alt="AWS - Carbon Footprint Tool – Diagramm, das den Weg zu 100 % erneuerbarer Energie darstellt" width="1024" height="378" />AWS: Diagramm, das die voraussichtlich ausgestoßenen Emissionen darstellt</div>Fazit: AWS hat einen ersten Schritt getan, um die Entwicklungsteams auf dem Weg zu einer nachhaltigeren Cloud-Architektur zu unterstützen. Es ist aktuell aber auch nicht mehr als ein erster Schritt. Das zeigt sich nicht nur am Detailgrad des Sustainability Pillars. Eine nächste, sinnvolle Verbesserung könnte die Übersicht des Strommixes in den Regionen sein. Und auch wenn das Carbon Footprint Tool einen guten Überblick gibt, sind nicht alle Auswertungen detailliert genug.<h3>Verfügbare Werkzeuge von Microsoft Azure</h3>Auch Microsoft strebt bis 2025 an, alle angebotenen Services ausschließlich durch erneuerbare Energie zu betreiben (<a href="https://azure.microsoft.com/de-de/global-infrastructure/sustainability/#carbon-benefits" target="_blank">Quelle</a> ). Aber auch hier fehlt eine Übersicht des aktuell genutzten Strommixes nach Regionen. Bei der Auswahl müssen sich User auf einzelne Ankündigungen von Azure verlassen, wie die Nachricht der Eröffnung eines <a href="https://news.microsoft.com/europe/2021/11/16/microsoft-opens-its-sustainable-datacenter-region-in-sweden-creating-new-opportunities-for-a-cloud-first-sweden/" target="_blank">neuen Rechenzentrums in Schweden</a> , das Microsoft mit 100 % erneuerbaren Energien betreibt.Vergleichbar mit AWS bietet auch Azure ein <a href="https://appsource.microsoft.com/en-us/product/power-bi/coi-sustainability.emissions_impact_dashboard?tab=Overview" target="_blank">Emissions Impact Dashboard</a> an. Die verursachten Cloud-Emissionen stellt es ebenfalls in Tonnen CO2-Äquivalente dar und Nutzer*innen können sie im zeitlichen Verlauf, nach Regionen und Services analysieren. Da für den Zugriff auf das Dashboard allerdings eine „Power BI Pro“-Lizenz benötigt wird, ist die Analyse nicht kostenlos.<div><img loading="lazy" src="https://media.graphassets.com/kc0MPTRVTF6oq6JEZAmF" alt="Azure – Emissions Impact Dashboard – Verschiedene Diagramme der Emissionen nach Services, Regionen und Zeiträumen" width="1024" height="578" />Emissions Impact Dashboard – Verschiedene Diagramme der Emissionen nach Services, Regionen und Zeiträumen (<a href="https://appsource.microsoft.com/en-us/product/power-bi/coi-sustainability.emissions_impact_dashboard?tab=Overview" target="_blank">Quelle</a> )</div>Eine Prognose in die Zukunft gibt es nicht, dafür lässt sich der Vergleich mit einer ähnlichen Infrastruktur im eigenen Rechenzentrum („On-Premises“) ermitteln. Da hierfür lediglich die Selbsteinschätzung der Effizienz der aktuellen Infrastruktur abgefragt wird, basieren die Ergebnisse nur auf groben Schätzungen.Fazit: Microsoft hat sich ebenfalls in Bewegung gesetzt und mit dem Emissions Impact Dashboard ein Analyse-Tool zur Verfügung gestellt. Leider kann nicht jedes Team darauf zurückgreifen, da die kostenpflichtige Lizenz eine Einstiegshürde darstellt. Um nach der Analyse des Ist-Zustandes mit der Optimierung unserer Architektur starten zu können, sollte Microsoft Hilfestellungen und Best Practices nachliefern. Aktuell fehlen sie noch.<h3>Die Tools der Google Cloud Platform im Überblick</h3>Google gibt an, bereits heute CO2-neutral zu sein. Bei genauerem Hinsehen erreichen sie das aktuell allerdings nur über Zertifikate und Emissionsausgleich. Im Gegensatz zu AWS und Azure visiert Google erst das Jahr 2030 an, um 100 % erneuerbare Energien zu nutzen (<a href="https://cloud.google.com/sustainability?hl=de" target="_blank">Quelle</a> ).Dennoch lässt sich sagen, dass Google im direkten Vergleich am besten abschneidet: Mit dem <a href="https://cloud.google.com/carbon-footprint?hl=de" target="_blank">Carbon Footprint Reporting</a> bietet Google eine kostenlose Übersicht der verursachten Emissionen an, die Anwender*innen direkt über den Billing-Account nutzen können. Auch hier lassen sich die Daten nach Ressourcen und Regionen filtern und im zeitlichen Verlauf betrachten.<div><img loading="lazy" src="https://media.graphassets.com/0v4BsG5tQv2664YfyaNX" alt="GCP – Carbon Footprint Reporting – Verschiedene Diagramme der Emissionen nach Zeiträumen und Projekten" width="1024" height="434" />GCP: Diagramme der Emissionen nach Monaten (links) und Projekten (rechts)</div>Im Vergleich zur Konkurrenz bietet GCP aber deutlich mehr Details. Das Dashboard ordnet die Emissionen einzelnen Services und Projekten zu. Damit können die Nutzer*innen die größten CO2-Verursacher einfacher erkennen und optimieren.Allerdings stellt Google nicht nur bereits verursachte Emissionen dar. Mit dem <a href="https://cloud.withgoogle.com/region-picker/" target="_blank">Region Picker</a> bietet das Unternehmen ein Werkzeug an, um die passende Region für das Hosting der genutzten Services auszuwählen. Neben dem Preis und der Latenz können Anwender auch den CO2-Fußabdruck einbeziehen. Die Faktoren fließen auch direkt bei der Auswahl einer Region ein: Regionen mit besonders hohem Anteil an erneuerbaren Energien hebt das Tool mit einem grünen Blatt-Icon hervor und sie sind direkt im Kontext der ausgeführten Aktion ersichtlich. Anders als bei AWS und Azure müssen wir die Informationen nicht selbst suchen.<div><img src="https://storage.googleapis.com/gweb-cloudblog-publish/images/Cloud_Run_region_selector.max-700x700.jpg" loading="lazy" alt="Google Cloud – Auswahl der Region mit Indikator für geringe Emissionen" width="700" height="469" />GCP: Auswahl der Region mit Indikator für geringe Emissionen</div>Fazit: Obwohl das Dashboard kostenlos ist, bietet Google viele Details. Außerdem gibt es bereits eine Übersicht der <a href="https://cloud.google.com/architecture/reduce-carbon-footprint?hl=de" target="_blank">Best Practices</a> zur Reduktion der Cloud-Emissionen. Google punktet außerdem mit zusätzlichen Informationen im Kontext der Services (Stichwort: Auswahl der Regionen). Dadurch haben wir die Möglichkeit, uns aktiv für eine nachhaltigere Lösung zu entscheiden.<h3>Ausblick</h3>Es ist auch heute schon möglich, die Emissionen unserer Cloud-Architektur zu ermitteln, egal welchen der drei großen Cloud-Provider wir nutzen. Im Artikel haben wir die aktuell verfügbaren Tools von AWS, Azure und Google Cloud betrachtet. Wir können aber mit Sicherheit davon ausgehen, dass sie in den nächsten Monaten jede Menge Verbesserungen der Tools und Dokumentationen veröffentlichen.Microsoft (Dashboard nicht kostenlos) und Amazon (Dashboard mit wenigen Details) müssen hier nachziehen, um den Anschluss an die GCP nicht zu verlieren. Währenddessen kann sich Google darauf fokussieren, weitere Orientierung direkt im User Interface zu bieten und so beim Aufbau einer nachhaltigeren Architektur zu unterstützen.Im nächsten Artikel der Reihe Green Cloud werden wir Möglichkeiten betrachten, um die gemessenen Emissionswerte zu reduzieren. Das Ziel ist, neben der Verfügbarkeit, der Performance und <a href="https://blog.codecentric.de/2020/04/cloud-fruehjahrsputz-aws-kosten/">dem Preis</a> noch einen weiteren Faktor in unsere Cloud-Strategie einfließen zu lassen: die Nachhaltigkeit unserer Software.

Green Cloud: Emissionen unserer Cloud-Architektur messen

Mit den <a href="https://aws.amazon.com/de/blogs/aws/introducing-cloudfront-functions-run-your-code-at-the-edge-with-low-latency-at-any-scale" target="_blank">CloudFront Functions</a> bietet AWS die Möglichkeit, den Funktionsumfang von CloudFront um kleine JavaScript-Funktionen zu erweitern. AWS führt diese Funktionen direkt an den Edge-Locations aus und ermöglicht es dadurch, alle ankommenden Requests auszuwerten oder zu bearbeiten, bevor sie an die Backend-Systeme weitergesendet werden. 

Das folgende Beispiel zeigt eine einfache *CloudFront Function*, die einen ankommenden Request als `event` übergeben bekommt. Diesem Request wird ein Header hinzugefügt, bevor der Request zur weiteren Verarbeitung wieder an CloudFront übergeben wird. 
```javascript
function handler(event) {
 const request = event.request;
 request.headers['custom-header'] = { value: "some value"};
 return request;
}
```
Da die Funktionen für jeden Request ausgeführt werden, ist es besonders wichtig, dass die Ausführung performant und effizient erfolgt. Ein Grund dafür, dass die CloudFront Functions so performant sind, ist der <a href="https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/functions-javascript-runtime-features.html" target="_blank">reduzierte JavaScript-Funktionsumfang</a>. Es sind hauptsächlich ES5- und ausgewählte ES6- und ES7-Features verfügbar. Damit fallen auch `import`- und `export`-Statements weg, die genutzt werden, um Code als Node-Module in anderen Dateien wiederzuverwenden.

```javascript
// module.js
export function myExportedFunction(event) {...}

// Im Test kann die exportierte Funktion kann nach dem Import genutzt werden
import { myExportedFunction } from './module.js';
```

Für die Anbindung der Funktion an CloudFront ist der fehlende `export` kein Problem, da lediglich der Pfad zur JavaScript-Datei benötigt wird. Wenn wir die Funktion aber mit Unit-Tests absichern wollen, stoßen wir auf Probleme. Amazon bietet zwar die Möglichkeit, CloudFront Functions manuell in der AWS-Konsole zu testen. Dies kann automatisierte Tests allerdings nicht ersetzen.

![cf_fn_testing.png](https://media.graphassets.com/PUvJ7GRhR8WI6FJbwKZu "Screenshot aus AWS Console: CloudFront Functions können über das CloudFront-UI getestet werden.")

Im Folgenden beschreibe ich zwei Möglichkeiten, die es ermöglichen, unsere CloudFront Functions zu testen, auch wenn wir sie nicht als Node-Module exportieren können.

## Lösung 1: Function
Die JavaScript-Funktion `readFileSync` erlaubt es, Dateien einzulesen und im JavaScript-Code zu nutzen. Anschließend lässt sich der eingelesene Code über den `Function`-Konstruktor initialisieren. Wir können jetzt unsere Tests wie gewohnt schreiben.

```javascript
const code = fs.readFileSync('./cloudfront-function.js');
const handler = new Function(`return ${code.toString()}`)();

// Die Funktion im Folgenden getestet werden
const result = handler(event);
```

Der Vorteil dieser Lösung ist, dass sie ausschließlich JavaScript-Features nutzt. Es ist also keine zusätzliche Dependency notwendig. Auf der anderen Seite müssen wir etwas mehr Code schreiben, um die Datei zu lesen und als Funktion zu initialisieren. Eine Alternative zum `Function`-Konstruktor ist die <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/eval" target="_blank">eval</a>-Funktion, die ebenfalls JavaScript-Code aus einem String parsen kann.

⚠️ **Achtung!** Beide Lösungen sind mit Vorsicht zu genießen. Das Einlesen von Code aus externen Quellen stellt ein Sicherheitsrisiko dar und sollte nur in einem gesicherten Umfeld stattfinden. In unserem Fall werden die Funktionen aber nur in Tests genutzt und öffnen keine Schwachstellen in unserem Produktivcode.

## Lösung 2: rewire
Die Bibliothek <a href="https://github.com/jhnns/rewire" target="_blank">rewire</a> erlaubt es, auf nicht-exportierte Properties und Funktionen zuzugreifen. Diese können entweder mit `__get__` gelesen oder mit `__set__` geschrieben werden. In unserem Fall reicht die Get-Funktion, der wir den Namen der gesuchten Funktion übergeben. Die Bibliothek gibt uns dann Zugriff auf die eigentlich nicht exportierte Funktion.

```javascript
const handler = rewire('./extract-ids-from-path.js').__get__('handler');
```

Im Vergleich zur ersten Lösung können wir hier also mit weniger Code an die zu testende Funktion kommen. Dafür müssen wir aber eine zusätzliche Dependency zu unserem Projekt hinzufügen.

## Fazit
Auch wenn es auf den ersten Blick ungewohnt ist, gibt es verschiedene Ansätze, um unsere CloudFront Functions zu testen. Je nach Präferenz können wir ausschließlich JavaScript nutzen oder eine zusätzliche Dependency hinzufügen, um etwas Code sparen. Egal für welchen Weg wir uns entscheiden: Unser Code sollte automatisiert getestet werden, um nicht auf manuelle Tests über die AWS-Konsole angewiesen zu sein.

AWS CloudFront Functions testen

Die ökologische Nachhaltigkeit eines Systems ist aktuell häufig noch kein Thema. Nachhaltigkeit bedeutet für mich in diesem Kontext die Reduktion der verursachten Emissionen durch gesenkten Ressourcenverbrauch – egal ob die Emissionen beim Cloudprovider im Rechenzentrum oder beim Datentransport zum User entstehen. Je früher diese Anforderung mitgedacht wird, desto einfacher kann sie schon in die Architektur einfließen.

Im Folgenden möchte ich Ideen für nachhaltige Architekturentscheidungen beschreiben und dabei auch einen Blick auf andere, nicht-funktionale Anforderungen werfen. Häufig können wir durch eine kostengünstigere oder performantere Lösung auch den Stromverbrauch unseres Systems senken. Der Fokus soll hierbei auf der Public Cloud liegen. Falls ihr ein bereits bestehendes System optimieren wollt, ist es sinnvoll, <a href="https://www.codecentric.de/wissens-hub/blog/emissionen-cloud-architektur-messen" target="_blank">zunächst den aktuellen Verbrauch zu analysieren</a>.

## Wahl der Cloud-Region
Die erste Entscheidung vor dem Deployment einer Ressource in die Cloud ist der Standort. Heutzutage bieten alle Cloud-Anbieter ihre Services weltweit in unterschiedlichen *Regions* und *(Availability) Zones* an. Relevante Faktoren für die Wahl eines Standorts sind die Kosten und Ausfallsicherheit. Auch die Entfernung und damit die <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a5.html" target="_blank">Latenz</a> zu den Usern spielt eine Rolle.

Möchte man ein möglichst emissionsarmes Deployment der Anwendung, ist der wichtigste Faktor der <a href="https://cloud.google.com/architecture/reduce-carbon-footprint#choose_the_most_suitable_cloud_regions" target="_blank">Strommix vor Ort</a>. Je nach Land und Region unterscheidet sich der Anteil erneuerbarer Energien im Strom stark. Google bietet mit dem <a href="https://cloud.withgoogle.com/region-picker" target="_blank">Region Picker</a> ein Tool an, um die Faktoren Preis, Latenz und Strommix zu gewichten und den optimalen Standort zu ermitteln. Bei den anderen Anbietern können wir mithilfe <a href="https://aws.amazon.com/de/blogs/architecture/how-to-select-a-region-for-your-workload-based-on-sustainability-goals" target="_blank">externer Services herausfinden</a>, in welchen Regionen der Anteil erneuerbarer Energien hoch ist.

Der Strommix sollte aber nicht das einzige Argument für eine Region sein. Jedes Datenpaket gelangt über eine Vielzahl von Systemen von unserem Server zum User und zurück. Je weiter die Strecke, desto mehr Zeit wird benötigt. Aber auch der Stromverbrauch steigt durch die Länge der Strecke an. Wenn unsere Anwendung außerhalb des eigenen Systems Datenverkehr verursacht, ist uns auch dieser Stromverbrauch zuzuschreiben. Hier gilt es also, zwischen dem besseren Strommix einer Region und der Entfernung zu unseren Usern abzuwägen.

## Managed Services
Bei den grundlegenden Compute- und Storage-Services haben wir aber häufig die Wahl zwischen mehreren Alternativen. Eine davon sind <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_hardware_a4.html" target="_blank">Managed Services</a>: Wir können Code ohne Server und Container mit *Google Cloud Functions* ausführen und Datenbanken ohne Updates und Migrationen mit *AWS DynamoDB* betreiben. 

Leider geben Anbieter kaum Informationen über Architektur und Auslastung der Managed Services heraus. Wir können uns an dieser Stelle nur darauf verlassen, dass die Serverless-Angebote auf höchste Auslastung optimiert werden. Dadurch sparen sich AWS, Azure und Co. Stromkosten und steigern ihre Marge. Wir können uns von einer höheren Auslastung weniger betriebene Hardware und damit einen geringeren Stromverbrauch erhoffen.

Generell muss der Service aber immer zuerst <a href="https://cloud.google.com/architecture/reduce-carbon-footprint#choose_the_most_suitable_cloud_services" target="_blank">zum zu lösenden Problem passen</a>. Wenn eine Funktion beispielsweise 24/7 benötigt wird, explodieren die Kosten von FaaS-Angeboten, wie *AWS Lambda* im Vergleich zu einer eigenen Serverinstanz schnell. Mit „As-a-Service“-Angeboten können wir aber die Verantwortung für die Auslastung unseres Systems an die Cloudprovider abgeben. 

## Leerlauf reduzieren
Wir alle kennen Test- und Entwicklungssysteme, die 24/7 betrieben werden – auch wenn niemand mit ihnen arbeitet. Ressourcen, die nicht benötigt werden, sollten alleine schon aus Kostengründen heruntergefahren werden. Dies reduziert auch den Stromverbrauch und damit die ausgestoßenen Emissionen. Dadurch können wir einen großen Einfluss nehmen, da viele Server im <a href="https://www.computerweekly.com/feature/A-waste-of-energy-Dealing-with-idle-servers-in-the-datacentre" target="_blank">Leerlauf auf Arbeit warten</a>.

Verarbeitet unser System nicht zeitkritische Workloads, können wir hier ebenfalls ansetzen. Ein typisches Beispiel sind Batchjobs, die in der Nacht aufwendige Berechnungslogiken durchführen. Wir können diese Workloads zeitlich verlagern und so Kosten sparen, da die Cloudprovider ihre Server günstiger anbieten, wenn die Auslastung gering ist. Ein Beispiel sind die *<a href="https://aws.amazon.com/de/ec2/spot/instance-advisor" target="_blank">EC2-Spot-Instanzen</a>* von AWS. Gleichzeitig erhöhen wir auch die Chancen für einen emissionsärmeren Strommix, wenn wir unsere Arbeit abseits von Industrie und Haushalten ausführen. Um den Strombedarf von Lastspitzen zu decken, muss häufig Strom aus nicht erneuerbaren Quellen hinzugenommen werden. Die Chance dafür können wir mit diesem Vorgehen verringern.

Mit Services wie der <a href="https://www.electricitymaps.com" target="_blank">Electricity Map</a> können wir noch dynamischer auf den aktuellen Strommix einer Region reagieren. Damit lassen sich Ort und Zeit für eine möglichst ressourcensparende Ausführung von Workloads ermitteln, die nicht zeitkritisch sind. Diese Lösung ist erstmal sehr komplex in der Umsetzung – erlaubt es dann aber, auf aktuelle Bedingungen zu reagieren und den nachhaltigsten Strommix zu nutzen.

Auch die asynchrone Verarbeitung mithilfe einer <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_software_a2.html" target="_blank">Queue</a> ist eine Möglichkeit, den eigenen Stromverbrauch zu optimieren. Anstatt bei hoher Last zusätzliche Instanzen hochzufahren, kann eine Queue die Anfragen abpuffern. Dadurch umgehen wir eine Überprovisionierung, um unerwartete Lastspitzen auf dem Server verarbeiten zu können. 

## Komponenten skalieren
Individuelle Skalierung kann aber auch einen Schritt früher anfangen. Wieso sollten wir das gesamte System dauerhaft laufen lassen, wenn eigentlich nur ein kleiner Teil ständig genutzt wird?

<a href="https://cloud.google.com/architecture/reduce-carbon-footprint#minimize_idle_cloud_resources" target="_blank">Google empfiehlt</a>, Microservices zu implementieren, falls Teile des Systems unterschiedlich stark genutzt werden. Beispielsweise wird ein *login-service* nur initial gebraucht, um eine Session zu starten. Im Anschluss benötigen die User den *search-service* aber häufig, um Produkte zu finden und den *basket-service*, um diese in den Einkaufswagen zu legen. Aber egal ob Microservices, Monolith oder etwas dazwischen – wir müssen die Nutzungsprofile unserer Systemkomponenten kennen. Nur dann können wir die beste Kombination von “as a service”-Angeboten und dedizierten Servern wählen, um das Problem zu lösen.

Spezialisierte Services helfen uns aber nicht nur dabei, die Performance zu verbessern, indem einzelne Komponenten schneller und stärker skaliert werden können. Auch für den Stromverbrauch hat dieser Ansatz Vorteile: Wir können Instanzen der Services – und damit auch den Stromverbrauch – herunterfahren. Die Kosten reduzieren wir damit gleich mit.

## Fazit
Wir können bereits beim Entwurf einer Architektur darauf achten, ein nachhaltigeres Fundament aufzustellen. Dabei muss es nicht unbedingt auf ein „entweder – oder“ hinauslaufen. Häufig gewinnen wir im Falle einer nachhaltigen Entscheidung auch auf der Kosten- und Performance-Ebene.

Aktuell gibt es noch große Unterschiede beim Strommix in unterschiedlichen Regionen. Über „As-a-Service“-Angebote kann die Verantwortung für eine optimale Auslastung der Ressourcen an die Provider abgegeben werden. Wenn Optimierungen wie diese zu den anderen Anforderungen an ein System passen, lassen sich Emissionseinsparungen auf einfache Weise umsetzen.

Nicht jedes Projekt wird von Anfang an möglichst sparsam entworfen. Aber auch im Nachhinein lassen sich Optimierungen umsetzen. Die Grundlage hierfür ist ein gutes <a href="https://www.codecentric.de/wissens-hub/blog/cloud-fruehjahrsputz-aws-kosten" target="_blank">Monitoring der Kosten</a> und der Performance eines Systems. Dadurch bekommen wir Hinweise für weiteres Optimierungspotential. Diese Potentiale betrachten wir im nächsten Teil der „Green Cloud“-Serie, wenn wir uns die Skalierung des Systems genauer anschauen.

Green Cloud: Ideen für eine nachhaltigere Architektur

Wenn Softwareprojekte in die Cloud gebracht werden, versprechen wir uns davon hohe Verfügbarkeit, planbare Kosten und eine immer dem Bedarf entsprechende Skalierung. Aufgrund der grenzenlosen Angebote ist es aber auch leicht, die Komponenten eines Systems zu überprovisionieren und damit mehr Ressourcen zu verbrauchen, als notwendig wären.

Nachdem ich im letzten Blogpost Ideen für eine <a href="https://www.codecentric.de/wissens-hub/blog/nachhaltigere-cloud-architektur" target="_blank">ressourcensparende Cloud-Architektur</a> besprochen habe, soll es dieses Mal darum gehen, wie wir die Emissionen unserer Anwendung mithilfe einer optimierten Skalierung reduzieren können. Skalierung bezieht sich hierbei auf die Bereitstellung von (Hardware-)Ressourcen und die Entscheidung, wie viele Server mit welcher Hardware-Ausstattung benötigt werden. Wie beim letzten Post liegt der Fokus ebenfalls auf der Public Cloud.

## Kapazitäten reduzieren
Die Last, die ein System verarbeiten können muss, ist häufig zeitlich sehr unterschiedlich verteilt. Selbstverständlich muss ein Onlineshop 24/7 verfügbar sein, damit Kunden jederzeit einkaufen können. Wenn meine Kundschaft aber nicht weltweit verteilt ist, wird die Last auf das System in der Nacht stark sinken. Auch <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_software_a3.html" target="_blank">AWS empfiehlt</a>, kritisch zu hinterfragen, welche Systeme herunterskaliert werden können.

Ähnliches gilt auch für die Softwareentwicklung selbst: Üblicherweise arbeiten die Teams tagsüber in einem relativ festen Zeitraum. Spätestens nachts benötigt niemand mehr <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_dev_a4.html" target="_blank">den Test-Server oder die Build-Pipeline</a>. Ein netter Nebeneffekt davon: Wenn mein Server nicht mehr läuft, kostet er auch nichts. Hier gewinnen wir also auch auf der Kostenebene, während wir einen großen Einfluss auf unseren Stromverbrauch nehmen.

## Skalierung der Datenspeicher
Rechtliche Bestimmungen spielen je nach Branche eine große Rolle bei der Frage, welche Daten ein Unternehmen für welche Zeiträume speichern muss. Häufig ist die einfache Antwort dabei: „Cloudspeicher ist so günstig, lasst uns einfach alles für immer speichern“. Wenn wir aber sehr viele Daten speichern und diese nur selten aufräumen, summieren sich die Kosten schnell.

Über die Kosten lässt sich gut für eine stromsparende Reduktion der genutzten Speichersysteme argumentieren. Denn auch wenn wir keine Größe für den Cloudspeicher angeben, skalieren wir diesen indirekt durch unsere tatsächliche Nutzung. Durch <a href="https://www.digitalcleanupday.org" target="_blank">regelmäßiges Löschen</a> unserer Daten sorgen wir dafür, dass die Cloudanbieter weniger Speichermedien vorhalten müssen und reduzieren ihren Strombedarf. Es ist also aus verschiedener Sicht sehr sinnvoll, die gespeicherten Daten regelmäßig zu überprüfen und nicht mehr verwendete Daten zu löschen.

Automatisiertes Löschen der gespeicherten Daten kann dabei helfen, den Arbeitsaufwand zu reduzieren. Ein Weg sind hier Retention Policies, mit denen wir festlegen können, ab wann unsere Daten vom System entfernt werden sollen. Falls die Daten nicht gelöscht werden können, aber die Zugriffe ab einem bestimmten Zeitpunkt absehbar abnehmen, erlauben Lifecycle Policies das automatische Verschieben der Daten in andere Speichersysteme. <a href="https://aws.amazon.com/de/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage" target="_blank">Magnetspeicher</a> sind dann eine gute Lösung, da sie energiesparender sind. Für Einträge in einer Datenbank lassen sich sogenannte <a href="https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/howitworks-ttl.html" target="_blank">„Time to Live“-Werte</a> konfigurieren. Ist die Lebensdauer der Datensätze überschritten, räumt die Datenbank automatisch auf.

## Hardware skalieren
Manche Anforderungen verlangen nach einem dedizierten Server. Weil die Auswahl der Cloud-Provider heutzutage sehr groß ist, ist es leicht, die stärkste Hardware zu provisionieren und mögliche Skalierungsprobleme frühzeitig mit Geld lösen zu wollen. „Sicher ist sicher“ gewinnt gegenüber der <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_hardware_a3.html" target="_blank">sparsamen Variante</a> bei der Wahl der Hardware. 

Mithilfe von detailliertem Monitoring eines Systems kann ich nicht nur Probleme und Fehler frühzeitig erkennen. Es lässt sich auch genauer beurteilen, wie hoch die Auslastung meiner Hardware ist. Das ermöglicht es, erst bei dauerhaftem Bedarf <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_hardware_a2.html" target="_blank">vertikal auf eine bessere Hardware zu skalieren</a>.

Außerdem ist es ratsam, regelmäßig nach neuen Servermodellen Ausschau zu halten. Diese sind häufig nicht nur günstiger, sondern auch performanter. Zusätzlich haben beispielsweise die <a href="https://aws.amazon.com/de/ec2/graviton/#Benefits" target="_blank">Graviton-Instanzen</a> von AWS einen deutlich niedrigeren Energieverbrauch bei gleicher Leistung. Ein Wechsel des Instanztyps spart letztlich nicht nur Geld, sondern auch Strom.

## Dynamische Skalierung 
Die horizontale Skalierung auf mehrere Server ist die zweite Möglichkeit, auf dynamischen Workload zu reagieren. Wenn sich die Last auf ein System zeitlich sehr unterschiedlich verteilt, ist es besser, in die Breite zu skalieren. Statt den dauerhaft höheren Energieverbrauch der besseren Hardware auf sich zu nehmen, lassen sich kurzfristige Lastspitzen auch über eine dynamische Skalierung auf mehreren Instanzen abfangen.

Generell ist es empfehlenswert, möglichst kleine Skalierungsschritte zu konfigurieren. Damit beugen wir einer Überprovisionierung vor. Auch hier gilt: Zunächst sollte das System beobachtet und dann bedarfsabhängig optimiert werden, anstatt Probleme mit besserer Hardware zu erschlagen. Ein weiterer Vorteil von diesem Vorgehen: Selbst bei stark überprovisionierter Hardware besteht das Risiko, dass die Last alle Erwartungen übersteigt und das System überfordert ist. Wenn ein System dynamisch reagieren kann, lassen sich auch unerwartete Zugriffszahlen besser verarbeiten.

Die Skalierungsregeln sollten über die <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_hardware_a2.html" target="_blank">Utilization</a> implementiert werden, um so eine optimale Auslastung der Systeme umzusetzen. Erst wenn eine Ressource eine gewisse Auslastung erreicht hat, stoßen wir die Skalierung an. Im selben Moment muss auch daran gedacht werden, die Ressourcen <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/sus_sus_user_a2.html" target="_blank">wieder herunter zu skalieren</a>, wenn sie nicht mehr benötigt werden.

## Spezialfall „Function as a Service“
„Function as a Service“-Angebote (FaaS) wie Azure Functions erlauben es, Code ohne Infrastruktur-Overhead in der Cloud auszuführen. Die Anbieter sorgen dafür, dass genügend Ressourcen zur Verfügung stehen, um Anfragen verarbeiten zu können. Interessant wird es, wenn eine Funktion nicht benötigt wird. Weil nach Laufzeit bezahlt wird, gibt es einen Scale-to-Zero und wir bezahlen nichts mehr. 

Leider geben die Cloud-Provider kaum Informationen über die genaue Architektur und Auslastung ihrer FaaS-Angebote heraus. Eine gewisse Grundkapazität muss jedoch immer vorgehalten werden, auch wenn unsere eigene Funktion aktuell nicht genutzt wird. Da diese Serverkapazität den Usern aber nicht abgerechnet wird, ist davon auszugehen, dass die Anbieter die Auslastung so weit wie möglich optimieren. Für uns bieten FaaS-Angebote damit eine gute Möglichkeit, die Skalierung unseres Systems vollständig abzugeben.

## Fazit
Generell gilt: Solange die aktuelle Last problemlos verarbeitet werden kann, können wir die kleinste Hardware-Konfiguration eines Systems laufen lassen. Für die unerwarteten Momente bietet sich eine dynamische Skalierung an. Grundvoraussetzung ist aber ein gutes Monitoring und detaillierte Kenntnis des Systems. Nur auf diese Weise können wir die Skalierung korrekt konfigurieren.

Häufig gewinnen wir mit der dynamischen Skalierung nicht nur beim Stromverbrauch. Auch die Kosten unseres Systems lassen sich auf diese Weise reduzieren. Es mag häufig nach der leichteren Lösung aussehen, statische Ressourcen zu nutzen. Aber langfristig rechnet sich ein dynamisch skalierendes System nicht nur finanziell, sondern auch bei den verursachten Emissionen unseres Systems.

Green Cloud: Nachhaltig skalieren 

Das Aufsetzen der CI/CD-Pipeline ist ein typischer Task in der Anfangszeit eines Projekts. Ist die Pipeline dann aufgesetzt, sind Änderungen nur noch selten notwendig. Dementsprechend wenig Routine entwickeln Programmierende im Umgang mit der Konfiguration einer Pipeline. Wenn dann noch besondere Anforderungen, wie Cross-Account-Deployments, ins Spiel kommen, wird die Konfiguration der Pipeline kompliziert.

Das AWS CDK bietet mit dem <a href="https://docs.aws.amazon.com/cdk/api/v2/docs/aws-cdk-lib.aws_codepipeline-readme.html" target="_blank">CodePipeline</a>-Konstrukt eine einfache Möglichkeit, die CI/CD-Pipeline für ein CDK-basiertes Projekt aufzusetzen. Bevor wir ein paar Beispiele betrachten, werfen wir einen Blick auf die Konzepte der CodePipeline.

## Die Struktur
![aws_codepipeline.jpg](https://media.graphassets.com/wckIVcQ7StSVaShojqqC)

Das CodePipeline-Konstrukt kapselt die drei AWS-Services CodePipeline, CodeBuild und CodeDeploy, aus denen eine Pipeline im AWS-Umfeld üblicherweise aufgebaut wird. Wie die Namen beschreiben, fokussieren sich die Services jeweils auf das Orchestrieren der Pipeline, das Bauen der Anwendung und das eigentliche Deployment.

Der Kern einer CodePipeline ist der `synth`-Schritt. Hier wird definiert, wie die Pipeline das CloudFormation-Template generieren soll, das im Anschluss für das Deployment genutzt wird. Alle Artefakte werden vollautomatisch in einem S3-Bucket abgelegt, der ebenfalls vom Konstrukt angelegt wird. Im Anschluss nutzt CodeDeploy das Template aus dem Bucket und startet das Deployment über CloudFormation. Mit <a href="https://docs.aws.amazon.com/cdk/v2/guide/cdk_pipeline.html#cdk_pipeline_stages" target="_blank">Stages</a> werden die Accounts und Regionen der Deployments konfiguriert. 

## Die Basics
```javascript
const pipeline = new CodePipeline(this, 'my-pipeline', {
 pipelineName: 'my-pipeline',
 selfMutation: true,
 synth: new ShellStep('synth', {
 input: CodePipelineSource.codeCommit(repository, 'main'),
 commands: ['npm ci', 'npm run build', 'npx cdk synth'],
 })
});
```
Der Beispielcode zeigt die Pipeline für ein NPM-basiertes Projekt. Das CloudFormation-Template wird synthetisiert, indem zunächst die Dependencies installiert und anschließend der Code gebaut wird (Zeile 6). Das Artefakt wird anschließend automatisch in einem S3-Bucket archiviert.

Eine weitere Besonderheit der CodePipeline ist, dass ihr Code im selben Repository liegt wie der Anwendungscode. Über das Property `selfMutation` (Zeile 3) konfigurieren wir, dass sich Codeänderungen an der Pipeline selbst aktualisieren können. Hierzu ist es notwendig, die Pipeline in einen eigenen CDK-Stack auszulagern und diesen zunächst manuell zu deployen. Anschließend aktualisiert sich die Pipeline bei jeder Codeänderung selbst.

Nachdem unser CloudFormation-Template synthetisiert wurde, muss das eigentliche Deployment gestartet werden. Hier kommen die bereits erwähnten Stages ins Spiel. Das folgende Beispiel zeigt das Hinzufügen einer Deployment-Stage mit dem Namen “MyPipelineStage” zur Pipeline. Diese wird automatisch am Ende der Pipeline ausgeführt. Eine Stage wird dafür genutzt, die notwendigen Stacks einer Anwendung zu initialisieren und damit das Deployment anzustoßen. Im Beispiel ist dies "MyStack", der in den AWS-Account "111111111111" und die Region "eu-central-1" deployt werden soll.
```javascript
pipeline.addStage(new MyPipelineStage(this, 'dev'));

[...]

class MyPipelineStage extends Stage {
 constructor(scope: Construct, id: string, props?: StageProps) {
 super(scope, id, props);
 new MyStack(this, 'my-stack', {
 env: { account: '111111111111', region: 'eu-central-1' },
 });
 }
}
```

## Die Erweiterung
Der Anwendungscode wird von AWS CodeBuild gebaut. Dieser Service bietet unterschiedliche Umgebungen, in denen dieser Prozess ablaufen kann. Je nach Stack des Projekts muss eine dazu passende Umgebung ausgewählt werden. Das folgende Beispiel zeigt die Konfiguration für ein Build-Environment, in dem Node.js in Version 18 verfügbar ist. Weitere Möglichkeiten zeigt AWS in <a href="https://docs.aws.amazon.com/codebuild/latest/userguide/available-runtimes.html" target="_blank">dieser Übersicht</a>.
```javascript
synthCodeBuildDefaults: {
 buildEnvironment: { buildImage: LinuxBuildImage.STANDARD_7_0 },
 partialBuildSpec: BuildSpec.fromObject({
 phases: {
 install: {
 'runtime-versions': { nodejs: '18' },
 },
 },
 }),
 }
```
Falls das Projekt Lambda-Funktionen enthält, die mit dem NodejsFunction-Konstrukt umgesetzt werden, übernimmt das CDK das Kompilieren des Codes. In unserer Pipeline reicht es, das `dockerEnabledForSynth`-Property zu setzen. Dadurch kann die CodePipeline den Typescript-Code zu JavaScript transpilieren.

In manchen Fällen möchten wir einen Schritt manuell bestätigen und die Automatisierung der Pipeline umgehen. Beispielsweise soll das Deployment auf die Produktionsumgebung erst nach einem Test der Änderungen auf der Entwicklungsumgebung stattfinden. Mithilfe eines <a href="https://aws.amazon.com/de/blogs/devops/manually-approving-security-changes-in-cdk-pipeline" target="_blank">ManualApprovalSteps</a> können wir die Pipeline auf die Bestätigung eines Users warten lassen, bevor es mit der nächsten Stage weitergeht. 
```javascript
const devDeploymentStage = pipeline.addStage(new DevPipelineStage(this, 'dev'));
devDeploymentStage.addPost(new ManualApprovalStep('approval'));
const prodDeploymentStage = pipeline.addStage(new ProdPipelineStage(this, 'prod'));
```

## Das Cross-Account-Deployment
Gerade wenn diverse Abteilungen und Teams im AWS-Umfeld unterwegs sind, hat sich ein Deployment über Account-Grenzen etabliert. Beispielsweise werden die Entwicklungs- und Produktionsumgebungen in unterschiedlichen AWS-Accounts umgesetzt. Die Pipeline kann jedoch zentral in einem eigenen Account laufen. Auch das Deployment in mehrere Regionen lässt sich leicht durch weitere Stages umsetzen.

Hierzu muss in der Pipeline zunächst das Property `crossAccountKeys` gesetzt werden, um die KMS-Keys zu generieren. Diese Schlüssel werden genutzt, um die Pipeline-Artefakte zu verschlüsseln. Dem anderen Account muss erlaubt werden, den Schlüssel zu nutzen, um die Artefakte wieder zu entschlüsseln. Alle Ressourcen und Berechtigungen übernimmt das CDK-Konstrukt für uns.
```javascript
new CodePipeline(this, 'my-pipeline', {
 crossAccountKeys: true,
 [...]
})

pipeline.addStage(new PipelineStage(this, 'dev'), {
 env: { account: '111111111111', region: 'eu-central-1' },
});
pipeline.addStage(new PipelineStage(this, 'prod'), {
 env: { account: '222222222222, region: 'us-east-1' },
});
```

## Das Fazit
Mit dem CodePipeline-Konstrukt erlaubt es das CDK unkompliziert die Pipeline für unser Projekt aufzusetzen. Besonders bei komplexeren Use Cases ist weniger Verständnis der AWS-Plattform notwendig, um Ergebnisse zu erzielen. Ein Beispiel sind hier die notwendigen Rollen und Policies, um Cross-Account-Deployments umzusetzen.

Durch die einfache API des Konstrukts können wir schnell Erfolge erzielen und uns auf die Implementierung von fachlichen Anforderungen konzentrieren. Setzen wir ein neues Projekt um, können wir die Konfiguration der CI/CD-Pipeline zukünftig dem CDK überlassen.

CI/CD-Pipelines mit AWS CDK CodePipeline

Das Internet produziert jährlich 900 Millionen Tonnen CO₂ – das ist deutlich mehr als Deutschland insgesamt emittiert. Hauptverantwortlich ist der immer weiter steigende Stromverbrauch beim Transport und der Speicherung von Daten. Wenn ihr kurz darüber nachdenkt, fallen euch sicher Dateien ein, die noch irgendwo gespeichert sind, weil ihr sie irgendwann nochmal gebrauchen könntet. Genau darum soll es in diesem Artikel gehen: Wie können wir Daten und damit Emissionen einsparen?

Dieser Blogpost betrachtet speziell die Möglichkeiten der Public Cloud, deren Anbieter auch ganz <a href="https://speakerdeck.com/ufried/patterns-of-sustainability-going-green-in-it?slide=121" target="_blank">eigennützige Motivationen</a> haben, ihre Emissionen zu verringern. Natürlich ist das Marketing aktuell ein wichtiger Beweggrund. Aber auch die finanziellen Gründe für eine Optimierung des Ressourcenverbrauchs sind klar: Ein geringerer Stromverbrauch senkt die Kosten für die Anbieter und steigert ihre Marge. Aus ökologischer Sicht ist Hardware, die nicht gekauft werden muss, Hardware, die nicht produziert wird und damit Ressourcen spart. Wir als Entwickler und Entwicklerinnen können durch unsere Nutzung also positiven Einfluss auf die Cloud-Anbieter nehmen – Stichwort <a href="https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/the-shared-responsibility-model.html" target="_blank">AWS Shared Responsibility</a>.

## Daten löschen
Nicht mehr benötigte <a href="https://patterns.greensoftware.foundation/catalog/cloud/delete-unused-storage-resources" target="_blank">Daten zu löschen</a> ist der einfachste Weg, den belegten Speicherplatz zu reduzieren. Bei der Frage, welche Daten nicht mehr benötigt werden, wird es aber spannend. Häufig wird zur Sicherheit erstmal alles gespeichert: *„Später können wir ja immer noch löschen“*. Hinzu kommt, dass Cloud-Speicher günstig sind. Erst mit steigender Nutzung und größeren Datenmengen fällt auf, dass die Kosten in die Höhe schießen.

Regelmäßiges Aufräumen muss aber keinen großen Zeitaufwand bedeuten. Mit <a href="https://patterns.greensoftware.foundation/catalog/cloud/set-retention-policy-on-storage-resources" target="_blank">Retention Policies</a> lassen sich Ressourcen automatisch aufräumen. Bei der Nutzung von DynamoDB-Tabellen können Time-To-Live-Werte konfiguriert werden, nach denen Einträge automatisch aus den Tabellen gelöscht werden. Unsere S3-Buckets können wir mithilfe von <a href="https://docs.aws.amazon.com/AmazonS3/latest/userguide/lifecycle-expire-general-considerations.html" target="_blank">Expiration-Rules</a> aufräumen lassen oder wir verschieben die Daten in energiesparenden Cold Storage. Ähnliche Konzepte finden sich in vielen Cloud-Services.

Regelmäßiges Aufräumen schont nicht nur den Geldbeutel, sondern spart auch Ressourcen. Der freigewordene Speicher kann anderen Nutzern zur Verfügung gestellt werden und verzögert damit, dass die Cloud-Provider neue Hardware bereitstellen müssen.

## Datensparsamkeit
Nicht nur mit Blick auf die Kosten und den Stromverbrauch sollten wir uns genau überlegen, welche Daten wir wirklich benötigen. Stichwort Datenschutz und <a href="https://patterns.greensoftware.foundation/catalog/cloud/reduce-transmitted-data" target="_blank">Datensparsamkeit</a>: Nicht alle Daten müssen gespeichert werden. Denn die Daten verbrauchen nicht nur Speicherplatz, sondern vergrößern auch die Requests, die wir über das Netzwerk verschicken. Es ist sehr sinnvoll, sich vor der Integration eines Tracking-Tools im Detail zu klären, welche Events und Daten wirklich notwendig sind.

Wenn ein System geringere Datenmengen verarbeiten muss, verbessert dies viele Aspekte. Angefangen bei der Performance, da Berechnungen schneller abgeschlossen werden. Auch die Hardwareanforderungen werden reduziert und damit schließt sich der Kreis: Wir reduzieren mit dem geringeren Leistungsbedarf auch unsere Rechnung und die Anbieter müssen weniger Hardware bereitstellen, um alle Kunden versorgen zu können.

## Daten cachen
Wenn Daten über das Netzwerk versendet werden müssen, bevor eine Anwendung ihre Funktionen bereitstellen kann, verlängert das die Zeit, bis die User mit ihrer Arbeit beginnen können. Je größer die Strecke zwischen Server und Endgerät ist, desto stärker fällt dieser Punkt ins Gewicht. Darunter leidet aber nicht nur die User-Experience. Auch der Stromverbrauch wird durch den steigenden Netzwerktraffic vergrößert, da viele Geräte an der Übertragung von Daten beteiligt sind.

Eine Verbesserung kann mithilfe von <a href="https://patterns.greensoftware.foundation/catalog/cloud/cache-static-data" target="_blank">Caching</a> erreicht werden. Beispielsweise indem wir Daten direkt auf den Endgeräten speichern, nachdem sie einmal verschickt wurden. Dadurch ersparen wir zukünftig weitere Datenübertragungen. Mithilfe eines Content Delivery Networks (CDN) können wir die Ergebnisse häufiger Anfragen im Cache halten, statt diese jedes Mal durch das gesamte Netzwerk und über viele Systeme zu verschicken.

Nochmals stärker wirkt sich ein Cache auf die Antwortzeit aus, wenn es sich nicht um statische Daten handelt, sondern zunächst Berechnungslogik ausgeführt werden muss. Wenn unsere Anwendung viele User mit ähnlichen Anfragen bedient, haben wir an der Stelle einen großen Hebel. Selbstverständlich muss ein Cache für den jeweiligen Use Case kompatibel sein. Statische Dateien, wie Bilder oder das Impressum, lassen sich gut vorhalten und effizient aus einem Cache ausliefern.

## Daten komprimieren
Bevor Daten über das Netzwerk verschickt werden, sollten sie so weit wie möglich komprimiert werden. Wie bei der Datensparsamkeit gilt auch hier: Wenn weniger Daten verschickt werden, spart das Zeit und Energie.

Ein wichtiger Entscheidungsfaktor sind die Endgeräte, auf denen unsere Anwendung genutzt wird. Während Desktop-Anwendungen nicht nur aufgrund der Bildschirmgröße mit größeren Bildern bespielt werden sollten, gilt es besonders bei mobilen Anwendungen <a href="https://patterns.greensoftware.foundation/catalog/web/properly-sized-images" target="_blank">Medien zu skalieren</a>. Wir reduzieren dadurch nicht nur die Transportzeit, sondern verringern auch die Anforderungen an Hardware zur Verarbeitung der Datenmengen. Gerade bei älteren Smartphones lassen sich dadurch ein paar Millisekunden Zeit einsparen, was für die User-Experience ein großer Gewinn sein kann.

Mit der Schonung der Endgeräte erreichen wir nicht nur eine bessere Usability, sondern können auch indirekt Einfluss nehmen: Ruckeln die täglich genutzten Anwendungen auf dem Smartphone, spielt man schnell mit dem Gedanken an ein <a href="https://www.sciencedirect.com/science/article/pii/S0959652621017790#bib53" target="_blank">neues Gerät</a>. Durch unsere Optimierungen können wir den Kauf noch ein wenig hinauszögern und die Produktion weiterer Hardware reduzieren.

## Datenverbrauch messen
Idealerweise arbeiten wir nicht nur einmalig am Datenverbrauch, sondern messen zukünftige Veränderungen, um entsprechend reagieren zu können. Beispielsweise könnte eine <a href="https://aws.amazon.com/de/blogs/architecture/optimizing-your-aws-infrastructure-for-sustainability-part-ii-storage" target="_blank">Zugriffsanalyse</a> ergeben, dass bestimmte Daten nur unregelmäßig und ohne Zeitdruck angefragt werden. Dann kann ein Wechsel von schnellen SSDs auf langsamere – aber auch energiesparende – magnetische Speichermedien sinnvoll sein. Preislich lohnt sich so ein Wechsel häufig ebenfalls.

Die Cloud-Provider bieten verschiedene Metriken zu ihren Speicherservices an. Gerade wenn wir eigene Volumes konfigurieren, sollten wir durch Alarme auf die entsprechenden Metriken sicherstellen, dass wir die Deployments weiterhin benötigen. Für den EBS-Service von AWS gibt die <a href="https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using_cloudwatch_ebs.html#ebs-metrics" target="_blank">*VolumeIdleTime*</a> an, wie lange keine Lese- und Schreibaktionen mehr ausgeführt wurden. Wenn die Idle-Time einen gewissen Wert überschreitet, sollte zumindest darüber nachgedacht werden, die Ressourcen für andere Kunden freizugeben.

## Fazit
Mit ein paar Verbesserungen können wir nicht nur Einsparungen bei den Emissionen unserer Systeme erreichen, sondern auch die Kosten reduzieren und die Performance verbessern. Das zeigt sich auch in anderen Bereichen der <a href="https://www.codecentric.de/wissens-hub/blog/green-cloud-nachhaltig-skalieren" target="_blank">Green-Cloud-Optimierungen</a>. Beim vorsichtigen Umgang mit Daten können wir allerdings auch den Datenschutz verbessern.

Am 16. März ist der <a href="https://www.digitalcleanupday.org" target="_blank">Digital Cleanup Day</a>. Nehmt den Tag zum Anlass und stellt euren Teams einen Termin ein. Analysiert eure Daten im Projekt genauer – ihr werdet Optimierungspotenziale erkennen. Mit den Ideen aus diesem Blogpost habt ihr dann passende Lösungen zur Hand, um den datenbasierten Stromverbrauch zu reduzieren. Viel Erfolg dabei!

Green Cloud: Daten und Emissionen sparen

MuleSoft's Anypoint Runtime Fabric version 2.0 no longer supports Vanilla Kubernetes. It only supports EKS, EKDS-A, AKS, GKE and OpenShift in different environments.

So how to install Anypoint Runtime Fabric on OpenShift? The MuleSoft documentation provides a good guideline on how to install a basic setup of Runtime Fabric on OpenShift (s. https://docs.mulesoft.com/runtime-fabric/latest/install-openshift). For the advanced settings, it is helpful to have a sound understanding of how OpenShift works.

From my point of view, MuleSoft should improve the documentation in two areas.

## Ingress traffic for OpenShift cluster 

OpenShift uses route resources to define how pods can be accessed from outside the cluster. It will not consider Kubernetes Ingress resources for Ingress traffic. Creating or modifying a Kubernetes Ingress automatically creates or updates an OpenShift route. Default domains in routes consist of the route name and the namespace name together with the base domain. OpenShift is using a wildcard certificate for domains that follow the described notation. This makes both HTTPS enablement for applications and the maintenance of it quite easy.

The challenge is how to set up the Runtime Fabric Ingress-Template with HTTPS and to use the wildcard certificate of OpenShift.

Long story short, the cluster admin needs to copy the OpenShift wildcard cluster certificate to the Runtime Fabric namespace.

1. Copy the wildcard certificate to your local file system:
```bash
oc get secret -n openshift-ingress router-certs-default -o yaml > default_certificate.yaml
``` 
2. Remove the status and meta-information and change the namespace to the Runtime Fabric namespace. Your file should look like this:
 ```yaml
apiVersion: v1
data:
  tls.crt: LS0ti..
  tls.key: LS...
kind: Secret
metadata:
  name: router-certs-default
  namespace: <Runtime Fabric namespace in my case rtf>
type: kubernetes.io/tls
```
3. Finally, execute the following command to create the secret with wildcard certificate to the Runtime Fabric namespace:
```bash
oc create -f default_certificate.yaml
```

For those who want to understand the reason behind this:
For TLS connections, the Kubernetes Ingress requires a hostname and a secret name. OpenShift only creates a route if the secret with that name exists in that namespace. Use {} as a wildcard for the attribute TLS in an Ingress (you can find an example of this [here](https://docs.openshift.com/container-platform/4.13/networking/routes/route-configuration.html#creating-edge-route-with-default-certificate_route-configuration)). This will create a route which is using the wildcard certificate of the ingress-controller. However, Anypoint doesn't accept this as a valid endpoint for Ingress traffic. To use a valid wildcard certificate in the Runtime Fabric Ingress-Template, the cluster administrator needs to copy the cluster wildcard certificate to the Runtime Fabric namespace.

On the bright side:
route type (edge, reencrypt, passthrough) defined by an annotation works fine with the Runtime Fabric Ingress-Template.

Hint:
The description above is not intended for a production environment. 
## Using a dedicated namespace to deploy MuleSoft applications

The standard configuration of Runtime Fabric on OpenShift will create a namespace with the ID of the environment of the deployed application.  You can define a list of target namespaces in which to deploy Mule applications (see [here](https://docs.mulesoft.com/runtime-fabric/2.3/install-openshift#optional-configure-authorized-namespaces)). The installation documentation is describing which Kubernetes resources are needed. The target namespace requires a Label with the Anypoint *environment_id* and *org_id*. The documentation leaves out where to find these IDs.

The *org_id* can be found in Anypoint's Access Management. In the menu *Organization* you will get a list of all available organizations. If you click on one of them, you see in the Organization info the "Organization Id".

![mule_access_manager_1.png](https://media.graphassets.com/zr9kq2tSQODpkVlzhiWD)

The *environment_id*s are a bit trickier. In Access Management there is a menu entry for environments that lists all available environments. If you look closely at the links for the environments, you notice an ID at the end of each URL. This ID is the *environment_id*. The easiest way to get the ID is to press CTRL and click on the link. In the new tab you can copy the *environment_id*  from the URL (don't worry that it shows the list of organizations).

![mule_access_manager_2.png](https://media.graphassets.com/OilSpJ5R3OppMS3h2Px8)

This MuleSoft blog article describes another way to get the *environment_id*: https://help.mulesoft.com/s/article/How-to-get-the-Environment-ID. Like always, there are multiple ways to solve a problem.

## Summary

Anypoint Runtime Fabric is easy to handle on OpenShift. Some fine-tuning is required here and there, but nothing major. In the next blog article, we will show you how to run Runtime Fabric locally on a development computer.

Fine-tuning MuleSoft's Anytime Runtime Fabric on OpenShift

Senior IT-Consultant

## Was ist AZ-900?

Azure bietet eine Reihe verschiedener Zertifizierungen an. Zu finden sind sie
<a href="https://learn.microsoft.com/en-us/credentials/browse/?credential_types=certification" target="_blank">hier.</a>

Darunter befindet sich auch die Zertifizierung AZ-900. Bei diesem Zertifikat handelt es sich um `Microsoft Certified: Azure Fundamentals`.

Diese prüft unter anderem Fachwissen über allgemeine Cloudkonzepte, Cloudmodelle oder auch Datenschutz und Compliance.

Detaillierte Informationen über diese Zertifizierung sind [hier](https://learn.microsoft.com/en-us/credentials/certifications/azure-fundamentals/) zu finden.
Und nachdem du diesen Blogpost gelesen hast, weißt du, wie ich mich vorbereitet und die Prüfung abgelegt habe.

## Vorbereitung

Prinzipiell kann man sich im Internet ja sowieso alles zusammen googeln. Das hab ich im Grunde auch getan. Ein guter erster Einstieg ist die [offizielle Website](https://learn.microsoft.com/en-us/credentials/certifications/azure-fundamentals/)der Zertifizierung. Dort sind dann auch weiterführende Links wie auch Testprüfungen zu finden.

Zusätzlich dazu habe ich bei <a href="https://learn.acloud.guru" target="_blank">A Cloud Guru</a> einen Account von der codecentric AG bekommen und habe mich mit Videos und weiteren Testprüfungen darauf vorbereitet.
Meiner Erfahrung nach ist aber `A Cloud Guru` allein nicht empfehlenswert, um für die Prüfung zu lernen, da die Videos aus meiner Sicht nicht die Prüfungssituation und den Stoff realistisch abbilden.
Mein Gefühl war es, dass Themen angesprochen werden, die in der Prüfung nicht dran kommen bzw. auch Themen nicht angesprochen, die drankommen.

Ich würde mich zumindest nicht 100 % auf `A Cloud Guru` verlassen.

Der Vorteil bei `A Cloud Guru` ist, dass durch die Videos und anschließenden Quizzes, der Inhalt nicht so trocken wie beispielsweise eine offizielle Dokumentation wirkt.

Mit einem Kollegen zusammen habe ich jeden Freitag (mit Ausnahme von Kundenterminen, internen Terminen, Urlauben, etc.) für ca. 2 Stunden für die Prüfung gelernt und so haben wir uns gegenseitig motiviert. Das war dann unsere „Selbsthilfegruppe“.

Bezüglich der Prüfung haben wir uns überhaupt nicht gestresst. Das wäre dann wohl auch erfolgreich in die Hose gegangen. Da wir in unserer Off-Project-Time (OPT) auch andere Sachen zu tun haben sind wir schnell drauf gekommen, so früh es geht mit unserer Selbsthilfegruppe anzufangen. Somit war der Startschuss Anfang Februar 2023.

Regelmäßig haben wir dann die kommenden Monate gelernt. Im Folgenden kann ich nur für mich sprechen: In meiner Freizeit hab ich mich erfolgreich dagegen gewehrt, weiterzulernen. Konsistent wäre es, aber wozu der Stress. `Life is hard enough as it is right?`

Nach und nach, Video für Video und Fragen über Fragen haben wir uns dann am 17.11.2023 für den `Exam Registration Day` entschieden: Der 08.12.2023 war dann der Prüfungstag.

## Prüfung

### Anmeldung

Bei der Anmeldung ist auch die AZ-900-Seite von Microsoft sehr hilfreich und man wird gut durch navigiert. Für Deutschland belaufen sich die Kosten auf 99 € Netto. In Summe habe ich 117,81 € bezahlt.

Es ist sowohl eine Prüfung vor Ort, als auch eine Onlineprüfung möglich. Ich habe mich für letzteres entschieden.

### Prüfungsvoraussetzungen

Nachdem man bezahlt hat, wird man dazu aufgefordert den `OnVue`-Client herunterzuladen und einen Systemtest zu machen. Den Downloadlink bekommt man mit weiteren Informationen per Mail. Dieser Test beinhaltet Netzwerkstabilität, Funktionalität der Webcam und des Mikrofons und Prüfung, ob noch andere Anwendungen offen sind oder auch weitere Monitore angeschlossen sind.

Es ist sehr empfehlenswert diesen Test zweimal zu wiederholen, da es bei mir beim ersten Mal zu Problemen geführt hat. Konkret hat der Client nicht geschlossene Anwendungen registriert, obwohl ich alles geschlossen hatte. In meinem Fall war das Betriebssystem MacOS.

Die Prüfung findet dann (sofern eine Onlineprüfung gewählt wurde) auch innerhalb dieses Clients statt.

### Die eigentliche Prüfung

Nach dem man sich für seine Prüfung angemeldet hat, wird diese per Mail bestätigt. 30 Minuten vor Beginn der Prüfung ist es möglich, sich bereits in den Warteraum zu begeben und einen offiziellen Systemtest durchzuführen. Es empfiehlt sich hier die gleiche Umgebung zu verwenden wie in den Vortests.

Anschließend kommen einige offizielle Schritte. Hierzu gehören:
* ein Selfie von dir
* jeweils ein Foto von der Vorder- und Rückseite deines Ausweises

Fotos von ...
* ... deiner Sicht auf den Computer
* ... deiner linken Seite
* ... deiner rechten Seite
* ... deiner Rückseite

Dieser Prozess hat bei mir ca. 15 Minuten gedauert. Solltest du mit den ganzen Vorbedingungen fertig sein bevor dein offizieller Prüfungstermin anfängt, darfst du auch früher anfangen.

Die Dauer der Prüfung beläuft sich auf 65 Minuten bzw. 45 Minuten. Folgendes Zitat aus meiner Anmeldung fasst es ganz gut zusammen:

**„[Die 65 Minuten] beinhaltet die Zeit, um die Kandidatenvereinbarung, Anleitungen und den Unterrichtskurs durchzugehen, Prüfungsfragen zu beantworten und Anmerkungen zu machen; wenn die Prüfung keine Laboratorien umfasst, ist die Dauer prinzipiell um 20 Minuten verringert.“**

Nachdem die „Laboratorien“ abgeschlossen sind, beginnt ein Timer mit (! Achtung!) **45 Minuten**.

Während der Prüfung wirst du aufgezeichnet. Laut Spielregeln darfst du gefühlt nicht mal in der Nase bohren, geschweige die Prüfungsfragen laut durchlesen. Sollte während einer Frage etwas unklar sein, besteht die Möglichkeit sich per Chat bei einer Aufsichtsperson zu melden. Dafür gibt es einen Chatbutton, den man klicken kann und es wird Kontakt zur Aufsichtsperson hergestellt. Aus Neugier habe ich ihn geklickt. Die Dauer zwischen Klick und Rückmeldung der Aufsichtsperson beläuft sich auf ca. 3 Minuten.

In meiner Prüfung waren es 40 Fragen. In verschiedenen Foren wird eine Zahl zwischen 40 und 60 genannt.

Die Prüfung habe ich auf Englisch abgelegt. Bei Anmeldung kann man aber auch die Prüfungssprache auf Deutsch einstellen. Ich habe mich aktiv gegen den Mix aus „Englisch lernen und Deutsch geprüft werden“ entschieden.

Nach Fragen auf Deutsch hab ich nie gesucht. Da in der Praxis die Umgebung sehr wahrscheinlich auf Englisch ist, empfiehlt sich diese Sprache. Bei den Fragen handelt es sich im Grunde um Multiple-Choice-Fragen. Teilweise gibt es auch andere Frageformate. Zum Beispiel muss man Blöcke von der „Question Area“ in die „Answer Area“ via Drag-and-drop. Das wurde vor allem bei Fragen genutzt, bei denen Reihenfolgen eine Rolle spielen.

Rechtecke mit anderen Rechtecken durch Pfeile verbinden. Oder auch die Lösung an einem Screenshot einer UI markieren. Es gibt noch weitere Abwandlungen und sicherlich auch welche, die nicht in meiner Prüfung verwendet wurden. Wenn du diese Varianten kennst, bist du meiner Meinung nach gut aufgestellt.

### Nach der Prüfung

Nachdem du die Prüfung bestanden hast, erhältst du eine E-Mail mit der Bestätigung und einem Link zu deinem Profil, bei der du dann dein Zertifikat begutachten, ausdrucken und professionell laminieren lassen kannst.

AZ-900-Zertifizierung: Mein How-to!

## Problemstellung
Ist man in einem <a href="https://playwright.dev/" target="_blank">Playwright-</a> Test abhängig von externen Services wie APIs (die auch mal nicht erreichbar sein können), gibt es u. a. folgende Möglichkeiten, diese Tests adäquat auszuführen.

* Die Anfrage tatsächlich aufrufen. Wie zum Beispiel eine Entwicklungsumgebung.
 * sollte das Backend nicht erreichbar sein, schlägt der Test fehl.
* Einen eigenen Dienst wie <a href="https://wiremock.org/" target="_blank">Wiremock</a> hochfahren und die Responses definieren.
* Den entsprechenden HTTP Call simulieren.

Dieser Blogartikel geht näher auf den letzten Punkt ein.

## Beispiel

Wenn man in seinem Test eine bestimmte Webseite aufruft, werden oft weitere implizite Anfragen durchgeführt. Das heißt, dass die zu testenden Websites während des Seitenaufbaus clientseitig weitere HTTP Calls auslösen. Im Folgenden wird anhand von Beispielen dieses Vorgehen Schritt für Schritt dargestellt.

> Verwendet wird ein Dienst von `jsonplaceholder`.

### Allgemeiner Test

Wir stellen uns bei dem unten implementierten Test vor, dass eine ganz bestimmte Anfrage implizit durchgeführt wird. Um dies zu verdeutlichen, leiten wir unseren Test direkt auf den Endpoint, um eine Basis für weitere Erweiterungen zu erarbeiten. In diesem Fall handelt es sich um <a href="https://jsonplaceholder.typicode.com/todos/1" target="_blank">`/todos/1`</a>.

> Dieses Pattern ist nicht praxisnah und dient nur der Einfachheit.


```typescript
import { test } from "@playwright/test";

test.describe('Description', async () => {

test('mytest', async ({ page }) => {

 // given
 // keine Voraussetzungen notwendig

 // when
 await page.goto('https://jsonplaceholder.typicode.com/todos/1')
 
 // then
 // expectations...
})

}
```

Zum Zeitpunkt dieses Blogbeitrags hat `GET /todos/1` folgende Response zurückgesendet.

```json
{
 "userId": 1,
 "id": 1,
 "title": "delectus aut autem",
 "completed": false
}
```

### Generische Erweiterung

Nun gilt es die Anfrage abzufangen und einen Callback auszuführen. Der Callback selber ist eine Funktion, die ausgeführt wird, sobald Playwright diese `route` erkennt. Der folgende, erweiterte Test von oben führt nach einem `console.log` den Request weiter und die Response bleibt die gleiche.

```typescript
import { Route, test } from "@playwright/test";

test.describe('Description', async () => {
 test('mytest', async ({ page }) => {

 // given
 // Führe für jede Anfrage auf diese URL ...
 await page.route('https://jsonplaceholder.typicode.com/todos/1', async (route: Route) => {
 // ... diesen callback aus
 console.log('invoked HTTP call to given route')
 await route.continue()
 })

 // when
 await page.goto('https://jsonplaceholder.typicode.com/todos/1')
 
 // then
 // expectations ...
 })
})
```

> Wie oben schon erwähnt, ist diese Form des Herauspickens einer Anfrage auf einen Endpoint nicht gängig und wird zur Veranschaulichung verwendet. Dieser Test testet momentan keine Website, sondern nur eine Anfrage, bei der die Antwort auch noch gemockt wird.

### Praxisbeispiel

Nun wird der Test umgewandelt. Wir greifen in unserem Test auf die Webseite zu. Dieser Aufruf löst weitere Anfragen aus. Hierzu gehört unter Anderem eine Anfrage, die an das Stylesheet `style.css` geht. Diese soll nun nicht wirklich durchgeführt werden. Die Response wird in diesem Beispiel als `text/plain` ersetzt und zurückgeliefert. Somit wird kein Styling auf der Seite geladen.

Hierfür bietet das <a href="https://playwright.dev/docs/api/class-route" target="_blank">Route</a> Interface die Funktion [`fulfill()`](https://playwright.dev/docs/api/class-route#route-fulfill) an, um diese Response zu definieren.

```typescript
import { Route, test } from "@playwright/test";

test.describe('Description', async () => {
 test('mytest', async ({ page }) => {

 // given
 // Führe für jede Anfrage auf diese URL ...
 await page.route(
 'https://jsonplaceholder.typicode.com/style.css',

 // ... diesen callback aus
 async (route: Route) => {
 console.log('invoked HTTP call to given route')

 // sende diese Response zurück
 await route.fulfill({
 status: 200,
 contentType: 'text/plain',
 body: 'No stylesheet for you',
 })
 },
 )

 // when
 await page.goto('https://jsonplaceholder.typicode.com/')
 
 // then
 // expectations ...
 })
})
```

Es empfiehlt sich, hier die Funktion so zu refactoren, um sie im 
```typescript
test.beforeEach(() => {})
```
aufzurufen und somit vor jedem Test die routes responses zu definieren.


> Einschub:
Die <a href="https://playwright.dev/docs/api/class-route#route-request" target="_blank">`route.request()`</a>-Funktion liefert den gesamten Request zurück und dadurch ist es möglich, bestimmte Requests zu filtern und entsprechend zu agieren. Um die Beispiele nicht zu verkomplizieren, wird auf die nicht näher eingegangen.

### Playwright UI

Die Playwright UI, eigentlich ein `Chromium` Browser, bietet auch den allseits bekannten `Network`-Tab an. Hier kann man den gemockten Request sehen und auch den Body näher analysieren.


| *Reale Anfrage* | *Gemockte Anfrage* |
|:--:|:--:|
![noMockedRequest.png](https://media.graphassets.com/322flvoeQ2q6wLVgxDRo) | ![mockedRequest.png](https://media.graphassets.com/QBAiHlgQRg6tObRHAWxr) |


| *Styling ohne mock* | *Styling mit mock* |
|:--:|:--:|
![noMockedStyle.png](https://media.graphassets.com/h1TSLbn2S4OW5LWpnEQD) | ![mockedstyle.png](https://media.graphassets.com/avYelIFRoSzOSVuB0XDD) | 


## Limitationen

Es können nur Netzwerkanfragen gemockt werden, die auch aus dem Browser raus ausgelöst werden. Diese sind im Netzwerk-Tab aus den Developer Tools des Browsers zu finden. Der Grund hierfür ist, dass es sich bei Playwright um eine Library handelt, die den User und somit die Interaktion mit Browser simuliert.

Ist die zu testende Webanwendung mit einem Fullstack Framework wie <a href="https://nextjs.org/" target="_blank">`NextJs`</a> oder <a href="https://remix.run/" target="_blank">`Remix`</a> implementiert, ist es entsprechend möglich, dass HTTP Calls auch im Backend aufgerufen werden.

Auf diese hat der Browser keinen Zugriff und sie können nicht gemockt werden.


## Fazit

Wie in diesem Blogbeitrag beschrieben, sind es nicht viele Schritte, um einen Request zu mocken. Gerade wenn man nicht Herr über das Backend ist, wird damit das Problem von konkret erwarteten Responses gelöst.

Playwright Tests und API Mocking

## Problem definition
<a href="https://playwright.dev/" target="_blank">Playwright</a> tests can sometimes depend on external services such as APIs, which might happen to be unavailable at times. In this case there are several options for executing these tests adequately, as described below.

* Actually call the request, such as a development environment.
 * If the backend cannot be reached, the test will fail.
* Start your own service such as <a href="https://wiremock.org/" target="_blank">Wiremock</a> and define the responses.
* Simulate the corresponding HTTP call.

_This blog article will illustrate the latter and describe how to simulate the corresponding HTTP calls._

## Example

If you call up a specific website in your test, further implicit requests are often made. This means that the website under test will trigger further HTTP calls on the client side during the page load. The following examples illustrate this procedure step by step.

> For upcoming examples, a service of `jsonplaceholder` is being used.

### General test

In the test implemented below, we imagine that a very specific request is carried out implicitly. To make this clear, we lead our test directly to the endpoint in order to develop a basis for further extensions. In this case, it is <a href="https://jsonplaceholder.typicode.com/todos/1" target="_blank">`/todos/1`</a>.

> This pattern is not practical and only serves the purpose of simplicity.


```typescript
import { test } from "@playwright/test";

test.describe('Description', async () => {

test('mytest', async ({ page }) => {
 // given
 // no prerequisites

 // when
 await page.goto('https://jsonplaceholder.typicode.com/todos/1')
 
 // then
 // expectations...
})

}
```

At the time of this blog post, `GET /todos/1` returns the following response.

```json
{
 "userId": 1,
 "id": 1,
 "title": "delectus aut autem",
 "completed": false
}
```

### Generic extension

Once we implemented the test from the previous example, we can start intercepting the request and executing a callback. The callback itself is a function that is executed as soon as Playwright recognizes this `route`. The following test, which is a extended test from above, continues the request after a `console.log` and the response remains the same.

```typescript
import { Route, test } from "@playwright/test";

test.describe('Description', async () => {
 test('mytest', async ({ page }) => {

 // given
 // for this route ...
 await page.route('https://jsonplaceholder.typicode.com/todos/1', async (route: Route) => {

 // ... execute this callback
 console.log('invoked HTTP call to given route')
 await route.continue()
 })

 // when
 await page.goto('https://jsonplaceholder.typicode.com/todos/1')

 // then
 // expectations ...
 })
})
```

> As mentioned above, this form of picking out a request to an endpoint is not common and is used for illustrative purposes. This test does not currently test a website, but only a request where the response is also mocked.

### Practical example

The test is now going to be converted. We access the website in our test. This call triggers further requests. One of them is a request that goes to the `style.css` stylesheet. This should not actually be executed. In this example, the response is replaced and returned as `text/plain`. This means that no styling is loaded on the page. 

For this purpose, the <a href="https://playwright.dev/docs/api/class-route" target="_blank">Route</a> interface offers the <a href="https://playwright.dev/docs/api/class-route#route-fulfill" target="_blank">`fulfill()`</a> function to define this response.

```typescript
import { Route, test } from "@playwright/test";

test.describe('Description', async () => {
 test('mytest', async ({ page }) => {

 // given
 // for this route ...
 await page.route(
 'https://jsonplaceholder.typicode.com/style.css',

 // ... execute this callback
 async (route: Route) => {
 console.log('invoked HTTP call to given route')

 // define this response
 await route.fulfill({
 status: 200,
 contentType: 'text/plain',
 body: 'No stylesheet for you',
 })
 },
 )

 // when
 await page.goto('https://jsonplaceholder.typicode.com/')
 
 // then
 // expectations ...
 })
})
```

It is recommended to refactor the function so that it can be used in the 
```typescript
test.beforeEach(() => {})
```
block. Therefore it's possible to invoke the function before every test.


> Out of scope but an FYI:
The <a href="https://playwright.dev/docs/api/class-route#route-request" target="_blank">`route.request()`</a> function returns the entire request, making it possible to filter certain requests and act accordingly. In order not to complicate the examples, these will not be discussed in detail.

### Playwright UI

The Playwright UI, actually a `Chromium` browser, also offers the well-known `Network` tab. Here you can see the mocked request and also analyze the body in more detail.


| *Actual request* | *Mocked request* |
|:--:|:--:|
![noMockedRequest.png](https://media.graphassets.com/322flvoeQ2q6wLVgxDRo) | ![mockedRequest.png](https://media.graphassets.com/QBAiHlgQRg6tObRHAWxr) |


| *Actual styling (actual request)* | *No styling (mocked request)* |
|:--:|:--:|
![noMockedStyle.png](https://media.graphassets.com/h1TSLbn2S4OW5LWpnEQD) | ![mockedstyle.png](https://media.graphassets.com/avYelIFRoSzOSVuB0XDD) | 


## Limitations

Only network requests that are triggered from the browser can be mocked. These can be found in the network tab of the browser's developer tools. The reason for this is that Playwright is a library that simulates the user and thus the interaction with the browser.

If the web application to be tested is implemented with a full-stack framework such as <a href="https://nextjs.org/" target="_blank">`NextJs`</a> or <a href="https://remix.run/" target="_blank">`Remix`</a>, it is also possible for HTTP calls to be called in the backend.

The browser has no access to these and cannot be mocked.

## Conclusion

As described in this blog post, there are not many steps involved in mocking a request. Especially if you do not have any possibility to access the backend, the problem of specific expected responses is being solved.

Playwright tests and API Mocking

„Sprichst du mit jemandem in einer Sprache, die er versteht, so erreichst du seinen Kopf. Sprichst du mit ihm in seiner eigenen Sprache, so erreichst du sein Herz.“ – Nelson MandelaDiesen Freitag und Samstag (12.-13.3.) sind auch wir bei der remote <a href="https://www.deafit.org" target="“_blank”">DeafIT 2021</a> dabei! Die Konferenz ist ein Raum für gehörlose und hörende IT-ler, um sich fachlich auszutauschen. Das einzigartige an dieser Konferenz: Jeder Talk wird sowohl in Laut- als auch Gebärdensprache zur Verfügung gestellt. Parallel dazu gibt es virtuelle Stände, die man besuchen kann. An unserem Stand wollen wir euch einen unserer Beiträge für mehr Inklusion in der IT zeigen: <a href="https://signtogether.github.io/DGSMemory" target="“_blank”">ein Memory, das beim Lernen Deutscher Gebärdensprache (DGS) unterstützt</a> .<h2>OffProject Time für gute Zwecke nutzen</h2>Als Softwareentwickler:Innen lösen wir ständig Probleme. Die meiste Zeit über tun wir das für unsere Kunden, die unsere Hilfe wollen, um ihre Geschäftsmodelle und -prozesse zu digitalisieren. Aber auch in unserem Alltag gibt es viele Herausforderungen, die man mit digitalen Lösungen begleiten kann. Nur fehlt dafür leider oft die Zeit und das Geld. Durch unsere OffProject Time bei codecentric können wir allerdings einen Beitrag leisten, unsere Expertise verstärkt auch für solche Projekte einzusetzen.Und so haben wir in den letzten Jahren den jährlichen Charity Day des Standortes München einem Hackathon zu Gunsten solcher Projekte gewidmet. Ein solcher Hackathon ist auch eine ideale Gelegenheit für Teambuilding. Der zeitlich knappe Rahmen schweißt uns mehr zusammen, und wir können einige wichtige Skills für unsere alltägliche Arbeit schulen: Gerne zerreden wir viele innovative Ideen, noch bevor wir ihnen überhaupt eine Chance gegeben haben. Dafür ist in diesem Setup keine Zeit, sondern man muss sich im Team schnell und konstruktiv auf ein gemeinsames Ziel einigen. Da sichergestellt ist, dass man sich zeitlich nicht zu ausschweifend damit auseinandersetzt, kann das auch wirklich etwas sein, an das man sich sonst nicht so heran getraut hätte, weil es dem Team doch zu roh oder kreativ erscheint. Beim Hackathon gilt: einfach ausprobieren. Dann überrascht man sich manchmal selbst, wie machbar vieles doch ist. Allerdings kann man auch nicht zu weit nach den Sternen greifen, sondern muss sich auf ein kleines Set an Features begrenzen, um realistischerweise zu einer nutzbaren Umsetzung zu kommen. So trainieren wir für uns immer wieder den MVP-Gedanken und fokussieren unsere Arbeit, statt viel abzuschweifen oder vergoldete Wasserhähne zu bauen.<h2>Die Idee des DGS Memory: Spielend Gebärden lernen</h2><img src="https://media.graphassets.com/I8G1QyS5Q7W7nX0lMv7u" alt="DGS Memory mit zwei aufgedeckten Karten: einem Video und dem Begriff &quot;Software Architektur&quot;" width="409" height="412" />In Bezug auf das unterstützte Lernen von DGS hat das für uns bedeutet: Wir passen ein bewährtes Spielkonzept wie Memory an die Bedürfnisse von Gebärdensprache an. Diese hat ganz andere Eigenschaften als wir es von Lautsprachen gewohnt sind, z. B. kann man Unterhaltungen auf Entfernung oder in lauten Umgebungen führen, stößt aber an Grenzen, wenn es dunkel ist. Daraus ergeben sich für Lernende ganz andere Herausforderungen. Statische Vokabelkarten funktionieren für das Lernen von Gebärdensprache nicht sehr gut, da das Visuelle und die Bewegung im Fluss eine große Rolle spielen. Hier kann ein digitaler Lernansatz wahnsinnig gut unterstützten, da wir mit Videos arbeiten können, statt mit statischen Bildern und Text. Für unsere Umsetzung ist also die größte technische Herausforderung, Videos gut einzubetten und dem Spieler vielfältige Möglichkeiten zu geben, diese anzuzeigen. Dabei haben wir sowohl alltägliche Vokabeln gewählt (Kategorien wie Tiere oder alltägliche Floskeln) als auch speziell an das Programm der DeafIT angepasste IT-Wörter wie „Agiles Projektmanagement“ oder „Web Development“. So wollen wir die Kommunikation auf der Konferenz, aber besonders auch im Alltag vereinfachen — egal ob beruflich oder privat. Gerne könnt ihr euch mit dem Memory auf die kommenden Konferenztage einstimmen!<h2>Mitstreiter gesucht!</h2>Mittlerweile hat sich aus dem Hackathon-Projekt eine <a href="https://github.com/signtogether" target="“_blank”">Open-Source-Initiative</a> entwickelt. Die aktuell geplanten Features enthalten z. B. verbesserte Accessibility, aber auch das Anlegen eigener Kategorien. Wir freuen uns wahnsinnig über Mitstreiter, egal ob es um Feedback, Hilfe bei Design oder Programmierung geht – jede:r kann sich gerne beteiligen. Besonders wünschen wir euch aber einfach Spaß beim Spielen und Lernen der wundervollen Deutschen Gebärdensprache!Hier gehts<ul><li><ul><li>zur DeafIT: <a href="https://www.deafit.org" target="“_blank”">https://www.deafit.org</a> </li><li>zum DGS Memory: <a href="https://signtogether.github.io/DGSMemory" target="“_blank”">https://signtogether.github.io/DGSMemory</a> </li><li>zum GitHub Repository: <a href="https://github.com/signtogether/DGSMemory/issues" target="“_blank”">https://github.com/signtogether</a> bzw. <a href="https://github.com/signtogether/DGSMemory/issues" target="“_blank”">https://github.com/signtogether/DGSMemory</a> </li></ul></li></ul>

Digitalisierung unterstützt Inklusion – Vorfreude auf die DeafIT 2021

Barrierefreiheit - Einfach loslegen!

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://media.graphassets.com/SwmH8NaDQmep7yDW2D1k"><img src="https://media.graphassets.com/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://media.graphassets.com/EM3qKOf3Tw6lyMctuYuN"><img loading="lazy" src="https://media.graphassets.com/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://media.graphassets.com/K9ZQz2c9QD255YvoIj1L"><img loading="lazy" src="https://media.graphassets.com/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://media.graphassets.com/YSlkREPhRgWHUv3kr4Mg"><img loading="lazy" src="https://media.graphassets.com/YSlkREPhRgWHUv3kr4Mg" alt width="640" height="312" /></a> AppDynamics Waterfall View</div> <div><a href="https://media.graphassets.com/I8zGqgdkRIKkzXbIuY2Q"><img loading="lazy" src="https://media.graphassets.com/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

Am Samstag, den 4. Oktober, um 16 Uhr ist es soweit: Die erste Partie der codecentric go challenge 2014 startet. Im Anschluss an die Partie, die auf dem KGS Go-Server gespielt wird, wird das Ergebnis incl. der Partie zum Nachspielen auf <a href="https://go.codecentric.de">http://go.codecentric.de</a> zu finden sein.Noch vor dem Start der ersten Partie waren beide Teilnehmer zu einem Interview bereit. Vielen Dank an beide!Franz-Josef Dickhut (FJD), 6. Dan:1. Du spielst seit vielen Jahren auf allerhöchstem Niveau Go. Wie hast Du in all diesen Jahren die Entwicklung des Computer-Go verfolgt?FJD: Zunächst nur am Rande, bis vielleicht vor zwei, drei Jahren, da Go-Programme einfach zu schwach waren, um für mich etwas Interessantes zu bieten. Da gab es bestenfalls mal eine Engine zu bewundern, die recht gut im Lösen lokaler Leben&Tod-Probleme war, oder dann allmählich auch auf 9×9-Brettern [Anmerkung des Autors: Die reguläre Größe eines Go-Brettes ist 19×19]. Inzwischen hat sich das aber grundlegend geändert, denn mit dem Monte-Carlo-Ansatz sind die Programme sprungartig stärker geworden, so dass es z.B. Spaß machte, gegen einige der Programme auf KGS zu spielen, obwohl die meisten Programme noch Vorgabe brauchen. Die stärksten Programme halte ich zwar immer noch für schwächer (zumindest in ihren 2013-er Versionen) als meine eigene Spielstärke, aber dadurch, dass sie ihre Züge so grundlegend anders generieren als ich bzw. als menschliche Gegner, bekommt man eine Menge Anregungen und z.T. einen neuen Blickwinkel für das eigene Spiel. Das macht die „Kisten“ auch interessant für mich, und dabei ist es nicht so relevant, ob sie nun etwas schwächer oder vielleicht schon etwas stärker sind als ich.2. Hattest Du jemals daran gedacht, Dich selbst an einem Go-Programm zu versuchen oder anderweitig einen Beitrag zur Entwicklung von Go-Programmen zu leisten?FJD: Selbst programmieren – nein, denn von Programmierung habe ich so gut wie keine Ahnung (mal abgesehen von 30 Jahre altem Schulstoff). Ich könnte mir aber vorstellen, als Tester, Berater, oder etwas ähnlichem mitzuwirken, was den golichen Teil der Arbeit angeht. Sicher bräuchte ich da auch etwas mehr Verständnis von der Arbeitsweise der Programme, aber das stelle ich mir schon so interessant vor, dass es sich vielleicht lohnen würde, mich da etwas einzulesen.3. Hast Du einen besonderen Plan für das Match? Hast Du Dir eine besondere Anti-Computer-Go-Strategie zurecht gelegt, vielleicht sogar eine besondere Anti-Crazy-Stone-Strategie? Oder wirst Du einfach nur versuchen, gutes Go zu spielen?FJD: Einen konkreten Plan, z.B. welche Eröffnungen ich spielen möchte, oder irgendwelche Spezialjosekis [Anmerkung des Autors: Joseki sind etablierte Abspiele in den Ecken des Brettes] habe ich mir für dieses Match nicht bzw. noch nicht zurecht gelegt. Ich kenne zwar die gängigen Tips für das Spiel gegen MC-Bots bzw. deren Schwächen (am besten ein Semeai mit Ko und Nakade [Anmerkung des Autors: eine komplexe und schwierige Leben-und-Tod-Stellung auf dem Brett]), aber es bewußt darauf anzulegen habe ich nicht vor – allerdings kommen diese „Stilmittel“ ohnehin in vielen meiner Partien vor. Ich würde also sagen, ich werde versuchen gutes Go zu spielen, und hoffe, dass die zu erwartenden „verrückten Kämpfe“ entstehen, weil CrazyStone eben doch ein paar Fehler macht, und nicht weil ich es darauf anlegen muss um noch eine Chance zu haben…4. Und eine letzte Frage: Wie beurteilst Du Deine Chancen im Match?FJD: Ich hoffe und glaube, dass ich zur Zeit noch der Favorit bin. Allerdings hat Ingo Althöfer, der dieses Match angeregt hatte, es geschafft, mir mit einigen geschickten Andeutungen ein paar Zweifel einzuimpfen. So weiß ich natürlich nicht, welche Verbesserungen die neueste CrazyStone Version mit sich bringt, und wie stark diese sich auf die Spielstärke auswirken werden. Auch kann ich als Laie nicht beurteilen, wie stark sich eine bessere Hardware und damit die höhere Anzahl der Simulationen letztlich in der Spielstärke niederschlagen. Da ich aber meine eigenen Spielstärkeschwankungen kenne, würde ich nicht auf ein 3-0 tippen.Rémi Coulom (RC), Entwickler von Crazy Stone (Übersetzung aus dem Englischen von Georg Snatzke):1. Wann hast Du mit der Entwicklung eines Go Programmes begonnen? Und wichtiger: Warum?RC: Ich begann 2005. Zuerst betreute ich mit Bruno Bouzy einen Studenten, Guillaume Chaslot. Das Thema seiner Forschung waren Monte Carlo Methoden bei Go. Guillaume verließ später Lille, um eine Doktorarbeit in Maastricht zu beginnen, aber ich wollte weiter an Go arbeiten. Deswegen habe ich im Sommer 2005 mit der Arbeit an Crazy Stone begonnen.<div>2. Hast Du Crazy Stone vollständig alleine entwickelt oder hattest Du Partner?</div>RC: Ich bin der einzige Programmierer von Crazy Stone, aber ich wurde unterstützt von Unbalance, dem Herausgeber von Crazy Stone, und meiner Universität, die mir viel freie Zeit zubilligte und Zugang zu sehr leistungsfähigen Computern gewährte (<a href="https://www.grid5000.fr/">https://www.grid5000.fr/</a> ).<div>3. Welche Programmiersprachen, Frameworks und Werkzeuge hast Du bei der Verwendung von Crazy Stone verwendet? Was waren Deine Gründe für ihre Wahl?</div>RC: Ich programmiere in C++ mit vim. Das sind die Werkzeuge, die ich gut kenne.<div>4. Neben Go hast Du auch Programme für einige andere Spiele entwickelt. Was sind aus Deiner Sicht die wesentlichen Unterschiede in der Programmierung von Go verglichen mit Schach oder Othello?</div>RC: Der hauptsächliche Unterschied ist, dass künstliche Intelligenz bei Schach und Othello auf dem Ansatz traditioneller Mini-Max-Suche beruht, während Crazy Stone Monte Carlo Baumsuche nutzt.<div>5. Kannst Du das grundlegende Prinzip beschreiben, Monte Carlo Methoden mit traditioneller Baumsuche in Go zu kombinieren? Gehe ich Recht in der Annahme, dass man in einer gegebenen Spielposition mit Baumsuche beginnt und Monte Carlo Methoden benutzt, um die Stellung an den Blättern des Baumes zu bewerten? Oder ist diese Sicht der Dinge zu einfach?</div>RC: Einige frühe Monte Carlo Programme haben diesen Ansatz verfolgt. Sie nutzten eine traditionelle Minimax-Baumsuche mit einer Monte Carlo-Bewertung an den Blättern. Aber dies war sehr ineffizient. Die aktuellen starken Monte Carlo Programme nutzen Monte Carlo-Bewertungen auch innerhalb des Baumes. Da der beste Zug häufiger durchsucht wird als die anderen, nähert sich der Monte-Carlo-Baum langsam einem Minimax-Baum an – wenn die Zahl der Monte Carlo Durchläufe gegen Unendlich geht. Aber er wird niemals ganz Minimax.<div>6. Wirst Du die normale kommerzielle Version von Crazy Stone für den Wettkampf gegen Franz-Josef Dickhut verwenden oder eine spezielle Match-Version?</div>RC: Ich werde die aktuelle, experimentelle Version von Crazy Stone benutzen. Sie ist ein wenig stärker als die kommerzielle Version.<div>7. Planst Du, das Programm zwischen den Spielen anzupassen, also auf Ereignisse im Match zu reagieren?</div>RC: Nicht wirklich. Ich arbeite ständig daran, Crazy Stone zu verbessern, so dass ich vielleicht tatsächlich eine unterschiedliche Version in jedem Spiel benutzen werde, falls ich unter der Woche eine Verbesserung finde. Aber ich erwarte nicht, Verbesserungen aufgrund dessen zu finden, was während des Matches passiert. Crazy Stone hat bereits viele Spiele gegen starke menschliche Gegner auf KGS hinter sich, und ich habe seine Schwächen dort bereits gut identifiziert.<div>8. Ich weiß aus persönlicher Erfahrung mit der Android Version von Crazy Stone, dass die Rechenleistung sehr wichtig für die Spielstärke des Programmes ist. Welche Hardware wirst Du für das Match nutzen?</div>RC: Ich werde wahrscheinlich einen 20 Core Node von Grid’5000 nutzen (Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz).<div>9. Was schätzt Du, wieviel stärker Crazy Stone auf dieser Hardware verglichen zu einem modernen Smartphone sein wird?</div>RC: Auf dieser Maschine schafft Crazy Stone ca. 40.000 Monte Carlo Durchläufe pro Sekunde, auf meinem Nexus 5 sind es 1.700. Ich weiß nicht, wieviele Spielstufen das ausmacht, aber die Spielstärkedifferenz ist sehr groß.<div>10. Eine letzte Frage: Wie beurteilst Du Deine Chancen im Match?</div>RC: Ich erwarte, dass Crazy Stone alle drei Spiele verlieren wird. Meiner Meinung nach ist es klar schwächer. Aber die Differenz ist nicht groß, so dass es mit Glück ein Spiel gewinnen kann. Ich hoffe, aufregende Spiele beobachten zu können.

codecentric go challenge 2014: Interviews mit Franz-Josef Dickhut und Rémi Coulom

Die codecentric go challenge 2014 ist vorbei. Franz-Josef Dickhut konnte Crazy Stone, eines der beiden stärksten Go Programme weltweit, mit drei Siegen bei einer Niederlage niederringen. Die Spiele können auf <a href="https://go.codecentric.de">go.codecentric.de</a> nachgespielt und heruntergeladen werden.Herzlichen Glückwunsch an Franz-Josef Dickhut und vielen Dank an codecentric für das Sponsoring der Veranstaltung!Wie auch schon direkt vor dem Beginn des Wettkampfes wollen wir die Kontrahenten selbst zu Wort kommen lassen.Die ersten Fragen gehen an den Sieger, Franz-Josef Dickhut (FJD): 1. Die Partien gegen Crazy Stone waren hart umkämpft und, so konnte man aus einigen Deiner Kommentare herauslesen, auch für Dich Schwerstarbeit. Warst Du von der Stärke von Crazy Stone überrascht oder hattest Du mit solch schweren Kämpfen gerechnet?FJD: Was die Spieltärke angeht, war ich nicht zu sehr überrascht. Mit etwas Arbeit hatte ich schon gerechnet. Aber nachdem die erste Partie so schief lief, war der Druck schon sehr groß, und das hat die Arbeit dann zusätzlich anstrengend gemacht. Ich fand es dann letztlich sehr schade, dass die letzte Partie eigentlich die am wenigsten interessante war. Schon am Anfang spielte Crazy Stone unerwartete – wohl auch schwache oder zumindest zu frühe – Züge, und dann kam auch schon das technische Problem, die weiße Gruppe starb und der Drops war gelutscht. Das war leider kein passender Abschluss für so ein enges und umkämpftes Match.2. Letztendlich blieb Deine Niederlage im ersten Spiel ein Ausrutscher. Was war in Runde 1 passiert? Was war anders als in den Partien 2, 3 und 4?FJD: In Runde 1 kam alles zusammen, was nicht passieren sollte: Eine Stellung, die Bots entgegen kommt (Moyo [eine große aber sehr lose, noch nicht fest abgeschlossene Gebietsanlage]), leichtsinniges Spiel und infolge dessen Fehler meinerseits. Demnach stand Crazy Stone früh klar vorn und dann kommen die Stärken der Monte-Carlo-Programme richtig gut zur Geltung. Ab der zweiten Partie habe ich vor allem vorsichtiger gespielt, um nicht wieder einen schnellen definitiven Nachteil zu riskieren. Und zur Entspannung habe ich nebenbei klassische Musik gehört, vielleicht hat das auch geholfen.3. Eine Frage unter uns Go-Spielern: Zu welchen Zeitpunkten waren die einzelnen Partien Deiner Meinung nach weitgehend entschieden? Gerade für etwas schwächere Spieler – auch für mich – ist das schwer abzuschätzen, insbesondere da Crazy Stone mich durch seine vielen Kikashi-Züge [starke Droh-Züge, die sofort beantwortet werden müssen] verwirrte. Mir war selten klar, ob der Bot nun besonders clever war oder sich bereits im Panik-Modus befand, weil er zu verlieren glaubte.FJD: Partie 1: eigentlich nach 70 Zügen vorbei. Ich denke aber, mit 170 auf 171 wäre es noch mal interessant geworden. Partie 2: wirklich sicher war ich mir erst mit 183, obwohl ich schon vorher ein gutes Gefühl hatte (konkret etwa um Zug 143) Partie 3: Das war die engste und schwierigste Partie des Matches, und als einziger Sieg von Weiß wohl auch der Knackpunkt. Während der Partie war es mir erst mit Zug 233/234 wirklich klar, dass ich gewonnen habe, aber die Partie war mit 210 definitiv entschieden. Partie 4: Nach dem Anbinden mit Zug 81, wonach die weiße Gruppe rechts einfach und ohne Schäden für Schwarz tot war.4. Wo liegen aus Deiner Sicht die besonderen Schwächen und Stärken von Crazy Stone? Sind die – soweit Du da Erfahrung hast – typisch für Monte-Carlo-Bots oder eher spezifisch für Crazy Stone?FJD: Zunächst mal halte ich Crazy Stone für eines der Monte-Carlo-Programme, die am schwierigsten zurecht zu legen sind, obwohl es auch noch unter den typischen Problemen leidet. Dazu gehören offensichtlich die Ko-Schwäche [Ko: eine Art Zugwiederholung durch dauerndes Schlagen und Zurückschlagen], also eine Aversion Kos zu spielen und relative Unfähigkeit, Ko-Stellungen zu bewerten (was auch z.T. für Nakade [Gruppen mit einer potenziell toten Form] bzw Eckformen gilt). Eine weitere Schwäche ist aber auch gleichzeitig die große Stärke: Steht eine Partie gut für den Bot, sind sie unglaublich flexibel und gleichzeitig unbeirrbar auf dem Weg zum Partiegewinn. Steht eine Partie aber erst mal schlecht für den Bot, eventuell auch nur knapp, aber erkennbar für den Bot, dann suchen sie aktiv nach einer Möglichkeit wieder zwingend nach vorn zu kommen, was für den menschlichen Spieler aber naiv und panisch wirkt. Erfahrene Spieler wissen aber, dass das beste, was man in solchen Situationen tun kann, ist, die Partie unklar zu halten, entweder die Partie Stück für Stück wieder knapper zu machen oder die Varianz zu erhöhen, und darüber hinaus auch ein Stück weit auf „unforced“ Fehler des Gegners zu warten. Das fehlt den Bots meiner Meinung nach noch, zumindest in der Feinabstimmung.5. Konntest Du Deinen Vorsatz durchhalten und einfach nur gutes Go spielen, oder hast Du im Verlauf des Matches doch versucht, spezielle Schwächen von Crazy Stone auszunutzen?FJD: Ich habe schon versucht, die besten Züge zu spielen, jedenfalls soweit es mir möglich ist. Natürlich habe ich in Situationen, wo es halbwegs gleichwertige Alternativen gab, diejenige zu wählen versucht, die Crazy Stone vermutlich die größeren Probleme bereiten würde. Ich habe aber nicht absichtlich schlechte Züge gespielt, nur weil dabei vermutlich/hoffentlich irgendein bekanntes Bot-Problem zum Tragen käme.6. Du hattest Dich mit der kommerziellen Version von Crazy Stone 2013 auf Deinen Gegner vorbereitet. Hat Dir diese Vorbereitung geholfen?FJD: Es hat auf jeden Fall geholfen, obwohl ich mich erst gegen die Hilfe „gewehrt“ habe (das 5-3 Joseki [typische Zugabfolgen in einer Ecke] aus der ersten Partie hatte ich mir eigentlich anders vorgenommen, aber dann „überkam“ mich meine Experementierfreude). Auch einfache typische „Josekifehler“ wie mit S29 aus Partie 3, das Auslassen des Deckungszuges am Rand nach der Eckinvasion oben rechts, und Zug 22 in Partie 4, der 1-Punkt Sprung statt Strecken in dem 5-3 Joseki dort, waren mir bekannt und halbwegs erwartet, wobei es sich doch jedesmal wieder als schwierig erweist, so etwas dann auch in eine gute Stellung zu überführen.7. Und empfandest Du Crazy Stone im Match stärker oder vergleichbar stark zu Deiner Trainingsversion?FJD: Die Match-Version war schon stärker, jedoch ohne grundlegende Unterschiede. Es lag wohl an der Hardware, denn mein Rechner ist schon knapp vier Jahre alt – hat allerdings eine für damalige Verhältnisse ordentliche Ausstattung mit einem AMD 6-core Prozessor (müsste nochmal nachschauen, wenn die genaue Konfiguration interessant wäre).8. Würdest Du, im Rückblick betrachtet, anders an das Match herangehen, bezogen sowohl auf die Vorbereitung als auch die konkreten Partien?FJD: Nicht wesentlich. Ich würde wohl versuchen, schon von der ersten Partie an etwas konzentrierter, weniger experimentell zu spielen, um mein Risiko für große Fehler zu reduzieren. Ich hatte ja schon vor dem Match vermutet, dass mir sowas in mindestens einer Partie passiert, aber es erhöht den Druck schon immens, wenn es gleich in der ersten passiert und man hinten liegt, ohne schon eine Idee zu haben, wie man dem Gegner normalerweise (ohne Patzer) beikommt. Das hat mich wirklich sehr verunsichert und mich einige Nerven gekostet.9. Würdest Du für einen weiteren Wettkampf dieser Art im nächsten Jahr zur Verfügung stehen?FJD: Ja, sogar gern.Rémi Coulom (RC), Entwickler von Crazy Stone (Übersetzung aus dem Englischen durch den Autor):1. Leider hattest Du nicht die Grid-Hardware zu Deiner Verfügung wie ursprünglich geplant, so dass Crazy Stone auf Deinem Desktop-Computer laufen musste. Außerdem hast Du für alle vier Spiele die kommerzielle Version Crazy Stone 2013 benutzt. Was war der Grund dafür?RC: Die aktuelle experimentelle Version ist nicht viel stärker als die veröffentlichte kommerzielle Version, daher zog ich es vor, eine stabile und gut getestete Version während des Wettkampfes zu benutzen.2. Die meisten Beobachter der Spiele hatten den Eindruck, dass Crazy Stones Monte Carlo Engine um so größere Probleme hat, je mehr nicht ausgespielte Stellungen es auf dem Brett gibt. Crazy Stone schien auch Schwierigkeiten mit der korrekten Bewertung bestimmter Eckstellungen zu haben. Was denkst Du zu diesen Beobachtungen?RC: Crazy Stone ist jedes Mal komplett verwirrt, wenn die Monte-Carlo-Durchläufe ein Leben-und-Tod-Problem falsch bewerten. Dies ist ein Problem von Monte-Carlo-Programmen, das klar identifiziert ist. Eine gute Lösung ist nicht einfach zu finden.3. Was sind Deiner Meinung nach die wichtigsten Gründe für die Niederlagen in Spiel 2, 3 und 4?RC: Spiel 3 war sehr eng und ich bin als Spieler nicht stark genug, irgendein offensichtliches Missverständnis auf Seiten von Crazy Stone zu erkennen. In Spiel 2 und Spiel 4 gab es große Leben-und-Tod-Fehler in den Durchläufen.4. Hard- und Software waren für alle vier Spiele des Wettbewerbs identisch. Gab es irgendeinen anderen Grund für die – von vielen Beobachtern so wahr genommene – vergleichsweise schwächere Vorstellung von Crazy Stone in Spiel 4? Oder war es schlicht Pech, das auf die falsche Bewertung der großen Leben-und-Tod-Stellung am rechten Brettrand schon früh im Spiel zurückzuführen ist?RC: Ja, das war Pech. Es gab auch ein kleines technisches Problem während des Spiels. Crazy Stone kappte wegen eines Netzwerk-Problems die Verbindung, stellte sie dann wieder her, aber die erste Instanz der Engine lief immer noch im Hintergrund weiter, was die verfügbare Prozessorleistung reduzierte. Aber angesichts der falsch verstandenen Leben-und-Tod-Stellung am rechten Rand hätte Crazy Stone auch mit 1000 Mal mehr CPU-Leistung schlecht gespielt.5. Das Zeit-Management von Crazy Stone für den Wettbewerb war recht einfach: Es dachte genau 38 Sekunden über jeden Zug nach. Glaubst Du, dass es im Bereich des Zeit-Managements von Monte-Carlo-Bots Verbesserungspotenzial gibt oder spielt dies nicht wirklich eine Rolle?RC: Ja sicher, dieser Bereich könnte verbessert werden. Bei Computer-Go-Turnieren gibt es für gewöhnlich eine Sudden-Death Zeitregelung, womit Crazy Stone geschickter umgeht. Die Heuristiken für das Zeit-Management für diese Art von Byoyomi Zeitkontrolle [wie in der codecentric go challenge 2014 verwendet] zu optimieren, ist nicht sehr interessant. Ich ziehe es vor, meine Energie auf wichtigere Probleme zu fokussieren.6. Nutzt Crazy Stone die Bedenkzeit des Gegners für eigene Berechnungen?RC: Ja.7. Konntest Du über Stärken und Schwächen von Crazy Stone aufgrund des Matches mit Franz-Josef Dickhut neue Erkenntnisse gewinnen?RC: Nein. Die Schwächen von Crazy Stone sind identifiziert. Das Problem ist, dass ich nicht weiß, wie ich sie gut beseitigen soll. Bei top Go-Programmen gibt es seit fast zwei Jahren keinen Fortschritt mehr.8. Was sind Deine Prioritäten für die Verbesserung von Crazy Stone? Welche Themen wirst Du als nächste angehen?RC: Das Hauptproblem ist, die Zufalls-Durchläufe intelligenter zu machen. In der Vergangenheit gab es Fortschritte bei Crazy Stone, indem weitere Muster in die Durchläufe eingebracht wurden. Ich glaube, dass ich die Spielstärke immer noch erhöhen kann, indem ich die Muster weiter verbessere, aber das wird nicht alles lösen. Es ist nicht möglich, Muster zu haben, die für jedes mögliche Spiel funktionieren. Es werden immer Konfigurationen in Spielen auftauchen, bei denen die Durchlauf-Muster Leben-und-Tod falsch bewerten. Die Lösung ist, die Strategie für Monte-Carlo-Durchläufe online anzupassen. Einige Algorithmen wurden vorgeschlagen, aber sie funktionieren noch nicht gut genug.9. Wann gibt es die nächste kommerzielle Version von Crazy Stone?RC: Über konkrete Zeitpunkte kann ich nichts sagen, aber es wird neue Versionen geben. Eine Version für den Windows-8-Store wird schon bald veröffentlicht. Für diese neue Version habe ich viel daran gearbeitet, den Spielstil von Crazy Stone im Endspiel zu verbessern: Wenn es klar gewinnt oder verliert, wird es anders als früher weniger verrückte Züge spielen, die Punkte wegwerfen. Ich habe auch „einfache“ Spielstufen eingeführt, die für Anfänger angenehmer zu spielen sein sollten.10. Noch eine etwas schwierigere Frage nach einem Zeitrahmen: Wie lange noch werden Franz-Josef Dickhut oder andere starke Amateur-Spieler eine Chance gegen Bots haben? Und wie viel länger werden Profis durchhalten?RC: Keine Ahnung. Sobald jemand eine gute Lösung für das Problem mit den Monte-Carlo-Durchläufen findet, das ich in Antwort Nr. 8 beschrieben habe, kann es sehr schnell unschlagbare Programme geben.11. Würdest Du für einen weiteren Wettkampf dieser Art im nächsten Jahr zur Verfügung stehen?RC: Ja, sogar gern.

codecentric go challenge 2014: Abschließende Interviews

An diesem Samstag, dem 3. Oktober, beginnt die zweite codecentric go challenge. Die challenge – organisiert von Prof. Ingo Althöfer von der Friedrich-Schiller-Universität Jena und gesponsort von codecentric – ist ein Match auf drei Siegpartien eines starken Computer-Go-Programms gegen einen führenden Amateurspieler. Im letzten Jahr hat Franz-Josef Dickhut, Amateur 6 Dan und elfmaliger deutscher Go-Meister, Crazy Stone mit 3:1 geschlagen. Dieses Jahr geht es für Franz-Josef gegen das japanische Program Zen. Zen und Crazy Stone haben die Computer-Go-Szene der letzten Jahre dominiert.Die Spiele werden online auf KGS ausgetragen: <a href="https://www.gokgs.com">https://www.gokgs.com</a> . Franz-Josef Dickhut spielt als „fj“, Zen als „Zen19S“. Alle Spiele beginnen um 14:00 Uhr. Die Ergebnisse kann man auf <a href="https://go.codecentric.de">go.codecentric.de</a> nachlesen, wo man die einzelnen Partien auch nachspielen kann.Wie schon im letzten Jahr haben wir erneut einige Fragen an die beiden Kontrahenten vor dem Start des Matches.Interview mit Franz-Josef Dickhut (FJD):1. Hast du die Entwicklung des Computer-Go im vergangenen Jahr verfolgt? Siehst du irgendwelche bemerkenswerten Entwicklungen?FJD: Ich habe zwar interessiert zugeschaut, wenn ich mal starke Bots auf KGS spielen sehen habe, aber sehr genau bzw. intensiv habe ich die Entwicklung nicht verfolgt.Große Spielstärkesprünge an der Spitze scheint es nicht gegeben zu haben, es sind aber wohl ein paar gute Programme dazu gekommen (DolBaram, Abakus) und die zweite Garde scheint allgemein etwas aufgeschlossen zu haben.2. Wie gut kennst du deinen diesjährigen Gegner Zen? Siehst du wesentliche Unterschiede zu Crazy Stone, gegen das du 2014 angetreten bist?FJD: Zen ist ja relativ viel auf KGS unterwegs, und die 2012er Version kannte ich noch aus eigener Erfahrung. Aber ich denke, seitdem ist es ziemlich gereift, was genau da anders geworden ist, kann ich noch nicht sagen, es scheint eine Joseki- und Fuseki-Bibliothek zu haben? Große Unterschiede zu Crazy Stone habe ich noch nicht herausarbeiten können (s.u.).3. Wie bereitest du dich dieses Jahr auf das Match vor?FJD: Ich werde mir die online verfügbaren Partien von Zen aus diesem Jahr in dieser Woche mal ansehen, um vielleicht ein paar Schwachpunkte herauszufinden, oder Hinweise zu bekommen, was ich besser nicht versuchen sollte 😉Hoffentlich ist die Zeit zur Vorbereitung nicht zu knapp.4. Und die obligatorische letzte Frage: Was sind Deine Erwartungen für das Match?FJD: Ich erwarte wieder enge Partien. Aber am Ende sollte ich gewinnen können. Ich hoffe nur, nicht wieder die erste Partie zu verlieren, denn letztes Jahr war nach der Auftaktniederlage der Druck schon unangenehm. Wenn ich tippen müsste, würde ich wieder auf ein 3:1 setzen.Interview mit Hideki Kato (HK), der Zen bei der codecentric go challenge repräsentiert. Übersetzung aus dem Englischen:1. Hideki, erzähl uns ein wenig über Zen. Wann und warum begann das Projekt?HK: Es gab zwei Phasen. 2005 begann Yoji Ojima („Yamato“) aus persönlichem Interesse, Computer Go zu studieren. 2006 begann ich einen Promotionskurs an der Universität von Tokyo mit Computer Go als Forschungsgegenstand. Bis 2009 hatten wir beide unsere eigenen Programme entwickelt, Zen und Fudo Go.Als Crazy Stone den UEC Cup im Dezember 2008 gewann (Fudo Go belegte den 2. Platz, Zen trat nicht an), dachte ich, dass es für mich alleine sehr schwer sein würde, Crazy Stone zu schlagen. Daher plante ich, ein Team mit Yamato zu bilden, da wir beide beabsichtigten, die Vorteile der beiden stärksten Programme zu vereinen, Crazy Stone und MoGo. Das Projekt (und das Team) DeepZen startete mit Yamato im August 2009 nach Zens erstem Auftritt und dem unerwarteten Gewinn der Computer-Olympiade in Pamplona. Das Ziel des Projektes war, den UEC Cup zu gewinnen, was der sehnliche Wunsch der japanischen Seite war. Dies gelang beim 5. UEC Cup im Dezember 2011 nach einer langen, sieglosen Durststrecke japanischer Programme in Japan (mehr als 10 Jahre – zu lange, um sich an die genaue Zahl zu erinnern :p). Das aktuelle Ziel ist, ein Programm auf professionellem Spielstärke-Niveau zu entwickeln.2. Wer arbeitet an Zen und was ist deine Rolle im Team?HK: Das Team DeepZen hat zwei Mitglieder. Yoji Ojima (Yamato) ist der Hauptentwickler und arbeitet an der Einzelversion von Zen. Ich, Hideki Kato, repräsentiere Zen nach außen und entwickle die parallele Cluster-Version von Zen. Außerdem bin ich für alles andere zuständig: PR, Agent von Zen etc.3. Gibt es deiner Meinung nach etwas Besonderes, das Zen einzigartig macht?HK: Yamatos Zeit wird vollkommen von der Arbeit an Zen beansprucht (kein Scherz 🙂 ) – durch das Tunen und/oder die Implementierung neuer Ideen. Er arbeitet sehr hart. Ich weiß nicht, ob du „MC simulation is Black Magic“ von Sylvain Gelly kennst, dem Hauptentwickler von MoGo. Es gibt keine grundlegende Theorie, unerwartetes Verhalten etc. Daher basiert die Verbesserung von MC-Go-Bots zur Zeit auf Trial-and-Error-Versuchen mit vielen Benchmark-Tests, bei denen jeder Test aus tausenden Spielen besteht und folglich richtig lange dauert. Da die Qualität der Simulation der Schlüssel zur Spielstärke von MC-Bots ist und deren Verbesserung sehr viel Zeit beansprucht, lande ich wieder bei meiner ersten Aussage in dieser Antwort.4. Auf welcher Hardware wird Zen für die Challenge laufen?HK: Ich werde einen Cluster aus 4 PCs nutzen:<ul><li>ein dual 12-core Xeon E5-2690 v3@2.6 GHz, 32 GB RAM,</li><li>ein dual 10-core Xeon E5-2690 v2@3 GHz, 32 GB RAM,</li><li>ein dual 6-core Xeon X5680@3.5 GHz, 8 GB RAM und</li><li>ein 8-core Core i7 5960X@3 GHz, 16 GB RAM.</li></ul>Die Computer werden mit einem GbE LAN verbunden – insgesamt 64 Kerne.5. Wirst du die kommerzielle Version von Zen oder eine spezielle Match-Version nutzen?HK: Eine spezielle Version für wichtige Spiele :).Die kommerzielle Version ist ein wenig älter (und somit schwächer) und nicht clusterfähig.6. Wirst du während der challenge am Programm arbeiten, also auf Ereignisse des Matches reagieren?HK: Ja, aber nur sehr eingeschränkt: Bugs fixen und/oder verschiedene Versionen für verschiedene Runden nutzen, z.B.Falls du mit „reagieren“ meinst, das Programm zu ändern bzw. zu verbessern: Das ist beinahe unmöglich. Auf dem Niveau von Zen ist die Bestätigung, dass eine „Verbesserung“ wirklich Zens durchschnittliche Spielstärke steigert, keine leichte Aufgabe. Viele Tests sind nötig (Benchmark- und Regressionstests, Praxistests etc.). Das dauert normalerweise einige Monate und mehr.7. Vor vielleicht zehn Jahren begannen Monte-Carlo-Methoden, Go-Computer-Programme deutlich stärker zu machen. Rémi Coulom, der Entwickler von Crazy Stone, sagte letztes Jahr, dass es seit zwei Jahren (nun also seit drei Jahren) kaum Fortschritt gäbe. Stimmst du dieser Einschätzung zu? Was, denkst du, ist nötig, um Computer Go auf eine professionelle Spielstärke zu heben?HK: Ja, ich stimme definitiv zu. Meiner Meinung nach ist das Wichtigste, einen top-down Leben-und-Tod-Algorithmus mit dem aktuellen bottom-up-MC-Framework zu kombinieren. Das Ziel ist bekannt, aber niemand hat es in den bisherigen fünfzig Jahren Computer-Spiel-Geschichte geschafft.Aber es sollte noch mehr geben, glaube ich. Leistungsfähige und flexible assoziative Speicher und Lernmethoden, z.B.8. Hast du die codecentric go challenge 2014 verfolgt, das Match zwischen Franz-Josef Dickhut und Crazy Stone? Irgendwelche Anmerkungen?HK: Das Ergebnis ist nicht überraschend.9. Die obligatorische Abschlussfrage: Wie bewertest du eure Chancen im Match?HK: Ungefähr mit 25% (oder weniger), da Zen ein mittlerer 5 Dan bei der gegebenen Bedenkzeitregelung ist. D.h., es gibt eine Lücke von 200 (oder mehr) Elo-Punkten.Glossar:Elo: Punktesystem, um die relative Spielstärke zu messebnFuseki: Die Eröffnungsphase einer Go-PartieJoseki: Feste Abspiele in den Ecken eines Go-BrettesMC: Monte-Carlo-Methoden: Algorithmen, um mittels zufälligen Abspielen und statistischen Methoden gute Züge in einer Go-Stellung zu findenUEC Cup: Jährliches Computer-Go-Turnier der Universität für Elekto-Kommunikation in Tokio, Japan

codecentric go challenge 2015

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://media.graphassets.com/SwmH8NaDQmep7yDW2D1k"><img src="https://media.graphassets.com/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://media.graphassets.com/EM3qKOf3Tw6lyMctuYuN"><img loading="lazy" src="https://media.graphassets.com/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://media.graphassets.com/K9ZQz2c9QD255YvoIj1L"><img loading="lazy" src="https://media.graphassets.com/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://media.graphassets.com/YSlkREPhRgWHUv3kr4Mg"><img loading="lazy" src="https://media.graphassets.com/YSlkREPhRgWHUv3kr4Mg" alt width="640" height="312" /></a> AppDynamics Waterfall View</div> <div><a href="https://media.graphassets.com/I8zGqgdkRIKkzXbIuY2Q"><img loading="lazy" src="https://media.graphassets.com/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

This Saturday, October 4th, at 4 pm, the first game of the codecentric go challenge 2014 will be started. We will document the finished game – which will be played on the KGS Go Server – at <a href="https://go.codecentric.de">http://go.codecentric.de</a> .Before the start of the first game both participants have agreed to an interview. Thanks a lot to both of them!Franz-Josef Dickhut (FJD), 6 Dan (translation from German by Georg Snatzke):1. Since many years you are playing go on the highest level. How did you follow the development of computer go in all these years?FJD: Originally not very much, until maybe two or three years ago, as go programs were simply too weak to have anything interesting for me to offer. At most one could marvel at an engine that was quite good in solving local live & death problems or on the 9×9 board [note by the author: the regular go board is size 19×19]. In the meantime, this has changed fundamentally as with the Monte Carlo approach the strength of the programs has made a leap. So for example it is now fun to play against some of the programs on the KGS go server, although most still need a handicap. I think that the strongest programs are still weaker than me, at least their versions of 2013. But as they generate their moves so fundamentally different than me or other human opponents, you get a lot of new suggestions and partly a new perspective on your own game. That makes the “boxes” interesting for me, too. At the same time, it is not so relevant if they are a little weaker or maybe even a bit stronger than me.<div>2. Have you ever thought working on a go program or making some other contribution to the development of computer go?</div>FJD: Programming myself – no, as I am virtually clueless about programming except of what I learned in school thirty years ago. But I could imagine to participate as a tester, consultant or in a similar role on the go part of the project. For sure I would need a better understanding how the programs work. But this I can imagine to be so interesting that it might be worthwhile to read more about it.<div>3. Do you have a special plan for the match? Did you prepare a special anti computer go strategy, maybe even a specific anti Crazy Stone strategy? Or will you just try to play good go?</div>FJD: I have no specific plan for the match – what openings to play or some special joseki [note by the author: patterns of play in the corner of the board] – at least not yet. I know the prevalent suggestions for playing against Monte Carlo bots and their weaknesses, preferably a semeai with ko and nakade [note of the author: a complex and difficult life and death situation on the board]. But I don’t intend to steer it that way on purpose. However, these “stylistic devices” appear in many of my games anyway.  So I would say I will try to play good go. I hope that the expected crazy fights occur because Crazy Stone does make a few mistakes and not because I have to aim at them in order to still have a chance…<div>4. One last question: How do you judge your chances in the match?</div>FJD: I hope and believe that I am still the favorite. But Ingo Althöfer, who proposed this match, was able to inject some doubts into me with a few clever remarks. Naturally I have no idea about the improvements of the newest Crazy Stone version and how strongly this affects its playing strength. Also as a layman I cannot judge how a better hardware and therefore a higher number of simulations work on the playing strength. But as I know the fluctuations in my playing strength, I would not bet on a 3-0.Rémi Coulom (RC), Entwickler von Crazy Stone:1. When did you start developing a computer go program? And more important: Why?RC: I started in 2005. First, I worked with Bruno Bouzy to supervise a student, Guillaume Chaslot. The topic of his research was Monte Carlo methods in Go. Then Guillaume left Lille to start a PhD thesis in Maastricht, but I wanted to continue working on Go. So I started Crazy Stone in the summer of 2005.2. Did you develop Crazy Stone completely alone or did you have partners?RC: I am the only programmer of Crazy Stone, but I received support from Unbalance (the publisher of Crazy Stone) and my university that gave me a lot of free time and access to large computing power (https://www.grid5000.fr/).3. What programming languages, technological frameworks and tools did you use in the development of Crazy Stone? What were your reasons for choosing them?RC: I program in C++ with vim. These are the tools I know well.4. Besides go you have developed programs for quite a few other games. From your point of view, what are the main differences in programming go compared to chess or Othello?RC: The main difference is that artificial intelligence in chess and Othello is based on the traditional min-max search approach, whereas Crazy Stone uses Monte Carlo tree search.5. Can you explain the basic principle how you combine Monte Carlo methods with traditional tree search in go? Am I correct to assume that in a given position you start with tree search and use Monte Carlo methods to evaluate the position at the leaves of the tree? Or is this view too simplistic?RC: Some early Monte Carlo programs used that approach. They used a traditional min-max tree search with Monte Carlo evaluation at the leaves. But it was very inefficient. The current strong Monte Carlo programs use Monte Carlo evaluation inside the tree too. Because the best move is searched more than the others, the Monte Carlo tree slowly approaches a min-max tree in the limit of an infinite number of playouts. But it is never quite min-max.6. Will you use the regular commercial version of Crazy Stone for the match against Franz-Josef Dickhut or do you have a special match version?RC: I will use the current experimental version of Crazy Stone. It is a bit stronger than the commercial version.7. Do you plan to adjust your program between the games, i.e. react to events in the match?RC: Not really. I am constantly working to improve Crazy Stone, so maybe I will use a different version in every game if I find an improvement during the week. But I don’t expect that I will find an improvement based on what happened in the match. Crazy Stone has already played plenty of games against strong humans on KGS, and I have already well identified its weaknesses there.8. I know from personal experience with the Android version of Crazy Stone that computing power is quite important for the playing strength of Crazy Stone. What hardware will you use for the match?RC: I will probably use one 20-core node of grid’5000 (Intel(R) Xeon(R) CPU E5-2660 v2 @ 2.20GHz).9. Can you estimate how much stronger Crazy Stone might be on that hardware compared to a modern smartphone?RC: On that machine, Crazy Stone will run about 40,000 playouts per second. On my Nexus 5 it runs 1,700 playouts per second. I don’t know extactly how much this is in terms of rank, but it makes a very big strength difference.10. One final question: How do you judge your chances in the match?RC: I expect Crazy Stone will lose all 3 games. It is clearly weaker in my opinion. But the difference is not huge, so it may win a game if it is lucky. I hope to enjoy watching exciting games.

codecentric go challenge 2014: Interviews with Franz-Josef Dickhut and Rémi Coulom

The codecentric go challenge 2014 is over. Franz-Josef Dickhut managed to defeat Crazy Stone, one of the two strongest go programs worldwide, in four games with three wins to one. You can replay and download the games at <a href="https://go.codecentric.de">go.codecentric.de</a> .Congratulations to Franz-Josef Dickhut for winning the match and thanks a lot to codecentric for the sponsoring!As just before the start of the match, we let the contenders speak for themselves.Let’s start with the winner, Franz-Josef Dickhut (FJD) (translated from German by the author): 1. The games against Crazy Stone were hard fought and, as one could assume from your comments during the competiton, were hard work for you, too. Have you been surprised by the playing strength of Crazy Stone or did you expect such heavy fighting?FJD: I was not too surprised concerning the playing strength. I expected it to be some piece of work. But the pressure was quite big after the first game went wrong, which made the work that much more exhausting. I thought it was ultimately a great pity that the final game was actually the least interesting one. From the start Crazy Stone played unexpected moves, which were probably also weak or at least played too early. Along came the technical problem, the white group died and the game was as good as over. Unfortunately, this was no fitting end for such a close and hard fought match.2. In the end your defeat in the first game remained an aberration. What happened in round 1? What was different compared to games 2, 3 and 4?FJD: In round 1 everything happened that should not happen: A position that fits the strenght of bots (Moyo [a large but loosely defined sphere of influence that may later become territory]), careless playing and mistakes on my part as a consequence. Because of this Crazy Stone was leading by a lot early on. This powerfully brings to bear the strengths of Monte Carlo programs. Beginning with the second game, I mainly played more carefully. This was in order not to risk a definitive disadvantage early on again. To relax, I listened to classical music during the games. Maybe this helped, too.3. One question from go player to go player: At which moments were the games mostly decided according to your judgement? This is hard to guess particularly for somewhat weaker players – for me, too. The reason for this is that Crazy Stone confused me with its many kikashi moves [urgent threatening moves that have to be answered right away by the other player]. I rarely understood if the bot was playing particularly clever or was already in panic mode because it believed it was losing.FJD: Game 1: Was actually over after 70 moves. But I believe that it may had have become interesting again if I had played move number 170 on the intersection of move number 171. Game 2: Only with move 183 I was absolutely sure, although I had a good feeling already around move 143. Game 3: This was the tightest and most difficult game of the match. As the only win with white it may well have been the decisive game. During the game I realized only around moves 233/234 that I had won. Actually, the game was decided with move 210. Game 4: After the connection with move 81. Thereafter, the white group on the right side was simply and without any compensation for white dead.4. What are in your judgement the specific strengths and weaknesses of Crazy Stone? Are these – according to your experience – typical for Monte Carlo bots or rather specific for Crazy Stone?FJD: First, I believe that Crazy Stone is one of the Monte Carlo programs that is hardest to set-up. This is although it still suffers from the typical problems. Obviously, one of these is the weakness with kos [a specific position with repetitive captures], i.e. an aversion to play ko and the relative incompetence in evaluating ko positions. This is also true for certain corner and nakade patterns [nakade describes groups with a potentially dead shape]. Then there is one weakness that is the big strength, too: If a bot has a good overall position, they are incredibly flexible and at the same time unflinching on their way to secure the win. But if a bot is behind, even only slightly, and recognizes this, then they actively search for a possibility to force getting in the lead again. For a human player on the other side, this looks naive and as if the bot is in panic. But experienced players know that the best one can do in such situations is to keep the game vague. Either one makes the game bit by bit closer again or one increases the variance; and additionally one partly waits for “unforced” errors of the opponent. The bots are lacking in these things in my opinion, at least concerning the fine tuning.5. Could you stick to your plan to just play good go or did you try during the competition to exploit special weaknesses of Crazy Stone?FJD: I tried to play the best moves, at least according to my abilities. In situations where there were roughly equivalent alternatives, I of course tried to choose that one which presumably creates more problems for Crazy Stone. But I didn’t play bad moves on purpose only because some known bot problem might possibly or hopefully come to bear.6. You prepared for your opponent with the commercial version of Crazy Stone 2013. Was this preparation helpful?FJD: It definitely did help, although at first I sort of resisted against this help. E.g. the joseki [opening moves in a corner] on the 5-3 intersection in game one was not intended this way, but then I felt the urge to experiment.I also knew and halfway expected some simple typical joseki errors such as move 29 in game 3, omitting a strengthening move on the side after an invasion in the upper right corner, and move 22 in game 4, a one point jump instead of an extension in this 5-3 point joseki. But it is still difficult each time to transform this into a good position.7. Did you have the impression that Crazy Stone in the match was stronger or equally strong compared to your traning version?FJD: The match version was stronger, but without principal differences. The reason may have been the hardware, as my computer is nearly four years old. But for those times it was reasonably well equipped with an AMD 6 core processor. But I would have to look it up, if the exact configuration is of interest.8. In retrospect, would you approach the match differently – concerning the preparation as well as the concrete games?FJD: Not substantially. But I would probably try from game 1 onwards to play with more concentration and experiment less in order to reduce my risk for big mistakes. I suspected before the match that this would happen to me in at least one game. But the pressure increases immensely when it happens already in the first game. Then one is behind without having an idea how to tackle the opponent under normal conditions, i.e. without a blunder. This was really very unsettling for me and cost me a lot of nerves.9. Would you be available for a similar competition next year?FJD: Yes, with pleasure.Rémi Coulom (RC), developer of Crazy Stone:1. Unfortunately you did not have the grid-hardware at your disposal as you have had originally planned and thus had to run Crazy Stone from your own desktop computer. You also used the commercial version of Crazy Stone 2013 for all four games. What was the reason for this decision?RC: The current experimental version is not much stronger than the released commercial version, so I preferred to use a stable well-tested version during the match.2. For most observers of the games it appeared as if Crazy Stones Monte Carlo engine got into trouble the more unsettled positions remained on the board. It seemed to have difficulties to correctly evaluate certain corner patterns, too. What do you think about these observations?RC: Crazy Stone always becomes completely confused when the playouts evaluate one life-and-death problem wrong. It is a problem of Monte Carlo programs that is well identified. It is not easy to find a good solution.3. What are the most important reasons in your view for the losses in games 2, 3 and 4?RC: Game 3 was very close, and I am not a strong enough player to see any obvious misunderstanding by Crazy Stone. Game 2 and 4 had big life-and-death errors in the playouts.4. If hardware and software were the same for all four games of the competition, was there any other reason for the comparatively weaker performance of Crazy Stone in game 4, as it was perceived by many spectators of the match? Or was it just bad luck based on the misunderstanding of the big life-and-death situation on the right side of the board early in the game?RC: Yes, it was bad luck. Also, there was a small technical problem during the game. Crazy Stone disconnected because of a network problem, then I reconnected it, but the first instance was still running in the background, thus reducing available CPU power. But it would still have played badly with the misunderstood life-and-death on the right side, even with 1000 times more CPU power.5. The time management of Crazy Stone was very basic for the match: It thought for exactly 38 seconds each move. Do you think there is room for improvement in the time management of Monte Carlo bots or doesn’t it really matter?RC: Yes, of course, this part could be improved. Computer go tournaments usually have a sudden-death time control, and Crazy Stone is more clever there. Optimizing time-management heuristics for such byo-yomi time control is not very interesting and I prefer to focus my energy on more important problems.6. By the way, is Crazy Stone utilizing the thinking time of the opponent for its own calculations?RC: Yes.7. Did you get any new insights into Crazy Stones strengths and weaknesses because of the matches with FJ?RC: No. The weaknesses of Crazy Stone are very well identified. The problem is I don’t know how to fix them well. Top-level Go programs have stopped making progress for almost two years now.8. What are your priorities for improving Crazy Stone, what issues will you tackle next?RC: The main problem is to make random playouts more clever. In the past, Crazy Stone made progress by adding more patterns to the playouts. I believe I still can get more strength by improving the patterns further, but it won’t solve everything. It is not possible to have patterns that work for every possible game. There will always be configurations that show up in games where the playout patterns get the life-and-death wrong. The solution is to adapt the playout policy online. Some algorithms have been proposed, but they don’t work yet well enough.9. When will the next commercial version of CrazyStone be available?RC: I can’t tell much about dates, but there will be new versions. A version for the Windows 8 store will be released very soon. For this new version, I worked a lot to improve the playing style of Crazy Stone in the endgame: when it is winning or losing by a lot, it will play less foolish moves that throw points away like it used to. Also, I made “easy” levels that should be more pleasant to play for beginners.10. And a somewhat tougher timeframe question: How long will Franz-Josef Dickhut or other strongest amateur players still have a chance against bots? How much longer will the professional players last?RC: I have no idea. As soon as someone finds a good way to solve the playout problem I described in answer #8, then unbeatable programs may come very fast.11. Would you be available for a similar competition next year?RC: Yes, with pleasure.

codecentric go challenge 2014: Final Interviews

This Saturday, October 3rd, marks the start of the second installment of the codecentric go challenge. The challenge – organized by Prof. Ingo Althöfer of the University of Jena, Germany, and sponsored by codecentric – is a best-of-five match of a strong computer go program against a leading amateur player. Last year saw Franz-Josef Dickhut, amateur 6 dan and eleven times German go champion, defeat Crazy Stone 3:1. This year Franz-Josef will face the Japanese go program Zen. Zen and Crazy Stone have dominated the computer go scene for the last years.The games will be played online on KGS: <a href="https://www.gokgs.com">https://www.gokgs.com</a> . Franz-Josef Dickhut will play as “fj”, Zen as “Zen19S”. All games will start at 2pm CEST / CET. The results will be documented on <a href="https://go.codecentric.de">go.codecentric.de</a> where you can also replay the games.Like last year, we had a few questions for the competitors before the start of the match.Interview with Franz-Josef Dickhut (FJD), translated from German:1. Did you follow what happened in computer go in the last year? Do you see any remarkable developments?FJD: I was an interested spectator when I saw strong bots play on KGS, but I didn’t follow the development closely or intensively. It looks as if there were no large jumps in playing strengths, but a couple of good programs seem to have entered the field (DolBaram, Abakus). Also, the second row seems to have closed the gap somewhat.2. How well do you know your opponent for this year, Zen? Do you see fundamental differences to Crazy Stone, your opponent from 2014?FJD: Zen is playing a lot on KGS and I have known the 2012 version myself. But I think it has matured considerably since then. I cannot say what exactly is different now – it now has a Joseki- and Fuseki-library? I could not recognize large differences to Crazy Stone up to now (see below).3. How do you prepare for the match this year?FJD: This week I will look through Zen’s games of this year that are available online. Maybe I find some weak points or get hints what I should not try in the first place 😉 Hopefully the time for preparation is not too short.4. And the obligatory last question: What are your expectations for the match?FJD: I expect close games again. But I should be able to win eventually. I only hope I will not lose the first game again, as last year the pressure after losing the starting game was quite uncomfortable. If I had to bet, I would say 3:1 again.Interview with Hideki Kato (HK), representing Zen for the codecentric go challenge. The answers are slightly edited:1. Please tell us a little bit about Zen: When and why was the project started?HK: There were two stages. In 2005, Yoji Ojima (aka Yamato) started studying computer Go because of his personal interest. In 2006, I started a graduate course at the University of Tokyo where the research theme was computer Go. Until 2009, both of us had been developing our own programs, Zen and Fudo Go, respectively.After Crazy Stone’s win at the UEC Cup in December of 2008 (Fudo Go was 2nd and Zen was absent), I thought it’s very hard to beat Crazy Stone by myself alone and planned to form a team with Yamato because both of us intended to combine the advantages of the strongest two programs, Crazy Stone and MoGo. Project (and team) DeepZen started with Yamato in August of 2009 after Zen’s debut and the unexpected win at the Computer Olympiad in Pamplona. The goal of the project was to win the UEC Cup, which was the fervent wish of the Japanese party. This was achieved at the 5th UEC Cup in December of 2011, after a “long-time-no-win” of Japanese programs in Japan (more than 10 years; too long to remember the exact number :p).The current goal is to develop a professional level program.2. Who is working on Zen and what is your role in the team?HK: Team DeepZen has two members. Yoji Ojima (Yamato) is the chief programmer and is developing the stand alone version of Zen. I, Hideki Kato, am the representative and I am developing the parallel (cluster) version of Zen. Also, I do everything else; public relations, agent of Zen, etc.3. Is there something special that makes Zen unique in your opinion?HK: Yamato’s time is consumed by Zen (no kidding 🙂 ) by tuning and/or implementing new ideas. He works very hard.I’m not sure if you know “MC simulation is Black Magic” written by Silvain Gelly, chief developer of MoGo. No background theory, unexpectable behavior, etc. So, currently the improvement of MC Go bots is based on try-and-fail with many benchmark tests and each test has a few thousands of games, hence takes a long long time. Since the quality of the simulation is the key of MC bots’ performance and improving it takes very long time, I’d like to return to the first line of this answer.4. On what hardware will Zen run during the challenge?HK: I’ll use a 4 pc cluster consisting of<ul><li>a dual 12-core Xeon E5-2690 v3@2.6 GHz, 32 GB RAM,</li><li>a dual 10-core Xeon E5-2690 v2@3 GHz, 32 GB RAM,</li><li>a dual 6-core Xeon X5680@3.5 GHz, 8 GB RAM and</li><li>an 8-core Core i7 5960X@3 GHz, 16 GB RAM.</li></ul>The computers are connected via a GbE LAN – 64 cores in total.5. Will you use the commercial version of Zen or will you play with a special match version?HK: A special version for important games :).The commercial version is a little bit older (thus weaker) and has no cluster parallel feature.6. Will you work on the program during the challenge, i.e. react to events in the match?HK: Yes, but only in a limited way, fix bugs and/or try different versions for different rounds, for example.If you said “react” to suggest “revise/improve”: It’s practically impossible. At the level of Zen, comfirming if an “improvement” really improves Zen’s performance on average is not an easy task. Many tests (benchmark, regression, practical etc.) are necessary. Usually this takes a few months or more.7. Some ten years ago, Monte-Carlo methods made go playing computer programs considerably stronger. Rémi Coulom, the developer of Crazy Stone, said last year that for two years (now three) there has been relatively little progress. Do you agree with this assessment? And what do you think is necessary to bring computer go programs to professional playing strength?HK: Yes, I strongly agree. The most important thing is to combine a top-down solver of L&D with the current bottom-up MC framwork, IMHO. Note that this has been targeted, but no one succeeded during this half century of computer game history.There should be more, I believe. Powerful and flexible associative memories and learning methods, for examples.8. Did you follow the codecentric go challenge 2014, the match between Franz-Josef Dickhut and Crazy Stone? Any comments?HK: The result is not surprising.9. The obligatory final question: How do you judge your chances in the match?HK: About 25% (or less) because Zen’s rank is middle 5 dan at this time setting. I.e., there is a 200 (or more) Elo point gap.Glossary:Elo: Point system to measure relative playing strength Fuseki: The opening stage of a game of go Joseki: Fixed patterns of play in the corners of the go board L&D: local Life and Death problems on the go board MC: Monte-Carlo methods: algorithms based on random plays and statistics to find good moves in a given go position UEC Cup: Yearly computer go tournament of the University of Electro-Communications in Tokyo, Japan

This Sunday, August 28th, the third codecentric go challenge is going to start. The challenge – organized by Prof. Ingo Althöfer of the University of Jena, Germany, and sponsored by codecentric – is a best-of-five match of a strong computer go program (also called “bot”) against a leading amateur player. Franz-Josef Dickhut, amateur 6 dan and eleven-time German go champion, won the first two codecentric go challenges. In 2014 he defeated Crazy Stone, in 2015 Zen, both times with 3:1.But since the codecentric go challenge 2015, the world of computer go has experienced a dramatic revolution. In March 2016, AlphaGo defeated Lee Sedol – undoubtedly one of the strongest go players ever – by 4:1. Motivated by this success, other go programs have improved dramatically as well.The codecentric go challenge 2016 will pit Lukas Krämer, amateur 6 dan and reigning German Go champion, against the Japanese program Zen.The games will be played online on KGS: <a href="https://www.gokgs.com">https://www.gokgs.com</a> . Lukas Krämer will play as “miao”, Zen as “Zen19X”. All games will start at 6pm CEST. The results will be documented on <a href="https://go.codecentric.de">go.codecentric.de</a> where you can also replay the games.Like every year, we had a few questions for the competitors before the start of the match.Interview with Lukas Krämer (LK), translated from German:1. What are your experiences with Go bots?LK: Lately I’ve often played lightning games against bots. But most of them are on 3 dan level on KGS. I have played a couple of games against 6 dan bots, too. Because of these games, I have the feeling that I can win against them with a high probability. But this depends on the bot as well as on my motivation to win. Most of the time I do something else simultaneously while playing against a bot. This would not feel right when playing against a person. Also, these were lightning games. A longer thinking time changes a lot of things, as you can go through a more thorough consideration process.2. If you followed the progress in computer go: What developments do you consider especially noteworthy?LK: The question about the developments in computer go is obviously obligatory for a yearly event. But it seems a little bit superfluous with respect to the developments and the attention AlphaGo got last year. In short: AlphaGo is an unbelievable game changer. It shifts our understanding of go and effects a lot of positive movement in the go community – triggered not least by the new attention. It may also find soon applications in areas of our daily life. One good example was the enormous reduction of power costs of Google because of the application of the systems of AlphaGo. What’s also noteworthy is the rapid improvement of all other bots in a very short time and the fact that there seem to be many more bots playing on KGS now.As I assume that every reader of this article has at least basic information about AlphaGo, I find the question about the impact of AlphaGo on us more important.Some observers of the Lee Sedol – AlphaGo match remembered the changes computers had on chess – one of the most closely related games to us, maybe the closest one. Professional chess, especially at the top 10 level, is dominated completely by the computer analysis of certain openings and positions. Also e-cheating became a topic difficult to address. Bobby Fischer, who experienced this change and one of the greatest chess legends of history, emphasized this as the worst deficit in today’s chess.I am relatively certain that go as a game is too complex. In my opinion the human limitations to memorize would make this impossible. I believe it unlikely that one can memorize computer responses for all candidate moves in all variations even when one looks only at one board position. If you try it anyway, it would possibly have the contrary effect. One would play worse as one leaves one’s own preparation more quickly. After that the question is who is the better player and has the better understanding of the game. Foreign ideas, whose deeper meaning you do not understand, can then be rather an impediment.E-cheating is another issue. This is a question of the financial effort if one intends to prevent it as in the world of chess. But also here a modified version of AlphaGo could represent a major part of the solution.In spite of these issues, which have a slightly negative ring to them, I see AlphaGo as a huge chance. But we have to make use of it.I like to concur with a comment of Michael Redmond, 9 dan professional, about the consequences of AlphaGo on the game of humans against humans. He said he hopes that AlphaGo – if it re-learns go without injected games – inspires human players to break conventions and play freely just as Go Seigen did.I have another hope: That the go community makes use of this unprecedented worlwide and media attention. I know that at the top level in Europe, the EGF, things are happening to position oneself in relation to the public and to work with this new chance. But it would be nice if more were be tried on country level, too. A broad base of players is the most important thing to spread go. This has been tried in the past but never worked really well. It is my dream that the DGoB uses money and effort to employ someone part-time. In my opinion, this person should then work professionally, effectively and trans-nationally as an organ of the DGoB to spread go, use marketing methods and search for sponsors. I am convinced this can be successful, as many good ideas and approaches failed or were not even tried, because the DGoB is a 100% volunteer organization. And these people – rightly – have to use their time for their jobs, too.3. Did your view on go change since AlphaGo proved that machines can beat even the strongest humans in go?LK: My view on go as a game did not change fundamentally. Before the match AlphaGo – Lee Sedol I had the impression that the bot is underestimated. But with this point of view I was relatively alone. Thus AlphaGo has surely opened the eyes a little bit for some people – including Lee Sedol. More amazing about the whole affair was the speed with which everything happened. If AlphaGo became stronger still, I would be happy to learn from the ideas of the bot and hopefully gain a better understanding of the game on a more abstract level.4. How did you prepare for the match against Zen?LK: To be honest, I do not know against which version I will play. We did not mention this while we were discussing other regulations. But I assume I will play against version Zen19b, which was already active on KGS, or a similar version. I looked through the games of Zen19b and I am convinced of its strength. This version has played convincingly and constantly powerful against strong players, among others American professionals and another 9 dan on KGS. Thus I believe that I would rate my chances rather negatively in a lightning match. But the difference between the mentioned games and the match against me will be the time settings. I hope that a longer thinking time will prove advantageous, as in my experience I play significantly better in tournaments with such settings. Unfortunately I do not know how Zen reacts to this change in time settings, but I am very excited to find out.5. How do you see your chances?LK: I am not sure of my chances. On the one hand, unfortunately I never could play against such a strong version of Zen before. On the other hand it must be pointed out that Zen has become much more powerful compared to one year ago. I am generally very convinced of my go. But it is always something different to play against a bot compared to playing against a human. They understand the game in another way than humans and this can be irritating. I intend to approach this match like all the others, too: With trust in my abilities and hopefully calm and relaxed, too.Interview with Hideki Kato (HK), representing Zen for the codecentric go challenge. The answers are slightly edited:1. Just after the codecentric go challenge 2015 AlphaGo entered the stage and revolutionized computer go. What did the advent of AlphaGo mean to you personally and to Team Zen?HK: In December 2014, Aja et. al. published a paper of the application of DCNN to computer go and I had some personal communications with him. So, AlphaGo’s policy network was not surprising. What surprised me was its value network, which most developers thought almost impossible to build. Actually, the value network was not perfect (as shown in game 4 of the AlphaGo – Lee Sedol match), but most surprisingly even top professionals couldn’t attack its weak points (except in game 4).This was observed, however, already with Crazy Stone. On KGS, Zen had a better rank than Crazy Stone (as well as direct matches), but the results against professionals were reversed.I couldn’t expect the win of AlphaGo because the top professonals were weaker, especially in the early stages, than expected, and AlphaGo’s improvement in the half year before the match against Lee Sedol was bigger than expected.That’s all for me. For team DeepZen (not Zen), Yamato recovered his motivation to improve Zen as AlphaGo showed the way.2. Last year you mentioned three areas where go programs still had room for improvement: combining Life&Death solvers with the Monte Carlo framework, associative memories and learning methods. According to your knowledge, did AlphaGo use any of these approaches to achieve this amazing power?HK: No. I’m afraid go will go the same way as chess and shogi, i.e. reach or even go beyond the level of human players without inventing human-like solutions. From the viewpoint of an AI researcher (me!), this is very disappointing because the game of go is just an application of AI research.3. Was there anything in the concept of AlphaGo that surprised you in particular?HK: Needless to say, the value network. Also, the belief that it can be built.4. In what areas did Zen improve since last year? How much stronger do you think Zen has become?HK: Mainly in the early stage of the game and end games (or static/silent positions) due to the use of DCNN to guide the search (policy network).On the improvement since last year’s match: I guess two stones on average, but still several weak points caused by the Monte Carlo simulation remain and Lukas has chances to win. Evidence: the best handcap was four stones against top professionals in 2015 and is two stones these days. See <a href="http://www.computer-go.info/h-c/index.html">Nick’s page about human-computer play</a> .5. What are your plans for Zen in the future?HK: Now I will not be able to control Zen due to the DeepZenGo project supported by Dwango (at least) until next March. It’s very, very hard for me to have any idea on the future of Zen now. Please note: The project was started by Yamato’s hope, and I’m continuing to support him because this is the objective of the team and the DeepZen project.I’ll study, anyway, how to learn not only one move but also a sequence of moves to overcome a weak point of current Monte Carlo simulations next year. The current candidate is DRNN. Also, I’d like to study how to introduce top-down control of the MCTS framework in the future. The current candidate is automatic capturing of models of outside (of an AI) by using ANN or augumented FSM.6. Do you see any possibility that AlphaGo will be challenged as the top go program – be it by Zen or any other Go program?HK: No doubt. The top runner is believed to be Zen, but I strongly believe there are some others almost being ready but not in the open, because the technology used for AlphaGo is not so difficult to implement if rich :).7. What version of Zen will play in the codecentric go challenge 2016 and on what hardware?HK: The version will be 12.0 but that may change. The hardware will be a dual Xeon server with a GPU (nVidia GTX 960) but that may change again, as this match takes at most five weekends and improved versions will be developed.8. How do you view your chances in the match against Lukas?HK: Most likely 3-1 for Zen. A 3-0 is also possible.Glossary:EGF: European Go Federation DGoB: Deutscher Go Bund (German Go Federation) DeepZen: The name of the team and the project, started in 2009: Yoji Ojima and Hideki Kato Zen: The program itself DeepZenGo: A cooperation project between DeepZen and Dwango, intended to beat AlphaGo Yamato: Yoji Ojima, the chief programmer of Zen MCTS: Monte Carlo tree search DCNN: deep convoluted neural network DRNN: deep recurrent neural network ANN: artificial neural network FSM: finite state machine

codecentric go challenge 2016

<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="https://blog.codecentric.de/2017/08/besuch-beim-europaeischen-go-kongress-oberhof/" target="_blank">in this blog post</a> – German only.<div><a href="https://media.graphassets.com/Te2CbDYS4KSRpJHSu8Nv"><img src="https://media.graphassets.com/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://media.graphassets.com/aJViQOYSkynwhnOrfIjA"><img loading="lazy" src="https://media.graphassets.com/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://media.graphassets.com/jTczCc3QIGU44OrJZzKQ"><img src="https://media.graphassets.com/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://media.graphassets.com/1aO6j2zRK268DbWnj19A"><img loading="lazy" src="https://media.graphassets.com/1aO6j2zRK268DbWnj19A" alt="The Rengo final" width="700" height="394" /></a> The Rengo final, KLT vs. SAT.</div><div><a href="https://media.graphassets.com/wLk1QRtSLWQu8kShcVuA"><img loading="lazy" src="https://media.graphassets.com/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://media.graphassets.com/5jsA9dKbS8aPBHr8jQtM"><img loading="lazy" src="https://media.graphassets.com/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

Standortleitung München

In einem GitOps-Workflow beschreibt das Entwicklungsteam alle Ressourcen eines Kubernetes-Projekts in einem Git-Repository. Dadurch können sowohl das Entwicklungsteam als auch das Infrastrukturteam alle Bestandteile eines Projektes überblicken. Was jedoch aus Sicherheitsgründen nie in einem Git-Repository liegen darf, sind Zugangsdaten wie Passwörter oder API-Schlüssel zu Drittanbieterschnittstellen. An diesem Punkt setzt das SealedSecrets-Projekt an. Es bietet die Möglichkeit, mittels Public-Key-Kryptografie die schützenswerten Daten zu verschlüsseln, um sie in dieser Form in einem Git-Repository speichern zu können. Damit liegen alle Bestandteile der Infrastruktur eines Projekts gemeinsam an einer Stelle.In diesem Blogpost sehen wir einen einfachen Anwendungsfall von SealedSecrets bei einem passwortgeschützten Webserver. Den Webserver rollen wir über GitOps in einem Kubernetes-Cluster aus. Wir schauen uns die Sicherheitsthematik an, die SealedSecrets mit sich bringt und zeigen abschließend zwei mögliche Alternativen auf.<h2>Was sind SealedSecrets?</h2>Der Kern des SealedSecrets-Projekts ist ein Kubernetes-Controller, der verschlüsselte Daten entschlüsselt und als Kubernetes-Secrets bereitstellt. Der Controller erstellt einen sogenannten SealingKey, der aus einem öffentlichen und einem privaten Schlüsselteil besteht. Das Kommandozeilenwerkzeug <code>kubeseal</code> nutzt den öffentlichen Teil des SealingKeys, um Daten zu verschlüsseln. Der Controller kann diese Daten mit dem privaten Teil des SealingKeys wieder entschlüsseln. Dieser private Teil liegt — vor Zugriffen geschützt — im Kubernetes-Cluster. Ausschließlich der SealedSecrets-Controller kann ihn einlesen.<h2>SealedSecrets unterstützen den GitOps-Workflow</h2>Als DevOps-Engineer verwende ich einen GitOps-Workflow, damit ich alle Kubernetes-Ressourcen an einem einzigen Ort verwalten kann. Das verschafft mir eine Übersicht über das gesamte System. Dank der Versionierung von Git erhalte ich außerdem einen Audit-Trail. Das heißt, ich kann alle Änderungen einer Tageszeit und einem Menschen – oder einer Maschine – zuordnen. Damit lassen sich Fehler leichter analysieren. Gleichzeitig bietet Git eine einfache Möglichkeit, Änderungen rückgängig zu machen. Bei einem Fehler lässt sich so schnell ein vorheriger Stand wieder herstellen.Gängigerweise sind schützenswerte Daten wie Passwörter oder API-Keys nicht Teil des Git-Repositorys. Committen wir zum Beispiel Zugangsdaten für AWS in ein öffentliches Repository, dann können wir innerhalb von Minuten einen Missbrauch feststellen. Mit dem Einsatz von SealedSecrets können wir auch diese eigentlich geheimen Daten verschlüsselt in ein Git-Repository einchecken. Damit ist der komplette Zustand eines Systems in Git beschrieben.<h2>Fallbeispiel Nginx</h2>Wir schauen uns nun ein einfaches Fallbeispiel mit einem Nginx-Webserver an. Das gesamte Repository ist <a href="https://github.com/rafaroca/sealedsecrets-workflow" target="_blank">auf GitHub</a> zu finden. Die Readme im GitHub-Projekt erklärt Schritt für Schritt, wie wir den lokalen Kubernetes-Cluster aufsetzen, der auf Änderungen des GitHub-Repositorys reagiert. Für die GitOps-Funktionalität installieren wir <a href="https://fluxcd.io/" target="_blank">Flux</a> im Cluster. Flux legt die Ressourcen, die im GitHub-Repository beschrieben sind, auch im Cluster an.<h3>Übersicht</h3>Das folgende Diagramm beschreibt, wie der Passwort-Hash von einem Entwickler zu einem Nginx-Pod in einem Kubernetes-Cluster kommt, ohne dass der Klartext einsehbar ist.<a href="https://media.graphassets.com/CbIJu8vZQ2a6QGq8VEC2"><img src="https://media.graphassets.com/CbIJu8vZQ2a6QGq8VEC2" alt="Diagramm Datenfluss SealedSecrets von Entwicklungsmaschine zu Kubernetes-Cluster" width="2140" height="982" /></a> Der Entwickler nutzt das <code>kubeseal</code>-Kommandozeilenwerkzeug, um den Passwort-Hash lokal zu verschlüsseln. Kubeseal lädt dazu den öffentlichen Teil des SealingKeys aus dem Cluster. Der Git-Commit, der den Hash beinhaltet, kommt durch ein <code>git push</code> in das Repository auf GitHub. Flux beobachtet das Git-Repository und erstellt die SealedSecret Custom Resource Definition (CRD) für den verschlüsselten Hash. Der SealedSecrets-Controller nutzt den SealingKey, um das SealedSecret in ein normales Kubernetes-Secret zu entschlüsseln. Das Secret wird schließlich dem Nginx-Pod zur Verfügung gestellt.<h3>Nginx</h3>Der Webserver schützt seine Standardseite durch ein Passwort, das mit Basic-Auth-Authentifizierung überprüft wird. Wir wählen Basic-Auth aus dem Grund, weil es einfach zu konfigurieren ist. In Produktivumgebungen setzen wir auf Identity Provider wie <a href="https://www.keycloak.org/" target="_blank">KeyCloak</a> , die Passwörter ausreichend sicher hashen.In unserem Fall konfigurieren wir unseren Nginx als Kubernetes-Deployment. Das geladene Image ist <code>nginx</code>, das unter Port 80 seine Dienste bereitstellt. Als <code>volumeMounts</code> geben wir eine ConfigMap und ein Secret an. In der <code>nginx-config</code>-ConfigMap verweisen wir auf den Pfad <code>/etc/nginx-htpasswd</code>, sodass Nginx unser Passwort von dort laden kann. Die ConfigMap existiert bereits im <a href="https://github.com/rafaroca/sealedsecrets-workflow/blob/main/cluster/nginx-config.yaml" target="_blank">GitHub-Repository</a> und enthält eine Minimalkonfiguration, um die Standardseite von Nginx mit einem Basic-Auth-Passwort zu schützen. Das <code>nginx-htpasswd</code> Secret darf nie im Repository landen. Erst der SealedSecrets-Controller erstellt es aus dem SealedSecret, das wir im nächsten Schritt erzeugen.<div>

```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-dpl
 namespace: default
spec:
 template:
 spec:
 containers:
 - image: nginx
 ports:
 - containerPort: 80
 name: http
 volumeMounts:
 - mountPath: /etc/nginx-htpasswd
 name: htpasswd
 - mountPath: /etc/nginx
 name: config
 volumes:
 - name: htpasswd
 secret:
 secretName: nginx-htpasswd
 - name: config
 configMap:
 name: nginx-config
```

</div><h3>Verschlüsselung mit kubeseal</h3>Das folgende Kommando erzeugt einen Passwort-Hash für den Nutzer <code>nginx-user</code> mit dem Passwort <code>weakpassword</code>, wandelt es in ein Kubernetes Secret und verschlüsselt es mit <code>kubeseal</code>. Das Kommando ist umfangreich, deshalb gehen wir im Anschluss die einzelnen Schritte durch. Eine Warnung vorweg: Die Shell-Historie zeichnet normalerweise alle Kommandos auf. So können Passwörter im Klartext auf der Festplatte landen. Jede Shell bietet einen Weg, die Historie temporär zu deaktivieren. In bash oder zsh macht das zum Beispiel das Kommando <code>unset HISTFILE</code>.<div>

```bash
USERNAME=nginx-user \
PASSWORD=weakpassword \
HTPASSWD=$USERNAME:$(openssl passwd -apr1 $PASSWORD) \
kubectl create secret generic nginx-htpasswd \
 --namespace default \
 --from-literal=htpasswd=$HTPASSWD \
 --dry-run=client \
 --output=yaml \
| kubeseal -o yaml \
> ./cluster/nginx-htpasswd-sealed.yaml
```

</div>Die Zeilen 1-3 erzeugen ein gültiges Nutzer-Passwort-Hash-Tupel, das Nginx verwenden kann. Dafür verwenden wir das <code>openssl</code>-Kommando mit <code>apr1</code> als Hashing-Algorithmus. Für Basic-Auth unter Nginx gibt es keine sicheren Hash-Verfahren. Deshalb ist es umso wichtiger, dass wir den Hash nicht unverschlüsselt in Git einchecken.Mit dem <code>kubectl create</code>-Befehl in den Zeilen 4-8 erzeugen wir ein Kubernetes-Secret. Das <code>--from-literal</code> in Zeile 6 bestimmt als Inhalt des Secrets eine Datei mit dem Namen <code>htpasswd</code> und als Inhalt den vorher generierten Passwort-Hash. Wir wollen das Secret nicht direkt im Cluster anlegen, sondern nur lokal die Repräsentation im YAML-Format ausgeben. Das geschieht durch <code>--dry-run=client</code> und <code>--output=yaml</code> in den Zeilen 7 und 8.Die Ausgabe von <code>kubectl</code> leiten wir in Zeile 9 an <code>kubeseal</code> weiter, welches das Secret in SealedSecret verschlüsselt. Dazu fordert es aus dem Cluster den öffentlichen Teil des SealingKeys an. Das SealedSecret speichern wir als yaml-Datei im <code>cluster</code>-Verzeichnis. Wir leiten die Ausgabe in eine Datei unter dem <code>cluster/</code>-Verzeichnis um. Diese Datei enthält nun ein <code>SealedSecret</code> mit verschlüsselte Daten.<div>

```yaml
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
 name: nginx-htpasswd
 namespace: default
spec:
 encryptedData:
 htpasswd: AgAsn2 [.. snip 8< 8< 8< ..] yJk=
 template:
 metadata:
 name: nginx-htpasswd
 namespace: default
```

</div>Zu sehen ist, dass der Name der Datei <code>htpasswd</code> lesbar bleibt. Der Inhalt wurde mit dem öffentlichen Schlüssel durch <code>kubeseal</code> verschlüsselt als <code>encryptedData</code> abgelegt. Die Datei <code>nginx-htpasswd-sealed.yaml</code> fügen wir unserem Git-Repository hinzu. Sobald Flux die Änderungen mitbekommt, erstellt es das <code>SealedSecret</code> als Ressource im Cluster. Das wiederum löst im SealedSecrets-Controller die Entschlüsselung aus. Der Controller nutzt den privaten Teil des SealingKeys, um die Passwortdatei entschlüsselt als Kubernetes-Secret bereitzustellen.<h2>Funktionstest</h2>Nun kann der Nginx-Pod starten, da das Secret <code>nginx-htpasswd</code> verfügbar geworden ist.<div>

```bash
$ kubectl get events
LAST SEEN REASON OBJECT MESSAGE
2m14s FailedMount pod/nginx-dpl-bddb77d95-9rtqv MountVolume.SetUp failed for volume "htpasswd" : secret "nginx-htpasswd" not found
20s Unsealed sealedsecret/nginx-htpasswd SealedSecret unsealed successfully
9s Started pod/nginx-dpl-bddb77d95-9rtqv Started container nginx
```

</div>Jetzt testen wir noch, ob unser Passwort auch funktioniert. Dafür erstellen wir eine Portweiterleitung, die den Zugriff von unserer Maschine auf unseren Service im Minikube-Cluster erlaubt.<div>

```bash
$ kubectl port-forward service/nginx-svc 8888:80
```

</div>Unter <a href="http://localhost:8888" target="_blank">http://localhost:8888</a> fragt unser Browser nun nach Authentifizierung. Wir loggen uns mit <code>nginx-user</code> und <code>weakpassword</code> ein und sehen die Startseite des Webservers. Das Klartextpasswort haben wir in diesem Workflow nie auf die Festplatte gespeichert. Das Passwort steht nur in verschlüsselter Form in unserem Git-Repository, womit wir die gesamte Infrastruktur unseres Beispiels beschrieben haben.<h2>Sicherheit</h2>Die <a href="https://github.com/bitnami-labs/sealed-secrets/blob/main/docs/developer/crypto.md" target="_blank">kryptografische Dokumentation von SealedSecrets</a> geht auf die technischen Details der Verschlüsselung ein. Eine Kryptoanalyse würde leider den Rahmen dieses Posts sprengen. Deswegen gehen wir davon aus, dass die Entwickler von SealedSecrets die kryptografischen Algorithmen korrekt verwenden. Bei der Verwendung von SealedSecrets basiert die Sicherheit auf der Geheimhaltung des privaten Teils des SealingKeys. Falls eine Angreiferin Zugriff auf den privaten Schlüsselteil bekommt, dann kann sie alle anderen geheimen Daten entschlüsseln.<h3>RBAC</h3>Mit “Rule Based Access Control” (RBAC) schützen wir den privaten Teil des SealingKeys vor unprivilegierten Nutzern. Einzig der SealedSecrets-Controller darf Zugriff auf den privaten SealingKey besitzen. Kubernetes regelt Zugriffskontrolle per RBAC. Bei der Installation erstellt der SealedSecrets-Controller bereits die nötigen RBAC-Ressourcen. Ein Administrator des Clusters muss allerdings die Konfiguration überprüfen und sicherstellen, dass die Berechtigungen korrekt eingerichtet sind.<h3>Renewal des SealingKeys</h3>Der SealedSecrets-Controller bringt einen Mechanismus mit, um regelmäßig den SealingKey zu erneuern. Das ist sinnvoll, denn falls ein SealingKey doch einmal kompromittiert werden sollte, dann können die aktuellen SealedSecrets nicht mit einem alten SealingKey entschlüsselt werden. Seit Version <a href="https://github.com/bitnami-labs/sealed-secrets/blob/main/RELEASE-NOTES.md#v090" target="_blank">v0.9.0</a> generiert der Controller standardmäßig alle 30 Tage einen neuen SealingKey. Die alten SealingKeys bleiben erhalten, damit der SealedSecrets-Controller alle existierenden SealedSecrets weiterhin entschlüsseln kann. Weil die alten SealingKeys weiter in Verwendung bleiben, sprechen wir hier von Renewal und nicht von Rotation. Wenn wir neue Secrets hinzufügen, oder alte rotieren, dann kommt der jeweils aktuellste SealingKey zum Einsatz.Sobald wir den Verdacht haben, dass der SealingKey kompromittiert wurde, ist es zwingend nötig, dass wir sofort einen neuen SealingKey erzeugen und im Anschluss alle Passwörter rotieren, die durch diesen privaten Schlüssel geschützt waren. Ein Rotieren der Passwörter muss dementsprechend schnell durchführbar sein. Im Idealfall können wir die Rotation automatisiert durchführen.Wenn wir in diesem Fall nur die verschlüsselten Passwörter ändern würden, dann könnte die Angreiferin auch die neuen Passwörter mit dem kompromittierten SealingKey entschlüsseln. Bloß einen neuen SealingKey zu erzeugen hilft uns auch noch nicht, denn die Passwörter – verschlüsselt mit dem bereits kompromittierten SealingKey – sind in der Git-History enthalten.In unserem Beispiel können wir das Renewal des SealingKey erzwingen, indem wir die Umgebungsvariable <code>SEALED_SECRETS_KEY_CUTOFF_TIME</code> des Deployments des SealedSecrets-Controllers auf die aktuelle Zeit setzen.<div>

```bash
$ kubectl set env deployment/sealed-secrets-controller SEALED_SECRETS_KEY_CUTOFF_TIME=$(date -R) --namespace kube-system
```

</div>Damit startet der Controller neu und legt einen neuen SealingKey an. Wir kontrollieren das, indem wir uns die aktiven Keys anzeigen lassen. Wie erwähnt, nutzt der Controller immer den aktuellsten Key.<div>

```bash
$ kubectl get secret -l sealedsecrets.bitnami.com/sealed-secrets-key=active --namespace kube-system
NAME TYPE DATA AGE
sealed-secrets-keybppmh kubernetes.io/tls 2 4s
sealed-secrets-keygcbgs kubernetes.io/tls 2 7d21h
```

</div><h3>Rotation des Passworts</h3>Nach dem Renewal des SealingKeys wechseln wir das Passwort unseres Nginx-Benutzers mit demselben <code>kubectl/kubeseal</code>-Befehl wie vorher. Nur setzen wir diesmal ein anderes Passwort. Die veränderte Datei <code>nginx-htpasswd-sealed.yaml</code> committen und pushen wir erneut in unser Git-Repository. Nachdem die Änderung im Cluster angekommen ist, müssen wir den Webserver neu starten.<div>

```bash
$ kubectl rollout restart deployment nginx-dpl
```

</div>Kubernetes legt zuerst einen neuen Pod an, und terminiert im Anschluss den alten. Wäre unser Webserver über ein Helm-Chart deployt, dann könnte Helm sogar für ein automatisches rollendes Deployment sorgen, sobald sich das Secret ändert.Beim Neustart liest der Webserver das neue <code>nginx-htaccess</code> Secret ein. Jetzt können wir uns mit dem neuen Kennwort auf dem Webserver mit dem existierenden Port-Forwarding anmelden.Idealerweise können wir diese Rotation automatisiert durchführen. Das zahlt sich aus, wenn wir den Katastrophenfall betrachten. Falls zum Beispiel der gesamte Kubernetes-Cluster gelöscht wurde, dann sind die SealingKeys unwiederbringlich verloren.Ohne SealingKey können sämtliche existierende SealedSecrets nicht mehr entschlüsselt werden. Wir müssen alle Passwörter nun erneut mit dem aktuellen SealingKey verschlüsseln. Wenn wir die Passwortrotation automatisiert haben, dann können wir den Cluster schnell wieder in einen funktionierenden Zustand bringen.<h2>Alternativen zu SealedSecrets</h2>SealedSecrets ist nicht das einzige Projekt, das Secrets in GitOps-Workflows unter Kubernetes unterstützt. SealedSecrets ist nur für den Einsatz in einem einzelnen Kubernetes-Cluster vorgesehen. Um dasselbe SealedSecret in mehreren Clustern zu entschlüsseln, müssten wir über einen eigenen Mechanismus den privaten Schlüsselteil in alle Cluster replizieren. Generell sollte jedoch der private Schlüsselteil den Cluster nicht verlassen, um das Risiko des Schlüsselverlustes gering zu halten. Falls die Entwickler über mehrere Cluster hinweg arbeiten, dann empfehlen sich diese Alternativen, die den Schlüssel einem Cloud-Provider anvertrauen, anstatt ihn im Cluster zu halten.<a href="https://github.com/mozilla/sops" target="_blank">Mozilla SOPS</a> bietet sehr ähnlich zu SealedSecrets die Verschlüsselung von Config-Dateien. SOPS basiert nicht auf Kubernetes, es existieren aber mehrere Kubernetes-Operator. Als Speicher für den Schlüssel unterstützt SOPS auch Cloud-Plattformen wie AWS KMS, GCP KMS und Azure Key Vault.<a href="https://external-secrets.io/" target="_blank">ExternalSecrets</a> speichert eine Referenz auf ein Secret, das an einer anderen Stelle gespeichert wird. Die gesamte Verschlüsselungsmechanik ist nun an eine externe Stelle ausgelagert. ExternalSecrets unterstützt mehr als ein Dutzend externe Provider, zum Beispiel die SecretsManager von AWS und GCP sowie Azure Key Vault.<h2>Fazit</h2>Wir haben gezeigt, wie wir mit SealedSecrets den Passwort-Hash für einen Webserver verschlüsselt in einem öffentlichen Git-Repository ablegen können. Durch unseren GitOps-Workflow mit Flux kommt ein geändertes Passwort in Git direkt im Kubernetes-Cluster an. In unserem Git-Repository befindet sich der Passwort-Hash lediglich verschlüsselt, aber nie als Klartext.Außerdem haben wir das Renewal des SealingKeys betrachtet. Sowohl die Passwörter selbst, als auch die SealingKeys müssen wir in regelmäßigen Abständen rotieren beziehungsweise neu generieren. Beides haben wir am Beispiel selbst durchgeführt.Damit haben wir einen GitOps-Workflow geschaffen, der alle Ressourcen in einem einzigen Git-Repository abbildet.

Passwörter sicher per GitOps deployen mit SealedSecrets

<h2>Introduction</h2>In the <a href="https://blog.codecentric.de/en/2019/11/message-pact-contract-testing-in-event-driven-applications/" target="_blank">previous posts</a> we learned that the Pact workflow requires you to exchange contracts and verification results between consumers and providers. We introduced two approaches on how the contract exchange can happen: 1) committing the Pact files to the provider repository, 2) make the provider fetch the Pact files. If you decide for the second approach you can utilize the Pact broker.The broker acts as an intermediary between consumers and providers. Consumers publish contracts to the broker and providers can download them. Additionally, providers can publish verification results. By checking the verification results, consumers can determine whether it is safe to deploy a specific version to an environment.In this post you will learn how the Pact broker can support your development workflow. The post is structured as follows. The first part is going to elaborate on the different features of the broker from a theoretical point of view. The second part will be more practical, focusing on how to integrate the broker into your build pipeline. Afterwards we are discussing potential challenges when implementing a Pact broker based workflow. The final section summarizes the main findings and closes the post.<h2>Pact broker features</h2>The Pact broker provides different features that can be used in different parts of your development workflow: exchanging contracts, exchanging verification results, tagging, and webhooks. Let’s look into each one in detail.<h3>Exchanging contracts</h3>Whenever a consumer generates a new contract it usually needs a verification from all its providers. Consumers can publish new contracts to the broker and providers can pull them when running the verification tests. But how does the provider know which contract it needs to verify?The broker requires you to assign a consumer version for every contract you publish. This version should represent the software version of your consumer. It does not have to follow any specific naming scheme, such as semantic versioning. It is common to take the commit hash so you can easily understand which version of your code is linked to this contract.When running a provider verification the provider needs to specify the consumer version it wants to verify. The broker will then return the latest version of the contracts for that specific consumer version.<h3>Exchanging verification results</h3>As soon as the verification is finished, the provider can publish the results back to the broker. Each verification result is associated with a provider version. The broker will then use both the consumer version of the contract that has been verified and the provider version that reported the verification results to update its verification matrix.<a href="https://media.graphassets.com/AULYIqq3RCWjk7r0gTvX"><img src="https://media.graphassets.com/AULYIqq3RCWjk7r0gTvX" alt="verification matrix" /></a> The verification matrix stores the verification results and the fact that a verification took place based on the consumer version, provider version, contract version, and tags.This is useful if you want to check the compatibility between a specific consumer and provider version. You can simply query the matrix without the need of running another verification test. An implementation of this compatibility check is the <a href="https://docs.pact.io/pact_broker/can_i_deploy"><code>can-i-deploy</code></a>  command line tool. You can specify the different pacticipant versions you want to deploy together and it will tell you whether it is safe to do so.If we want to check whether it is safe to deploy to production, however, how do we know which versions are currently in production? Also, how can we check whether a feature branch of a consumer would be safe to merge? This is where tags come in.<h3>Tagging</h3>The broker allows you to assign a tag to a pacticipant version. Tags can be used in any way you like but the following two use cases are common:<ol><li>Indicate that a version is deployed in a specific environment by tagging the environment name (e.g. <code>test</code> or <code>prod</code>).</li><li>Indicate that a version is part of a feature branch by tagging the branch name (e.g. <code>ABC-123/new-login</code>).</li></ol>Tagging the environment name is useful when executing <code>can-i-deploy</code> so that you don’t have to know the exact versions of your pacticipants but can simply ask: Is it safe to deploy this specific version to production?Tagging the feature branch name on the other hand allows you to publish and verify the contracts of a new feature before merging the branches in all pacticipants. By tagging your consumer versions with the feature branch name, providers can verify the latest version of that feature. If you choose the same name for both the consumer and the provider branch, you can run provider verifications of the consumer branch from your provider branch.<h3>Webhooks</h3>Webhooks can be used to notify other components in your development workflow about changes in the broker. They can be configured for the following events:<ul><li>Contract published</li><li>Contract published with changed content, updated or new tags</li><li>Verification results published</li></ul>Additionally you can specify whether only certain consumers or providers should be considered. Whenever such an event occurs, the broker will send an HTTP request to the URL you configured.You can specify an HTTP header and body of that request, as well as basic authentication if required. Additionally, there are some <a href="https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown#dynamic-variable-substitution" target="_blank">dynamic variables</a>  that you can use in order to customize the request:<ul><li>Consumer and provider name</li><li>Consumer and provider version number</li><li>Consumer and provider version tags</li><li>Consumer and provider labels</li><li>URL to the contract on the broker</li><li>URL to the verification result on the broker</li></ul>This allows custom integrations with your build pipelines or other tools such as Jira or Slack. The next section will guide you through an example setup of the build pipelines in GitLab.<h2>Pimping your build pipeline</h2>Now that we discussed all the different parts of the Pact broker we want to put it to practical use. The following subsections feature an example setup including a consumer repository, a provider repository, a Pact broker and GitLab build pipelines.<h3>Example setup</h3>Continuing the example of our <a href="https://blog.codecentric.de/en/2019/10/consumer-driven-contract-testing-with-pact/" target="_blank">first blog post</a> , we are looking at a front-end consumer which uses the login functionality of a user service provider. The following diagram illustrates the actors / components relevant to our scenario.<a href="https://media.graphassets.com/dL603FidQz0pbwVxinR6"><img src="https://media.graphassets.com/dL603FidQz0pbwVxinR6" alt="example setup" /></a> The consumer publishes contracts to the Pact broker via the pipeline. A webhook on newly published contracts triggers the respective provider verifications. The results of the provider verification are published to the broker. By creating version tags after successful deployments we enable the use of the <code>can-i-deploy</code> to check if a change can safely be deployed to production.For the examples in this chapter we are using GitLab CI build pipelines defined in <code>.gitlab-ci.yml</code> files. Each pipeline run consists of multiple stages where the preceding stage has to succeed for the next one to begin. Build artifacts are passed between the stages. The following stages are going to be relevant in the next subsections.<div>

```highlight yaml
stages:
 - build
 - publish # (consumer only)
 - can-i-deploy
 - deploy
 - tag

```

</div><h3>Consumer pipeline: Generating and publishing contracts</h3>In the pipeline of the <code>login-view</code> consumer we are generating the contracts during the build stage. We can then either immediately publish the generated contracts, or pass them as build artifacts to the following stages. The following code snippet illustrates a pipeline job that generates the contracts into the <code>pacts</code> folder that then gets exported as a build artifact by GitLab.<div>

```highlight yaml
pact-test:
 image: node:latest
 stage: build
 script:
 - "npm run test:pact"
 artifacts:
 paths:
 - pacts

```

</div>The follow-up job then uses the <code>pact-broker</code> executable from the <code>pactfoundation/pact-cli</code> Docker image to publish the contracts it picked up from the previous stage to the broker.<div>

```highlight yaml
pact-publish:
 image: pactfoundation/pact-cli:latest
 stage: publish
 script:
 - "pact-broker publish pacts
 --consumer-app-version=$CI_COMMIT_SHORT_SHA
 --tag=$CI_COMMIT_REF_NAME
 --broker-base-url=$PACT_BROKER_BASE_URL
 --broker-token=$PACT_BROKER_API_TOKEN"

```

</div>We are using the current git commit hash as the consumer version and tagging it with the current branch name. The config options <code>broker-base-url</code> and <code>broker-token</code> are set via manually configured environmental variables. It is possible to define them in an overarching GitLab group so that they are exposed to multiple projects.Having the consumer pipeline in place that publishes new contracts, let’s investigate how to trigger provider verification tests through a GitLab pipeline.<h3>Provider pipeline: Executing verification tests</h3>As explained in the introduction, the Pact broker can act upon published contracts. In order to make the broker trigger a GitLab pipeline through a webhook, we first need to <a href="https://docs.gitlab.com/ee/ci/triggers/">create a pipeline token</a>  in the <code>user-service</code>. We then use the resulting pipeline trigger to create a webhook on the Pact broker which acts on contract modifications.The following JSON payload represents a webhook resource on the broker:<div>

```highlight json
{
 "description": "Trigger user-service verification",
 "provider": { "name": "user-service" },
 "enabled": true,
 "request": {
 "method": "POST",
 "url": "https://gitlab.com/api/v4/projects/1122344/ref/master/trigger/pipeline?token=12345678&variables[PACT_CONSUMER_TAG]=${pactbroker.consumerVersionTags}",
 "body": ""
 },
 "events": [{ "name": "contract_content_changed" }]
}

```

</div>We are passing a variable <code>PACT_CONSUMER_TAG</code> to the pipeline that we can use in our build script to pull the correct contract for the verification. The broker replaces <code>${pactbroker.consumerVersionTags}</code> automatically.As we do not want to run a full pipeline but only the verification tests, we need to make use of the <a href="https://docs.gitlab.com/ee/ci/yaml/#onlyexcept-basic" target="_blank"><code>only</code> and <code>except</code> keywords</a> . The following YAML snipped illustrates the pipeline job definition.<div>

```highlight yaml
pact-verify:
 stage: build
 script:
 - ./gradlew pactTest
 only:
 - triggers

```

</div>In this case, the job will only be executed if the pipeline is triggered through the API and not in regular builds. To avoid running all the jobs in a triggered build, you will have to exclude triggers on all other steps.In the example above we run the Pact verification tests through a custom gradle task <code>pactTest</code>. It pulls the correct Pact from the broker by evaluating the <code>System.env.PACT_CONSUMER_TAG</code> variable which was sent with the webhook. If the tests are configured correctly, the verification results will be published to the Pact broker. Each success and each failure is associated with both the consumer version and the provider version.After successfully implementing the part of the provider pipeline that published verification results to the broker we can utilize the verification matrix to check which pacticipant versions are compatible and if it is safe to deploy a certain version to production.<h3>Can I deploy?</h3>The <code>can-i-deploy</code> command queries the verification matrix. To answer the important question “Can I deploy this change to production?”, however, we first need to let the Pact broker know what pacticipant versions are currently running in production.This can be accomplished using the <code>create-version-tag</code> command. Simply place it inside a pipeline job that gets executed right after a successful deployment. The following YAML snippet defines a <code>pact-tag</code> job that creates a version tag <code>production</code> based on the pacticipant version that was deployed.<div>

```highlight yaml
pact-tag:
 image: pactfoundation/pact-cli:latest
 stage: tag
 script:
 - "pact-broker create-version-tag 
 --pacticipant=user-service 
 --version=$CI_COMMIT_SHORT_SHA
 --tag=production
 --broker-base-url=$PACT_BROKER_HOST
 --broker-token=$PACT_BROKER_API_TOKEN"
 only:
 refs:
 - master

```

</div>If you have a multi-stage deployment you can add different jobs at different stages that create version tags based on the environment, e.g. development or staging.With the tagging in place we can further extend our pipelines to include a job before actually deploying that executes <code>can-i-deploy</code> and aborts the pipeline in case we were about to break something. The following YAML extract contains the definition of a <code>pact-can-i-deploy</code> job inside the login view project.<div>

```highlight yaml
pact-can-i-deploy:
 image: pactfoundation/pact-cli:latest
 stage: can-i-deploy
 script:
 - "pact-broker can-i-deploy
 --pacticipant login-view
 --version $CI_COMMIT_SHORT_SHA
 --to production
 --broker-base-url $PACT_BROKER_BASE_URL
 --broker-token $PACT_BROKER_API_TOKEN"

```

</div>There are multiple ways to invoke the <code>can-i-deploy</code> command. For our use case we are going to specify the pacticipant, its version, and the stage to deploy to. In other words, we are checking if a positive verification result exists between the user service version that is running in production and the login view version that we are currently trying to deploy.If this job fails and your pipeline stages are configured correctly, a missing verification will bring your pipeline to a halt. Note that a failing <code>can-i-deploy</code> does not always mean incompatible versions. It can also mean that the verification results are still pending. Based on how you configure your pipelines there can be a race between provider verifications and consumer pipelines attempting to deploy.<h2>Challenges</h2>While the Pact broker is an extremely convenient way to share and verify Pacts, there are some obstacles we were facing during adoption that we would like to share.When using the Pact broker, some challenges of distributed software development suddenly become visible. While this is not a shortcoming per se it can be confusing to developers at times, e.g. when your build is failing due to a missing verification but you do not immediately see why this verification is missing.Additionally, it can be very difficult to implement a development workflow that integrates version control, your build server and the pact broker while being easy to use and fitting your processes. As always, the devil is in the details. Your setup looks differently depending on whether you use feature branches or do trunk based development, whether you use GitLab CI or Jenkins, and whether you deploy only to one or multiple environments.While webhooks give you the possibility to customize your integrations, there are not many pre-built integrations available, yet. We built a custom Slack application that notifies developers when new contracts or verification results are published and allows you to manually trigger provider verifications. Another nice feature would be to have merge request integration that tells you whether it is safe to merge a branch into another one based on the verification matrix.You should also keep in mind that Pact is a rather new technology and documentation is scattered across different projects and websites. We’ve spent weeks figuring out all the details until we ended up with a usable Pact broker integration. We can recommend the hosted Pact broker service of <a href="https://pactflow.io/">pactflow.io</a>  which also features an updated, more streamlined user interface to at least take away the hassle of operating the broker yourself.<h2>Summary</h2>In this post we have seen how you can use the Pact broker to support your consumer-driven contract testing workflow. The broker facilitates the exchange of contracts between consumers and providers, integrates other tools through webhooks, and can be used to store and query verification results.We also demonstrated how to integrate the broker into your GitLab CI pipelines. We looked at a job definition to publish contracts, how to trigger provider verification test jobs, how to tag pacticipant versions, as well as a job that queries the verification matrix before deploying to production.Although the Pact broker is a very useful tool when implementing consumer-driven contract testing, setting everything up can be challenging and time-consuming. You will have to read a lot of documentation, or even source code. Nevertheless in the end we felt that it was worth the effort as the broker made the whole workflow more transparent and reliable.Have you ever used the Pact broker? Did you set it up yourself or did you use the hosted solution? Would you do it again in the next project? Let us know!

Implementing a consumer-driven contract testing workflow with Pact broker and GitLab CI

<h2>Introduction</h2>Consumer-driven contract testing is an alternative to end-to-end tests where not all services have to be deployed at the same time. It enables testing a distributed system in a decoupled way by decomposing service interactions into consumer and provider tests that can be executed independently.<a href="https://docs.pact.io/" target="_blank">Pact</a>  is the de facto standard for consumer-driven contract testing. It is mainly used for testing request-response style interactions, e.g. communication between services via HTTP, but its specification also includes asynchronous interactions. The term consumer refers to a component making use of the data or functionality of another component which is referred to as the provider.The <a href="https://github.com/pact-foundation/pact-specification" target="_blank">Pact specification</a>  defines a format to specify interactions in a way that they can be understood by consumers and providers independently of the programming language used. The specification is currently implemented in Ruby, JavaScript, Go, Python, Swift, PHP and available for JVM and .NET languages as well.In this blog post we want to take a look at the basics of consumer-driven contract testing with Pact. The remainder of this post is structured as follows. First we will discuss the Pact workflow on a conceptual level. Afterwards we are going to see how to implement such a workflow, also giving minimal code examples for consumer and provider tests. The next section briefly discusses advantages and disadvantages of Pact. We are closing the post by summarizing the main findings and giving an outlook for the upcoming blog posts of this series.<h2>Pact workflow</h2><h3>Concepts</h3>The consumer-driven contract testing workflow involves different entities and concepts. We want to look at the basic concepts in the following paragraphs, before we jump into the development workflow. We will use a toy example throughout the post for illustration purposes. Imagine a login form in a web application that is implemented as a JavaScript application using React with a Kotlin back-end to verify the credentials. The interactions we want to test are related to login and logout.<ul><li>Consumer. An application takes the role of a consumer as soon as it makes use of the functionality of another component, e.g. by initiating an HTTP request. In our example the React application would be the consumer of the login and logout functionality.</li><li>Provider. The provider role involves offering functionality to other applications, e.g. by offering an HTTP API. In our example the back-end authentication service provides login and logout functionality.</li><li>Interaction. An interaction defines what functionality is consumed and how. An HTTP interaction would include the request made from the consumer to the provider, the provider state at that time, as well as the response from the provider. A successful login would be modelled as one interaction.</li><li>Provider state. The provider state captures the state the provider is in during the interaction. States act as a test fixture in your provider tests, allowing you to mock your downstream services or configure your database. In our login example, there might be a state capturing that the user John Doe exists and has a specified password.</li><li>Contract / Pact file. The contract, also known as Pact file, contains all interactions between a specific consumer and provider. In our example scenario there would be one contract between the front-end and the back-end containing all interactions with respect to login and logout.</li><li>Verification. During the verification of a contract, the interactions defined in the Pact file are replayed against the provider code and the actual responses are compared with the expected ones defined in the contract. The verification result needs to be communicated to the developer of the consumer in some way.</li></ul>Note that an application can (and most likely will) be both consumer and provider, depending on the interaction you are looking at. Frontends are typically consumers, but they can also be providers when you think about bidirectional communication over WebSocket, for example.<h3>Consumer workflow</h3>We are talking about consumer-driven contract testing, so let’s look at the consumer development workflow first. As a consumer you want to use some functionality that is provided by another application. Thus the first step is to specify the interactions you want to perform inside a Pact file.While it is possible to create and edit your Pact files with a text editor, it is encouraged to write consumer tests instead. Consumer tests will not only verify your code but also generate the Pact file for all the interactions tested.The next step is to execute the provider tests against your Pact file. If the provider verification is successful it means that the consumer version that generated the contract is compatible with the provider version that verified it. If both are deployed together their interactions should work as expected.<h3>Provider workflow</h3>Although Pact is consumer-driven it also adds benefits to the development workflow of providers. If you want to make a change to your API, for example, you can simply verify all existing contracts. If the verification is successful your change should not break any of the consumers and you can safely deploy the provider changes.This enables providers to not only add new features but also remove deprecated functionality from their API without the fear to break existing functionality.<h2>Implementation</h2><h3>Consumer tests</h3>A consumer test is typically written as follows. First you define your interactions. Then you pass them to the Pact library that will generate the Pact files and create a stub server for you that mimics the provider. Finally you can execute the consumer logic that will invoke the API and check if it works as expected.We will use a concrete example implemented in JavaScript using <a href="https://github.com/pact-foundation/pact-js" target="_blank">pact-js</a>  and jest to illustrate how we can write a consumer test for our login endpoint.<div>

```highlight javascript
import { Interaction, Pact } from '@pact-foundation/pact';

const provider = new Pact(providerConfig);

const successfulLogin = new Interaction()
 .given('jane.doe has password baby1234')
 .uponReceiving('username jane.doe and password baby1234')
 .withRequest({
 method: 'POST',
 path: '/login',
 headers: {},
 body: {
 username: "jane.doe",
 password: "baby1234"
 }
 })
 .willRespondWith({
 status: 200
 });

await provider.addInteraction(interaction);

const response = await UserService.login({
 username: "jane.doe",
 password: "baby1234"
});

expect(response.status).toBe(200);

```

</div>First we are setting up the provider. The provider config contains consumer and provider names for this contract as well as some options for the stub server such as the TCP port. Afterwards we are defining the interaction: Given a user with valid credentials, when we send those credentials the provider will respond with 200.By adding this interaction to the provider we can then invoke the API and will receive a response as expected. How you invoke the API and what you actually test is up to you. In this case we are simply checking that the <code>UserService</code> calls the correct endpoint with the correct payload.In a real world scenario your interactions will most likely look a bit more complex. Not only will you have more complex data but you might also take HTTP headers into account. Additionally it is possible to use matchers instead of exact expectations, i.e. you can pass any password as long as it is a string. This is useful when you want to use the stub server also for manual testing.<h3>Exchanging Pact files</h3>After the consumer has generated a new Pact file it needs to be shared with all respective providers for verification. There are different ways this can be achieved:<ol><li>Commit Pact files to provider repository. The simplest variant of this workflow is to manually create a new PR with the changed interactions to the provider. Then your CI pipeline can execute the provider verification tests. Instead of manually creating a merge request you could automate this process, e.g. by letting the consumer build automatically committing the new interactions and creating a merge request.</li><li>Provider fetches Pact files. Instead of duplicating the Pact files into the provider repository the consumer can publish the interactions to a third party from where the provider can download them before each verification. This third party could be your build server artifact storage (e.g. Gitlab build artifacts), an object storage (e.g. Amazon S3), or the <a href="https://docs.pact.io/getting_started/sharing_pacts" target="_blank">Pact broker</a> .</li></ol>Introducing the Pact broker as an intermediary has the additional benefit that the provider can also publish the verification results to the broker. Both consumers and providers can then query the broker for verification results to find out which versions are compatible and if it is safe to deploy a particular version to production.Now that we have seen options to exchange Pact files between consumers and providers, let’s focus on the implementation of the provider verification tests next.<h3>Provider tests</h3>In order to verify a consumer contract, providers replay all interactions against their implementation using provider verification tests. They can be implemented in a different language than the consumer and we are going to verify our login interaction using Kotlin, JUnit 5, <a href="https://github.com/DiUS/pact-jvm" target="_blank">pact-jvm</a>  and mockk.The following code block contains all basic concepts needed to implement a provider test.<div>

```highlight kotlin
@Provider("account-service")
@PactBroker
class ProviderVerificationTest {

 private val authenticationProvider = mockk<AuthenticationProvider>()

 @TestTemplate
 @ExtendWith(PactVerificationInvocationContextProvider::class)
 fun pactVerificationTest(pactContext: PactVerificationContext) {
 val service = AccountService(authenticationProvider)
 try {
 pactContext.verifyInteraction()
 } finally {
 clearAllMocks()
 service.shutdown()
 }
 }

 @State("jane.doe has password baby1234")
 fun `jane doe has password baby1234`() {
 every {
 authenticationProvider.authenticate("jane.doe", "baby1234")
 } returns true
 }

}

```

</div>The class level annotation <code>@Provider</code> indicates that this is a provider test and it takes the provider name as an argument. The provider name is used to decide which interactions should be replayed. The <code>@PactBroker</code> annotation makes pact-jvm pull the contract from the Pact broker. If you committed the files to the provider repository you can use the <code>@PactFolder</code> annotation instead.By defining a <code>@TestTemplate</code> method that is extended with a <code>PactVerificationInvocationContextProvider</code>, JUnit 5 will generate a test method for each of your interactions. In our case we are creating a new instance of our account service that will listen for HTTP requests. The <code>pactContext.verifyInteraction()</code> call will replay the interaction against your endpoint and check the response according to the contract definition.Before each interaction is replayed, pact-jvm will execute all <code>@State</code> methods that are relevant for this interaction. This allows you to setup your mocks or fill your database based on the expected state before the interaction. In our case we simply tell the mocked authentication provider to accept the credentials that the interaction is going to send.After all interactions have been verified, pact-jvm will report the verification results. It will also publish them to the Pact broker if configured. In case a verification failed you might want to adjust the interaction or implement new functionality in the provider to fulfill the new consumer contract.<h2>Discussion</h2>We have learned about the Pact workflow and how to implement it. But should you use it for your new project? Should you include it into your existing codebase? The answer is, as always, it depends.Pact works great if you feel the need to test your service interactions but do not want the complexity associated with full-blown end-to-end tests. Pact still adds complexity however. If you can get away with a monolithic application and can avoid interactions between distributed services, go for it. It will simplify your testing and development workflow a lot.Nevertheless if you rely on independently developed distributed services to scale your development efforts across multiple teams, Pact will facilitate discussions between your teams, encourage API first design, and increase the confidence in deploying and evolving your APIs over time.Contracts can also be used as API documentation by example. Similar to a unit test documenting the behaviour of your code by providing input together with expected output, interactions can be read by others to understand the API behaviour.It is important to note that consumer-driven does not mean consumer-dictated. I observed situations in which consumers would simply publish new expectations about the providers to the other team and expect them to implement it like this. Of course consumers should drive the discussion and providers should respect contracts previously agreed on to avoid breaking their consumers. But Pact is not a tool to replace inter-team communication.We do not recommend using Pact for public APIs with an unknown set of consumers. In this case it might be better to rely on a combination of <a href="https://swagger.io/specification/" target="_blank">OpenAPI</a>  and a tool like <a href="https://github.com/codecentric/hikaku" target="_blank">Hikaku</a> .Independent of which Pact workflow you decide to implement, whether you are manually copying JSON files or using the Pact broker, make sure every developer understands the Pact concepts and is familiar with the workflow. Otherwise you risk frustration or bugs because you merged or deployed in the wrong order and now your integration broke although Pact was supposed to avoid that.<h2>Summary and outlook</h2>In this post we have seen how you can utilize Pact to test your distributed service interactions. Consumer tests generate expectations towards the provider in the form of Pact files. Providers have to verify those interactions through provider tests.As the Pact specification is implemented in many different languages you can use Pact even if your services are written in different languages. Exchanging Pact files can be done in many different ways, ranging from manually committing them to the provider repository or using a third party service such as the Pact broker.Pact can improve your confidence in evolving your APIs as long as all consumers are known and also following the same workflow. Pact does not work well for public APIs with unknown consumers.In the upcoming post we will look at how you can use Pact in an asynchronous setup, e.g. in an event driven architecture. Have you used Pact before in any of your projects? How was your experience? Which setup worked and which did not? Please let us know in the comments!<hr />Cover image by <a href="https://flic.kr/p/qQTMa" target="_blank">Gunnar Wrobel</a>

Consumer-driven contract testing with Pact

<h2>Introduction</h2>In the <a href="https://blog.codecentric.de/en/2019/10/consumer-driven-contract-testing-with-pact" target="_blank">previous blog post</a> we introduced contract testing with Pact as an alternative to end-to-end tests when developing distributed applications. Pact works great for interactions between services that follow a request-response pattern, for example when using HTTP. However, not all communication follows the request-response pattern.Consider event-driven architectures, where communication is typically asynchronous. Events are emitted and services can subscribe to them. Nevertheless every consumer of such an event has an implicit contract with the provider in terms of what information an event contains. Luckily, Pact also provides functionality to implement contract testing in event-driven architectures.In this blog post we are describing how to use Pact to test message passing contracts. First we are going to look at the message Pact specification and see how interactions differ compared to the known request-response format. Then we are briefly introducing our example scenario that will be used throughout the post. The following section explains how to write consumer tests for message pacts, followed by a section about the respective provider tests. Afterwards we are discussing the importance of backwards compatibility and possible gotchas when relying on Pact to check if you are safe to deploy a new consumer version. The next section discusses the problem that arises when using message Pact if your messages are commands rather than events, and proposes a solution. We are closing the post by summarizing the main findings.<h2>Message Pact Specification</h2><a href="https://github.com/pact-foundation/pact-specification/tree/version-3#introduces-messages-for-services-that-communicate-via-event-streams-and-message-queues" target="_blank">Pact Specification 3.0</a> includes message passing contracts. In contrast to the request-response interactions, a message interaction only contains a single JSON object representing the message.The provider initiates the interaction by publishing a message. All consumers will read and process the message accordingly. The Pact specification is independent of the transmission medium. Messages could be transmitted using publish-subscribe message brokers, queues, or logs, for example.<h2>Example Scenario</h2>Our example project describes three services that exist in a web shop. There is a checkout service which publishes an <code>OrderPlaced</code> event after a customer completed the checkout. This message is consumed by two independent services: a fulfillment service and a billing service. The following diagram illustrates the interaction between the three services and a message broker.<a href="https://media.graphassets.com/MWIyfRQ7TKyagdMBUXaE"><img loading="lazy" src="https://media.graphassets.com/MWIyfRQ7TKyagdMBUXaE" alt="example scenario architecture" width="611" height="151" /></a> The <code>OrderPlaced</code> events are serialized into JSON and look like this:<div>

```highlight json
{
 "items": [
 {
 "price": 1295,
 "name": "A Teddy Bear"
 }
 ],
 "customerId": "133"
}

```

</div>The fulfillment service is only interested in the customer ID to know where to ship to, as well as the items that need to be included into the package. The billing service on the other hand is only interested in the total price in order to charge the customer.All code examples are written in Kotlin and you can find the source code of the complete <a href="https://github.com/rafaroca/pact-msg/" target="_blank">example project on GitHub</a> .<h2>Consumer Tests</h2>As Pact is consumer-driven by design, let’s look at an example of a message consumer test first. The consumer examples make use of the JVM Consumer DSL to describe the message format and provide example data.The fulfillment service would define a message format like so<div>

```highlight kotlin
val fulfillmentJsonBody = newJsonBody { o ->
 o.stringType("customerId", "230542")
 o.eachLike("items") { items ->
 items.stringType("name", "Googly Eyes")
 }
}.build()

```

</div>Note that the item price is not part of this contract. The message format of the billing service relies on the price of the items and the customer ID.<div>

```highlight kotlin
val billingJsonBody = newJsonBody { o ->
 o.stringType("customerId", "230542")
 o.eachLike("items") { items ->
 items.numberType("price", 512)
 }
}.build()

```

</div>This leads to two different interactions about the same message, one by each consuming service. The consumer test of the fulfillment service is outlined in the snippet below.<div>

```highlight kotlin
@ExtendWith(PactConsumerTestExt::class)
class FulfillmentServiceConsumerContractTest {

 @Pact(consumer = "fulfillment-service", provider = "checkout-service")
 fun publishOrderPlaced(builder: MessagePactBuilder): MessagePact =
 builder
 .hasPactWith("checkout-service")
 .expectsToReceive("an order to fulfill")
 .withContent(fulfillmentJsonBody)
 .toPact()

 @Test
 @PactTestFor(pactMethod = "publishOrderPlaced")
 fun testPublishOrderPlaced(messages: List<Message>) {
 for (message in messages) {
 assertThat {
 fulfillmentHandler.handleRequest(message.contents!!.valueAsString())
 }.isSuccess() 
 }
 }
}

```

</div>The Pact function defines the message payload and the Pact test function calls the fulfillment handler with the message payload. A message Pact interaction may contain multiple messages by invoking <code>expectsToReceive().withContent()</code> more than once. This can be useful to test dependencies between messages but we can safely ignore that for our case. In the following test function we loop over all messages, asserting that the handler is able to process them without failure, thus verifying the interaction on the consumer side.<h2>Provider Tests</h2>In a true consumer-driven fashion we have proven that our consumer adheres to the contract. Now let’s switch over to the provider which needs to verify that it is able to produce the expected messages. The consumer defines provider expectations for each interaction.<div>

```highlight kotlin
@PactVerifyProvider("an order to fulfill")
fun anOrderToFulfill(): String? {
 val checkoutService = CheckoutService()
 val order = Order(
 listOf(
 Item("A secret machine", 1559),
 Item("A riddle", 9990),
 Item("A hidden room", 3330)
 ), "customerId"
 )
 val orderPlacedEvent = checkoutService.placeOrder(order)
 return orderPlacedEvent.toJsonString()
}

```

</div>First we are creating an order with three items and a customer ID. We are then passing it to the <code>checkoutService</code> instance that will place the order and return the <code>OrderPlaced</code> event. We then need to convert the event to a JSON string that matches the expectations of the consumer.As the consumer test only contains type matchers, the items and customer number do not have to be exact matches. The item names and prices as well as the count of the items in the list may be different from the example in the contract and still verify correctly.Given correct provider and consumer tests and a working integration into your development workflow you can safely release new versions of your messages to production. Or can you?<h2>Backwards Compatibility Matters</h2>One big advantage of using Pact is that you can introduce even backwards incompatible changes in your APIs and avoid accidentally breaking consumers. As soon as all your consumers migrated to the new version you can deploy the changes that is not backwards compatible. But does it work the same way with asynchronous messages?In event driven architectures it is always possible that old messages are still in the system. Just because a new provider version was put into production does not mean that only messages with the new structure exist. Depending on the message passing technology, messages with an old format might be in flight or could be manually replayed even months after they have been deprecated.This means that even when using Pact to check for breaking changes in your messages you always need to pay attention to backwards compatibility. One way to address this issue could be to never remove or rename fields in messages, and only adding optional fields. The disadvantage of this approach is that your messages will grow and your providers still have to be able to produce those old messages in order to verify the contract.Another solution could be to extend the Pact specification to allow marking messages as deprecated. They would only be replayed during the consumer tests but would not have to be verified by the provider. When evolving your message format you can add a new message and mark the old one as deprecated. Unfortunately this will make your contracts grow over time.To address the growing amount of deprecated messages one can imagine an integration with the message broker or event store that can tell you whether deprecated messages can be safely deleted from the contract if they are no longer in flight or already migrated to the new format in the event store.<h2> Message Pact and the Command Pattern</h2>In the message Pact specification the provider is defined as a service that emits events in the form of messages. Consumers subscribe to certain events and will process the corresponding messages. This works well when messages are events, just like the <code>OrderPlaced</code> event from our example shop.If we consider a distributed <a href="https://en.wikipedia.org/wiki/Command_pattern" target="_blank">command pattern</a> , however, commands are serialized as messages that asynchronously invoke other services. Commands typically target a service that is known by the invoking component. Instead of a message broker, where multiple services can subscribe, the command is placed into a queue which gets polled regularly by the receiver.In this scenario treating the message creator as the provider seems counter-intuitive. Instead the message creator is consuming functionality of the command receiver. It is just like the request-response pattern but asynchronous and without a response as there is no back-channel through the queue.Additionally, if you test commands using message pacts and the command receiver is the consumer, the workflow is not really consumer driven. Thinking of a command as a request without a response, the workflow should be driven by the service sending the command.Unfortunately you cannot simply swap the roles and everything works fine. The way message Pact tests are implemented, consumers have to process the message and providers have to produce it. This implementation does not fit the command pattern use case. However there is a reasonable workaround possible without extending the Pact specification.Swapping provider and consumer is possible if you adjust the way you write consumer and provider tests. Consumer tests now compare if the generated message corresponds to the one returned by the Pact testing framework, instead of checking if the message can be consumed.In the provider test we extract the message from the interaction and return it for verification instead of actually producing a message using our service. The test is now a tautology from the perspective of the Pact testing framework. However, before returning the message we can feed it to our command processor and verify that it can be processed with custom test assertions.<h2> Summary</h2>In this post we have seen how message Pact can be used to test interactions in event-driven architectures. In the consumer tests we verify that we can process incoming events. The providers on the other hand have to prove that they can produce the expected messages.Backwards compatibility can be an issue, especially when working with event stores and logs or message queues, as messages can still be in-flight or can be replayed at a later point in time. Consumers still need to be able to process those messages, even if the provider does not publish them anymore.When your message represents an asynchronous command rather than an event, the message Pact workflow no longer feels consumer-driven. We showed that by switching the roles and adapting the way consumer and provider tests are written, you can still use message Pact to test your command interactions.Have you used message Pact in before? What were your experiences with the workflow? How many consumers did you implement and which message passing technology did you use? Let us know in the comments!

Message Pact – Contract testing in event-driven applications

Office & 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) 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) 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).

IT Developer & Consultant

Standortleitung 

Recruiterin

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

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten