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

IT-Security

Produktentwicklung

Weitere Leistungen...

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

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 Frankfurt am Main

Unser codecentric Team am Standort Frankfurt am Main stellt sich vor.

codecentric Team Frankfurt am Main

Willkommen im Team Frankfurt

Entwicklung strukturierter Maßnahmen zu effizienter Remote-Work: Ein „Arbeitsblatt“

Principal Agile & Product Coach

<p>In diesem Artikel beschreiben wir die Entwicklung, zusammen mit den Herausforderungen, des Logstash-Java-Input-Plug-ins für Apache PLC4X, das im Rahmen des Open-Source-Projekts <em>Apache PLC4X</em> in Absprache mit Elastic entwickelt wurde.</p><h2>Architektonische Übersicht über das Logstash-Java-Input-Plug-in</h2><p>Zunächst werfen wir einen Blick auf die grundlegende Architektur und Systemlandschaft und werden im Anschluss die Umsetzung des Plug-ins betrachten. In der nachfolgenden Abbildung ist eine Übersicht über das Einsatzgebiet des Plug-ins zu sehen.</p><p><a href="https://media.graphassets.com/QGkcjYiTRFGOO3orSoBA"><img width="700" height="174" src="https://media.graphassets.com/QGkcjYiTRFGOO3orSoBA" alt="Overall architecture Logstash Java Input Plug-in PLC4X" /></a> </p><p>Wir verwenden im Plug-in das Framework Apache PLC4X, um Daten von IIoT-Geräten (Industrial Internet of Things) mittels Pull-Prinzip abzufragen. Diese Daten werden an Logstash übergeben, welches diese anschließend über ein Output-Plug-in der Pipeline mittels Push-Prinzip weiterleitet. Hier haben wir beispielsweise <em>ElasticSearch</em> gewählt.<br /> Neben der Abfrage von mehreren IIoT-Geräten in einer Pipeline ist es ebenfalls möglich, mehrere Pipelines zu definieren, um die Abfragen auf mehrere Pipelines zu verteilen. Dies ist z. B. bei verschiedenen Gerätetypen oder Standorten sinnvoll.</p><h2>Die Entwicklung des Plug-ins und der zugehörige Build-Prozess (als Teil von Apache PLC4X)</h2><p>Für die Entwicklung eines Logstash-Java-Input-Plug-ins gibt es von Elastic eine Anleitung, die <a href="https://www.elastic.co/guide/en/logstash/current/java-input-plugin.html" target="_blank">hier</a>  gefunden werden kann.<br /> Dort wird erklärt, dass als erstes der Quelltext von <em>logstash</em> heruntergeladen und gebaut werden muss. Anschließend wird im Projekt des Java-Logstash-Input-Plug-ins der Pfad zu <em>logstash</em> in der Datei <em>gradle.properties</em> eingetragen. Dieser Schritt ist notwendig, solange die entsprechende JAR-Datei von <em>logstash</em> noch nicht auf dem <em>Maven Central Repository</em> verfügbar ist. Aktuell ist noch unklar, wann dies der Fall ist – es existiert aber bereits ein <a href="https://github.com/elastic/logstash/issues/11002" target="_blank">Issue</a>  im entsprechenden GitHub-Projekt von Elastic.</p><p>Wird das Logstash-Java-Input-Plug-in anschließend gebaut, verwendet das Skript <em>gradle.build</em> die Datei <em>rubyUtils.gradle</em> von <em>logstash</em>. In diesen Utils wird JRuby heruntergeladen und anschließend verwendet. Für das Herunterladen und Entpacken von JRuby wird der Befehl <b><em>commandLine ‚./mvnw‘, ‚clean‘, ‚install‘, ‚-Pdist‘, ‚-Pcomplete‘</em></b> verwendet. Gradle führt Maven an dieser Stelle über einen Maven-Wrapper aus. Dies ist im Rahmen des Apache-PLC4X-Projekts ungünstig. Denn PLC4X verwendet Maven selbst als Build-Tool. Daher ergäbe sich bei einfacher Einbindung von Gradle aus der Elastic-Anleitung folgender Build-Prozess:</p><p><a href="https://media.graphassets.com/8xsMyWkSdyjWwCkvqIde"><img loading="lazy" width="700" height="462" src="https://media.graphassets.com/8xsMyWkSdyjWwCkvqIde" alt="Build process with maven and gradle (plc4x project)" /></a> </p><p>Hier ist eine unnötige Verkettung von Build-Tools zu sehen, da Maven Gradle ausführt und dieses im Anschluss wiederum Maven aufruft. Daher haben wir beschlossen, den Gradle-Teil des Build-Prozesses ebenfalls in Maven umzusetzen, sodass sich folgender Ablauf ergibt:</p><p><a href="https://media.graphassets.com/ukUKvCE5RkaoqQcprPJO"><img loading="lazy" width="700" height="334" src="https://media.graphassets.com/ukUKvCE5RkaoqQcprPJO" alt="build process with maven (plc4x project)" /></a> </p><p>Abschließend stellen wir noch die Umsetzung des Build-Prozesses mit Maven und den zugehörigen Plug-ins vor.</p><table><tbody><tr><td></td><td><a href="https://media.graphassets.com/wkgbOmfRGmmUWu1M38OA"><img loading="lazy" width="250" height="635" src="https://media.graphassets.com/wkgbOmfRGmmUWu1M38OA" alt="build process" /></a> </td></tr><tr><td><strong>groovy-maven-plugin:</strong> In diesem Schritt wird die Version ohne <em>SNAPSHOT</em> berechnet und als künstliche Eigenschaft in Maven (<em>current-full-version</em>) gesetzt. JRuby benötigt die Version in diesem Format, da es ansonsten mit einer Fehlermeldung abbricht.</td></tr><tr><td><strong>download-maven-plugin:</strong> Dieses Plug-in lädt und entpackt JRuby, das zum Erstellen des Artefakts benötigt wird.</td></tr><tr><td><strong>maven-resources-plugin:</strong> Dieses Plug-in bearbeitet alle Ressourcen (z. B. ersetze <em>${current-full-version}</em> durch die Version).</td></tr><tr><td><strong>maven-shade-plugin:</strong> Erstellt eine Fat JAR aus den Klassen und Dateien des Plug-ins sowie allen Abhängigkeiten.</td></tr><tr><td><strong>exec-maven-plugin:</strong> Mit diesem Plug-in werden JRuby und Gem aufgerufen, die anschließend das Artefakt <em>logstash-input-plc4x-X.X.X.gem</em> erstellen.</td></tr><tr><td><strong>build-helper-maven-plugin:</strong> Mit diesem Plug-in wird das Artefakt in Maven hinzugefügt, sodass es ebenfalls in der <em>install</em>-Phase von Maven berücksichtigt wird.</td></tr></tbody></table><h2>Beispielkonfiguration des Plug-ins</h2><p>Voraussetzung für die Verwendung des Plug-ins ist die Installation in Logstash. Anschließend kann das Plug-in wie folgt initialisiert und konfiguriert werden.<br /></p><div>

```autoconf
## logstash pipeline config - input
input {
	## use plc4x plugin (logstash-input-plc4x)
	plc4x {
		## define sources
		sources => {
			source1 => "opcua:tcp://opcua-server:4840/"
			source2 => "opcua:tcp://opcua-server1:4840/"
			source3 => "..."
		}
		## define jobs
		jobs => {
			job1 => {
				# pull rate in milliseconds 
				rate => 2
				# sources queried by job1
				sources => ["source1", ...]
				# defined queries [logstash_internal_fieldname => "IIoT query"]
				queries =>  {
					PreStage => "ns=2;i=3"
					MidStage => "ns=2;i=4"
					PostStage => "ns=2;i=5"
					Motor => "ns=2;i=6"
					ConvoyerBeltTimestamp => "ns=2;i=7"
					RobotArmTimestamp => "ns=2;i=8"
				}
			}
			job2 => { .... }
		}
	}
}
 
## logstash pipeline config - filter
filter {
	...
}
 
## logstash pipeline config - output
output {
	...
}
```

</div><p>Im Abschnitt <em>input</em> wird das Plug-in durch <em>plc4x</em> initialisiert. Innerhalb des <em>plc4x</em>-Abschnitts können <em>sources</em> und <em>jobs</em> definiert werden. <em>Sources</em> sind die Connection-Strings für die jeweiligen PLCs (hier beispielsweise OPC UA Server).<br /> Im <em>jobs</em>-Abschnitt können einzelne <em>jobs</em> definiert werden. Diese enthalten <em>queries</em> (Abfragen) für bestimmte <em>sources</em>. Die Abfragen sind in der Form <em>X => „Y“</em> angegeben. X ist der interne Feldname für Logstash. Y ist die Abfrage, die zum PLC gesendet wird.<br /> Für jeden Job wird eine Rate angegeben, die die Zeitspanne zwischen den einzelnen Abfragen definiert. Im Beispiel werden die fünf definierten Felder alle <em>300</em> Millisekunden von <em>source1</em> abgefragt.</p><h2>Quelltext des Java-Logstash-Plug-ins für PLC4X</h2><p>Das Plug-in besteht aus einer Klasse, die wir für diesen Blogbeitrag in drei Abschnitte aufgeteilt haben.</p><p>Im ersten Teil des Plug-ins werden die <em>sources</em> eingelesen und anschließend dem Builder des Scrapers von PLC4X hinzugefügt. Der Scraper ist ein Teil von PLC4X, um Daten regelmäßig von beliebigen PLCs abzufragen.</p><div>

```java
// parse sources
for (String sourceName : sources.keySet()) {
	Object o = sources.get(sourceName);
	if(o instanceof String) {
		String source = (String)o;
		builder.addSource(sourceName, source);
	} else {
		logger.severe("URL of source " + sourceName + "has the wrong typ!");
	}
}
```

</div><p>Der zweite Abschnitt des Quellcodes ist für das Einlesen und Erstellen der <em>jobs</em> zuständig.<br /> In der äußeren <em>for-</em>Schleife wird über alle definierten <em>jobs</em> iteriert. Für jeden einzelnen Job werden anschließend die Rate, die <em>sources</em> als auch die Abfragen eingelesen und dem <em>jobBuilder</em> (ebenfalls Teil des Scrapers) von PLC4X zugewiesen.</p><div>

```java
// parse jobs
for (String jobName : jobs.keySet()) {
	Object o = jobs.get(jobName);
	if (o instanceof  Map) {
		Map job = (Map<String, Object>) o;
		JobConfigurationTriggeredImplBuilder jobBuilder = builder.job(
			jobName, String.format("(SCHEDULED,%s)", job.get("rate")));
		for (String source : ((List<String>) job.get("sources"))) {
			jobBuilder.source(source);
		}
		Map<String, Object> queries = (Map<String, Object>) job.get("queries");
		for (String queryName : queries.keySet()) {
 
			String fieldAlias = queryName;
			String fieldAddress = (String) queries.get(queryName);
			jobBuilder.field(fieldAlias, fieldAddress);
		}
		jobBuilder.build();
	} else {
		logger.severe("Jobs of wrong Type!");
	}
}
```

</div><p>Nachdem nun alle <em>sources</em> und <em>jobs</em> eingelesen sind, können wir den Scraper ausführen. Bei der Initialisierung des Scrapers übergeben wir eine Lambda-Funktion, die nach erfolgreicher Abfrage der Felder aufgerufen wird. In dieser Funktion werden die erhaltenen Werte geloggt und die Ergebnisse anschließend vom <em>consumer</em> akzeptiert (der <em>consumer</em> ist Teil des Logstash-API und nimmt die Daten entgegen).</p><div>

```java
// start scraper
ScraperConfigurationTriggeredImpl scraperConfig = builder.build();
try {
	plcDriverManager = new PooledPlcDriverManager();
	triggerCollector = new TriggerCollectorImpl(plcDriverManager);
	scraper = new TriggeredScraperImpl(scraperConfig, (jobName, sourceName, results) -> {
		HashMap<String, Object> resultMap = new HashMap<String, Object>();
		resultMap.put("jobName", jobName);
		resultMap.put("sourceName", sourceName);
		resultMap.put("values", results);
 
		//TODO: add guard for debug mode, so only in debug mode its run
		for (Map.Entry<String, Object> result : results.entrySet()) {
			// Get field-name and -value from the results.
			String fieldName = result.getKey();
			Object fieldValue = result.getValue();
			logger.finest("fieldName: " + fieldName);
			logger.finest("fieldValue: " + fieldValue);
		}
		consumer.accept(resultMap);
	}, triggerCollector);
	scraper.start();
	triggerCollector.start();
} catch (ScraperException e) {
	logger.severe("Error starting the scraper: "+ e);
}
```

</div><h2>Fazit und Lessons Learned</h2><ul><li><b>Benennung von Dateien und Klassen</b><br /> Die Logstash-Java-Input-Plug-ins sind bei der Benennung der Dateien und Konfigurationen sehr sensitiv. Die Namen der Gemspec-, JAR- sowie Gem-Dateien müssen alle derselben Benennung folgen (z. B. <em>logstash-input-plc4x</em>). Ebenfalls müssen der Klassenname und einige Konfigurationen (beispielsweise Inhalte der Ruby-Konfiguration, also der <em>.rb</em>-Dateien) bezüglich der Benennung übereinstimmen. Zu Beginn der Entwicklung hatten wir uns überlegt, die <em>aritfact-id</em> des Projekts zu verwenden. Dabei hatten wir das Problem, dass wir diese nicht überall durch das <em>maven-resource-plugin</em> ersetzen lassen konnten. Dadurch stimmten die Benennungen teilweise nicht überein und es kam zu Problemen bei Installation und Ausführung des Plug-ins. Nachdem wir uns für eine statische Benennung des Plug-ins entschieden und alle relevanten Stellen identifiziert hatten, ließ sich das Plug-in in Logstash installieren und ausführen. Diese Lösung hat auch den Vorteil, dass die artifact-id <em>plc4j-logstash-plugin</em> mit dem Namensschema von PLC4X und der Plug-in Name <em>logstash-input-plc4x</em> mit dem Namensschema für Plug-ins in Logstash übereinstimmt.</li><li><b>Installationsdauer des Plug-ins</b><br /> Die Installation des Plug-ins in Logstash benötigt meist ~2 Minuten. Dies ist im Fehlerfall (wie z. B. bei der Problematik mit der Benennung) sehr unglücklich, da so zwischen Änderung und Test dieser einige Minuten vergehen.</li><li><b>Build-Tools: Maven, Gradle, JRuby, …</b><br /> Ein weiteres Learning dieses Projekts besteht darin, dass wir in zukünftigen Projekten die Verwendung mehrerer Build-Tools, genau wie hier, hinterfragen werden. Ansonsten entstehen gegebenenfalls ungünstige Verkettungen von Build-Tools wie oben beschrieben (Maven und Gradle). An dieser Stelle möchten wir uns auch bei <em>Christofer Dutz</em> bedanken, der uns bei dieser Problematik unterstützt hat.</li></ul><p>Der Quellcode des gesamten Plug-ins ist hier im PLC4X-Projekt zu finden.</p>

Logstash-Java-Input-Plug-in für Apache PLC4X

In diesem Artikel beschreiben wir gesammelte Best Practices für das Integration Testing von Microservices. Zu diesem Zweck haben wir ein Projekt namens <a href="https://github.com/codecentric/toti-example-service"  target="_blank">toti-example-service</a> erstellt und auf GitHub veröffentlicht. Wir werden uns in diesem Beitrag immer wieder auf dieses Projekt und auf den Quelltext beziehen.

## Kurzer Überblick über das Demo-Projekt
Das Projekt haben wir mit Kotlin und dem Spring-Boot-Framework erstellt. Es enthält beispielhaft zwei REST-Endpunkte, um die Interaktion mit einer Datenbank sowie einem anderen Microservice zu demonstrieren. Wie üblich bei Spring haben wir im Projekt verschiedene Schichten implementiert, wie Controller, Services, Repositories und Web-Clients.

Im Folgenden sind die Funktionalitäten der Beispielanwendung zu sehen:

![image.png](https://media.graphassets.com/4MuzMwhQwSdyZAdlMtRy)

Wie auf der Abbildung zu erkennen ist, wurde eine Funktionalität für Blogposts implementiert. Diese kann man in einer DynamoDB-Tabelle verwalten, und es steht eine einfache CRUD-API zur Verfügung.

Die zweite Funktionalität demonstriert die Kommunikation mit einem anderen Microservice. Hierbei ist es möglich, einen oder mehrere Fakten über Katzen (CatFacts) abzurufen. Diese werden im Hintergrund über einen WebClient von einer öffentlichen API abgefragt.

## Warum Integration Testing?
Wir stellen immer wieder fest, dass Integrationstests in Projekten zu wenig Beachtung finden und dementsprechend selten genutzt werden. Dabei hat sich gezeigt, dass sie einen großen Beitrag zur Sicherheit und Stabilität der Schnittstellen leisten können, da sie den Service als Black Box betrachten. Diese Sichtweise führt dazu, dass der Service aus der Sicht eines externen Systems getestet wird, was zur Verbesserung der Schnittstellen-Stabilität beiträgt.

Durch die Gewährleistung der Stabilität der Schnittstelle bieten Integrationstests bei Refactorings eine große Sicherheit, da der API-Vertrag garantiert unverändert bleibt. Dies erleichtert es, sowohl die interne Datenstruktur als auch die Implementierung eines Microservices zu ändern.

Im Projektalltag hat es sich mittlerweile etabliert, Fehler zunächst mit einem Integrationstest zu reproduzieren, bevor man sie behebt. Dadurch wird sichergestellt, dass der Fehler nicht erneut auftritt, und Sonderfälle sowie Ausnahmen sind im Quellcode dokumentiert – gegebenenfalls inklusive der Ticketnummer. Integrationstests helfen somit nicht nur bei der Stabilität der Software, sondern auch bei der Dokumentation von Ausnahmefällen.


## Was wir unter einem Integrationstest verstehen

Es kommt häufig vor, dass es Missverständnisse darüber gibt, was ein Integrationstest umfasst und was ihn ausmacht. Wir verstehen darunter einen Test, bei dem der Microservice unter möglichst realistischen Bedingungen getestet wird. Das bedeutet, dass der gesamte Quellcode, der auch in Produktion ausgeführt wird, getestet werden sollte – und auch ausschließlich dieser. Konkret bedeutet dies:

- Keine Beans überschreiben
- Keine Extra-Konfiguration, keine *TestConfiguration*
- keine Mocks des Quelltexts
- **echte Http-Aufrufe**
- **echte Persistenz in einer Datenbank** (z. B. PostgreSQL ausgeführt in Docker, …)


## Abgrenzung zu anderen Testarten
**Abgrenzung zu Unit-Tests:**
- Unit-Tests konzentrieren sich auf individuelle Komponenten, während Integrationstests die Zusammenarbeit zwischen Komponenten prüfen.
- Unit-Tests sind in der Regel schneller, da sie in Isolation ausgeführt werden, während Integrationstests mehr Zeit in Anspruch nehmen können, da sie die Interaktion zwischen Komponenten testen.

**Abgrenzung zu End-to-End-(E2E-)Tests:**
- E2E-Tests testen das gesamte System aus der Perspektive des Benutzers, während sich Integrationstests auf die Interaktionen zwischen Komponenten konzentrieren.
- E2E-Tests sind in der Regel langsamer als Integrationstests, da sie das gesamte System testen und oft komplexere Testumgebungen und -szenarien erfordern.


**Abgrenzung zu Performance-Tests:**
- Performance-Tests messen Leistungskennzahlen wie Antwortzeiten, Durchsatz und Ressourcenverbrauch, während Integrationstests die Funktionalität und Zusammenarbeit zwischen Komponenten testen.
- Performance-Tests haben den Fokus auf die Leistung und nicht auf die Funktionalität, während sich Integrationstests darauf konzentrieren, ob die Komponenten korrekt zusammenarbeiten.
## Wie sieht das in unserem Beispiel aus?

Um die zuvor genannten Anforderungen zu erfüllen, nutzen wir verschiedene Frameworks wie zum Beispiel <a href="https://wiremock.org/"  target="_blank">Wiremock</a>, <a href="https://greenmail-mail-test.github.io/greenmail/"  target="_blank">Greenmail SMTP Server</a>, <a href="https://www.testcontainers.org/modules/databases/postgres/"  target="_blank">Datenbanken in Docker</a> oder <a href="https://www.testcontainers.org/modules/localstack/"  target="_blank">AWS Localstack</a>. Auf diese Weise stellen wir sicher, dass die produktive Umgebung im Test möglichst genau nachgebildet wird. Konkret bedeutet dies:

![image.png](https://media.graphassets.com/d8R1xzzTiBJKLIpZAwYg)

In der Grafik wird deutlich, dass unser Microservice als Black Box betrachtet wird (grüne Box). Die Testumgebung wird möglichst realitätsnah nachgebildet, wie an den Boxen *Wiremock* und *Docker*(DynamoDb) zu erkennen ist. Der Test nutzt den HTTP-Server Wiremock und startet den Docker-Container, bevor die Testfälle ausgeführt werden. Anschließend ruft der Test unseren Microservice über die Rest-API auf, um beispielsweise Entitäten zu erstellen und abzurufen. Dies ist ein Beispiel für ein Integrationstest-Setup.

Hier eine Liste möglicher Frameworks zum Mocken des Microservice-Umfelds:
- Testcontainer: Postgres Dockerfile
- Testcontainer: Oracle Dockerfile
- Testcontainer: InfluxDb Dockerfile
- Testcontainer: Local DynamoDB Dockerfile
- Testcontainer: AWS Localstack (z. B. für SQS, SNS)
- Wiremock (leichtgewichtiger HTTP-Server, um andere Microservices zu mocken)
- GreenMail - SMTP Server Mock
- UnboundID LDAP Server Mock
- Eigene Extensions, um bspw. eine UDP Verbindung zu mocken


## Testcontainer am Beispiel DynamoDB als JUnit 5 Extension

Um das Testcontainer-Framework vor dem Start aller Tests zu initialisieren und hochzufahren, müssen die Daten für die Verbindung zum Container (Host, Port) in der Spring-Umgebung bekannt gemacht werden. Wir haben dabei gute Erfahrungen mit der Kapselung dieser Schritte in einer JUnit 5 Extension gemacht:

```kotlin

class DynamoDbLocalExtension : BeforeAllCallback {

    companion object {
        @JvmStatic
        var container = DynamoDbLocalContainer()

        @JvmStatic
        var initialized = false
    }

    override fun beforeAll(context: ExtensionContext) {
            if (!initialized) {
                container.withExposedPorts(8000)
                    .start()
                System.setProperty(
                    "dynamo.endpoint",
                     "http://${container.containerIpAddress}:${container.getMappedPort(port)}"
            )

                )

                createTables(context)
            }
    }

    private fun createTables(context: ExtensionContext) {
        val blogPostRepository = SpringExtension.getApplicationContext(context).getBean(BlogPostRepository::class.java)
        blogPostRepository.blogPostTable().createTable()
    }

    class DynamoDbLocalContainer : GenericContainer<DynamoDbLocalContainer>("amazon/dynamodb-local:latest")
}

```

Die JUnit 5 Extension erweitert den *BeforeAllCallback*, um sicherzustellen, dass die Initialisierung vor dem Hochfahren des Spring-Contexts stattfindet. Dabei werden die Konfigurationsparameter gesetzt und beim Hochfahren des Spring-Contexts dynamisch geladen.

Es ist jedoch zu beachten, dass die Methode *beforeAll* vor jeder Testklasse aufgerufen wird. Um sicherzustellen, dass der Container nur einmal initialisiert wird, verwenden wir die statische *initialized*-Property. Daher verzichten wir auch auf die automatisierte Verwaltung des Frameworks, die über die Annotation *@Container* gesteuert wird. Diese würde dazu führen, dass der Container nach jedem Test heruntergefahren wird.

## Performance-Überlegungen
In verschiedenen Projekten wurde argumentiert, dass das Starten mehrerer Docker-Container viele Ressourcen des Host-Systems verbraucht und daher nicht praktikabel ist. Heutzutage ist dies jedoch kein Problem mehr, da in der Regel alle Computer, insbesondere die von Entwicklern, mit ausreichenden Ressourcen ausgestattet sind. Im praktischen Betrieb ergeben sich in der Regel keine Probleme.

Sollte es dennoch zu Engpässen kommen, besteht die Möglichkeit,  <a href="https://www.testcontainers.cloud/"  target="_blank">Testcontainers in der Cloud von atomicjar</a>  zu verwenden.

Durch die Möglichkeit, alle Umgebungssysteme eines Services durch Container abzubilden, entsteht im Integrationstest eine zusätzliche Umgebung. So ist es unserer Meinung nach möglich, mit nur zwei Umgebungen (zum Beispiel Staging und Production) zu arbeiten und die Tests als Development-Umgebung zu betrachten.

## Beispiel für einen Integrationstest
Abschließend möchten wir ein kurzes Beispiel vorstellen, wie man einen Test konkret implementieren kann. Wir wollen hier die Schnittstelle zum Anlegen eines Blogposts ansprechen und testen, ob diese den Post korrekt anlegt und zurückgibt:

```kotlin

@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
@ExtendWith(DynamoDbLocalExtension::class)
class BlogPostIntegrationTest {
    companion object {
        @JvmStatic
        @RegisterExtension
        val rest = WebTestClientExtention()
    }

    @Test
    internal fun `should create blog post and return it`() {
        val id = IdGenerator.nextAsLong()
        rest.webTestClient.put()
            .uri { uriBuilder ->
                uriBuilder.path("/blogposts/{id}")
                    .build(id)
            }.bodyValue(
                """
                {
                   "id": $id,
                   "title": "some title 2",
                   "content": "the content 2"
                }
            """.trimIndent()
            )
            .headers { headers -> headers.contentType = MediaType.APPLICATION_JSON }
            .exchange()
            .expectStatus().is2xxSuccessful
            .expectBody().json("""
                {
                   "id": $id,
                   "title": "some title 2",
                   "content": "the content 2"
                }
            """.trimIndent())
    }

}

```
In dem obigen Test Case wird deutlich, dass die zuvor angesprochene JUnit Extension mithilfe der *@ExtendWith*-Annotation verwendet wird, um sicherzustellen, dass die lokale DynamoDB vor dem Test hochgefahren und initialisiert wird. Anschließend rufen wir den Service über den *WebTestClient* von Spring Boot wie in einem externen System auf. In diesem Beispiel wird die Antwort nur auf das JSON-Dokument und den HTTP-Status geprüft, aber es könnten auch umfangreichere Validierungen durchgeführt werden. Ein bewährtes Framework für Validierungen ist beispielsweise <a href="https://assertj.github.io/doc/"  target="_blank">assertJ</a>, das sich hier gut einfügt.

**Takeaways:**
- Integrationstests sind wichtig für stabile und sichere Schnittstellen in Microservices.
- Der Test sollte den Service als Black Box betrachten und unter realistischen Bedingungen durchführen.
- Frameworks wie Wiremock, SMTP Server, Datenbanken in Docker oder AWS Localstack können ein praktikables Integrationstest-Setup bereitstellen.
- Die Abbildung aller Umgebungssysteme eines Services durch Container schafft im Integrationstest eine zusätzliche Umgebung.
- Parallelisierung von Integrationstests kann Testdauer verkürzen und Testabdeckung verbessern.
- Integrationstests sollten automatisiert in den Entwicklungsprozess durch Continuous Integration/Continuous Delivery integriert werden.
- Integrationstests geben ein gutes Gefühl, da die Schnittstellen nach außen garantiert funktionieren.


Wir bedanken uns für das Lesen dieses Beitrags und hoffen, einige Denkanstöße zum Thema Integration Testing gegeben zu haben. Wir werden diese Gedanken in weiteren Beiträgen vertiefen; der nächste wird sich mit dem Thema der Parallelisierung dieser Tests befassen.



Microservice Integration Testing done right 

IT Consultant and Software Engineer 

Cloud Solution Architect, DevOps Engineer, Full Stack Developer

Senior IT Consultant

VueJS performance tips. Part I

VueJS performance tips. Part II

I'm an interviewer: how to prepare if I am a techie, not a hiring manager

Frontend Developer

<p><em>Die Luft ist zum Schneiden, der Beamer rauscht auf höchster Stufe und die Hemden vieler Teilnehmer sehen alles andere als frisch aus. Erleichterte Blicke, als der PO dem Team dankt und das Planungsmeeting beenden will – „Aber“, fällt ihm da eine Entwicklerin aus der hinteren Ecke des Raumes ins Wort, „für meine Komponente gibt es in diesem Sprint noch überhaupt nichts zu tun.“ Also, alle wieder hinsetzen, alles zurück auf null und noch mal von vorne beginnen mit dem Zuweisen der Stories in den Sprint.</em></p><p>In vielen Scrum-Projekten, in denen ich über die letzten Jahre gearbeitet habe, gab es ein ähnliches Problem: Die benötigten Technologien sind sehr heterogen und die Entwickler daher zu spezialisiert, als dass sie in allen Bereichen des Projektes eingesetzt werden könnten. Im Folgenden erläutere ich daraus resultierende Probleme und zeige verschiede Lösungsansätze.</p><p><span></span></p><p>Besonders Projekte, die neue Technologien in einem größeren Legacy-IT-Umfeld einführen, neigen durch den Mix an Alt und Neu dazu, eine große Menge an Sprachen, Frameworks und Tools zu beinhalten. Als Beispiel ein Technologie-Stack aus einem aktuellen Projekt: <em>PhoneGap, AngularJS, Node.js, Java-Middleware, XML-basierte Messaging-Sprache, Oracle Database</em>. Dazu kommen all die kleinen Tools und Frameworks, die in agiler Software-Entwicklung vorausgesetzt werden. Wer agiles Vorgehen schon mit der Entwickler-Muttermilch aufgesogen hat, neigt dazu, den zusätzlichen Lernaufwand zu unterschätzen, den es braucht, um TDD zu verinnerlichen, Mockito zu verwenden, Maven-Skripte auf dem CI-Server und eine Test Coverage-Analyse in seiner IDE ausführen zu lassen. Die Menge an neuem Wissen und Vorgehen, die Menschen lernen können, ist begrenzt. Es gilt also, die richtigen Prioritäten zu setzen. Doch dazu später mehr.</p><h2>Das Feature-Team</h2><p>Die optimale Größe eines Development-Teams liegt laut Scrum-Guide bei drei bis neun Entwicklern. Möchte man Feature-Teams bilden, so sollten diese Entwickler in der Lage sein, ohne externe Hilfe einen Wert für den Kunden zu schaffen. Also Anforderungen komplett von der UI bis zur Persistenz zu entwickeln.</p><blockquote><p>“Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Having more than nine members requires too much coordination.” <a href="http://www.scrumguides.org/scrum-guide.html" target="_blank">(1)</a> </p></blockquote><p> </p><blockquote><p>“‘A feature team is a long-lived, cross-functional, cross-component team that completes end-to-end customer features—one by one.’ Feature teams are an essential element to scaling up agile development.” <a href="http://www.featureteamprimer.org/" target="_blank">(2)</a> </p></blockquote><p>Der Scrum-Guide spricht explizit nur von Entwicklern, egal welche Rolle sie im Development-Team einnehmen. Trotzdem erkennen die Autoren an, dass es in einem Team Spezialisierungen geben kann, wobei die Verantwortung für die Entwicklung aller Teile immer beim gesamten Team verbleibt:</p><blockquote><p>“Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”  <a href="http://www.scrumguides.org/scrum-guide.html" target="_blank">(1)</a> </p></blockquote><h2>Das Komponenten-Feature-Team</h2><p>Schauen wir einem imaginären Project Manager über die Schulter, wie er ein Entwickler-Team für den oben genannten Technologie-Stack zusammengestellt hat:</p><ul><li>2 Tester, da das Team wenig Erfahrung in Testautomatisierung hat.</li><li>1 UX / UI-Experte, verantwortlich für Design und Implementierung der Oberfläche.</li><li>1 PhoneGap-Entwickler.</li><li>1 JS-Entwickler, für AngularJS und Node.js.</li><li>2 Java-Entwickler, verantwortlich für die Middleware-Komponenten.</li><li>1 Entwickler für die XML-basierte Messaging-Sprache.</li><li>1 Oracle Datenbank-Spezialist.</li></ul><p>Das Ergebnis ist ernüchternd. Um ein Feature-Team zu bilden, das alle Bereiche der Entwicklung abdecken kann, haben wir für die meisten Bereiche nur einen Entwickler.</p><p>Die negativen Folgen liegen auf der Hand: Es bilden sich Wissenssilos, Code-Reviews und Pair-Programming sind deutlich erschwert. Der Abgang eines Entwicklers kann das gesamte Projekt in Schieflage bringen. Die andere Seite ist, dass es einen deutlichen Overhead in der Planung gibt. <strong>Der eindimensionale Velocity-Wert ist zur Planung nicht mehr ausreichend.</strong> Das Commitment des Teams wird es nur geben, wenn es in keinem der Technologie-Bereiche einen Engpass gibt. Damit bleiben Product Owner und Entwickler während der Planung zwangsweise im alten Komponentendenken hängen. Es kann passieren, dass der Product Owner die User Stories wieder mehr als Komponenten-Stories schreibt, da diese scheinbar einfacher zu planen sind. Durch die Fokussierung auf Komponenten wird aber gegen zwei wichtige <a href="https://en.wikipedia.org/wiki/INVEST_(mnemonic)" target="_blank">INVEST</a> -Faktoren verstoßen – die Stories sind nicht mehr unabhängig voneinander und sie liefern alleine keinerlei Wert für den Kunden. Aus agiler Sicht ist diese Lösung daher eine der schlechtesten.</p><h2>Lösungsansätze</h2><h3><h3>1) Mehr Flexibilität der Entwickler</h3><p>Die häufigste Antwort auf das geschilderte Problem ist, dass sich die Entwickler weiterbilden sollen und werden. Der Java-Entwickler lernt JavaScript und der Datenbank-Entwickler wird zum Teilzeit-Java-Entwickler. Der <em>Feature Team Primer</em> spricht davon, dass die Teams zum Lernen gezwungen werden.</p><blockquote><p>A feature team organization exploits speed benefits from specialization, as long as requirements map to the skills of the teams. But when requirements do not map to the skills of the teams, learning is ‘forced,’ breaking the overspecialization constraint. Feature teams balance specialization and flexibility. <a href="http://www.featureteamprimer.org/" target="_blank">(2)</a> </p></blockquote><p>Aus meiner Erfahrung funktioniert dies in vielen Fällen nicht. Wie weiter oben bereits erwähnt, sind der Wille und die Fähigkeit zum Lernen begrenzt. Die Einführung von agilen Feature-Teams beinhaltet schon viel Neues. Auch für Entwickler, die schon länger mit agilen Methoden arbeiten, gibt es – ganz im Sinne von Continuous Improvement – immer noch vieles zu lernen und zu verbessern. Wenn Sie wählen müssten, ob ein Kollege agiles Vorgehen wie Test-Driven-Development verbessert, oder ob er ein mittelmäßiger Teilzeit-Frontend-Entwickler wird. Nun ja…</p><p>Eine gewisse Spezialisierung ist hilfreich, damit sich Expertentum bilden kann. Nur Experten werden in ihrem Bereich sehr gute Lösungen finden und implementieren können. Nur Experten werden Verantwortung für zukunftsfähige Lösungen in ihrem Bereich übernehmen.</p><p>Fazit: Die Flexibilitätssteigerung ist erstrebenswert, aber sie kann nur für solche Teams eine Lösung sein, die schon länger agil entwickeln und in denen es eine sehr hohe Lernbereitschaft gibt.</p><h3>2) Komponenten-Teams</h3><p>Eine Möglichkeit, die Komplexität und Anzahl der Technologien zu reduzieren ist Komponenten-Teams einzuführen. Anstatt eines gibt es zwei Entwicklungsteams, die zum Beispiel Frontend und Backend-Technologie untereinander aufgeteilt haben. Es gibt Vorteile: Die Scrum-Meetings sind fokussierter. Die Zusammenarbeit im Team wird erleichtert, die Verantwortung für die entwickelten Komponenten wächst. Die Teamaufteilung ist in vielen Unternehmen näher an der klassischen (gewohnten) Organisation.</p><p>Die Nachteile aber sind vielfältig:</p><ul><li>Dadurch, dass keine User Stories, sondern Komponenten-Stories bearbeitet werden, steigt der Planungsoverhead. Es müssten Integrationsphasen und daraus entstehende Rückläufer eingeplant werden.</li><li>Das Risiko von <a href="https://de.wikipedia.org/wiki/Muda" target="_blank">unnötigem Aufwand</a>  steigt: Komponenten werden „auf Halde“ erweitert, ohne zu wissen, ob darauf aufbauende Features von anderen Teams jemals umgesetzt werden.</li><li>Durch falsch verstandene Schnittstellen können leicht Bugs entstehen.</li><li>Komponententeams können weniger Feedback zu Produktdesign und Implementierungsmöglichkeiten geben. Das <em>Warum</em> geht verloren, wenn Teams detaillierte technische Komponentenstories als Input erhalten.</li><li>Nicht-funktionale Anforderungen sind schwieriger einzuhalten, da die Verantwortlichkeit dafür diffundiert.</li><li>Es ist schwieriger Tester schon während der Entwicklung einzubeziehen.</li></ul><p>Fazit: „It depends“ – Komponenten-Teams können in bestimmten Umgebungen Vorteile bieten, doch haben sie gegenüber Feature-Teams in der agilen Entwicklung insgesamt eine erhebliche Anzahl an Nachteilen. Lassen sich Komponententeams nicht vermeiden, so können einige der Nachteile durch überlappende Plannungsmeetings und automatisiertes Contract-Testing abmildern.</p><h3>3) Größere Teams</h3><p>Ein naheliegender Ansatz ist es, das Team zu vergrößern. Der Vorteil dieser Lösung ist die sehr einfache Umsetzung. Bereiche mit dem<a href="https://de.wikipedia.org/wiki/Truck_Number" target="_blank"> Bus-Faktor </a> von 1 können sehr schnell personell verstärkt werden. Ich habe schon Scrum-Teams mit 16 Entwicklern gesehen.</p><p>Es gibt allerdings auch hier einige Nachteile. Erstens wird die Aufteilung in gefühlte Komponententeams innerhalb des Scrum-Teams noch zunehmen. Der zweite Nachteil nennt bereits der oben zitierte Scrum-Guide: Der Aufwand für Kommunikation und Koordination im Team nimmt stark zu. Möchte man, dass alle Teammitglieder täglich ein paar Worte direkt miteinander wechseln, sind in einem 8-köpfigen Team 28 Gespräche nötig. Bei 16 Personen müssten täglich schon 120 Gespräche geführt werden. Durch die Größe des Teams steigt auch die Velocity stark an. Klingt erst mal gut. Doch bei zu vielen User Stories in einem Sprint wird es schwierig den Fokus zu behalten. Die täglichen Standup-Meetings, wie auch Planung und Demo, dauern zu lang. Schnell passiert es dann, dass Entwickler nicht mehr aktiv teilnehmen, da der Nutzen im Vergleich zum Aufwand infrage gestellt wird.</p><p>Fazit: Die Vergrößerung des Teams scheint eine schnelle Lösung sein, um ein Wissenssilo oder einen Engpass abzubauen. Komponentengrenzen können so aber nicht aufgelöst werden. Langfristig überwiegen auch hier die negativen Folgen.</p><h3>4) Reduktion der Technologien</h3><p>Ein weiterer möglicher Lösungsansatz ist es die Anzahl der verwendeten Technologien zu reduzieren. Man würde sich wünschen, dass für jede neue Technologie mindestens eine alte aus dem Projekt entfernt wird. Wie in einem guten Bücherregal, aus dem man für jedes neue Buch auch eines herausnehmen muss – und so für eine stetige Qualitätssicherung und Perfektionierung sorgt. In der Praxis geschieht diese Technologie-Reduktion leider aus unterschiedlichsten Gründen oft nicht. Dabei sollten die hier zuvor genannten Probleme und Herausforderungen deutlich machen, dass es nicht unbedingt sinnvoll ist, neue Technologien einzuführen, wenn man alte dafür nicht ablösen kann.</p><p>Ist es nicht möglich, die Anzahl der Technologien im Projekt zu reduzieren, kann eine andere Strategie helfen. Im DDD gibt es das Konzept der Anti-Corruption-Layer (ACL), die verhindern, dass das eigene Domänenmodell durch unsaubere externe Schnittstellen verschmutzt wird. Durch ein technologisches ACL kann man eine Legacy-Technologie vor einem Entwicklungs-Team verbergen. Ob es die moderne REST-Fassade vor einem alten Hostsystem ist, oder die moderne Messaging-Technologie als Adapter zu einem alten selbstentwickelten System. Auf diese Weise können Komplexitäten verringert werden.</p><p>Fazit: Die Reduktion der verwendeten Technologien ist die nachhaltigste, aber auch die am schwierigsten umzusetzende Lösung. Beim Starten agiler Projekte sollte darauf geachtet werden, nicht leichtfertig neue Technologien einzuführen, wenn dafür nicht auch alte entfernt werden können. Frameworks wie Vaadin könnten dabei helfen, Barrieren zwischen Frontend- und Backend-Entwicklern zu verringern. Andere <a href="https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/" target="_blank">Firmen</a>  haben sich für Node.js im Frontend- und Backend entschieden, um einen homogeneren Technology-Stack zu haben. In einer heterogenen Umgebung können Legacy-Technologien durch technologische ACL verborgen werden.</p><p>Zusammengefasst: Ein heterogener Technologiestack stellt jedes Entwicklungsteam vor eine Herausforderung. Eine Flexibilitätssteigerung des Entwicklungsteams ist erstrebenswert. Notwendig ist, dass sich für jede Technologie neben dem/der Experten/in weitere Entwickler Basiswissen erarbeiten. Langfristig wird es sich auszahlen, die Anzahl der Technologien zu reduzieren.</p><p> </p><p><em>Keine der oben genannten Lösungsansätze ist einfach oder kommt ohne Nachteile aus. Gerne stelle ich daher die Frage nach weiteren Strategien und Lösungen an die Leser: Kennt ihr die beschriebene Problematik und habt ihr weitere Ideen zur Verbesserung? Ich freue mich über eure Kommentare.</em></p></h3>

Spezialisierung in Agilen Feature-Teams

<p>Der Herr, der eben beim Auspacken seines Laptops beinahe meinen Kaffeebecher umgestoßen hat, schaut kurz auf meinen Bildschirm und sieht den geöffneten Hystrix-Vortrag. Ja, von Hystrix hat er schon einmal gehört, hat sein Team ihm vorgeschlagen, soll gut funktionieren. Doch dann holt er Luft für sein großes Aber: “Warum sollte ich meinen Entwicklern Zeit dafür geben ein Framework einzuführen, das ihnen hilft auf Ausfälle und Fehler zu reagieren? Ich möchte, dass sie in der Zeit stattdessen verhindern, dass diese Fehler überhaupt auftreten”.</p><p><span></span></p><p><span>Ich vermute, dass ich wohl erst nach Göttingen an dem Vortrag weiter arbeiten kann, klappe den Rechner zu und beginne zu erzählen: In komplexen verteilten Systemen sind Ausfälle und Fehler immanent; Systeme, die nicht fehlertolerant sind, werden keine zufriedenstellende User-Experience bieten können. Der Einsatz von Hystrix sensibilisiert Entwickler beim Einbinden von externen Diensten über den möglichen Einfluss auf das eigene System nachzudenken.</span></p><p><span>In verteilten Systemen addieren sich die Ausfallzeiten: Angenommen das Team meines Sitznachbarn schafft es, dass jeder Service zu 99,99% erreichbar ist, also deutlich unter 5 Minuten Downtime pro Monat hat. Wenn man dann weiter annimmt, dass ihre Microservice-Architektur aus 30 unabhängigen Services besteht, dann werden nur noch zu 99,7% der Zeit alle Services verfügbar sein – oder anders gesagt: Fast zweieinviertel Stunden pro Monat, ist nicht das komplette System verfügbar. Sind die Services nicht verfügbar oder fehlerhaft, sind die Kunden unzufrieden und man verdient kein Geld mit ihnen – kurzum: die Software ist wertlos.</span></p><p><span>Die oben skizzierte Erkenntnis führt zu dem Mantra der Resilience-Bewegung: </span><i><span>“Do not try to avoid failures. Embrace them”. </span></i><span>Wer mehr Details über die Grundlagen von Resilience und Resilient Software Design erfahren möchte, sei auf die gute<a href="https://jaxenter.de/unkaputtbar-einfuehrung-resilient-software-design-15119"> Resilience-Einführung</a>  oder den Talk über <a href="https://www.youtube.com/watch?v=T9MPDmw6MNI">Resilience-Patterns </a> von Uwe Friedrichsen verwiesen.</span></p><p><span>Wir wollen also mit den Fehlern umgehen, anstatt zu versuchen, sie zu vermeiden. Eine Technologie um diese sogenannte Resiliance zu erreichen ist Hystrix, ein Java-Framework aus dem Netflix Open Source Stack. Die Entkopplung einzelner Services in verteilten Systemen ist die Kernaufgabe von Hystrix; und damit der Aufbau eines robusten und fehlertoleranten Systems.</span></p><h2>Die wichtigsten Eigenschaften von Hystrix</h2><p><a href="https://media.graphassets.com/tU7LoSipQMCut1NKMWOL"><img src="https://media.graphassets.com/tU7LoSipQMCut1NKMWOL" alt="hystrix-features" width="700" height="334" /></a> </p><p> </p><ul><li><span>Alle Aufrufe von externen Systemen werden in HystrixCommands verpackt, welche typischerweise in einem separaten Thread ausgeführt werden.</span></li><li><span>Aufrufe werden abgebrochen, wenn sie mehr Zeit brauchen als vorab als Obergrenze festgelegt wurde. Es muss also z.B. nicht mehr auf Netzwerk- oder Datenbank-Timeouts gewartet werden, bis eine Programmausführung fortgesetzt werden kann.</span></li><li><span>Für jede externe Abhängigkeit wird ein eigener kleiner Thread-Pool verwaltet. Damit wird verhindert, dass eine einzelne fehlerhafte Abhängigkeit ein ganzes System non-responsive machen kann.</span></li><li>Die Ausführungszeiten, Erfolge und Fehler eines jeden HystrixCommands werden gemessen, erfasst und in einem Dashboard zur Verfügung gestellt.</li><li><span>Ein circuit-breaker stoppt alle Aufrufe einer externen Abhängigkeit, die derzeit nicht erreichbar oder fehlerhaft ist. </span></li><li><span>Es können Fallback-Logiken implementiert werden, für den Fall, dass externe Abhängigkeiten keine oder fehlerhafte Antworten liefern.</span></li></ul><h2>Hello World mit Hystrix</h2><p>Nach der Einführung in die grundlegenden Konzepte von Hystrix wird es Zeit für ein Beispiel:</p><div>

```java
public class CommandHelloWorld extends HystrixCommand {
 
   private final String name;
 
   public CommandHelloWorld(String name) {
     super(HystrixCommandGroupKey.Factory.asKey("ExampleGroup"));
     this.name = name;
    }
 
   @Override
   protected String run() {
     //network call
     return getLocalizedGreeting(name);
    }
 
   @Override
   protected String getFallback() {
     //graceful degradation - use english as fallback
     return "Hello " + name + "!";
    }
 
    [...]
 }
```

</div><p>Der obige Code zeigt ein einfaches HystrixCommand, das versucht eine entferne Ressource aufzurufen um eine Begrüßung in der Sprache des Nutzers abzurufen. Sollte der Aufruf fehlschlagen, so wird als Fallback eine englische Begrüßung ausgegeben. Ein HystrixCommand kann synchron, asynchron oder mit dem Observer-Pattern ausgeführt werden:</p><p>1) Synchrone Ausführung</p><div>

```java
 String s = new CommandHelloWorld("World").execute();
```

</div><p>2) Asynchrone Ausführung</p><div>

```java
 Future fs = new CommandHelloWorld("World").queue();
 String s = fs.get();
```

</div><p>3) Observer-Pattern</p><div>

```java
 Observable fWorld = new CommandHelloWorld("World").observe();
 fWorld.subscribe((v) -> {
   System.out.println("onNext: " + v);
 })
```

</div><p>Die Wiki-Dokumentation des Hystrix-Projektes ist umfangreich und gut verständlich. Daher verzichte an dieser Stelle auf weitere Einstiegsbeispiele und verweise stattdessen auf <a href="https://github.com/Netflix/Hystrix/wiki/How-To-Use">das originale Tutorial bei GitHub.</a> </p><h2>Konfiguration und Metriken</h2><p><span>Hystrix ist schnell eingebaut, aber es gibt doch eine gewisse Lernkurve, die man einplanen sollte. Zum Beispiel für die Konfiguration: Die Möglichkeiten der Konfiguration sind umfangreich. Der Ansatz von Netflix ist es, die Kommandos in der Standardkonfiguration zu starten und dann im Betrieb zu messen, beobachten und feinzujustieren. Dafür braucht man zwingend dynamische Konfiguration und jemanden, der das Hystrix-Dashboard im Auge behält.</span></p><p><span>Auch langfristig sollte man die Metriken von Hystrix überwachen und die sehr umfangreichen Informationen nicht ungenutzt lassen. So kann man zum Beispiel die Hystrix Streams, bzw. deren aggregierte Informationen, in Elasticsearch speichern und langfristig aus den Metriken lernen</span></p><h2>Neues und Ausblick auf Hystrix 2.0</h2><p><span>Das aktuelle Hystrix-Release 1.5 beinhaltet Erweiterungen im Bereich der Metriken. Die Metric-Streams werden nun auch unaggregiert angeboten und können dadurch deutlich flexibler konsumiert und ausgewertet werden. Die HystrixCommands unterstützen seit Version 1.5.3 nun außerdem die Cancellation, so dass dem ausführenden Thread ein interrupt-Signal gesendet wird, wenn auf dem Future ein cancel() aufgerufen wird oder ein unsubscribe() auf der Subscription.</span></p><p><span>Für Hystrix 2.0 ist das Update auf Java 8 geplant – das wird die Verwendung von Hystrix deutlich kompakter machen.</span></p><h2>Fazit</h2><p>Es wurde erläutert warum in verteilten Systemen immer mit dem Ausfall von Resourcen gerechnet werden muss und wie die Funktionen von Hystrix dabei helfen ein Resilient-Software-Design zu erreichen.  Dieser Artikel ist ein kurzer Einstieg in das Thema und ist der Auftakt einer mehrteiligen Blogartikel-Serie zum Thema Hystrix in der verschiedene codecentric-Kollegen ihr Praxiswissen zum Thema teilen werden. Im nächsten Teil wird unter anderem das Thema dynamische Konfiguration von Hystrix beleuchtet werden.</p>

Hystrix: Fehlertoleranz statt Hochverfügbarkeit – Eine Einführung in Resilience mit Hystrix

<p>„Software-Entwicklung muss nicht wehtun“, sagt Nils Wloka in der ersten Folge von #EineMateMit, dem neuen IT-Talk-Format der codecentric. Wo es zuweilen schmerzte, und wie er dies abstellen möchte, erläutert der Kopf des codecentric Digitization Labs nach einem kurzen Schluck aus der Mate-Flasche. „Ich denke, dass es inzwischen sehr viele Schichten gibt, zwischen den Menschen, die Probleme mit Software lösen lassen wollen und den Menschen, die Probleme mit Software lösen können.“ Die meisten dieser Schichten und viele der deswegen notwendigen Rituale könne man entfernen, und so wieder „zu einer angenehmeren und effektiveren Art und Weise der Software-Entwicklung kommen“.</p><p><span></span></p><p> </p>
<a href="https://www.youtube.com/watch?v=heLtAebYugQ" target="_blank"><img src="https://media.graphassets.com/YwhNYeKIS6S4DIfGRUqZ" alt="YouTube" />
zum Video "Digitalisierung und Rapid-Prototyping | Eine Mate mit Nils Wloka #EineMateMit"</a>
<div></div>
<br>



<p><em>Eine Mate Mit </em>ist ein Format, in dem verschiedenste Menschen aus der IT-Branche aus ihren Projekten, und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei der codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Die Gemeinsamkeit der Interviews: <strong>Kurz, knackig, auf den Punkt</strong>.</p><h3>5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p><em>Eine Mate Mit</em> möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links, direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p> </p><p>Wir freuen uns auf eure Kommentare hier im Blog auf Twitter unter #EineMateMit oder auf youtube. Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen. Jeweils hier auf dem codecentric Blog und auf youtube.</p><p><img src="https://media.graphassets.com/2LLzp22LTSGB5bZYUUVw"> </p><p> </p><p>Weiterführende Links für die heutige Folge mit Nils Wloka:</p><p><a href="https://www.codecentric.de/leistungen/digitale-produktentwicklung">Die codecentric Digitization Labs</a>  bieten die Möglichkeit, digitale Produktideen<br /> unmittelbar mittels Software zu validieren.</p><p><a href="https://www.codecentric.de/wissens-hub/softwerker#softwerker-magazine">Der Digitalisierungs-Softwerker</a>  bietet einen guten Einblick in die Herausforderungen der Digitalisierung; auch und gerade für nicht-Entwickler.</p><p><a href="https://youtu.be/heLtAebYugQ">Und hier noch mal der Link auf das heutige #EineMateMit-Video mit Nils Wloka</a> </p><p> </p><p> </p>

Rapid-Prototyping und Digitization Labs. Eine Mate mit… Nils Wloka.

<p>„Die Software läuft halt einfach“, sagt Dieter Dirkes sichtlich zufrieden, als er über sein letztes großes Keycloak-Projekt erzählt. Dieses Projekt ist seit einem Jahr im Einsatz und bietet verteilt über 26 Länder Single-Sign-On (SSO), Idendentiy- und Access-Management. „Innerhalb von 2 Tagen hatten wir den ersten technischen Durchstich fertig“, sagt Dirkes, der Leiter des Münsteraner Standorts der codecentric AG. Eine technische Einordnung von SSO mit Keycloak, die Highlights und auch die Probleme, die in den Projekten entstanden sind, erzählt Dieter Dirkes in dieser Ausgabe von Eine Mate Mit.  #EineMateMit.</p><p><span></span></p><h2>Über Keycloak</h2><p>Komfortables Single Sign-On in einer professionellen Identity- und Accessmanagement (IAM) Umgebung – und das auch noch Open Source? Keycloak als OpenID Connect Provider macht’s möglich. Keycloak wird von Red Hat entwickelt und gefördert. Das Produkt ist komplett in Java geschrieben und bedient sich sehr ausgiebig an Red Hats Java Stack. So wird standardmässig WildFly als Applicationserver eingesetzt, und auch die Clustering- und HA-Funktionen von WildFly werden genutzt.</p><p> </p>


<a href="https://www.youtube.com/watch?v=YRoEtEjya5U" target="_blank"><img src="https://media.graphassets.com/GfCV9ZySSi2CyPdMe4TM" alt="YouTube" />
zum Video "Was ist Keycloak? | Eine Mate mit Dieter Dirkes #EineMateMit"</a>
<div></div>
<br>

<p> </p><p><em>Eine Mate Mit </em>ist ein Format, in dem verschiedenste Menschen aus der IT-Branche aus ihren Projekten und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei der codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Die Gemeinsamkeit der Interviews: <strong>Kurz, knackig, auf den Punkt</strong>.</p><h3>#EineMateMit – 5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p><em>Eine Mate Mit</em> möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p>Wir freuen uns auf eure Kommentare hier im Blog, auf Twitter unter #EineMateMit oder auf youtube. Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen. Jeweils hier auf dem codecentric Blog und auf youtube.</p><p><img src="https://media.graphassets.com/2LLzp22LTSGB5bZYUUVw"> </p><p>Weiterführende Links für die heutige Folge mit Dieter Dirkes:</p><p>Die Projektseiten befinden sich unter <a href="http://keycloak.jboss.org/" target="_blank">http://keycloak.jboss.org</a> , die Sourcen sind in GitHub unter <a href="https://github.com/keycloak/keycloak" target="_blank">https://github.com/keycloak/keycloak</a>  zu finden. Lead-Entwickler sind im wesentlichen Stian Thorgersen, Bill Burke und Marek Posolda.</p>

Was ist Keycloak? Eine Mate mit… Dieter Dirkes zum Thema SSO #EineMateMit

<p>„Aufgrund der gestiegenen Rechen- und Speicherkapazitäten sind in den letzten Jahren ganz neue Möglichkeiten entstanden“, sagt Michael Plümacher, Data Scientist bei der codecentric. Einige seiner aktuellen Data-Science- und Big Data-Projekte stellt er in der neuen Folge EineMateMit kurz vor: von Vorschlags-Systemen bis zu automatisierter Analyse von Dokumenten-Scans. Michael erzählt außerdem, welche Tools er meistens einsetzt und in welchem Kundenprojekt er mit seinen Data-Science-Ansätzen an die Grenzen gestoßen ist.</p><p></p>

<a href="https://www.youtube.com/watch?v=u2w0y8piHHo" target="_blank"><img src="https://media.graphassets.com/jbaUDHjUTPqqOC0ZWwCl" alt="YouTube" />
zum Video "Data Science und Big Data | Eine Mate mit Michael Plümacher #EineMateMit"</a>
<div></div>
<br>
<p><em>Eine Mate Mit </em>ist ein Format, in dem verschiedenste Menschen aus der IT-Branche aus ihren Projekten und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei der codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Die Gemeinsamkeit der Interviews: <strong>kurz, knackig, auf den Punkt</strong>.</p><h3>#EineMateMit – 5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p><em>Eine Mate Mit</em> möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p>Wir freuen uns auf eure Kommentare hier im Blog, auf Twitter unter #EineMateMit oder auf YouTube. Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen. Jeweils hier auf dem codecentric-Blog und auf YouTube.</p><p> </p><p><img src="https://media.graphassets.com/2LLzp22LTSGB5bZYUUVw"> </p><p> </p><h2>Mehr zu Data Science und Big Data</h2><p>Diese Blogposts geben noch mehr Hintergrund zu aktuellen Data-Science- und Big-Data-Projekten der codecentric:</p><p><a href="/wissens-hub/blog/fraud-analyse-mit-data-science-techniken">Fraud-Analyse mit Data-Science-Techniken von Shirin Glander</a> </p><p><a href="/wissens-hub/blog/verteilte-stream-processing-frameworks-fuer-fast-data-big-data-ein-meer-moeglichkeiten">Verteilte Stream Processing Frameworks für Fast Data & Big Data – Ein Meer an Möglichkeiten</a> </p><p> </p><p></p>

Data Science und Big Data: Eine Mate mit… Michael Plümacher #EineMateMit

<p>„Das Schöne ist, dass es eine klar definierte Schnittstelle zwischen Operations und Entwicklern gibt“, sagt Roland Huß, als er im Vorfeld des <a href="https://www.meetup.com/de-DE/DevOps-Frankfurt/events/241112360/" target="_blank">DevOps Meetups „Java-Entwicklung im Zeitalter von Kubernetes und OpenShift“</a>  über die Vorteile von Container-Lösungen für DevOps-Projekte spricht.</p><p>„Ich versuche heute zu zeigen, warum es auch für Java-Entwickler sinnvoll ist und auch Spaß machen kann, Applikationen mit Kubernetes zu deployen“, erzählt Roland Huß über seinen Vortrag.</p><p>Viele sprächen von einem neuem IT-Zeitalter bei dem Anwendungen in Container verpackt und von Orchestrierungsplattformen wie Kubernetes oder OpenShift skalierbar betrieben werden. „Tatsächlich spricht vieles dafür, dass wir unsere Java-Anwendungen künftig nicht mehr als JAR, WAR oder EAR Artefakte ausliefern werden sondern als Docker Container Images.“, so Huß. „Mein Vortrag zeigt wie dieser Übergang schmerzfrei vollzogen werden kann. Tools wie <em>minikube</em> oder <em>minishift</em> zeigen wie einfach es ist, komplexe Plattformen wie Kubernetes oder OpenShift mit einem einzigen Kommando zu installieren. Um ein bestehendes Projekt auf diese Umgebungen umzustellen helfen Werkzeuge wie das fabric8-maven-plugin.“</p><p><span></span></p><h2>Über Kubernetes und DevOps</h2><p>Kubernetes ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen. Es unterstützt Docker und andere Container-Tools. Kubernetes eignet sich hervorragend um Microservice-Anwendungen verteilt über mehrere Server auszuführen, und die Server-Ressourcen dabei optimal auszunutzen.</p><p>OpenShift bezeichnet sich als „enterprise-ready“ Container Application Platform, da es zu Docker und Kubernetes noch verschiedene DevOps-Tools und Support-Möglichkeiten hinzufügt.</p><p>Es gibt viele DevOps-Definitionen… Im Kern geht es darum, die Prozesse so zu verbessern, dass Betrieb und Entwicklung besser zusammenarbeiten können.</p>
<a href="https://www.youtube.com/watch?v=IO130Zb_vDA&t=13s" target="_blank"><img src="https://media.graphassets.com/EruwaGUET3qhwnEVlQC1" alt="YouTube" />
zum Video "DevOps und Container | Eine Mate mit Roland Huß #EineMateMit"</a>
<div></div>
<br>
<p> </p><p><em>Eine Mate Mit </em>ist ein Format, in dem Menschen aus der IT-Branche aus ihren Projekten und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Was alle Interviews verbindet: <strong>Kurz, knackig, auf den Punkt</strong>.</p><h3>#EineMateMit – 5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p><em>Eine Mate Mit</em> möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p>Wir freuen uns auf eure Kommentare hier im Blog, auf YouTube oder auf Twitter unter #EineMateMit. Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen. Jeweils hier auf dem codecentric Blog und auf YouTube.</p>
<img src="https://media.graphassets.com/2LLzp22LTSGB5bZYUUVw">
<p> </p><p>Weiterführende Links für die heutige Folge mit Roland Huß:</p><p>Kubernetes: <a href="https://kubernetes.io/" target="_blank">https://kubernetes.io/</a> </p><p>Open Shift: <a href="https://www.openshift.com/" target="_blank">https://www.openshift.com/</a> </p><p>Seite des DevOps-meetups: <a href="https://www.meetup.com/de-DE/DevOps-Frankfurt/events/241112360/" target="_blank">https://www.meetup.com/de-DE/DevOps-Frankfurt/events/241112360/</a> </p><p>fabric8: <a href="https://fabric8.io/" target="_blank">https://fabric8.io/</a> </p><p>Geschichte der Containerisierung (für Frachtgüter): <a href="https://de.wikipedia.org/wiki/Containertransport#Geschichte" target="_blank">https://de.wikipedia.org/wiki/Containertransport#Geschichte</a> </p><p> </p>

DevOps und Container: Eine Mate mit… Roland Huss. #EineMateMit

<p>„Da hab‘ ich gewusst, ich will User Story Mapping ab jetzt in jedem Projekt nutzen“, sagt Hias Wrba, als er davon erzählt, wie er das erste Mal die Methode „User Story Mapping“ nach Jeff Patton angewendet hat.</p><p>Mathias „Hias” Wrba arbeitet seit nunmehr fast 15 Jahren als quereingestiegener User-Experience-Stratege und -Designer im Bereich digitale Medien. Seine Schwerpunkte sind Research-getriebene Strategie- und Produktentwicklung in agilen Kontexten. Er leitet seit 2018 gemeinsam mit Bernd Feldmayer den Münchner Standort der <a href="https://uxi.de/">UX&I</a>  GmbH.</p><p>Für Hias ist User Story Mapping ein Tool, um das Gesamtsystem eines Software-Projektes auf eine verständliche Art zu beschreiben, wie auch um leichter sinnvolle Priorisierungen vornehmen zu können. <strong>„Das eigentliche Product Backlog in Scrum ist so wenig Produkt und eigentlich nur eine Sammlung von Stories“</strong>, so Wrba. „Und mit User Story Mapping bekommt man dann plötzlich den Kontext und den Überblick.“</p><h2>User Story Mapping und Quick Personas</h2><p>Hias, der als Gastdozent am artop–Institut das Vorgehensmodell UX Thinking schult, erzählt in dieser Folge von „Eine Mate mit“ außerdem von Quick Personas und auch ganz offen von den Fehlern, die ihm bei der Umsetzung von Projekten unterlaufen sind.</p>

<a href="https://www.youtube.com/watch?v=-LlUw_2GWbI" target="_blank"><img src="https://media.graphassets.com/zaOg3OzDRd25JEmICoZC" alt="YouTube" />
zum Video "Was ist User Story Mapping? | Eine Mate mit Hias Wrba #EineMateMit"</a>
<div></div>
<br>


<p> </p><p>Eine Mate mit ist ein Format, in dem verschiedenste Menschen aus der IT-Branche aus ihren Projekten und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Die Gemeinsamkeit der Interviews: kurz, knackig, auf den Punkt.</p><h3>#EineMateMit – 5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p>Eine Mate mit möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p>Wir freuen uns auf eure Kommentare im Blog, auf <a href="https://twitter.com/codecentric">Twitter</a>  unter #EineMateMit oder auf auf <a href="https://www.youtube.com/user/codecentricAG">YouTube</a> . Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen.</p><div><img src="https://media.graphassets.com/2LLzp22LTSGB5bZYUUVw">
 <p>Eine Mate Mit – User Story Mapping</p></div><p>Weiterführende Links zur heutigen Folge zum Thema User Story Mapping mit Hias Wrba:</p><p><a href="https://jpattonassociates.com/user-story-mapping/">User Story Mapping</a> </p><p><a href="https://www.uxpin.com/studio/blog/ux-designers-5-minute-guide-lean-personas/">Lean / Quick Personas</a> </p><p> </p>

Was ist User Story Mapping? Eine Mate mit Hias Wrba #EineMateMit

<p>„Es geht nicht darum, sich als Entwickler-Rockstar zu fühlen, der noch das letzte Prozent Perfektion herausholt, sondern gemeinsam, für alle Entwickler, die Software-Entwicklung zu verbessern“, sagt Benedikt Ritter im Gespräch über Software Crafting bzw. Software Craftsmanship. Benedikt arbeitet seit September 2013 als Software Craftsman bei der codecentric, er ist Member der Apache Software Foundation und Committer beim Apache Commons Projekt. „Software Crafting hat zwei Aspekte“, sagt Benedikt, „auf der einen Seite geht es um die Verbesserung der Software-Entwicklung. Also ‚Wie‘ Software entwickelt wird; auf der anderen Seite geht es um die Professionalisierung des Umgangs miteinander.“</p><p><span></span></p><h2>Software Crafting oder Software Craftmanship?</h2><p>Derzeit sieht man beide Begriffe Software Crafting und Software Craftsmanship. Im Interview, welches wir dieses Mal in der Lobby des neuen codecentric-Gebäudes in Solingen geführt haben, erklärt Benedikt, wie es dazu kommt und welcher Begriff in Zukunft wahrscheinlich mehr zu sehen sein wird. Außerdem geht es um den Sinn einer Software-Crafter- oder Software-Craftsmanship-Zertifizierung und welches die ersten Schritte sein könnten, wenn man sich auch Software Crafter nennen möchte. Und dann zählt Benedikt auch noch ganz handfest die Vorgehensweisen auf, die aus seiner Sicht, am meisten dazu beitragen, besser Software zu entwickeln.</p><p> </p>

<a href="https://www.youtube.com/watch?v=IgsCeabDn5g" target="_blank"><img src="https://media.graphassets.com/i7LOQleOR02pAv15td73" alt="YouTube" />
zum Video "Was ist Software-Craftsmanship/-Crafting? | Eine Mate mit Benedikt Ritter #EineMateMit"</a>
<div></div>
<br>

<p> </p><p><em>Eine Mate Mit </em>ist ein Format, in dem verschiedenste Menschen aus der IT-Branche aus ihren Projekten und von ihren Erfahrungen erzählen. Ob Speaker auf einem bei der codecentric gehosteten Meetup, ob Kollegen, ob Konferenz-Dauergäste oder das Arbeitstier aus dem letzten Projekt. Die Gemeinsamkeit der Interviews: <strong>Kurz, knackig, auf den Punkt</strong>.</p><h3>#EineMateMit – 5 Minuten, 5 Fragen: IT-Wissen kurz und erfrischend</h3><p><em>Eine Mate Mit</em> möchte Interesse wecken, an Themen und Menschen. Und wer sich danach weiter mit dem Thema beschäftigen möchte, findet weiterführende Links direkt am Ende des Videos und im jeweils zugehörigen Blog-Artikel.</p><p>Wir freuen uns auf eure Kommentare hier im Blog, auf Twitter unter #EineMateMit oder auf youtube. Sagt uns eure Meinung zu dem Format, wünscht euch Themen und diskutiert mit. Wir werden in den nächsten Monaten regelmäßig neue Folgen veröffentlichen. Jeweils hier auf dem codecentric Blog und auf youtube.</p><p><img src="https://media.graphassets.com/2LLzp22LTSGB5bZYUUVw">
 </p><p>Weiterführende Links für die heutige Folge mit Benedikt Ritter:</p>
<p><a href="https://www.softwerkskammer.org/">https://www.softwerkskammer.org/</a></p>
<p><a href="http://softwarecrafters.org/">http://softwarecrafters.org/</a> </p>
<p><a href="https://www.socrates-conference.de/">https://www.socrates-conference.de/</a> </p>
<p><a href="https://www.amazon.de/Software-Craftsman-Professionalism-Pragmatism-Robert/dp/0134052501">https://www.amazon.de/Software-Craftsman-Professionalism-Pragmatism-Robert/dp/0134052501</a>
<p><a href="http://autoweird.fm">http://autoweird.fm</a> </p><p><a href="https://twitter.com/BenediktRitter">https://twitter.com/BenediktRitter</a> </p>

Was ist Software Crafting/Software Craftsmanship? Eine Mate mit Benedikt Ritter #EineMateMit.

Standortleitung Frankfurt

Server Actions wurden in Next.js 14 als neue Methode zum Senden von Daten an den Server eingeführt 
(siehe die [Dokumentation](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations)).
Es sind asynchrone Funktionen, die sowohl in Server-Komponenten, innerhalb von serverseitigen Forms, als auch in
Client-Komponenten verwendet werden können.
Während der Aufruf einer Server Action im Code als ein normaler Funktionsaufruf erscheint, wird er von Next.js als
POST-Request an den Server interpretiert.

In diesem Blogpost zeige ich anhand einfacher Beispiele, wie wir Server Actions verwenden können und was dabei zu
beachten ist.

## Server Actions: ein Beispiel

Als Beispiel dient eine einfache Webanwendung, mit der User angelegt und gesucht werden können.
Die Suche soll live anhand eines Suchtexts erfolgen, d.h. unsere Anwendung muss clientseitig auf Änderungen an der
Sucheingabe reagieren und die Daten vom Server laden.

Im Folgenden gehe ich nur auf die wichtigen Code-Stellen ein. Den gesamten Code der Beispielanwendung findet ihr
hier: https://github.com/LukasL97/nextjs-server-actions-example

### User anlegen und bearbeiten

Zum Anlegen und Bearbeiten von Usern definieren wir eine `UserPage`.
Diese wird zunächst serverseitig gerendert und lädt dabei den existierenden User direkt aus der
Datenbank, falls im URL-Pfad eine ID übergeben wurde. Dieser User wird dann an die `UserForm`-Komponente weitergegeben,
mit der der User bearbeitet werden kann, bzw. neu angelegt, falls keine ID übergeben wurde.

```tsx
// app/user/[[...id]]/page.tsx

import { getUserFromDb } from '@/app/db';
import { UserForm } from '@/app/components/UserForm';

export default async function UserPage({ params }: { params: { id?: string[] } }) {
  const id = params.id?.at(0);
  const user = id ? await getUserFromDb(id) : undefined;

  return <>
    <h1>User</h1>
    <UserForm user={user}/>
  </>;
}
```

Die Komponente `UserForm` ist wiederum eine Client-Komponente.* Sie enthält den `firstName` und `lastName` als States,
die
gesetzt werden, wenn wir in die entsprechenden Inputs schreiben. Beim Klick auf den Save-Button wird die Server
Action `saveUser` aufgerufen, die den `firstName`, `lastName` und ggf. noch die `id`, falls diese existiert, übergeben
bekommt. Daraufhin wird zurück zur Root URL navigiert.

```tsx
// app/components/UserForm.tsx

'use client';

import { useRouter } from 'next/navigation';
import { saveUser } from '@/app/actions/saveUser';
import { useState } from 'react';
import { User } from '@/app/user';

export function UserForm({ user }: { user: User | undefined }) {
  const id = user?.id;

  const [firstName, setFirstName] = useState(user?.firstName ?? '');
  const [lastName, setLastName] = useState(user?.lastName ?? '');

  const router = useRouter();

  return <>
    <div>
      <label>First Name</label>
      <input
        type="text"
        value={firstName}
        onChange={(e) => setFirstName(e.target.value)}
      />
    </div>
    <div>
      <label>Last Name</label>
      <input
        type="text"
        value={lastName}
        onChange={(e) => setLastName(e.target.value)}
      />
    </div>
    <button onClick={async () => {
      await saveUser({ id, firstName, lastName });
      router.push('/');
    }}>
      Save
    </button>
  </>;
}
```

Die Server Action `saveUser` ist eine einfache asynchrone Funktion. Wichtig ist, dass sie mit `'use server'` deklariert
wird, damit Next.js sie als Server Action identifizieren kann.
Die Server Action schreibt den übergebenen User in die Datenbank. Falls er noch keine ID hat (also ein neu
angelegter User ist), wird zunächst noch eine zufällige ID erzeugt. Schließlich wird noch der Cache
mittels `revalidatePath('/')` invalidiert. Dadurch stellen wir sicher, dass die Root Page beim nächsten Aufruf frisch
gerendert wird und die aktuellen User enthält.

```ts
// app/actions/saveUser.ts

'use server';

import { User } from '@/app/user';
import { randomUUID } from 'crypto';
import { putUserIntoDb } from '@/app/db';
import { revalidatePath } from 'next/cache';

export async function saveUser(user: User) {
  if (!user.id) {
    user.id = randomUUID();
  }
  await putUserIntoDb(user);
  revalidatePath('/');
}
```

Das Beispiel mit `saveUser` zeigt uns, wie wir Server Actions verwenden können, um Daten an den Server zu senden.
Im Vergleich zu [Route Handlers](https://nextjs.org/docs/app/building-your-application/routing/route-handlers) haben
Server Actions den Vorteil, dass sie Typsicherheit zur Compile-Zeit sicherstellen.
Während es bei Route Handlers z.B. schnell passieren kann, dass unser Request Body auf der Client-Seite nicht mit dem
erwarteten Body auf der Server-Seite übereinstimmt, wird das durch die statische Typisierung bei Server Actions zunächst
verhindert.

Wichtig zu erwähnen ist allerdings, dass Server Actions natürlich, genauso wie Route Handlers, unter der Haube
HTTP-Endpunkte sind. Das heißt, dass ein Nutzer, der über das Frontend auf die Anwendung Zugriff hat, auch Zugriff auf
den POST-Request hat, der bei Aufruf der Server Action an den Server gesendet wird, sowie auf die Response, die er vom
Server empfängt.
Dadurch ist er z.B. in der Lage, einen fehlerhaften Request Body an den Server zu schicken.
Besonders bei öffentlich verfügbaren Anwendungen ist daher in der Praxis doch eine
Eingabevalidierung auf Server-Seite notwendig, da auch TypeScripts statische Typisierung solche Situationen nicht
abfangen kann.
Genauso müssen natürlich Authentifizierung und Authorisierung in der Server Action geprüft werden.

### Suche von Usern

Wir haben gesehen, dass wir Server Actions verwenden können, um Daten an den Server zu senden.
Dadurch drängt sich natürlich die Frage auf, ob wir Server Actions auch verwenden können, um Daten vom Server zu lesen.
Tatsächlich ist das technisch möglich, da Server Actions auch eine Response an den Client zurückgeben können.
Ich möchte zunächst zeigen, wie wir eine Live-Suche mittels einer Server Action implementieren können und danach
erklären, warum das in der Praxis keine so gute Idee ist und wie man es besser macht.

Die `SearchPage` ist als serverseitige Komponente implementiert und lädt initial alle User direkt aus der Datenbank. Da
wir hier serverseitiges Rendering verwenden, müssen wir zunächst einmal weder auf Server Actions noch auf Route Handlers
zurückgreifen, um uns die User vom Server zu ziehen.

```tsx
// app/page.tsx

import { UserSearch } from '@/app/components/UserSearch';
import { getAllUsersFromDb } from '@/app/db';

export default async function SearchPage() {
  const users = await getAllUsersFromDb();

  return <>
    <h1>User Search</h1>
    <UserSearch users={users}/>
  </>;
}
```

Die `SearchPage` gibt die initial geladenen User an die `UserSearch`-Komponente weiter, die clientseitig gerendert wird.
Die `UserSearch` hält die Liste der User als State. Über ein Input-Feld kann nach Usern gesucht werden. Sobald sich
der Input ändert, wird die Server Action `getUsers` aufgerufen, und das Ergebnis mittels `setUsers` in den State
geschrieben.
Unterhalb des Suchfelds wird die aktuelle Userliste angezeigt.

```tsx
// app/components/UserSearch.tsx

'use client';

import { User } from '@/app/user';
import { useState } from 'react';
import { getUsers } from '@/app/actions/getUsers';
import Link from 'next/link';

export function UserSearch(props: { users: User[] }) {
  const [users, setUsers] = useState(props.users);

  return <>
    <input
      type="text"
      placeholder="Search user..."
      onChange={async (e) => {
        const users = await getUsers(e.target.value);
        setUsers(users);
      }}
    />
    <ul>
      {users.map((user, index) => (
        <li key={index}>
          <Link href={`/user/${user.id}`}>{user.firstName} {user.lastName}</Link>
        </li>
      ))}
    </ul>
    <Link href="/user">
      <button>New User</button>
    </Link>
  </>;
}
```

Die Server Action `getUsers` ist eine asynchrone Funktion, die mit `'use server'` als Server Action deklariert wird und
ein `Promise<User[]>` zurückgibt.
`getUsers` ruft zunächst alle User von der Datenbank ab und filtert dann anhand des gegeben Suchbegriffs, sodass nur
diejenigen User zurückgegeben werden, deren `firstName` oder `lastName` den Suchbegriff enthält.

```ts
// app/actions/getUsers.ts

'use server';

import { User } from '@/app/user';
import { getAllUsersFromDb } from '@/app/db';

export async function getUsers(searchTerm: string): Promise<User[]> {
  const users = await getAllUsersFromDb();
  return users.filter(user => user.firstName.includes(searchTerm) || user.lastName.includes(searchTerm));
}
```

#### Wie man es ohne Server Action besser macht

Wir haben gesehen, dass wir mit der Server Action `getUsers` die Liste von Usern vom Server laden können, wenn sich
clientseitig etwas an der Sucheingabe ändert.
Der Ansatz hat jedoch einen entscheidenden Nachteil: die Server Action wird als POST-Request umgesetzt.
Da wir Daten vom Server lesen, würden wir eigentlich einen GET-Request erwarten.
Praktisch hat die Limitierung auf POST-Requests den Nachteil, dass Requests nicht gecached werden.
Das bedeutet, dass bei jeder Abfrage von `getUsers` mit dem gleichen Suchbegriff der Server tatsächlich aufgerufen wird,
statt dass bei wiederholten Abfragen die bestehenden Daten aus dem Cache geladen werden.

Glücklicherweise gibt es einen einfachen Weg, wie wir die Live-Suche auch ohne Server Action (und auch ohne Route
Handler) umsetzen können, nämlich mittels eines Suchparameters, den wir der `SearchPage` übergeben.
Die `SearchPage` verwendet serverseitiges Rendering und lädt die User direkt aus der Datenbank.
Dann filtert sie die Liste von Usern anhand des `searchTerm`, der über den Suchparameter `q` in der URL übergeben wird.

```tsx
// app/page.tsx

import { UserSearch } from '@/app/components/UserSearch';
import { getAllUsersFromDb } from '@/app/db';

export default async function SearchPage({ searchParams }: {
  searchParams: { [key: string]: string | string[] | undefined }
}) {
  const searchTerm = getSearchTerm(searchParams);

  const users = (await getAllUsersFromDb())
    .filter(user => user.firstName.includes(searchTerm) || user.lastName.includes(searchTerm));

  return <>
    <h1>User Search</h1>
    <UserSearch users={users}/>
  </>;
}

function getSearchTerm(searchParams: { [key: string]: string | string[] | undefined }): string {
  const searchTerm = searchParams?.q;
  if (typeof searchTerm !== 'string') return '';
  return searchTerm;
}
```

Die Komponente `UserSearch` ändert sich insofern, als dass der `onChange`-Handler des Input-Felds nicht mehr die Server
Action `getUsers` aufruft.
Stattdessen wird der Router verwendet, um den eingegeben Suchbegriff als Suchparameter `q` an die URL zu hängen.

```tsx
'use client';

import { User } from '@/app/user';
import Link from 'next/link';
import { useRouter } from 'next/navigation';

export function UserSearch(props: { users: User[] }) {
  const router = useRouter();

  return <>
    <input
      type="text"
      placeholder="Search user..."
      onChange={async (e) => {
        router.push(`?q=${e.target.value}`);
      }}
    />
    <ul>
      {props.users.map((user, index) => (
        <li key={index}>
          <Link href={`/user/${user.id}`}>{user.firstName} {user.lastName}</Link>
        </li>
      ))}
    </ul>
    <Link href="/user">
      <button>New User</button>
    </Link>
  </>;
}
```

Bei jedem Zeichen, welches der Nutzer in das Suchfeld eingibt, wird nun ein Fetch Request mit der GET-Methode und dem
neuen Suchbegriff als Parameter ausgeführt.
Der Fetch Request hat den Vorteil, dass nicht die komplette Seite neu geladen wird, sondern nur die Daten auf der Seite,
was eine angenehmere User Experience bedeutet.
Außerdem wird der
clientseitige [Router Cache](https://nextjs.org/docs/app/building-your-application/caching#router-cache)
von Next.js verwendet.
Dieser verhindert, dass bei Eingabe des gleichen Suchbegriffs kurz hintereinander der gleiche Fetch Request mehrfach
aufgerufen wird, und reduziert dadurch die Anzahl an Requests, die tatsächlich an den Server gesendet werden.

## Fazit

Server Actions in Next.js 14 bieten eine interessante Option, Daten serverseitig zu verarbeiten und gleichzeitig
statische Typesicherheit zu gewährleisten.
Wir haben anhand des Beispiels gesehen, wie wir eine Webanwendung mit Datenbankanbindung in Next.js komplett ohne Route
Handlers umsetzen können.
Im Code erscheinen die Server Actions als normale Funktionsaufrufe, was zu einer guten Lesbarkeit des Codes beitragen
kann.

Wir haben aber auch gelernt, dass Server Actions nicht das Allheilmittel sind, mit dem wir die gesamte Kommunikation
zwischen Client und Server abbilden sollten, auch wenn das technisch möglich ist.
Zum Lesen von Daten ist serverseitiges Rendering die bessere Option, da wir dadurch Caching-Mechanismen optimal
ausnutzen können.
Außerdem müssen wir auch bei der Verwendung von Server Actions Maßnahmen wie Authorisierung und Validierung ergreifen,
die eine sichere und korrekte Ausführung unserer Anwendungen gewährleisten.

---

&ast; *In dem konkreten Beispiel wäre es zwar auch möglich `UserForm` als Server-Komponente zu implementieren, bei
der `saveUser` als Submit Action verwendet wird. In der Praxis ist es allerdings häufig so, dass wir clientseitige
Validierungen verwenden wollen, welche direkt bei Eingabe des Nutzers eventuelle Fehler anzeigen und daher nur mit
clientseitigem Rendering funktionieren.*

Server Actions in Next.js 14

In this blog post we will take a look at macro annotations, a powerful tool for code transformation and generation in Scala.
Macro annotations allow us to transform the code of a definition, e.g., a class or method, at compile time.
This can be used to reduce boilerplate code, because the compiler generates it for us.
During compilation, a macro annotation will expand the *abstract syntax tree (AST)* of the annotated definition.
The transformation code is written in Scala itself, making use of Scala's reflection API to analyze and transform the AST.
Hence, the use of macros is also referred to as *metaprogramming*.

Macro *annotations* are one of two types of macros in Scala 2. 
The other one are *def macros*, which are explained in [[1]](https://docs.scala-lang.org/overviews/macros/overview.html).
Macro annotations are an experimental feature and have to be enabled via compiler flag `-Ymacro-annotations`
in Scala 2.13, or by using the macro paradise plugin in older version starting from Scala 2.10.

## Caching method return values with macro annotations

As a simple example for macros in Scala 2 (version 2.13.10), we will implement a macro annotation for caching return values of arbitrary methods.
The cache will store key-value pairs of the input parameters of the method as well as its return value
and directly return them for cached inputs.
The code we will see in the following can be found [here](https://github.com/LukasL97/scala-macros-example).

We start by defining a `Cache` trait with a simple `MapCache` implementation:

```scala
trait Cache[K, V] {
  def put(key: K, value: V): Option[V]
  def get(key: K): Option[V]
}

class MapCache[K, V] extends Cache[K, V] {
  private val map = mutable.Map.empty[K, V]

  override def put(key: K, value: V): Option[V] = map.put(key, value)
  override def get(key: K): Option[V] = map.get(key)
}
```

Before introducing the macro annotation, we first want to have a look at how an implementation *without macros* could look like.
The caching logic can be generalized into a method with type parameters `K` and `V` for the key and value types:

```scala
def cached[K, V](cache: Cache[K, V], input: K)(f: => V): V = {
  cache.get(input) match {
    case Some(value) =>
      value
    case None =>
      val result = f
      cache.put(input, result)
      result
  }
}
```

The method takes the `cache` and the `input` as parameters and wraps a function `f`. 
It looks up the `input` in the `cache` and returns the respective value if one is found.
In case of a cache miss, the function `f` is executed and the result is cached and then returned.

This `cached` method can now be used in methods of arbitrary signature:

```scala
val fCache = new MapCache[(Int, Int), Int]

def f(x: Int, y: Int): Int = cached(fCache, (x, y)) {
  x * y
}

val gCache = new MapCache[(Int, String), String]

def g(x: Int, s: String): String = cached(gCache, (x, s)) {
  x.toString + s
}
```

The generic `cached` method provides some simplification for implementing the methods whose results we want to cache.
However, we still have to define a cache for each method and pass it along with the input parameters to the `cached` method.
This feels like boilerplate, which we can get rid of with a macro annotation.

### Generating the caching logic

We introduce a `cached` macro annotation, which can be used to annotate a method of arbitrary signature, providing all
the required caching logic.
In the first step, we only implement the transformation of the annotated method itself. 
For now, the cache that is used by the annotated method still has to be defined in the application code. 
This will be improved in a later step.

```scala
class cached extends StaticAnnotation {
  def macroTransform(annottees: Any*): Any = macro cached.impl
}

object cached {
  def impl(c: whitebox.Context)(annottees: c.Tree*): c.Tree = ???
}
```

The `cached` annotation extends the `StaticAnnotation` class and defines a `macroTransform` method.
The actual code transformation happens in the `impl` method, which gets the *annottees* along with a context as inputs.

The *annottees* are a sequence of ASTs, namely the definitions that are annotated by the `cached` annotation.
In our example, there will always be one annottee, as we will annotate methods. 
Multiple annottees can occur, for instance, when a class with a companion object is annotated.
In this case, both the class and its companion object are passed to the `macroTransform` method and can be transformed
in its implementation.

The context provides access to Scala's reflection API, including features such as *quasiquotes* and *term names*, which we
will make use of in the transformation code. We can import those directly as `import c.universe._`.

Now, let's have a look at the implementation of the macro transformation. 
This may seem overwhelming at first, but we will give a step-by-step explanation below:

```scala
def impl(c: whitebox.Context)(annottees: c.Tree*): c.Tree = {
  import c.universe._

  annottees.head match {
    case q"""$mods def $method[..$typeParams](
      ...$params): $returnType = $rhs""" =>                        // (1)

      val paramNames = params.flatten.map {
        case q"$_ val $name: $_ = $_" => name                      // (2)
      }

      val cacheName = TermName(s"${method}Cache")                  // (3)
      val keyName = TermName(c.freshName("key"))
      val resultName = TermName(c.freshName("result"))

      val newRhs =                                                 // (4)
        q"""
         val $keyName = (..$paramNames)
         $cacheName.get($keyName) match {
           case Some(value) =>
             value
           case None =>
             val $resultName = $rhs
             $cacheName.put($keyName, $resultName)
             $resultName
         }
        """
      val expandedMethod = q"""$mods def $method[..$typeParams](
        ...$params): $returnType = $newRhs"""                      // (5)

      expandedMethod

    case annottee => 
      c.abort(annottee.pos, "Annottee must be a method")           // (6)
  }
}
```

We start in (1) by pattern matching the annottee against a quasiquote, a code snippet wrapped inside an interpolated string `q"..."`.
Quasiquotes are a useful notation for constructing ASTs, which would otherwise have to be written as a bunch of nested
method applications.
As seen in the code, quasiquotes can also be used for pattern matching, allowing us to extract parts of the AST.
Conceptually, this is similar to normal string interpolation with `s"..."`, which allows inserting or extracting parts
of the string.
Note that in quasiquotes, we extract parts of the AST instead of strings.
For instance, `$mods` are the modifiers of the annotated method (e.g. `private`) and `rhs` is the expression on the
right-hand side of the annottee. 
Also note how the parameters and type parameters of the method are extracted.
The `..$typeParams` notation indicates a list of trees (in this case type trees).
Meanwhile, the `...$params` notation indicates a nested list of lists of trees, representing the parameter lists
of the annotated method.

The pattern matching ensures, that the annottee is indeed a method.
Otherwise, we jump to the default case (6), where we abort compilation with a corresponding error message.

In (2), we extract the names from the parameters, which we will use in the transformed right-hand side of the method
to build the key that is looked up and stored in the cache. 
Then, we define some variable names in (3), which we will also use in the right-hand side.
The `$cacheName` references a variable outside the method scope, which we assume to be present.
If it is not, the compilation will fail.
The other two variable names will reference local variables in the method body.
To avoid any naming conflicts with existing variables, we create them calling the `freshName` method from Scala's
reflection API, which ensures that the generated name will be unique.

The main part of the code transformation happens in (4), where we define `newRhs`, the new body of the method.
The new right-hand side is more or less identical to the implementation of the `cached` method that we defined earlier.
The key is created as a tuple built from the method parameters, using the `(..paramNames)` notation.
In case of a cache miss, the original method body `rhs` is used to retrieve a result.

Finally, in (5), the `expandedMethod` is built, using all the parts of the original method, but replacing the right-hand side
with `newRhs`. This method definition will replace the annotated method during compile time.

With this in place, we can annotate arbitrary methods as `@cached`. 
The compiler will then transform each method according to the macro transformation defined above.
The application code now looks as follows, still requiring the explicit definition of the `fCache` and `gCache` for
the two methods `f` and `g`, but already the method definitions themselves are simplified:

```scala
val fCache = new MapCache[(Int, Int), Int]

@cached
def f(x: Int, y: Int): Int = x * y

val gCache = new MapCache[(Int, String), String]

@cached
def g(x: Int, s: String): String = x.toString + s
```

### Generating caches at compile time

Now that we have simplified the method body by implementing the `cached` macro annotation, we also want to get rid
of the explicit `Cache` instance definitions.
In order to achieve that, we need to not only transform a definition, but generate an entirely new
definition as well, namely the cache.
Luckily, macro annotations allow us to expand an annottee into as many ASTs as we want.
This allows us to expand the annotated method into both the transformed method and an additional value definition for
the cache. The `impl` method of the macro annotation is adapted as follows:

```scala
def impl(c: whitebox.Context)(annottees: c.Tree*): c.Tree = {
  import c.universe._

  annottees.head match {
    case q"""$mods def $method[..$typeParams](
      ...$params): $returnType = $rhs""" =>

      val (paramNames, paramTypes) = params.flatten.map {
        case q"$_ val $name: $tpt = $_" => name -> tpt             // (1)
      }.unzip

      val cacheName =                                              // (2)
        TermName(c.freshName(method + "_generatedCache"))
      val keyName = TermName(c.freshName("key"))
      val resultName = TermName(c.freshName("result"))

      val newRhs = ...
      val expandedMethod = q"""$mods def $method[..$typeParams](
        ...$params): $returnType = $newRhs"""

      val cacheKeyType = tq"(..$paramTypes)"                       // (3)
      val cache =                                                  // (4)
        q"""
         private val $cacheName: Cache[$cacheKeyType, $returnType] =    
           new MapCache[$cacheKeyType, $returnType]
         """

      q"$expandedMethod; $cache"                                   // (5)

    case annottee => 
      c.abort(annottee.pos, "Annottee must be a method")
  }
}
```

In (1) we extract the types of the method parameters, which we then use in (3) to define the key type of the cache.
The interpolator `tq"(..$paramTypes)"` is used to build a tuple type of the `paramTypes`. 
The `tq"..."` notation is similar to `q"..."`, which we learned previously, with the difference that the latter is used
to build expression trees, while the former is used for type trees.

Instead of referencing a cache definition from application code, our new `cacheName` in (2) will reference a generated
value definition.
We use a fresh name for the cache, which avoids naming conflicts and also allows us to annotate multiple overloaded methods
that share the same name but with different method signatures.

The cache definition is generated in (4). It uses the unique `cacheName` as name, the tuple of the method parameter types
as key type and the return type as value type. We use the `MapCache` implementation as before.

Finally, in (5) we return both the `expandedMethod` and the `cache` as two individual definitions created from a single
annottee.


With the caches generated from macro transformation as well, our application code reduces to only the methods with
the `@cached` annotation. 
Any trace of actual caching logic is removed and deferred to code generation at compile time.

```scala
@cached
def f(x: Int, y: Int): Int = x * y

@cached
def g(x: Int, s: String): String = x.toString + s
```

### Custom cache implementations from implicit cache factories

So far we have used a simple `MapCache` implementation for the caches. 
In a real-world example, one would rather use a more advanced caching solution, which provides features such as a
size limit and expiration of entries.
For example, we could use a cache implementation based on *Guava*, that would implement our previously defined
`Cache` trait:

```scala
class GuavaCache[K, V] extends Cache[K, V] {
  
  private val cache = CacheBuilder.newBuilder()
    .maximumSize(1000)
    .expireAfterAccess(5, TimeUnit.MINUTES)
    .build[K, V]

  override def put(key: K, value: V): Option[V] = {
    val oldValue = get(key)
    cache.put(key, value)
    oldValue
  }

  override def get(key: K): Option[V] = Option(cache.getIfPresent(key))
}
```

We would like to be able to use different Cache implementations with the `@cached` annotation without having to
touch the macro transformation for each one.
An easy way to achieve that, is by resolving the cache implementation from the implicit scope.
First, we provide a `CacheFactory` that offers an `apply` method producing a `Cache`:

```scala 
trait CacheFactory {
  def apply[K, V](): Cache[K, V]
}
```

An example implementation using the previously defined GuavaCache would look as follows.
It is defined as implicit value in order to allow the generated code to resolve it:

```scala
implicit val guavaCacheFactory: CacheFactory = new CacheFactory {
  override def apply[K, V](): Cache[K, V] = new GuavaCache[K, V]
}
```

In the generated code, we replace the explicit creation of a `MapCache` with a call of Scala's `implicitly` method,
which receives the `CacheFactory` as type parameter.
The `apply` method is called on the resolved `CacheFactory`, yielding a `Cache` of the appropriate key and value type:

```scala
val cache =
  q"""
   private val $cacheName: Cache[$cacheKeyType, $returnType] = 
     implicitly[CacheFactory].apply[$cacheKeyType, $returnType]()
  """
```

During implicit resolution, the compiler will look for an implicit definition that fits the required `CacheFactory` type and thereby
find the `guavaCacheFactory`.

## Conclusion

Using the caching example, we have seen how macro annotations can be used in Scala 2 to generate code
at compile time.
The `cached` annotation can be reused and is independent of the signature of the method it is applied to.
Also, we bypass the overhead of defining a cache for every method whose return values we want to cache,
by generating it as a new definition for every annotated method.

While macro annotations provide an interesting way to use metaprogramming in Scala, they are also somewhat clumsy to use
in practice, especially with regard to IDE support, which is not always working properly.
Taking IntelliJ IDEA using the Scala plugin as an example, the IDE is often unable to infer the type of calls to the
reflection API properly.
Quasiquotes are also somewhat difficult to work with, as they are essentially just strings containing
Scala code, which are not type-checked in any form by the IDE plugin.

With the rework of the language in Scala 3, macro annotations have unfortunately been removed from the language.
Only recently they have been added again as an experimental feature in the pre-release version
[3.3.0-RC2](https://github.com/lampepfl/dotty/releases/tag/3.3.0-RC2).
Compared to Scala 2, their usage is still rather clumsy.
We will have a look at macro annotations in Scala 3 in the [next blog post](/wissens-hub/blog/macro-annotations-in-scala-3).

## References

[1] https://docs.scala-lang.org/overviews/macros/overview.html


Macro annotations in Scala 2

In a [previous blog post](/wissens-hub/blog/macro-annotations-in-scala-2) we took a look at macro annotations in Scala 2, where they have been present for a while.
Only recently they have been added to Scala 3 as well, specifically in the pre-release version 
[3.3.0-RC2](https://github.com/lampepfl/dotty/releases/tag/3.3.0-RC2) of the Dotty compiler.
Same as in Scala 2, macro annotations in Scala 3 allow us to transform the *abstract syntax tree (AST)* 
of a definition (e.g. a class or method) at compile time, allowing us to reduce boilerplate code, 
as the compiler generates it for us.

Macro annotations in Scala 3 differ from Scala 2 macro annotations with regard to when they are expanded during compilation.
While in Scala 2, macro annotations are expanded *before type-checking the AST*, in Scala 3, they are expanded
*after type-checking*.
This decision was made intentionally by the language designers, in order to ensure safety and robustness and
improve IDE support. [[1]](https://www.scala-lang.org/blog/2018/04/30/in-a-nutshell.html)

However, this decision makes the implementation of Scala 3 macro annotations currently more verbose.
In Scala 2, we could mostly write Scala code in quasiquotes and use it as output of our macro implementation.
Meanwhile, in Scala 3, we additionally have to take care of symbols, unique identifiers of definitions,
which especially makes adding new members to a class more complicated than in Scala 2.

In the blog post on Scala 2 macro annotations, we implemented a simple macro annotation for caching return values of
arbitrary methods as an example of how macro annotations can be used to reduce boilerplate code by generating it at
compile time. 
In this post, we will transfer this example to Scala 3, with some limitations.

## Caching method return values with macro annotations

Our goal is to implement a macro annotation that we can use to annotate methods.
If an annotated method is called with some input parameters, the method will first look them up in a dedicated cache
and return the corresponding value if the input is found in the cache.
In case of a cache miss, the method body is executed as normally and the result returned, but the result is also stored
in the cache, in order to retrieve it from there if the method is invoked with the same input again.
The entire code for this example can be found [here](https://github.com/LukasL97/scala-3-macros-example).

First, we define a `Cache` trait with a simple `MapCache` implementation (which is identical to the Scala 2 example):

```scala
trait Cache[K, V] {
  def put(key: K, value: V): Option[V]
  def get(key: K): Option[V]
}

class MapCache[K, V] extends Cache[K, V] {
  private val map = mutable.Map.empty[K, V]

  override def put(key: K, value: V): Option[V] = map.put(key, value)
  override def get(key: K): Option[V] = map.get(key)
}
```

In Scala 3, a macro annotation is defined as a subclass of the newly added `MacroAnnotation` class.
Currently, the class has to be annotated as `@experimental`, as the `MacroAnnotation` is still an experimental
feature in version 3.3.0-RC2 of the language.
The class in which we use our macro annotation has to be annotated as `@experimental` as well.
We define our `cached` annotation as subclass of `MacroAnnotation`:

```scala
@experimental
class cached extends MacroAnnotation {
  override def transform(using quotes: Quotes)(
    tree: quotes.reflect.Definition
  ): List[quotes.reflect.Definition] = ???
}
```

The `MacroAnnotation` offers a `transform` method which we override to define our macro transformation.
The `transform` method can return multiple definitions, allowing to add more members to the enclosing class,
which we will make use of to add a dedicated cache for the annotated method.
It has an additional implicit parameter `q` of type `Quotes`, which provides programmatic
access to the reflection API of Scala 3, similar to the `Context` in Scala 2.

Our implementation of the `transform` method transforms the body of the annotated method according to the
previously mentioned approach for reusing method return values.
Additionally, it generates the cache, which is referenced in the new method body and added as member to the enclosing
class.
Let's have a look at the implementation.
A step-by-step explanation is given below.

```scala
override def transform(using quotes: Quotes)(
  tree: quotes.reflect.Definition
): List[quotes.reflect.Definition] = {
  import quotes.reflect._

  tree match {
    case DefDef(name, params, returnType, Some(rhs)) =>          // (1)

      val flattenedParams = params.map(_.params).flatten         // (2)
      val paramTermRefs = flattenedParams.map(
        _.asInstanceOf[ValDef].symbol.termRef)
      val paramTuple = 
        Expr.ofTupleFromSeq(paramTermRefs.map(Ident(_).asExpr))
        
      (paramTuple, rhs.asExpr) match {
        case ('{ $p: paramTupleType }, '{ $r: rhsType }) =>      // (3)

          val cacheName = Symbol.freshName(name + "Cache")       // (4)
          val cacheType = 
            TypeRepr.of[Cache[paramTupleType, rhsType]]
          val cacheRhs = 
            '{ new MapCache[paramTupleType, rhsType] }.asTerm
          val cacheSymbol = Symbol.newVal(tree.symbol.owner,
            cacheName, cacheType, Flags.Private, Symbol.noSymbol)
          val cache = ValDef(cacheSymbol, Some(cacheRhs))
          val cacheRef = Ref(cacheSymbol)
            .asExprOf[Cache[paramTupleType, rhsType]]

          def buildNewRhs(using q: Quotes) = {                   // (5)
            import q.reflect._
            '{
              val key = ${ paramTuple.asExprOf[paramTupleType] }
              $cacheRef.get(key) match {
                case Some(value) =>
                  value
                case None =>
                  val result = ${ rhs.asExprOf[rhsType] }
                  $cacheRef.put(key, result)
                  result
              }
            }
          }
          val newRhs = 
            buildNewRhs(using tree.symbol.asQuotes).asTerm
          
          val expandedMethod = DefDef.copy(tree)(
            name, params, returnType, Some(newRhs))              // (6)

          List(cache, expandedMethod)
      }
    case _ =>
      report.error("Annottee must be a method")                  // (7)
      List(tree)
  }
}
```

Starting in (1), the input AST is matched against a `DefDef` which is the definition of a method.
If the annottee is not a method, we report a compilation error in (7).

We first process the parameters of the method in (2), mapping them to an expression that represents
a tuple of the input parameters.
In Scala 2, we could just do this using a dedicated quasiquotes notation.
Now, we have to extract the symbols from the parameter definitions and build references to their identifiers.
The method `Expr.ofTupleFromSeq` allows us to build a tuple expression from a list of expressions.

In (3), we pattern match the parameter tuple expression and the method's right-hand side against *quotes*.
Quotes are conceptually similar to quasiquotes in Scala 2.
They are written as `'{ ... }` and can contain any typed Scala code.
In this case, we use them to extract the types of the parameter tuple and the method body, which we will use
as key and value type parameters of the cache.

We then build the cache definition in (4), starting with a fresh name.
We construct a type representation of the `Cache` type, with the key and value type parameters we extracted in (3).
The right-hand side of the cache definition is written as a quote in which we create a `MapCache`.
Then, we create the `cacheSymbol` as a symbol representing a `val`.
As parent we use the owner of the expanded method, i.e., the class in which the method is defined.
We then create the `cache` as `ValDef`, the definition of a `val`, using the symbol and right-hand side we
just created.
The `cache` will later be returned alongside the transformed input method.
We also need an additional reference to the `cacheSymbol`, in order to access the new cache definition inside
the transformed body of the annotated method.
In Scala 2, it was possible to just use the term name in a quasiquote.
Scala 3 however does require a `Ref` to the symbol explicitly.

The transformation of the method body happens in (5).
We use a helper method `buildNewRhs` to which we pass the symbol of the original method `asQuotes`.
This is necessary in order to ensure that any definitions created in the quote that describes our new
right-hand side are owned by the method.
Otherwise, the definitions inside the new right-hand side would be owned by the enclosing class and the
code would not compile.

The quote in `buildNewRhs` contains the transformed method body, which is analogous to the Scala 2 implementation.
The reference to the cache is inserted into the quote as `$cacheRef`, which is a *splice*.
Splices allow us to insert expressions into quoted code blocks, evaluating them before the surrounding code.
Similarly, we insert the `paramTuple` and the original `rhs` into the quote.
For the code to type-check, we have to cast them explicitly to expressions of the expected types.

It has to be noted, that we did not use fresh names for the `key` and `result` definitions in the new
method body.
This would of course still be possible and require a similar approach as with the `cacheRef`, creating
a new symbol for each and then references to these symbols, which can then be used inside the quoted code block.
For simplicity, this is omitted here, and we confine ourselves to using the static names `key` and `result`,
which could potentially have naming conflicts to method parameters.

Finally, in (6) we create the `expandedMethod` as a copy of the input method, replacing the original
right-hand side with the `newRhs`.
Then, we return it alongside the `cache`.

Now, we can use the annotation to annotate arbitrary methods as `@cached`.
The compiler will transform the annotated methods each according to the macro transformation defined above.
Additionally, it will add a dedicated `Cache` value for each annotated method as a member of the enclosing class.
As an example, two annotated methods with different method signatures, both using the `@cached` annotation, could look
as follows:

```scala
@cached
def f(x: Int, y: Int): Int = x * y

@cached
def g(x: Int, s: String): String = x.toString + s
```

## Conclusion

The caching example shows us that, even though they are in an experimental state, macro annotations in Scala 3 can 
already be used to reduce boilerplate code.

Compared to their usage in Scala 2, macro annotations in Scala 3 are more verbose, which is due to the fact that they
work with typed ASTs, compared to untyped ASTs in Scala 2.
Hence, we have to take care of proper usage of symbols and references, which makes especially the definition of the
cache more laborious than in Scala 2.

Further, it is no longer possible to use implicit resolution to pass a value from application
code into the code generated by the macro.
This is due to the fact that macro expansion now happens after implicits are resolved by the compiler.
An `implicitly` in macro code will not be resolved from an implicit (or `given`) value in application code.
In the Scala 2 implementation, we used [this trick](/wissens-hub/blog/macro-annotations-in-scala-2#custom-cache-implementations-from-implicit-cache-factories) to make the cache implementation configurable,
i.e., to define an implementation other than the simple `MapCache` class in the application code and use it in the
code generated by the macro transformation.

Lastly, IDE support is still an issue in Scala 3, at least at the moment, using the Scala plugin of IntelliJ IDEA.
However, with macro annotations just having been added as experimental feature to Scala 3, there is some hope that
this might change in the future.
In this regard, quotes in Scala 3 are an improvement over quasiquotes in Scala 2,
as they are actually interpreted as Scala code by the IDE.

## References

[1] https://www.scala-lang.org/blog/2018/04/30/in-a-nutshell.html

Macro annotations in Scala 3

In recent years, large language models (LLMs) have made remarkable progress in interacting with humans,
showcasing their ability to answer a wide array of questions.
Trained on publicly accessible internet content, these models have broad knowledge across many different topics.
However, they are limited to information that was available to them during training and thus fail to answer any
questions about specific content from your personal documents.

In this article, we will have a look at how we can overcome this limitation, by combining 
[OpenAI](https://platform.openai.com/docs/overview)'s chat completion model
with a [Pinecone](https://www.pinecone.io/) vector database.
We will first have a look at the general approach and then go into detail and implement an intelligent question
answering system in Python, using the APIs of both OpenAI and Pinecone, which enables the LLM to provide useful
responses to inquiries about personal documents.

## Approach

The core idea of the approach is to use OpenAI's chat completion model to answer questions about our documents.
To do so, we create a prompt that includes the question and the documents and asks the model to answer the question
based on the text contents of these documents.
With this naive idea we face the obstacle that the prompt we can provide as input to the chat completion model is 
limited in length.
Meanwhile, we might have a large number of documents, whose contents combined exceed this limit.
Hence, we first have to filter the documents to find the most relevant ones for the question, in order to reduce the
length to the prompt below the limit.

To find the documents that are relevant for a question we make use of text embeddings.
Text embeddings are high-dimensional numerical vectors that represent the meaning of a text in such a way, that
semantically related texts are close to each other in the vector space.
We can use an embedding model to embed all our documents, resulting in a vector for each document.
While different embedding models are available, we will use an embedding model provided by OpenAI via the API.

The resulting vectors are then stored in a vector database.
Vector databases are designed to store and efficiently query large amounts of vectors.
Querying uses an algorithmic approach to find the nearest neighboring vectors to a given query vector
in a database index, using different distance metrics.
In this case, we will use the vector database provided by Pinecone, which is a managed vector database service.

![openai-pinecone-search-embedding.png](https://media.graphassets.com/nkjDpDIlQX6LJagAyvSN)

With a Pinecone index filled with our embedded documents, we can now ask questions about their contents.
To do so, we first embed the question using the same embedding model that we used for the documents.
This results in a vector representation of the question, which should be close to the vectors of semantically
related documents, that could provide the information required to answer the question.

By querying the Pinecone index with the embedding vector of the question, we retrieve the nearest document vectors in
the database.
We load the texts of the found documents and combine them to a prompt for the chat completion model, along with the
question text.
Then, we put the prompt into the chat completion model, which will return an answer to our question based on
the texts of the relevant documents.

![openai-pinecone-search-query.png](https://media.graphassets.com/hnayhIzMSHGnTNnJ3nSC)

## Implementation

We will look at an implementation of the question answering approach in a small Python script.
You can find the entire code for the demo on [GitHub](https://github.com/LukasL97/openai-pinecone-search).

### Set up OpenAI and Pinecone

We first need to create accounts and API keys for [OpenAI](https://platform.openai.com/) and
[Pinecone](https://app.pinecone.io/) in the respective developer consoles.
Assuming the API keys are stored in environment variables, we can initialize the OpenAI and Pinecone clients in
our python script.

```python
import os
import openai
import pinecone

openai.api_key = os.getenv("OPENAI_API_KEY")
pinecone.init(api_key=os.getenv("PINECONE_API_KEY"), environment='gcp-starter')
```

### Create the Pinecone index

We can create a Pinecone index either in the Pinecone console or programmatically using the client.
Here, we will do the latter to create an index named *document-search-index*.
The index can be configured with regard to different parameters, most notably the dimensions and the metric.
The dimensions specify the size of the vectors that we will store in the index.
As our embedding model will use vectors of size 1,536, we set the dimensions accordingly.
For the metric we have the choice between *cosine*, *dotproduct* and *euclidean*.
[As the OpenAI documentation recommends using cosine similarity](https://platform.openai.com/docs/guides/embeddings/which-distance-function-should-i-use),
we will use the *cosine* metric.

```python
pinecone_index_name = 'document-search-index'
pinecone.create_index(pinecone_index_name, metric='cosine', dimension=1536)
```

We can also configure the index with regard to the number of pods and pod type.
However, in the free tier we are limited to a single pod and pod type.
The [Pinecone documentation](https://docs.pinecone.io/docs/choosing-index-type-and-size) explains how the index can be
configured in more detail.

### Embed and store your documents in the Pinecone index

Now that we have created the Pinecone index, we can embed and store our documents in the index.
First, we need to load our documents from the disk.
In this case, we assume that the documents are stored in a directory named *data*.
The documents are loaded from the directory and returned as a list of dicts, consisting of the *title* (i.e. the
filename
without ending) and the *content*.

```python
import os

def load_documents():
    documents = []
    documents_path = 'data'
    for filename in os.listdir(documents_path):
        file_path = os.path.join(documents_path, filename)
        with open(file_path, 'r', encoding='utf-8') as file:
            content = file.read()
        documents.append({'title': filename.split('.')[0], 'content': content})
    return documents
```

Next, we need a function to embed the content of a document using OpenAI's embedding model.
The OpenAI client offers an endpoint for that, which allows us to specify an embedding model.
We use the model *text-embedding-ada-002*, which is
[recommended by OpenAI](https://platform.openai.com/docs/guides/embeddings/embedding-models) at the time of
writing this article. The model generates embedding vectors of size 1,536.

```python
import openai.embeddings_utils

def get_embedding_vector_from_openai(text):
    return openai.embeddings_utils.get_embedding(text, engine='text-embedding-ada-002')
```

With the documents and the embedding function, we are now able to fill our Pinecone index with the embedded documents.
The *upsert* method of the Pinecone client expects a list of vectors with *id*, *values* (i.e. the actual vector), and
*metadata*.
The *id* is a unique identifier for each vector in the index and can be used to query a particular vector.
As we won't need this in our use case, we simply set a random value as *id*.
The *metadata* can be any additional information that we want to store together with the vector.
In this case, we store the title of the document as *metadata*.

```python
import time
import uuid

def fill_pinecone_index(documents):
    index = pinecone.Index(pinecone_index_name)
    for doc in documents:
        try:
            embedding_vector = get_embedding_vector_from_openai(doc['content'])
            data = pinecone.Vector(
                id=str(uuid.uuid4()),
                values=embedding_vector,
                metadata={'title': doc['title']}
            )
            index.upsert([data])
            print(f'Embedded and inserted document with title ' + doc['title'])
            time.sleep(1)
        except:
            print(f'Could not embed and insert document with title ' + doc['title'])

documents = load_documents()
fill_pinecone_index(documents)
```

You may notice that we have added a `time.sleep(1)` after each embedding and insertion.
This is in order to avoid a rate limit error from OpenAI, which only allows a certain number of tokens to be embedded
per minute.
Further, the embedding model we use is currently limited to texts of up to 8,191 input tokens, which may not be
enough for all documents in *data*.
In this case, we simply skip the embedding and insertion of these document, so that not all our documents will end up
as vectors in the index.
If you have large documents with a lot of text, you may want to consider splitting them into smaller chunks and embed
those individually.

### Answer questions about the documents

To answer questions about our documents, we will first find the relevant ones by querying the Pinecone index, and then
use these documents and combine them with the question into a prompt for the OpenAI chat completion endpoint, 
asking the model to answer the question based on the given text.

To retrieve the relevant documents, we simply embed the question using the same model that we used to embed the
documents.
Then, we query the index with this embedding vector, which will retrieve the top *k* similar vectors in the index.
We set *k* to 1 in this case, as we only answer the question based on a single document.
You may want to use a larger value for *k* to enable the system to take multiple documents into account,
if that is required for your use case.
We fetch the title of the document from the metadata, which will enable us to retrieve the document from the disk.

```python
def query_pinecone_index(query):
    index = pinecone.Index(pinecone_index_name)
    query_embedding_vector = get_embedding_vector_from_openai(query)
    response = index.query(
        vector=query_embedding_vector,
        top_k=1,
        include_metadata=True
    )
    return response['matches'][0]['metadata']['title']
```

We use the title of the document to retrieve the document content from the disk:

```python
def load_document_content(title):
    documents_path = 'data'
    file_path = os.path.join(documents_path, title + '.txt')
    with open(file_path, 'r', encoding='utf-8') as file:
        content = file.read()
    return content
```

We further implement a helper method, to combine the document and the question into a prompt for the chat completion
model:

```python
def create_prompt(question, document_content):
    return 'You are given a document and a question. Your task is to answer the question based on the document.\n\n' \
           'Document:\n\n' \
           f'{document_content}\n\n' \
           f'Question: {question}'
```

Finally, we can use the OpenAI client to ask the chat completion model to answer the question based on the document.
We set the model to *gpt-3.5-turbo-16k*.
This is not the state-of-the-art model, but it is currently cheaper than the different variants of *gpt-4* and should
be sufficient for this use case.
The *16k* version of the model allows for up to 16,385 tokens, which allows us to put long texts into the prompt.
We pass a list of messages to the chat completion model, which consists of the conversation up to this point.
As we start a new conversation, our list consists of a single user message with our prompt as content.
The model returns a list of completion choices, which could be more than one if specified in the request.
As we did not specify a value, it defaults to only a single completion.
We extract the message content of the completion, which contains the answer to our prompt.

```python
def get_answer_from_openai(question):
    relevant_document_title = query_pinecone_index(question)
    print(f'Relevant document title: {relevant_document_title}')
    document_content = load_document_content(relevant_document_title)
    prompt = create_prompt(question, document_content)
    print(f'Prompt:\n\n{prompt}\n\n')
    completion = openai.ChatCompletion.create(
        model='gpt-3.5-turbo-16k',
        messages=[{
            'role': 'user',
            'content': prompt
        }]
    )
    return completion.choices[0].message.content

question = input('Enter a question: ')
answer = get_answer_from_openai(question)
print(answer)
```

### Examples

Now we can ask questions about information from out documents and retrieve an answer from OpenAI.
Using around 800 Wikipedia articles about different topics as our example documents, we try out the following question:

> What role does the president play in the political system of Angola?

The Pinecone index yields the vector of the document *Politics of Angola* as most similar to the embedded query.
Using this document in our prompt enables OpenAI to answer the question correctly:

> The president in the political system of Angola holds almost absolute power. They are the head of state and head of government, as well as the leader of the winning party or coalition. The president appoints and dismisses members of the government, members of various courts, the Governor and Vice-Governors of the Nacional Angolan Bank, the General-Attorney and their deputies, the Governors of the provinces, and many other key positions in the government, military, police, intelligence, and security organs. The president is also responsible for defining the policy of the country and has the power to promulgate laws and make edicts. However, the president is not directly involved in making laws.

While this is already impressive, it has to be mentioned that we cheated a little, as we used Wikipedia articles
as our documents for testing the system.
As the OpenAI model was trained on publicly available internet content, it is likely that it has seen this exact
article and would have been able to answer the question anyway, even without receiving the document as part of the
input prompt.
Hence, we will have a look at what happens when we ask about a topic that has not been seen by the OpenAI model
before.

To this end, I made up an article about the fictional chemist *Jacob Miller*, who was born in 1850, discovered a
chemical element in 1886, which he named *Jacobium*, received the Nobel Prize for his findings in 1901, and died
in 1932.
You can find the article in the 
[*data* directory of the GitHub repository](https://github.com/LukasL97/openai-pinecone-search/blob/main/data/Jacob%20Miller%20(Chemist).txt).
The document was embedded along with all other documents and inserted into the Pinecone index.
Now, let's have a look at what happens when we ask about Jacob Miller:

> In which year did the discoverer of the chemical element Jacobium win the nobel prize?

As we would expect, the Pinecone index yields the vector of the document *Jacob Miller (Chemist)* as most similar
to the embedded query.
Using this document in the prompt enables the chat completion model to provide the correct answer to the question:

> The discoverer of the chemical element Jacobium won the Nobel Prize in Chemistry in the year 1901.

## Conclusion

As demonstrated in this article, we can combine large language models and vector databases to build intelligent
question answering systems, that are able to answer questions about specific content from our documents.
With managed services like OpenAI and Pinecone, we can easily build such systems without having to worry about
training our own models or setting up and maintaining our own vector database.

As a disclaimer, I want to note that data privacy should be considered when using the approach presented in this article
to build a question answering system on documents that contain sensitive information.
[While OpenAI claims, that they do not train their models on inputs provided via the API](https://openai.com/enterprise-privacy),
you might still want to consider alternatives when working with private or enterprise data.
Instead of using OpenAI, you could use [one of the many open source LLMs](https://github.com/eugeneyan/open-llms) and
host it yourself, which naturally comes with significantly greater expenses.

Further, Pinecone is not the only vector database service available.
An interesting alternative is the open-source database solution [Chroma](https://www.trychroma.com/), which
actually comes with its own embedding model.
Instead of inserting and querying embedding vectors into the database, Chroma allows us to work with the texts directly,
rendering the use of OpenAI's embedding model unnecessary.
Another alternative is [Faiss](https://faiss.ai/index.html), which is an open-source library for efficient GPU-driven
vector similarity search.
Compared to Pinecone, Faiss lacks the ability to store vectors, as it is only a vector index, not a vector database.
Both Chroma and Faiss require you to host a database yourself, which make them somewhat less convenient to use than
the managed Pinecone database.


Answer questions about your documents with OpenAI and Pinecone

Server Actions were introduced in Next.js 14 as a new method to send data to the server (see the [documentation](https://nextjs.org/docs/app/building-your-application/data-fetching/server-actions-and-mutations)).
They are asynchronous functions that can be used in server components, within server-side forms, as well as in
client-side components.
While the invocation of a Server Action appears as a normal function call in the code, it is interpreted as POST request
to the server by Next.js.

In this blog post, I demonstrate in simple examples how Server Actions can be used and what we have to consider when
using them.

## Server Actions: an example

As an example, we implement a simple web application that can be used to save users and also search them.
The search should use a search text and react to client-side changes in the input by loading the data from the server.

In the following, I will only show the important code sections. You can find the entire source code of the example
application here: https://github.com/LukasL97/nextjs-server-actions-example

### Adding and editing users

We define a `UserPage` to add and edit users.
The page is rendered server-side and loads the existing user directly from the database if an ID was given via the URL
path.
This user is then passed to the `UserForm` component, which can be used to edit the user, respectively add a new user if
we did not pass any ID.

```tsx
// app/user/[[...id]]/page.tsx

import { getUserFromDb } from '@/app/db';
import { UserForm } from '@/app/components/UserForm';

export default async function UserPage({ params }: { params: { id?: string[] } }) {
  const id = params.id?.at(0);
  const user = id ? await getUserFromDb(id) : undefined;

  return <>
    <h1>User</h1>
    <UserForm user={user}/>
  </>;
}
```

The `UserForm` component is implemented as a client component.* It contains the `firstName` and `lastName` as states,
which are set when we write into the respective inputs.
On clicking the save button, the Server Action `saveUser` is called, passing it the `firstName`, `lastName`, and
possibly the `id`, if it exists.
After that, we route back to the root URL.

```tsx
// app/components/UserForm.tsx

'use client';

import { useRouter } from 'next/navigation';
import { saveUser } from '@/app/actions/saveUser';
import { useState } from 'react';
import { User } from '@/app/user';

export function UserForm({ user }: { user: User | undefined }) {
  const id = user?.id;

  const [firstName, setFirstName] = useState(user?.firstName ?? '');
  const [lastName, setLastName] = useState(user?.lastName ?? '');

  const router = useRouter();

  return <>
    <div>
      <label>First Name</label>
      <input
        type="text"
        value={firstName}
        onChange={(e) => setFirstName(e.target.value)}
      />
    </div>
    <div>
      <label>Last Name</label>
      <input
        type="text"
        value={lastName}
        onChange={(e) => setLastName(e.target.value)}
      />
    </div>
    <button onClick={async () => {
      await saveUser({ id, firstName, lastName });
      router.push('/');
    }}>
      Save
    </button>
  </>;
}
```

The Server Action `saveUser` is a simple asynchronous function.
It has to be noted that we have to declare it with `'use server'`, in order to ensure that Next.js is able to identify
it as a Server Action.
The Server Action writes the given user into the database.
If it does not yet have an ID (i.e., if it is a newly added user), a random ID is generated first.
Finally, the cache is invalidated using `revalidatePath('/')`.
Thereby, we make sure that the root page will be freshly rendered on the next load, containing the updated users.

```ts
// app/actions/saveUser.ts

'use server';

import { User } from '@/app/user';
import { randomUUID } from 'crypto';
import { putUserIntoDb } from '@/app/db';
import { revalidatePath } from 'next/cache';

export async function saveUser(user: User) {
  if (!user.id) {
    user.id = randomUUID();
  }
  await putUserIntoDb(user);
  revalidatePath('/');
}
```

The `saveUser` example shows us how we can use Server Actions to send data to the server.
Compared to [Route Handlers](https://nextjs.org/docs/app/building-your-application/routing/route-handlers), Server
Actions have the advantage that they provide type safety during compile time.
When using Route Handlers, it can easily happen that, for instance, our request body on the client side does not match the
expected request body on the server side.
The static type checking on Server Actions prevents this error.

However, it is important to note that Server Actions, just as Route Handlers, are implemented as HTTP endpoints under
the hood.
This means that if a user has access to the frontend of the application, they will also have access to the POST
request, which is sent to the server when the Server Action is invoked, as well as the response that is received from
the server.
A user could use this information to send an invalid request body to the server.
Hence, we still require an input validation in practice, especially for publicly available applications, as TypeScript's
static typing will not prevent such scenarios.
Furthermore, the Server Action needs to check for authentication and authorization as well.

### User search

We have seen that we can use Server Actions to send data to the server.
This raises the question if we can use Server Actions to read data from the server as well.
In fact, this is technically possible, as Server Actions are able to return a response to the client.
I would first like to demonstrate how we can implement a live search using a Server Action and then explain why this is
not that great of an idea in practice, and provide a better alternative.

The `SearchPage` is implemented as a server-side component that initially loads all users directly from the database.
As we make use of server-side rendering here, we require neither Server Actions nor Route Handlers to fetch the users
from the server at this point.

```tsx
// app/page.tsx

import { UserSearch } from '@/app/components/UserSearch';
import { getAllUsersFromDb } from '@/app/db';

export default async function SearchPage() {
  const users = await getAllUsersFromDb();

  return <>
    <h1>User Search</h1>
    <UserSearch users={users}/>
  </>;
}
```

The `SearchPage` passes the initially loaded users to the `UserSearch` component, which is rendered on the client side.
The `UserSearch` holds the list of users as state. Via an input field, one can search for users.
As soon as the input is changed, the Server Action `getUsers` is invoked and the result is written to the state
via `setUsers`.
Below the search field, the current list of users is printed.

```tsx
// app/components/UserSearch.tsx

'use client';

import { User } from '@/app/user';
import { useState } from 'react';
import { getUsers } from '@/app/actions/getUsers';
import Link from 'next/link';

export function UserSearch(props: { users: User[] }) {
  const [users, setUsers] = useState(props.users);

  return <>
    <input
      type="text"
      placeholder="Search user..."
      onChange={async (e) => {
        const users = await getUsers(e.target.value);
        setUsers(users);
      }}
    />
    <ul>
      {users.map((user, index) => (
        <li key={index}>
          <Link href={`/user/${user.id}`}>{user.firstName} {user.lastName}</Link>
        </li>
      ))}
    </ul>
    <Link href="/user">
      <button>New User</button>
    </Link>
  </>;
}
```

The Server Action `getUsers` is an asynchronous function, declared as Server Action via `'use server'`, returning
a `Promise<User[]>` as result.
First, `getUsers` loads all users from the database.
Then, it filters the users using the given `searchTerm`, returning only the users whose `firstName` or `lastName`
contain the `searchTerm`.

```ts
// app/actions/getUsers.ts

'use server';

import { User } from '@/app/user';
import { getAllUsersFromDb } from '@/app/db';

export async function getUsers(searchTerm: string): Promise<User[]> {
  const users = await getAllUsersFromDb();
  return users.filter(user => user.firstName.includes(searchTerm) || user.lastName.includes(searchTerm));
}
```

#### A better alternative without Server Actions

We have seen that we can load the list of users from the server using the Server Action `getUsers` whenever a
client-side change on the search input occurs.
However, this approach has a decisive drawback: the Server Action is implemented as POST request.
As we are reading data from the server, we would actually expect a GET request instead.
In practice, this limitation to POST requests has the disadvantage that requests are not cached.
This means that on each call of `getUsers` with the same search term the server is actually invoked, instead of loading
existing data from the cache on recurring invocations.

Fortunately, there is a simple way to implement live search without a Server Action (and without a Route Handler as
well), namely using a search parameter that we pass to the `SearchPage`.
The `SearchPage` uses server-side rendering and loads the users directly from the database.
Then, the list of users is filtered using the `searchTerm`, which is given via the search parameter `q` in the URL.

```tsx
// app/page.tsx

import { UserSearch } from '@/app/components/UserSearch';
import { getAllUsersFromDb } from '@/app/db';

export default async function SearchPage({ searchParams }: {
  searchParams: { [key: string]: string | string[] | undefined }
}) {
  const searchTerm = getSearchTerm(searchParams);

  const users = (await getAllUsersFromDb())
    .filter(user => user.firstName.includes(searchTerm) || user.lastName.includes(searchTerm));

  return <>
    <h1>User Search</h1>
    <UserSearch users={users}/>
  </>;
}

function getSearchTerm(searchParams: { [key: string]: string | string[] | undefined }): string {
  const searchTerm = searchParams?.q;
  if (typeof searchTerm !== 'string') return '';
  return searchTerm;
}
```

The `UserSearch` component is changed with regard to the `onChange` handler of the input field, which no longer calls
the Server Action `getUsers`.
Instead, the router is used to add the input search term as search parameter `q` to the URL.

```tsx
'use client';

import { User } from '@/app/user';
import Link from 'next/link';
import { useRouter } from 'next/navigation';

export function UserSearch(props: { users: User[] }) {
  const router = useRouter();

  return <>
    <input
      type="text"
      placeholder="Search user..."
      onChange={async (e) => {
        router.push(`?q=${e.target.value}`);
      }}
    />
    <ul>
      {props.users.map((user, index) => (
        <li key={index}>
          <Link href={`/user/${user.id}`}>{user.firstName} {user.lastName}</Link>
        </li>
      ))}
    </ul>
    <Link href="/user">
      <button>New User</button>
    </Link>
  </>;
}
```

On every character that the user enters into the search field, a fetch request is executed, using the GET method and the
new search term as parameter.
A fetch request has the advantage that it does not lead to a full page reload, but instead only loads the data on the
page, which leads to a better user experience.
Furthermore, it uses the
client-side [Router Cache](https://nextjs.org/docs/app/building-your-application/caching#router-cache) of Next.js.
The Router Cache prevents the same fetch request from being executed multiple times when we enter the same search term
several times in a row. In this way, we are able to reduce the number of requests actually sent to the server.

## Conclusion

Server Actions in Next.js 14 offer an interesting option to process data on the server while ensuring static type
safety.
Based on an example, we have seen how we can implement a web application with database access in Next.js completely
without using Route Handlers.
In the code, Server Actions appear as normal function invocations, which may improve readability of the code.

However, we also learned that Server Actions are not a one-size-fits-all solution to implement the entire communication
between client and server, even though we can technically use them in that way.
For reading data, server-side rendering is a better option, as it allows us to make optimal use of caching mechanisms.
Furthermore, when using Server Actions, we must also take measures such as authorization and validation to ensure that our
applications run securely and correctly.

---

&ast; *In this concrete example, it would indeed be possible to implement `UserForm` as a server component, which
uses `saveUser` as a submit action. In practice however, we often would like to make use of client-side validation, which
shows potential errors directly on a user input and therefore can only work with client-side rendering.*

Full Stack Developer

Digital Product Coach

<p>TOD (Team-oriented development/Teamorientierte Entwicklung) ist ein Begriff, den wir geprägt haben, um einen flexiblen Entwicklungsalltag zu beschreiben. Nachdem wir in unserem letzten Team mit den verschiedensten Programmier-Modi experimentiert hatten, fanden wir es unnötig, Ansätze wie „Pair Programming“, „Ensemble Programming (früher Mob Programming)“, „Parallel Programming“ und „Einzelkämpfer-Modi“ voneinander abzutrennen. Im Laufe des Tages sprangen wir zwischen diesen Techniken hin und her, wobei ständig neue Variationen entstanden, je nachdem, wie es die Situation erforderte. TOD beschreibt diesen flexiblen Ansatz des ständigen Experimentierens, bei dem wir nicht an künstliche Leitplanken gebunden waren, sondern uns als Gruppe weiterentwickeln konnten, mit dem Vorteil, einen Shared-Everything-Ansatz im Team zu etablieren. Die Konzentration auf Programmiertechniken, an denen zwei oder mehr Personen beteiligt sind, hat uns also geholfen, unser Wissen auf intelligente Weise an das gesamte Team weiterzugeben. Und das Ganze machte obendrein noch jede Menge Spaß.</p><p>TOD ist für uns eines der besten Werkzeuge, um Wissen im Team zu teilen, die Entwickler-Skills zu verbessern und den Zusammenhalt und Spaß im Team zu erhöhen. In diesem Artikel geben wir euch einen Überblick über die Techniken innerhalb von TOD und teilen unsere Erfahrungen, die wir in realen Projekten mit TOD gemacht haben.</p><h2>Pair Programming – ein guter Einstieg</h2><p><a href="https://media.graphassets.com/6WkAuzFHQRiKq47LrMhK"><img src="https://media.graphassets.com/6WkAuzFHQRiKq47LrMhK" alt="pair programming" width="1024" height="607" /></a> </p><p>Die Konzentration auf Programmiertechniken, an denen zwei oder mehr Personen beteiligt sind, hat uns geholfen, unser Wissen auf intelligente Weise an das gesamte Team weiterzugeben. Eine Methode, die auch Spaß macht.</p><p>Pair Programming ist eine gute Möglichkeit, mit dem Wissensaustausch zu beginnen. Zwei Programmierer lösen gemeinsam ein Problem, sprechen darüber, tauschen Ideen aus usw. Es ist auch gut, um jemanden nach Urlaub oder Krankheit auf den neuesten Stand zu bringen, ohne den Rest des Teams auszubremsen.</p><p>Verschiedene Studien (z. B. [1] und [2]) berichten über eine bessere Code-Qualität während der Software-Entwicklung mit dem Resultat, dass am Ende weniger Bugs entstehen. Sobald man anfängt, die Einzelkämpfer-Rolle aufzugeben, wird man definitiv bessere Ergebnisse erzielen. Ein positiver Nebeneffekt ist, dass man beginnt, den Bus Factor und das Wir-Gefühl innerhalb des Teams zu erhöhen.</p><p>Ein Nachteil beim Pair Programming verbirgt sich im Wort „Pair“: Bei dieser Methode sind nur zwei Programmierer beteiligt. Sie kann dazu führen, dass einzelne Teammitglieder kleine Teile des gesamten Wissens verlieren, was nicht gut für die Verbreitung von Wissen im Team wäre. Das war ein Grund, warum wir versucht haben den Einsatz von Pair Programming auf das nötige Minimum herunterzufahren.</p><h2>Ensemble Programming – erhöhe den Bus Factor des Teams</h2><p><a href="https://media.graphassets.com/1SKF1LxS7e1Z5c9hetIJ"><img loading="lazy" src="https://media.graphassets.com/1SKF1LxS7e1Z5c9hetIJ" alt="mob-soft-mode" width="1024" height="511" /></a> </p><p>Ensemble Programming (früher Mob Programming) macht Spaß und ist eine gute Möglichkeit, Wissen im ganzen Team zu verbreiten. Ensemble Programming bedeutet, dass ein Team von Entwicklern (4-6 Personen sind perfekt) einen Computer benutzt, um an einer Aufgabe zu arbeiten. Einer der Gruppe ist das „intelligente Eingabegerät“, während die anderen dafür verantwortlich sind die Person an der Tastatur zu navigieren.</p><p><a href="https://media.graphassets.com/tUYH0W7WTW6WFYyAAxwU"><img loading="lazy" src="https://media.graphassets.com/tUYH0W7WTW6WFYyAAxwU" alt="mob programming-in-a-nutshell" width="1024" height="867" /></a> </p><p>Die Rolle des Drivers wechselt häufig, zum Beispiel alle 7 Minuten. Hier solltet ihr mit eurem Team experimentieren, um den für euch besten Timer zu finden. Ihr solltet auch verschiedene Driver-Navigator-Patterns ausprobieren. Dies alles wird euch helfen, das Wissen im gesamten Team zu verbreiten. Außerdem wird es sich positiv auf den Bus Factor eures Teams auswirken. Der Bus Factor definiert den Gesundheitszustand eures Teams. Wenn sich der Bus Factor eurer Teamgröße nähert, bedeutet das, dass das Team gesund bleibt, auch wenn einige Teammitglieder ausfallen. Kurz gesagt, der Bus Factor bedeutet, dass, wenn eine Person des Teams von einem Bus überrollt wird, das Team in Schwierigkeiten geraten würde, wenn diese Person über ein spezielles Wissen verfügt und die einzige Person wäre, die dieses Wissen besitzt.</p><p>Ein effektives Ensemble Programming erfordert Fähigkeiten, die im Laufe der Zeit aufgebaut werden. Am ersten oder gar am zehnten Tag wird es nicht perfekt funktionieren. In einem früheren Blog-Beitrag haben wir die Einzelheiten von „Ensemble Programming und Share Everything“ bereits <a href="/wissens-hub/blog/mob-programming-shared-everything">beschrieben</a> . Dort werdet ihr auch ausführlichere Informationen über die verschiedenen Muster und Experimente erhalten, mit Fokus auf Remote Ensemble Programming.</p><h2>Parallel Programming – Alle für einen</h2><p>Streng genommen erlauben Ensemble Programming und Pair Programming nur einen Bildschirm und eine Person, die gleichzeitig tippen kann. Jeder, der mit den Techniken gearbeitet hat, wird zustimmen, dass es Situationen gibt, in denen dies frustrierend und einschränkend sein kann. Es ist eine Kunst, lange genug dabei zu bleiben und sich von dieser Frustration zum Lernen zwingen zu lassen, und dennoch zu wissen, wann es wirklich an der Zeit ist, sich zu trennen und parallel zu arbeiten.</p><p><a href="https://media.graphassets.com/R2sNThTQyVw9SI6gXXJw"><img loading="lazy" src="https://media.graphassets.com/R2sNThTQyVw9SI6gXXJw" alt="parallel programming" width="1024" height="696" /></a> </p><p>Als wir an den Punkt kamen, an dem es schwierig war, eine gute Lösung für ein Problem zu finden, und fast jeder in der Gruppe eine Idee hatte, um es zu lösen, haben wir Ensemble Programming gestoppt und, wie wir es nannten, „<strong>Parallel Programming</strong>“ gestartet. Jeder versuchte, das Problem auf seinem eigenen Rechner zu lösen, während man in der Videokonferenz online blieb oder man zusammensaß. Jeder durfte reden und konnte sich gegenseitig fragen oder über Erkenntnisse sprechen.</p><p>Das traditionelle Ensemble Programming ist in dieser Situation frustrierend, weil eine Person die Dokumentation lesen will, eine andere versucht Code zu ändern oder einen Befehl auszuführen, und eine andere Person nach Antworten im Internet suchen möchte. Und das Lesen von Text auf dem Bildschirm eines anderen ist eine Herausforderung an sich, wenn z.B. unerwartetet gescrollt wird, usw.</p><p><a href="https://media.graphassets.com/WbA8HcIVSna2787xmZ9S"><img loading="lazy" src="https://media.graphassets.com/WbA8HcIVSna2787xmZ9S" alt="single piece flow" width="1024" height="672" /></a> </p><p>Einer der Vorteile von Ensemble Programming ist der Single-Piece-Flow – die Idee, dass immer nur an einem Punkt gearbeitet wird. Eine schlanke Produktion wertet das Konzept zusätzlich auf. Das Gute bei Parallel Programming ist, dass es den Single-Piece-Flow behält. Alle Entwickler arbeiten immer noch an der gleichen Aufgabe. Aber das parallele Arbeiten gibt ihnen die Freiheit, die Richtung einzuschlagen, in die sie gehen wollen. Ein Beispiel dafür ist die Fehlerbehebung. Wenn der Fehler schließlich gefunden wird, erklärt die Person, die ihn gefunden hat, den anderen das Problem. Die anderen verstehen die Erklärung sofort, weil sie sich gerade mit derselben Sache innerhalb desselben Kontextes beschäftigt haben.</p><p>Nützlich hierbei war für uns die Festlegung von Time-Boxen (etwa 20 Minuten). Nachdem die Zeit abgelaufen war, kamen wir wieder zusammen, um unsere individuellen Recherchen auszutauschen und zu entscheiden, ob wir mehr Zeit benötigen (eine weitere Zeitbox einzurichten) oder ob wir wieder mit Ensemble Programming weiter machen und eine der gefundenen Lösungen ausprobieren wollten. Während des Ensemble Programmings und des Experimentierens mit verschiedenen Modi fanden wir es auch vorteilhaft, Time-Boxen einzurichten, wodurch eine gewisse Disziplin entsteht.</p><h2>Anwendung der Techniken in der Praxis</h2><p>Bei einem unserer letzten Projekte haben wir mit Ensemble Programming begonnen. Nach einer Weile ließen wir uns von den Herausforderungen entmutigen und wechselten zu Pair Programming und Einzelkämpfer-Modi. Aber wir probierten den Ensemble-Ansatz immer mal wieder aus. Irgendwann hatten wir eine gewisse Sicherheit bei Ensemble Programming erreicht und, was wichtiger war, dessen Vorteile erkannt. Wir kamen zu der Einsicht, dass wir so viel wie möglich als Team zusammenarbeiten wollten und dass wir Ensemble Programming als unsere Haupttechnik zur Softwareentwicklung einsetzen wollten. Wir beschlossen Einzelkämpferaufgaben in unserem Tagesgeschäft so weit wie möglich zu reduzieren, was meist abhängig von der Arbeit bzw. Aufgabe war. Wenn es zur aktuellen Aufgabe passt, ist Einzelkämpferarbeit durchaus sinnvoll. Wir wollten sie einfach auf ein vernünftiges Minimum reduzieren.</p><p>Ein Nachteil von striktem Pair oder Ensemble Programming ist, dass die Arbeitszeiten synchronisiert werden müssen. Dies ist mit gewissen sozialen Kosten verbunden. Wir hielten es für ein besseres Modell, alle arbeiten zu lassen, wann sie wollten, mit grober Orientierung an den üblichen Bürozeiten. Daran sind die meisten Programmierer bereits gewöhnt. Wenn jemand von Natur aus 30 Minuten früher als andere im Büro eintrifft, sollte er sich eine andere Aufgabe suchen, die sich am besten als Einzelkämpfer bewältigen lässt. Teams können solch relevante Aufgaben auf eine To-do-Liste (oder Single-Task-Backlog) setzen, um auf solche Momente vorbereitet zu sein. Wenn später weitere Entwickler zur Arbeit kommen, können sich daraus Pair- oder Ensemble-Programming oder mehrere Pair-Programming-Sessions, usw.,  entwickeln.</p><p><a href="https://media.graphassets.com/CJX3LjayTfKE2tUMnCYd"><img loading="lazy" src="https://media.graphassets.com/CJX3LjayTfKE2tUMnCYd" alt="distribution methods" width="1024" height="683" /></a> </p><p>Wie im Diagramm grob dargestellt, haben wir als primäre Technik Ensemble Programming verwendet. Seit wir die großen Vorteile von Parallel Programming entdeckt haben, haben wir sie häufiger als Pair Programming zusammen mit Ensemble Programming eingesetzt. Aber wir entdeckten diese Technik erst in einem späteren Stadium des Projekts, was den kleineren Balken im Diagramm erklärt.</p><h2>Finde den Weg für dein Team</h2><p>Der oben beschriebene Team-Lernprozess nahm Zeit in Anspruch. Das Team muss erst seinen optimalen Weg finden – was eine gewisse Zeit beansprucht.</p><p>Vielleicht wird euer Team feststellen, dass es am bequemsten und effizientesten ist, wenn es hauptsächlich mit Pair Programming arbeitet. Solange das Team zufrieden ist und seine Ziele erreicht, ist das in Ordnung. Darum geht es bei TOD wirklich: ein Team, das frei experimentiert und gemeinsam den besten Ansatz für sich entdeckt. Und doch bedeutet die Denkweise eine kontinuierliche Verbesserung, während das Team seinen idealen Ansatz sucht. Wir fordern uns selbst immer wieder heraus, sammeln Ideen und versuchen neue Experimente, um uns stetig weiter zu verbessern.</p><p>TOD ist teamspezifisch. Euer Team könnte einen idealen Weg finden, aber wenn ihr als Einzelperson einem neuen Team beitretet, müsst ihr bereit sein, euch anzupassen, den Prozess neu zu beginnen und die in diesem Szenario gewonnenen Erkenntnisse und Ergebnisse akzeptieren.</p><h2>TOD stärkt dein Team</h2><p>Wir stellten bei der Einführung der teamorientierten Entwicklung fest, dass das Wir-Gefühl und die Wohlfühl-Atmosphäre von Tag zu Tag zunahmen. Wir wuchsen zu einem starken Team zusammen, in dem jedes einzelne Teammitglied hoch motiviert war und seine ganze Energie einsetzte. Wir erkannten auch, dass so etwas wie ein Wissens-Safe-Space entstand. Jeder hatte sein eigenes Fachwissen und konnte bei verschiedenen Dingen helfen. Und jeder war bereit zu lernen. Somit hatte niemand im Team Angst zu fragen: „Das habe ich nicht verstanden. Kann es mir nochmal jemand erklären?“.</p><p><a href="https://media.graphassets.com/d1arg0X5TWGL6pN8gGnF"><img loading="lazy" src="https://media.graphassets.com/d1arg0X5TWGL6pN8gGnF" alt="we are the team" width="1024" height="697" /></a> </p><p>Klingt das alles gut für euch? Warum versucht ihr dann nicht heute euer erstes kleines Experiment? Macht die Teamarbeit wieder großartig und wertvoll!</p><h2>Quellen</h2><p>[1] Herez Moise Kattan, Flavio Soares, Alfredo Goldman, Eduardo Deboni, and Eduardo Guerra. 2018. Swarm or pair? strengths and weaknesses of pair programming and mob programming. In Proceedings of the 19th International Conference on Agile Software Development: Companion (XP ’18). Association for Computing Machinery, New York, NY, USA, Article 43, 1–4. DOI:<a href="https://doi.org/10.1145/3234152.3234169" target="_blank">https://doi.org/10.1145/3234152.3234169</a> </p><p>[2] Jim Buchan and Mark Pearl. 2018. Leveraging the Mob Mentality: An Experience Report on Mob Programming. In Proceedings of the 22nd International Conference on Evaluation and Assessment in Software Engineering 2018 (EASE’18). Association for Computing Machinery, New York, NY, USA, 199–204. DOI:<a href="https://doi.org/10.1145/3210459.3210482" target="_blank">https://doi.org/10.1145/3210459.3210482</a> </p>

Team-oriented development

<p>Mob Programming ist eine Methode, die wir exzessiv eingesetzt haben, um den Wissensaustausch im Team zu fördern, Entwickler-Skills zu schärfen und den Teamzusammenhalt zu erhöhen. Das mögen nicht unbedingt die Primärziele eures Unternehmens sein, aber sie tragen enorm dazu bei, eure eigentlichen Ziele erfolgreich zu erreichen. In diesem Artikel teilen wir mit euch die Ansätze, die wir nutzten, um Mob Programming machbar, effektiv und unterhaltsam zu machen.</p><h2>„Shared Everything“</h2><p>In einem unserer letzten Projekte haben wir Mob Programming eingeführt, um das Hauptziel „Wissensaustausch im Team“ zu erreichen. Wir wollten damit alle Entwickler auf das gleiche Niveau bringen, statt uns mit Titeln, Kategorisierungen und Spezialisierungen aufzuhalten. Das Ergebnis unserer kontinuierlichen Arbeit an einem „Shared Everything“-Mindset war, dass unser „Bus Factor“ sich an unsere Teamgröße annäherte.</p><h2>Bus Factor?</h2><p>In jedem Team findet man einzelne Personen, die ein Silo an spezifischem Wissen darstellen. Wissen, das essentiell für die Ergebnisse und die Performance des Teams entscheidend ist. Wenn eine solche Person nun das Team plötzlich verlässt, wird das gesamte Team darunter leiden.</p><div><a href="https://media.graphassets.com/IStAzEB4R1mKwRHkdBqX"><img src="https://media.graphassets.com/IStAzEB4R1mKwRHkdBqX" alt="bus factor" width="1024" height="1024" /></a> <p>Bild von Lai Man Nung, unsplash</p></div><p><em><strong>Der Bus Factor eines Teams ist die Anzahl der Teammitglieder, die „von einem Bus überfahren werden müssen“, damit ein Team in ernste Schwierigkeiten kommt.</strong></em></p><p>Somit ist der Bus Factor ein Indikator dafür, wie „gesund“ dein Team in Bezug auf Wissenstransfer und Skill-Sharing ist. Ein hoher Bus Factor deutet auf einen guten Wissenstransfer innerhalb des Teams hin.</p><p>Wie haben wir Mob Programming und Shared Everything etabliert?</p><h2>Mob Programming – Ein Abenteuer</h2><div><a href="https://media.graphassets.com/ai9qU79SShqHkJODAYIB"><img loading="lazy" src="https://media.graphassets.com/ai9qU79SShqHkJODAYIB" alt="remote mob session" width="1024" height="640" /></a> <p>Remote Session – Bild von den Autoren</p></div><p>Während des besagten Projektes waren wir in der glücklichen Lage, DDD (Domain-driven Development), TDD (Test-driven Development), und, was wesentlicher war, Mob-Programming-Techniken zu verwenden.</p><p>Wir hatten einen holprigen Start. Mob Programming fühlte sich für uns total fremd an gegenüber der Art der Softwareentwicklung, die wir gewohnt waren. In täglichen Retrospektiven wurde das Gefühl von Verlangsamung beanstandet und man war relativ schnell frustriert, dass man nicht mehr wie gewohnt die Macht über das Keyboard und die damit verbundene Kontrolle hatte. Wir versuchten es, gaben es auf, starteten neu und hörten wieder auf.</p><p>Was wir damit sagen wollen, ist, dass wir am Anfang viel experimentierten. Während dieser Phase wurden wir durch den <a href="http://www.mobprogrammingguidebook.com/images/mobprogrammingguidebook.pdf" target="_blank">Guide von Maaret Pyhäjärvi</a>  inspiriert.</p><p>Wir begannen zu erkennen, dass Wissen im Team viel besser zu den einzelnen Teammitgliedern transferiert wurde und sich auch unsere Codequalität erhöhte.</p><p>Dennoch blieben die Herausforderungen bestehen. Wir waren auch zu Beginn an einem Punkt angekommen, an dem wir diese eigentlich gute Idee aufgeben wollten. Aber wir hatten dann einen sehr guten Workshop mit <a href="https://woodyzuill.com/" target="_blank">Woody Zuill</a> . Dieser Workshop-Tag half uns enorm dabei, festzustellen, dass die Mob-Programming-Technik uns unterstützt, uns selbst als Menschen, aber auch als Team weiterzuentwickeln. Wir waren wieder enthusiastisch! Neben den vielen Tipps und Tricks, die Woody uns mitgab, war eines für uns entscheidend: die Daily Retrospektive. Eine tägliche Retro? Ja. Jeden Tag um ca. 16 h kamen wir für fünf Minuten zusammen. In dieser Retro geht es darum, dass jeder etwas sagt, was an diesem Tag gut gelaufen ist. Wir empfehlen euch, dafür einen Alarm einzurichten, um damit vertraut zu werden.</p><p>Eine weitere Herausforderung bei uns war, dass wir den Fokus auf Remote Mob Programming setzen mussten, da ein Teil unseres Teams über verschiedene Standorte verteilt war. Hierbei holten wir uns Inspiration aus dem <a href="https://www.remotemobprogramming.org/" target="_blank">Guide von Simon Harrer, Jochen Christ, und Martin Huber</a> . Wir mussten einige Regeln etablieren, um Remote-Arbeit für uns erfolgreich zu machen.</p><h3>Einige „Shared Everything“-Regeln</h3><ul><li><strong>Kamera immer an</strong><div><a href="https://media.graphassets.com/nBsdt2CKTaugEPav2jx7"><img loading="lazy" src="https://media.graphassets.com/nBsdt2CKTaugEPav2jx7" alt="webcam" width="1024" height="387" /></a> <p>Bild von Aksa2011, pixabay</p></div><p>Da das Team über verschiedene Standorte verteilt war, war es für uns besonders wichtig, die „Kamera immer an“-Regel zu forcieren. Das hilft allen Teammitgliedern, sich wie „Bürger erster Klasse“ zu fühlen. Es gibt, vor allem für die Remote-Mitglieder, ein besseres „Wir“-Gefühl. Zusätzlich hat es den Vorteil, dass bei Diskussionen und Meetings ein besseres Verständnis erzielt wird, weil man neben der Sprache so auch die Gestik der sprechenden Person mitbekommt. Das bringt uns zur nächsten Regel …</p></li><li><strong>30-Sekunden-Regel</strong><div><a href="https://media.graphassets.com/e0m2vVsRpm7JwKHyBrSw"><img loading="lazy" src="https://media.graphassets.com/e0m2vVsRpm7JwKHyBrSw" alt="timer" width="1024" height="358" /></a> <p>Bild von Aron Visuals, unsplash</p></div><p><strong>Wenn jemand mehr als 30 Sekunden spricht und sich dabei außerhalb der Kamera befindet, kann jeder das Meeting unterbrechen, damit die Situation bereinigt werden kann.</strong></p><p>Da bei uns im primären Projektbüro jeder sein eigenes Notebook verwendete, war es sowieso Standard, dass jeder die ganze Zeit vor der Kamera war.</p><p>In den Business-Meetings mit unseren Stakeholdern war jeder angehalten teilzunehmen, damit wir unsere „Shared-Everything“-Philosophie forcieren konnten. Es war entscheidend, unsere Einrichtung so anzupassen, dass alle Gäste im Raum von den Remote-Mitgliedern/-Teilnehmern deutlich gesehen werden konnten – ob es darum ging, die Körpersprache wahrzunehmen oder einfach nur zu wissen, wer genau spricht. Daher machte diese Regel auch einen Unterschied wie Tag und Nacht. Die zusätzlichen Personen wurden also vor Beginn des Meetings auf die vorhandenen Kameras (Notebooks) verteilt. Die Beteiligten haben in unserem Fall sehr gut mitgespielt.</p></li><li><strong>10-Minuten-Regel</strong><div><a href="https://media.graphassets.com/DmyvaY7MSeUbmWwdKoK3"><img loading="lazy" src="https://media.graphassets.com/DmyvaY7MSeUbmWwdKoK3" alt="speaking" width="1024" height="355" /></a> <p>Bild von Clem Onojeghuo, unsplash</p></div><p>Bei der 10-Minuten-Regel geht es im Wesentlichen darum, dass jeder Teilnehmer ausreichend abgeholt ist. Falls einer der Beteiligten für mehr als zehn Minuten nichts sagte, wurde das Meeting kurz unterbrochen und derjenige sollte kurz den Stand zusammenfassen. Das klingt nach einer harten Regel, ja, aber für uns war es extrem wichtig, dass jeder alles mitbekam. Nur so konnten wir einen guten Wissenstransfer sicherstellen. Üblicherweise ist es ein Indikator, falls jemand eine Weile nichts zu sagen hat, dass derjenige den Faden der Konversation verloren hat.</p></li><li>Brauchst du eine Pause? Nimm dir eine.<div><a href="https://media.graphassets.com/DuweXxQduW8qtM8Yukzw"><img loading="lazy" src="https://media.graphassets.com/CG2UQ6nQnyZQkH1pFB4w" alt="break" width="1024" height="368" /></a> <p>Bild von Alex, unsplash</p></div><p>Mob Programming braucht eine extrem hohe Fokussierung und Aufmerksamkeit von jedem. Hinzu kommt, dass Lernen schnell müde macht. Somit war es jedem in unserem Team erlaubt, eine Pause zu machen, wann immer eine benötigt wurde. Das Positive bei Mob Programming ist, dass man sehr schnell wieder auf dem Laufenden ist, wenn man aus einer Pause zurückkehrt. Wir haben verschiedene Pausenmodelle ausprobiert und sind am Ende bei der individuellen Pause geblieben. Das Einzige, was wir versucht haben zu synchronisieren, war die Mittagspause. Ansonsten konnte sich jeder eine individuelle Pause nehmen, sofern es nötig war. Die Person wurde dann einfach immer an das Ende der Mob-Programming-Liste gefügt und konnte sich somit eine Runde lang aufgleisen.</p></li></ul><p>Bei Business-Meetings haben wir allerdings eine andere Pausenregelung angewandt. Wir haben hier die 45-Minuten-Regel verwendet. Also alle 45 Minuten eine kurze Pause. Das war besonders für unsere Remote-Teilnehmer sinnvoll, weil diese Meetings anstrengend sein können, wenn man nicht unbedingt in seiner Muttersprache folgen muss.</p><p>Die Regeln oben halfen uns während der Mob-Programming-Sessions sehr. Und Mob Programming half uns, das gesamte Wissen an jedes einzelne Teammitglied weiterzugeben. Jeder in unserem Team kannte also jede kleine Ecke unserer Anwendung und konnte an jedem Teil davon arbeiten.</p><h2>Unsere Experimente</h2><p>Wie wir bereits erwähnten, haben wir viel experimentiert. Experimente machen Spaß. So haben wir zum Beispiel verschiedene Ansätze für Mob Programming, die wir in „Dojos“ bei Woody Zuills Workshop gelernt haben, ausprobiert. Wir haben sie strict, soft und freestyle genannt:</p><ul><li><strong>Strict<br /> </strong><a href="https://media.graphassets.com/DuweXxQduW8qtM8Yukzw"><img loading="lazy" width="250" height="117" src="https://media.graphassets.com/DuweXxQduW8qtM8Yukzw" alt="mob-strict-mode" /></a> <br /> Die strikte Art und Weise, Mob Programming durchzuführen, bedeutet, dass ausschließlich der Navigator reden darf. Der Rest darf nur zuschauen. Man darf nicht antworten, auch nicht auf direkt gestellte Fragen. Man kann sich vorstellen, dass das ziemlich schnell frustrierend sein kann. Vor allem, wenn man mit ansehen muss, wie der Navigator anfängt zu straucheln und einem nicht erlaubt ist, zu antworten oder Hinweise zu geben. Allerdings kann das überraschenderweise große Benefits mit sich bringen. Der Navigator zum Beispiel lernt laut zu denken, was wiederum der nächste Navigator aufgreifen kann. Dem Mob Fragen zu stellen ist eine effektive Methode der Kommunikation (auch wenn diese unbeantwortet bleiben)Auf der anderen Seite lernt der Mob, sich in Geduld zu üben und, was wir als wichtiger empfinden, dem Navigator Raum zu lassen, Dinge einfach auszuprobieren. Wenn man gelernt hat, mit diesen Frustrationen umzugehen, wird man merken, dass diese Art und Weise eine sehr friedvolle Technik ist. Keine Diskussionen, keine Argumente. Einfach programmieren und dabei versuchen, den anderen und dessen Gedankengang zu verstehen.</li><li><strong>Soft<br /> <a href="https://media.graphassets.com/uydRh5SZR3yPGmd2bK4M"><img loading="lazy" width="250" height="125" src="https://media.graphassets.com/uydRh5SZR3yPGmd2bK4M" alt="mob-soft-mode" /></a> <br /> </strong>Diese Art ist ähnlich zur strikten Methode, mit dem Unterschied, dass der Mob reden darf, falls eine Frage vom Navigator gestellt wird. Man kann auf Fragen reagieren oder die Hand heben und warten, bis man an der Reihe ist, wenn man einen Hinweis oder eine Idee teilen möchte. Das erlaubt es, einem strauchelnden Teammitglied aktiv helfen zu können. Nichtsdestotrotz kann diese Technik in lange Diskussionen und den Freestyle-Modus abschweifen. Daher ist hier Vorsicht geboten.</li><li><strong>Freestyle<br /> <a href="https://media.graphassets.com/fKtb40bTIOMGAHY3x1Vj"><img loading="lazy" width="250" height="116" src="https://media.graphassets.com/fKtb40bTIOMGAHY3x1Vj" alt="mob-freestyle-mode" /></a> </strong><br /> Im Freestyle-Modus gibt es nur den Driver und alle anderen sind Navigatoren. Jeder darf frei Hinweise, Kommandos, Ideen äußern oder eine Diskussion starten. Wir haben gemerkt, dass es bei dieser Methode wichtig ist, Techniken anzuwenden, die Diskussionen reduzieren. Eine Möglichkeit ist es, die Idee eines Teammitglieds aufzugreifen und durchzuführen, egal ob sie gut oder schlecht endet, statt diese totzudiskutieren. Das Ergebnis kann überraschend sein!</li></ul><p>Wir waren die meiste Zeit im Soft-Modus unterwegs, ein guter Kompromiss zwischen den anderen beiden Modi. Auch haben wir während des Tages immer mal wieder den Freestyle-Modus angewandt. Zudem haben wir uns einen Timeslot pro Tag (maximal eine Stunde) für den strikten Modus genommen, weil wir das Training für Geduld und Lösungsfindung sehr gut fanden.</p><p>Zudem haben wir viel mit der Mob-Programming-Rundenzeit experimentiert. Wir haben sehr kurze (2-3 min), mittlere (5-12 min) und lange (15-25 min) Rundenzeiten ausprobiert. Wir haben eine Zeit ausgewählt und 1-2 Runden Mob Programming durchgeführt. Wir haben festgestellt, dass bei den langen Zeiten sehr schnell der Fokus verloren wurde. Auch bei den zu kurzen Zeiten waren wir uns schnell einig, dass es nicht funktioniert, weil einfach zu wenig Zeit war, wenn man kurz nachdenken wollte oder man eine kleine Diskussion startete. Am Ende haben wir uns bei Zeiten zwischen 6-8 min eingependelt. Das war für uns genug Zeit, um etwas zu erreichen, aber auch, um mal eine kleine Diskussion zu führen.</p><p>Als hundertprozentiges Remote-Team mussten wir uns auch nebenbei noch eine Lösung suchen, um die Driver-Navigator-Wechselzeiten zu verbessern (Push des Codes zu einem dedizierten Git-Branch, Wechsel des Screensharings, etc.). Wir haben sie mittels Bash-Skripten und Disziplin auf ca. 30 Sekunden reduziert. Bei Timern unter 6 min ist das auch ein signifikanter Aspekt.</p><p>Auch haben wir verschiedene Driver-Navigator-Methoden ausprobiert. Viele Teams bleiben beim Navigator-Driver-Pattern. Wir haben nebenbei noch folgende Muster versucht:</p><ul><li><strong>Navigator-Driver-Mob</strong><br /> <a href="https://media.graphassets.com/mYat3uvTS7lsyLYq9INA"><img loading="lazy" width="250" height="101" src="https://media.graphassets.com/mYat3uvTS7lsyLYq9INA" alt="navigator-driver" /></a> <br /> Der Navigator wird zum Driver, der Driver tritt dem Mob bei, und der Nächste aus dem Mob wird zum Navigator.</li><li><strong>Driver-Navigator-Mob</strong><br /> <a href="https://media.graphassets.com/6GDWeccZRiq1Cc0vMH4N"><img loading="lazy" width="250" height="100" src="https://media.graphassets.com/6GDWeccZRiq1Cc0vMH4N" alt="driver-navigator" /></a> <br /> Der Driver wird zum Navigator, der Navigator tritt dem Mob bei, und der Nächste aus dem Mob wird zum Driver.</li><li><strong>Driver-Mob-Navigator-Mob</strong><br /> <a href="https://media.graphassets.com/RAGYBbtkSCiCaeFqzPsp"><img loading="lazy" width="250" height="115" src="https://media.graphassets.com/RAGYBbtkSCiCaeFqzPsp" alt /></a> <br /> Der Driver und der Navigator treten dem Mob bei und die zwei Nächsten des Mobs werden zum Driver und zum Navigator.</li></ul><p><strong>Driver-Navigator-Mob</strong> wurde unser Standard, denn:</p><ul><li>Wenn jemand den Faden verlor, war hierbei die Chance groß, dass derjenige durch die Driver-Rolle wieder aufgegleist wird, bevor er zum Navigator wird.</li><li>Während des Wechsels ist es von Vorteil, wenn der Driver aus dem Mob kommt, da er bereits die nötigen Dateien etc. öffnen kann, bevor es zum Wechsel kommt.</li></ul><p>Aber wir fanden auch die anderen Muster interessant und zum Teil auch hilfreich. Haben wir schon erwähnt, dass wir es sehr mochten zu experimentieren?</p><h2>Psychologische Sicherheit im Mob Programming</h2><p>Die Forschung hat gezeigt, dass psychologische Sicherheit ein starker Prädiktor für die Teamleistung ist. Es ist ein angenehmes Gefühl, sagen zu können, was man denkt, und zu sein, wer man ist, ohne sich zu schämen oder Auswirkungen befürchten zu müssen. Die enge Zusammenarbeit hat uns geholfen, uns als Menschen zu verbinden. Selten gab es in unserem Team etwas wie den „Code eines anderen“, und jeder wusste und fühlte sich mit den Fähigkeiten und persönlichen Umständen des anderen wohl.</p><p>Es ist uns gelungen, uns mehrmals persönlich zu treffen und zusammenzuarbeiten – was sehr vorteilhaft ist. Sich live treffen, abends gemeinsam ein Bier trinken, die Familie des Kollegen kennen lernen – das sind Dinge, die ein Team stärken und vereinigen.</p><h2>Die Ironie des Shared Everything und des Bus Factors</h2><p>Die Verwendung des Mob-Programming-Ansatzes als Teil einer „Shared Everything“-Mentalität kann sehr vorteilhaft sein. Im Laufe des Projekts stellten wir fest, dass sich unser Bus Factor unserer Teamgröße angenähert hatte. Mit anderen Worten: Man hätte im Grunde das gesamte Team auflösen müssen, damit das Wissen und die Fähigkeiten aus dem Projekt verloren gehen. Das ist phänomenal.</p><p>Wir stellten auch eine hohe Zufriedenheit fest, die sich im Team verbreitete. Alle waren leidenschaftlich an den Experimenten und der Zusammenarbeit interessiert. Niemand fürchtete sich zu sagen: „Ich habe das nicht verstanden“, „Können wir das ändern?“ oder: „Wir sollten das mal so versuchen“.</p><div><a href="https://media.graphassets.com/LxVateSEOpHjgdvdHkow"><img loading="lazy" src="https://media.graphassets.com/LxVateSEOpHjgdvdHkow" alt="leaving" width="1024" height="372" /></a> <p>Bild von Ryan Tang, unsplash</p></div><p>Ein hoher Busfaktor schützt das Team, falls die Leute es verlassen. Die Ironie dabei ist jedoch, dass, wenn ein „Shared-Everything“-Team gebildet wird, niemand das Team verlassen will. Wir hatten während dieses Projekts keine Fluktuation in unserem Team.</p><p>Trotz der wirklich interessanten Technologien und des kooperativen Kunden, der an dem Projekt beteiligt war, fasste ein Teammitglied am Ende des Projekts das Gefühl des Teams mit den Worten zusammen: „<em><strong>Ich bin wirklich traurig, dass dieses Projekt zu Ende geht. Nicht wirklich wegen der Projektarbeit, sondern weil ich das Team verliere.</strong></em>“</p>

Mob Programming und Shared Everything

<h4>The coronavirus is thrusting society towards digitalisation. Expect many changes to remain long after the crisis has gone.</h4><p>Mike Chang, Product Owner at Altoread (names changed) briefed his technical staff last week in regards to COVID-19: “We need to prepare for traffic at up to 4x normal levels…”</p><p>Altoread offers readers computer and smartphone-based alternatives to traditional paper books. As libraries shut their physical buildings over the past weeks, they pointed their readers towards such digital services.</p><p>But the second half of Mike’s statement was the most interesting part: “We are expecting this to be a permanent change. After the crisis, traffic will not fall again.”</p><p>COVID-19 has already had a dramatic effect on the world. But much more is to come. As governments prepare to spend “unlimited” amounts of money to prop up their economies, people around the world in various stages of lockdown are being forced to find new ways to get on with work and daily life. They are charting new waters, waters which in many cases, no amount of persuasion up to this point had caused them to venture into. And be it video conference, grocery delivery or online shopping, those waters are almost exclusively digital services.</p><p>Many of the old, non-digital habits will return after COVID-19 is gone, but some won’t. In 2014, a strike on the London Underground closed some tube lines, forcing commuters to create new itineraries using the remaining lines to get to work and back. <a href="https://www.cam.ac.uk/research/news/london-tube-strike-produced-net-economic-benefit" target="_blank">A study</a>  by Oxford and Cambridge universities revealed that after the strike had ended, 5% of passengers continued using their new itinerary, apparently preferring it to their previous route. Could something similar happen in the online space after coronavirus?</p><h2>Digitalisation by force</h2><p>The world was already on a trajectory of going digital. This inevitable change nevertheless takes time. People stick to their old habits, and it’s quite difficult for firms to persuade them to try something new. Grocery shopping is a case in point. In the US, Target famously used customer loyalty-card data to predict, with impressive accuracy, which of its shoppers were in their second trimester of pregnancy. They then bombarded these ladies with promotional material intended to influence them to switch to Target as their main household shopping source. The second trimester of pregnancy, science has revealed, is one of the few times in life that people are especially open to breaking old habits and forming new ones.</p><p>The novel coronavirus has put us into a similar situation, though rather by necessity and force than by hormones or nature. In Spain and some other European countries, police and the armed forces are patrolling the streets and enforcing the lockdown. There is no longer an option to resist digitalisation and avoid “new-fangled stuff”. You no longer have a choice to support your local bricks-and-mortar book seller. You are literally being forced to conduct business online by people carrying guns. That beats even the second trimester.</p><div><a href="https://media.graphassets.com/AKimbKMiTDSNSzrjDRpe"><img src="https://media.graphassets.com/AKimbKMiTDSNSzrjDRpe" alt="Man sweats at computer while armed and masked men say &quot;Just order online&quot;" width="700" height="323" /></a> <p>This gives a new meaning to “One-Click Ordering”. Comic by Florian Schneider.</p></div><h2>Ordering a New World</h2><p>The effect is being felt in digital demand. Amazon is employing 100,000 new warehouse and logistic workers to deal with the increase in orders. Microsoft Teams remote collaboration software has stuttered under sudden demand, whilst the share price of Zoom, a video communications service, has rocketed against the backdrop of a wider market freefall. And as for grocery shopping, Woolworths, an Australian supermarket, has suspended online shopping and delivery in some regions, unable to cope.</p><div><a href="https://media.graphassets.com/v9l8y657R6YxUNn2Ba3e"><img loading="lazy" src="https://media.graphassets.com/v9l8y657R6YxUNn2Ba3e" alt="Empty pasta shelves at a supermarket during COVID-19 crisis" width="640" height="480" /></a> <p>Perhaps shoppers who only know how to cook pasta are preparing for Italy to disappear</p></div><p>The changes are everywhere. Teachers are sharing their contact details with students in order to be able to instruct them remotely, previously a taboo idea for many in their attempt to strictly separate work and private life. Churches are holding services entirely online. “Ghost” music concerts (be it <a href="https://twitter.com/JamesBlunt/status/1238500843030302721" target="_blank">pop</a>  or classical) are being played in empty theatres and broadcast for free. Tomorrow <a href="https://live.theleaddev.com/" target="_blank">Lead Dev Live</a>  will kick off, one of many free online events created to replace a cancelled in-presence conference; over 10,000 people have signed up. Localised small interest groups have switched to online.</p><p>Before Corona, aficionados would probably have told you that these events can only be conducted in-person. Isn’t the entire purpose of church, or a software conference, physically coming together to socialise, interact and exchange ideas? Live-recorded music concerts were always just a flavour of recorded music. Homeschooling is/was either banned or vaguely tolerated in most countries. But when it’s virtual or nothing, virtual suddenly has virtue.</p><h2>Borders close. Online communities open.</h2><p>These approaches are already opening new horizons. This month, codecentricer Chris Dutz will present live from his home in Frankfurt, Germany at the Melbourne, Australia IoT meetup. The Lead Dev London could never have handled so many attendees at the physical conference – this newfound reach might be something the organisers would like to continue. Will virtual meetups continue after the crisis, defined by time and language rather than by region? In the education space homeschooling is unlikely to take off, but expect to see a few new methods filter through into normal practise after the crisis.</p><div><a href="https://media.graphassets.com/KYi4gEHmQN2WTxjKc6aV"><img loading="lazy" src="https://media.graphassets.com/KYi4gEHmQN2WTxjKc6aV" alt="A video conference" width="600" height="263" /></a> <p>As long as each participant in a video conference remains 1m from his monitor, the mandated 2m is maintained between any two participants at all times.</p></div><p>Earlier in the crisis, when social distancing was only beginning to be encouraged, there were reports on Twitter of managers continuing to insist that employees come to the office, because permitting employees to work from home “might create a precedent”. In other words, after COVID-19 crisis has passed, people might ask their bosses why they shouldn’t continue to <a href="https://blog.codecentric.de/en/category/remote/">work from home</a> : “I avoided a long commute, I was able to work without distractions, and as you can see, I got more done than ever.”</p><p>Assuming the reports are true, these managers are spot on. Employees will request this and more, and citizens will make other changes. The net effect on society is going to be a sudden jump forward in digitalisation, where heretofore unreachable people, having broken down the mental or cultural barrier, jump on the train of online shopping, banking and other services.</p><h2>Reopening unemployment</h2><p>Sadly, many of the businesses which are hardest hit right now will also carry the cost of this change forever. Bricks and mortar stores might struggle to reopen, only to find that 10% of their customers have permanently disappeared. Employee layoffs could create structural unemployment – a situation in which existing skills have become irrelevant and previously talented people become unemployable. It’s not an easy problem to solve, and governments will be further restricted in their ability to help by the debt which they have racked up during their “save the economy” spending sprees.</p><p>The future is bright for digitalisation enablers like codecentric. Management consults tell me of their attempts to convince heads of business that they are not, for example, a bank which has some supporting IT, they are an IT company which offers banking services. This message is getting easier to understand. The need for digital enablement support in every type of company will only increase.</p><p>Hopefully, companies like codecentric can also help with the structural unemployment. We can’t work miracles with totally unqualified people, but we do try hard to make our hiring as inclusive as possible – the qualifications to work with us are soft rather than hard. Demonstrating initiative and a deep desire to learn can be worth more to us than a university degree. Besides listing open positions, we also accept applications for any unlisted job – maybe <a href="https://www.codecentric.de/karriere/" target="_blank">we need you</a>  and we just don’t know it yet.</p><p>As for those digital reading services, Altoread is perfectly positioned to handle the surge in demand from the bunkered-down bookworms. codecentric helps them to run their digital services as a cloud-native company. This enables them to automatically scale their IT infrastructure up to cope with surges in customer traffic. As the traffic drops again, the systems scale back down. That is, if the traffic ever drops down again.</p>

Death, downturn and dramatic digitalisation – COVID-19’s legacy-to-be

<p><span>Mob programming is a technique we use extensively for sharing knowledge in the team, improving developer skills and increasing team cohesion. These might not be the primary goals of your business, but they probably contribute much more than you realise to achieving your goals. In this article, we share the techniques we have developed to make Mob programming feasible, fun and effective.</span></p><h2><span>“Shared everything”</span></h2><p><span>In a recent project, we introduced mob programming as part of our goal to share everything inside our team. We wanted to have all developers on the same level, rather than having titles, categorisations and specialisations. As a result of consistently applying a “shared everything” mindset, our team’s “bus factor” approached the team size.</span></p><h2><span>Bus factor?</span></h2><div><a href="https://media.graphassets.com/IStAzEB4R1mKwRHkdBqX"><img src="https://media.graphassets.com/IStAzEB4R1mKwRHkdBqX" alt="bus factor" width="1024" height="1024" /></a> <p>– Image by Lai Man Nung - unsplash</p></div><p><i><span>In any team, there are individuals who are the sole possessors of specific knowledge, knowledge which is essential to the team’s performance and the outcomes. If these people were to suddenly leave the team, the team would suffer.</span></i></p><p><b><i>The bus factor of a team is the number of team members that would need to be “hit by a bus” before the team would end up in serious trouble.</i></b></p><p><i><span>So the bus factor indicates how healthy your team is regarding knowledge transfer and skill sharing. A high bus factor indicates healthy knowledge sharing and a healthy team.</span></i></p><p><span>How did we apply mob programming and “shared everything”?</span></p><h2><span>Mob programming – An adventure</span></h2><div><a href="https://media.graphassets.com/ai9qU79SShqHkJODAYIB"><img loading="lazy" src="https://media.graphassets.com/ai9qU79SShqHkJODAYIB" alt="remote mob session" width="1024" height="640" /></a> <p>– Remote mob programming session – Screenshot by the authors</p></div><p><span>During the project in question, we were lucky enough to use DDD (Domain Driven Design), TDD (Test Driven Development), and more importantly mob programming techniques.</span></p><p><a href="https://media.graphassets.com/nBsdt2CKTaugEPav2jx7"><img loading="lazy" src="https://media.graphassets.com/nBsdt2CKTaugEPav2jx7" alt="mob-in-a-nutshell" width="1024" height="867" /></a> </p><p><em>Mob programming in a nutshell: You have one computer and three or more developers. One is typing (driver), one or the rest of the developers lead the driver and give commands (navigator-s). The whole team is working on the same issue at the same time. See the different mob programming modes in the experiment section.</em></p><p><span>Initially we had a bumpy start. Mob programming felt completely different to the software development we were used to. A feeling that we might not be moving fast enough was repeatedly mentioned in retrospectives, and there was the frustration of not being able to take the keyboard and control. We tried it, abandoned it, restarted, and stopped again.</span></p><p><span>In the beginning, we experimented a lot and were inspired by the <a href="http://www.mobprogrammingguidebook.com/images/mobprogrammingguidebook.pdf">Guide from Maaret Pyhäjärvi</a> .</span></p><p><span>We started to see how knowledge was being transferred to every team member and code quality seemed to be increasing.</span></p><p><span>Nevertheless, the challenges continued. Just when we were about to give up the idea for good, we had a great mob programming workshop with <a href="https://woodyzuill.com/">Woody Zuill</a> </span><span>. This helped us to see how the technique allowed us to develop as people and as a team, and we were enthusiastic again! Among the many ideas we picked up from Woody was the practice of a daily retrospective. Generally we did this at about 4pm and tried to keep it to 5 minutes. In the daily retro everyone said something which went positive during the day. To get used to it, we needed to set up an alarm.</span></p><p><span>We needed to focus on </span><i><span>remote</span></i><span> mob programming, because the team members were spread over different locations. Here we got inspired by a <a href="https://www.remotemobprogramming.org/">remote mob programming guide</a>  from Simon Harrer, Jochen Christ, and Martin Huber</span><span>. We needed to establish a few rules …</span></p><h3><strong>Some “shared everything” rules</strong></h3><ul><li><b><b>Camera always on<br /> </b></b><div><a href="https://media.graphassets.com/e0m2vVsRpm7JwKHyBrSw"><img loading="lazy" src="https://media.graphassets.com/e0m2vVsRpm7JwKHyBrSw" alt="webcam" width="1024" height="387" /></a> <p>– Image by Aksa2011, pixabay</p></div><p><span>Since the team was spread over several locations, it was important for us to define the “</span><b>Camera always on</b><span><span>” rule. That helped that all team members felt like first-class citizens. It gives you a better ‘we’ feeling, especially for the remote members. Additionally, it promotes a better understanding in discussions and meetings, because you will get the gestures of the speaking person. Which brings us to the next rule…</span></span></p></li></ul><p> </p><ul><li><b><b>30-second rule<br /> </b></b><div><a href="https://media.graphassets.com/DmyvaY7MSeUbmWwdKoK3"><img loading="lazy" src="https://media.graphassets.com/DmyvaY7MSeUbmWwdKoK3" alt="timer" width="1024" height="358" /></a> <p>– Image by Aron Visuals, unsplash</p></div><p><b>If a person speaks for more than 30 seconds off-camera, the meeting must be interrupted in order to force corrections.<br /> </b>Since every one of us in our primary project office had their own notebook with a camera, most of the time everyone was on camera by default. However, typically stakeholders would visit us for meetings. In order to enforce our “shared everything” philosophy, everyone needed to participate in these meetings on equal footing. It was critical to adjust our setup so that all the guests in the room could clearly be seen by the remote members/participants. Whether for catching body language or simply for being aware of who exactly was speaking, this rule makes a difference like night and day. So, the extra persons were distributed to the existing notebooks (cameras), before the meeting started. The stakeholders were extremely co-operative.</p></li></ul><p> </p><ul><li><b><b><b><b>10-minute rule<br /> </b></b></b></b><div><a href="https://media.graphassets.com/CG2UQ6nQnyZQkH1pFB4w"><img loading="lazy" src="https://media.graphassets.com/CG2UQ6nQnyZQkH1pFB4w" alt="speaking" width="1024" height="355" /></a> <p>– Image by Clem Onojeghuo, unsplash</p></div><p><b><b><b><span>If a remote participant doesn’t say anything for 10 minutes, stop the meeting and ask them to say something or summarise the last minutes. Sure, that is a hard rule, but for us it was important that everyone understood the matter of the meetings and kept the knowledge spread. If someone doesn’t talk for a while, it’s usually an indicator that they have lost track of what is going on.</span></b></b></b></p></li></ul><p> </p><ul><li><b><b>Do you need a break? Take one.<br /> </b></b><div><a href="https://media.graphassets.com/DuweXxQduW8qtM8Yukzw"><img loading="lazy" src="https://media.graphassets.com/DuweXxQduW8qtM8Yukzw" alt="break" width="1024" height="368" /></a> <p>– Image by Alex, unsplash</p></div><p><b><span>Mob programming needs high attention and focus, and learning is tiring. Everyone in the team should be allowed to take a break whenever it is needed. The positive thing while doing mob programming is that this person will get back into the flow quickly.<br /> </span></b><span>We tried various break techniques, and generally settled on the “individual breaks” technique. We generally synchronised lunch, but otherwise there were no agreed breaks. Any person could take a short break whenever they felt it was necessary. When they came back we simply put them on the end of the list. This avoided discussion and organisation. And the person could get in again easily.</span></p></li></ul><p><span>For business meetings of course, you need to take breaks together. Here we established another rule – the “45-minute rule”, which basically meant a forced break every 45 minutes. Meetings are quite stressful for remote participants who are not speaking their native language. This helps them to stay tuned in.</span></p><p><span>The rules above helped us a lot while doing mob programming. And mob programming helped us a lot to spread all the knowledge to every single team member. So, everyone on this team knows every small corner of our application and was able to work on every part of it.</span></p><h2><span>Experiments for the win</span></h2><p><span>As we mentioned earlier, we did a lot of experiments. Experiments are fun. So, for example, we tried to do mob programming in three different ways which we learned as “Dojos” from Woody Zuill during his workshop. We called them strict, soft, and freestyle.</span></p><p> </p><ul><li><b>Strict<br /> <a href="https://media.graphassets.com/uydRh5SZR3yPGmd2bK4M"><img loading="lazy" src="https://media.graphassets.com/uydRh5SZR3yPGmd2bK4M" alt="mob-strict-mode" width="250" height="117" /></a> <br /> </b><span><span>The strictest implementation of the driver-navigator pattern. Only the navigator is allowed to speak, others simply watch. Literally, they may not speak, even to answer questions.</span></span>This very quickly becomes frustrating for the mob as they see the navigator struggling but are not allowed to give them any answers. Surprisingly, this can create great benefits. The navigator learns to think out loud so that the next navigator can easily take over. Asking the mob questions (which go unanswered) is a surprisingly effective method of communication.The mob learns patience, and the vital art of letting someone else have a go; trying someone else’s ideas out. Once you learn to handle the frustration, you find that this is the most peaceful technique of all. No discussion, no arguments. Just coding and trying to understand each other.</li></ul><p> </p><ul><li><b>Soft</b><span><br /> </span><i><span><a href="https://media.graphassets.com/fKtb40bTIOMGAHY3x1Vj"><img loading="lazy" src="https://media.graphassets.com/fKtb40bTIOMGAHY3x1Vj" alt="mob-soft-mode" width="250" height="125" /></a> <br /> </span></i><span><span>This is similar to the strict technique, but the mob is allowed to speak when requested by the navigator. They can answer questions and also raise their hands and wait until they are asked to speak. This removes some of the seeming stupidity of the strict technique when you watch a teammate flounder. However, if you are not careful, this technique can degrade into long discussions and “freestyle”.</span></span></li></ul><p> </p><ul><li><b><b>Freestyle<br /> <a href="https://media.graphassets.com/mYat3uvTS7lsyLYq9INA"><img loading="lazy" src="https://media.graphassets.com/mYat3uvTS7lsyLYq9INA" alt="mob-freestyle-mode" width="250" height="116" /></a> <br /> </b></b>In freestyle mode there is one driver and the rest of the team members are navigators. Everyone is free to give a command, mention an idea, or start a discussion. We found that in this mode it was important to apply techniques to reduce discussion. One such technique is just accepting the idea of a colleague and trying it out to prove it good or bad, instead of discussing it to death. Often the result is surprising!</li></ul><p><span>We think we ended up in the soft mode most often – a good compromise between other techniques. Freestyle felt like a natural thing to do a bit every day too. But, we found that we had to reserve a time slot (maximum of 1 hour) for doing the strict mode because we valued this training in solution finding and patience, but one doesn’t just accidentally fall into doing something that feels so unnatural.</span></p><p><span>We also experimented with the mob programming time. So, we tried to set the timer to a very low (2-3 minutes), medium (5-12 minutes), and high (15-25 minutes) time. And then we started to mob for 1 to 2 rounds. We figured out that a timer set too high will cause followers to lose their focus. Also, too low times are bad because you start, think about something, start a small discussion and boom …. the time is over. At least, we stick to 6-8 minutes for a driving round. It was enough time for us to get something done, but also to discuss a little about an idea.</span></p><p><span>As a remote team, we also had to factor in the overhead of switching (pushing to a dedicated Git branch, switching screen sharing). We managed to reduce this to 30 seconds when we were disciplined, but no further. So with a timer of less than about 6 minutes, this became a significant aspect.</span></p><h3>What about the mob programming patterns</h3><p><span>Another thing we tried are different ways of driver-navigator patterns. Many teams are stuck on the navigator-driver-mob pattern. We tried every possible variation:</span></p><p> </p><ul><li><b>Navigator-driver-mob<br /> <a href="https://media.graphassets.com/6GDWeccZRiq1Cc0vMH4N"><img loading="lazy" width="250" height="101" src="https://media.graphassets.com/6GDWeccZRiq1Cc0vMH4N" alt="navigator-driver" /></a> <br /> </b>The navigator becomes the driver, the driver joins the mob, and the next out of the mob becomes the navigator.</li></ul><p> </p><ul><li><b>Driver-navigator-mob<br /> <a href="https://media.graphassets.com/RAGYBbtkSCiCaeFqzPsp"><img loading="lazy" width="250" height="100" src="https://media.graphassets.com/RAGYBbtkSCiCaeFqzPsp" alt="driver-navigator" /></a> <br /> </b>The driver becomes the navigator, the navigator joins the mob, and the next out of the mob becomes the driver.</li></ul><p> </p><ul><li><b>Driver-mob-navigator-mob<br /> <a href="https://media.graphassets.com/LxVateSEOpHjgdvdHkow"><img loading="lazy" width="250" height="115" src="https://media.graphassets.com/LxVateSEOpHjgdvdHkow" alt /></a> <br /> </b>The driver and the navigator join the mob and the next two of the mob become the driver and the navigator.</li></ul><p><i><span>Driver-navigator-mob</span></i><span> became our default order, because:</span></p><ul><li><span>If someone lost touch with what was going on, they had a better chance to mentally get back into it as a driver before becoming navigator. </span></li><li><span>The changeover friction is reduced when the driver comes from the mob. They can ensure they have the right programs and classes open 30 seconds before changeover, which isn’t practical when they’re trying to navigate.</span></li></ul><p><span>However, at various times we found the other patterns to be interesting and helpful. Did we mention it before? We loved to experiment.</span></p><h2><span>Psychological safety</span></h2><p><span>Research has shown that psychological safety is a strong predictor of team performance. This is basically feeling comfortable to say what you think and be who you are without embarrassment or fear of repercussions. Collaborating together so closely helped us bond as people. There was rarely such a thing as “someone else’s code”, and everyone knew and was comfortable with everyone else’s capabilities and personal circumstances.</span></p><p><span>We managed to meet and work together in person a number of times – something which is very beneficial. Meet live, have a beer together in the evening, meet the family of your colleague – these are things which strengthen a team into a unit.</span></p><h2><span>The irony of shared everything and bus factor</span></h2><p><span>Using the mob programming approach as part of a “shared everything” mindset can be very beneficial. As the project went on, we noticed that our bus factor had approached our team size. In other words, you would basically need to remove the entire team for the knowledge and skills to be lost from the project. This is quite a phenomenal result.</span></p><p><span>We also discovered a high satisfaction spread through the team. Everyone was passionate about doing the experiments and working with each other. No-one feared to say “I didn’t get this”, “could we change this?” Or, “we should try this”.</span></p><div><a href="https://media.graphassets.com/czdEdbSNSSeqOmZFiPz7"><img loading="lazy" src="https://media.graphassets.com/czdEdbSNSSeqOmZFiPz7" alt="leaving" width="1024" height="372" /></a> <p>– Image by Ryan Tang, unsplash</p></div><p><span>High bus factor protects the team in the case that people leave it. Yet the irony of this is, when a “shared everything” team is established, no-one wants to leave. We had no fluctuation in our team during that project.</span></p><p><span>Despite the really interesting technologies and co-operative customer involved in the project, at the end of the project one team member summed up the team feeling by saying “I’m really sad that this project is ending. Not really because of the project work, but because of losing the team”.</span></p>

Mob programming and shared everything

Staff Engineer

<div><a href="https://media.graphassets.com/wtYRn5XsRKyngX9rLvgl"><img loading="lazy" title="MongoDB World Tour 2012" src="https://media.graphassets.com/wtYRn5XsRKyngX9rLvgl" alt="MongoDB World Tour 2012" width="180" height="240" /></a> <p>MongoDB World Tour 2012</p></div><p>Im Rahmen der MongoDB World Tour 2012 hat 10gen, die Firma hinter MongoDB, Station in der bayerischen Landeshauptstadt gemacht.</p><dl><dt></dt></dl><p>Die <a href="http://www.10gen.com/events/mongodb-munich" target="_blank">eintägige Konferenz</a>  im Hilton Park Hotel drehte sich natürlich voll und ganz um MongoDB in all seinen Facetten. Dabei war das Programm ein guter Mix aus Vorträgen von 10gen Ingenieuren sowie von Vorträgen aus der mittlerweile doch sehr großen deutschen Benutzergemeinde. So verwundert es auch nicht, dass die Konferenz mit über 200 Besuchern für eine Herstellerkonferenz erstaunlich gut besucht war. Und wie verschiedene Umfragen während der Vorträge zeigten, setzen viele dieser Besucher MongoDB auch bereits produktiv ein. Dabei ist die Datengröße dieser Installationen meist noch im unteren Gigabyte-Bereich, lediglich wenige Anwender setzen schon Datenbanken im Petabyte-Bereich ein.</p><p>codecentric ist bereits seit April dieses Jahres Partner von 10gen und arbeitet eng mit diesen zusammen. So wurden u.a. die Benutzergruppen in Düsseldorf und Frankfurt erfolgreich gestartet sowie auch die ersten Projekte.  Daher war es nur logisch, dass wir uns auch an der Konferenz mit zwei eigenen Beiträgen beteiligt haben.</p><p><span></span></p><p> </p><div><a href="https://media.graphassets.com/9loBkixRRyu6BIgje3os"><img loading="lazy" title="Tobias Trelle @ MongoDB Munich 2012" src="https://media.graphassets.com/9loBkixRRyu6BIgje3os" alt="Tobias Trelle @ MongoDB Munich 2012" width="225" height="300" /></a> <p>Tobias Trelle @ MongoDB Munich 2012</p></div><p><a href="https://twitter.com/tobiastrelle" target="_blank">Tobias Trelle</a> , Senior IT Consultant am Standort Düsseldorf, hat eine umfassende Einführung in Spring Data MongoDB gegeben. Spring ist ein in der Java-Welt weit verbreitetes Framework für leichtgewichtige Enterprise Applikationen, welches eine sehr schöne Abstraktionsschicht für Java-Applikationen darstellt. Unterstützung für relationale Datenbanken bietet das Teilprojekt Spring Data JPA schon seit längerem. Im Zuge der NoSQL-Bewegung wurde das <a href="http://www.springsource.org/spring-data" target="_blank">Spring Data Projekt</a> , angetrieben von <a href="https://twitter.com/olivergierke" target="_blank">Oliver Gierke</a> , auf diverse NoSQL-Datastores ausgeweitet und es gibt u.a. mit Spring Data MongoDB ein Teilprojekt, welches den Zugriff aus Java-Applikationen heraus auf Dokumente in MongoDB vereinfacht. Die Folien seines Vortrages finden sich auf <a href="http://de.slideshare.net/tobiastrelle/mongodb-munich-2012-spring-data-mongodb" target="_blank">Slideshare</a> :</p><div><div><div><p>Klicken Sie auf den unteren Button, um den Inhalt von de.slideshare.net zu laden.</p><p><a href="#">Inhalt laden</a> </p></div></div><div></div></div><p> </p><p> </p><div><a href="https://media.graphassets.com/f6mHNSdtTf2Td8Bjn0tK"><img loading="lazy" title="Uwe Seiler @ MongoDB Munich 2012" src="https://media.graphassets.com/f6mHNSdtTf2Td8Bjn0tK" alt="Uwe Seiler @ MongoDB Munich 2012" width="300" height="168" /></a> <p>Uwe Seiler @ MongoDB Munich 2012</p></div><p><a href="https://twitter.com/uweseiler" target="_blank">Ich selbst</a> <span>, Senior IT Consultant am Standort Frankfurt, habe einen Vortrag zum Thema „Map/Confused? – A practical approach to Map/Reduce with MongoDB“ gegeben, in dem ich die Möglichkeiten und Limitierungen der verschiedenen Ansätze der Verwendung des Map/Reduce-Verfahren innerhalb von MongoDB  dargestellt habe. Die verschiedenen Möglichkeiten dabei sind Map/Reduce in der JavaScript-Engine von MongoDB, das mit Version 2.2 eingeführte Aggregation Framework sowie das Zusammenspiel mit Apache Hadoop mittels des MongoDB-Hadoop-Adapters. Diese Ansätze habe ich in einer praxisorientierten ersten Annäherung v.a. auf ihre Performance hin untersucht. Auch diese Folien finden sich auf <a href="http://de.slideshare.net/uweseiler/mapconfused-a-practical-to-mapreduce-with-mongodb" target="_blank">Slideshare</a> :</span></p><p></p><div><div><div><p>Klicken Sie auf den unteren Button, um den Inhalt von de.slideshare.net zu laden.</p><p><a href="#">Inhalt laden</a> </p></div></div><div></div></div><p> </p><p>Weitere persönliche Highlights unter den Vorträgen waren für mich die folgenden:</p><ul><li>Mit <a href="https://twitter.com/mathias_mongo" target="_blank">Mathias Stearn</a>  war einer der Core Developer von 10gen (er selbst hat sich als Nummer 6 bezeichnet) unter den Speakern und hat das neue Aggregation Framework vorgestellt. Dabei kam der Vortrag komplett ohne Powerpoint aus und wurde komplett in der Shell gehalten. Alleine das war natürlich schon purer Geek Porn und neben dem fundierten Wissen einfach sehr angenehm zuzuhören und -schauen. In einem weiteren Vortrag hat er dann noch die Interna des Jornalings und der Storage Engine vorgestellt und da er das alles selbst programmiert hat, kann man sich vorstellen, dass wirklich sehr tief in die Interna geschaut wurde und man konnte noch viel dabei lernen.</li></ul><p> </p><ul><li><a href="https://twitter.com/tomassino" target="_blank">Tomislav Zorc</a>  und <a href="https://twitter.com/Bernd_Z" target="_blank">Bernd Zuther</a>  haben ihre „Pizza Shardoni“ vorgestellt. Dabei handelt es sich um einen sehr schönen Showcase, der mit Hilfe von MongoDB und Wicket erstellt wurde. Der Kern des Showcases ist der Pizzabäcker Mario, der durch ein neues Herstellungsverfahren München mit 500.000 Pizzen pro Sekunde beliefern kann. Auf dieser Idee wurde ein Bestellsystem sowie ein Reporting programmiert und eindeutiges Highlight war, als alle Zuhörer über ihre Mobile Devices angefangen haben, Pizzen zu bestellen.</li></ul><p> </p><ul><li>Christian Brensing, Senior Developer, hat ein Projekt vorgestellt in dem die Applikation BayerText des Freistaates Bayern zur Verwaltung und Erstellung von Serienbriefen von Oracle auf MongoDB umgestellt wurde. Besonders interessant waren dabei seine Ausführungen, wie man die in MongoDB fehlende Transaktionalität einfach auf der Applikationsschicht implementieren kann. Schön war auch ein Punkt seines abschließenden Fazits: „Developing the data layer is fun again!“</li></ul><p> </p><p>Eröffnet und beendet wurde die Konferenz standesgemäß von <a href="https://twitter.com/jonnyeight" target="_blank">Alvin Richards</a> , Technical Director for EMEA, von 10gen. Besonders interessant war dabei sein Ausblick auf die kommende Version 2.4 von MongoDB. Überraschend war vor allem der Zeitpunkt, welcher mit Winter 2012 angegeben wurde. Was das genau heißen mag wird die Zukunft zeigen, aber es ist ein eindeutiger Hinweis auf einen wieder kürzeren Releasezyklus. Zudem hat er mögliche Neuigkeiten angedeutet, wobei er deutlich darauf hingewiesen hat, dass der Umfang immer im Fluss ist und dass die einzige Wahrheit im öffentlich zugänglichen JIRA von 10gen steht. Ich freue mich besonders auf V8 und bin gespannt auf den erwarteten Performancezuwachs.</p><div><a href="https://media.graphassets.com/plNx2WE7RbSMNsj29EVr"><img loading="lazy" title="Highlights of MongoDB 2.4" src="https://media.graphassets.com/plNx2WE7RbSMNsj29EVr" alt="Highlights of MongoDB 2.4" width="700" height="525" /></a> <p>Highlights of MongoDB 2.4</p></div><p><span>Insgesamt war es ein rundum gelungener Tag rund um MongoDB, die Organisation und die Verpflegung ließ absolut keine Wünsche offen und es gab eine Menge an interessanten Gesprächen und Diskussionen. Daher freue mich schon auf die Neuauflage 2013 und wer bis dahin zum Thema MongoDB auf dem Laufenden bleiben will, sei zum Abschluss noch einmal in eine der MongoDB User Groups in eurer Nähe eingeladen.</span></p><p></p>

Eindrücke von der MongoDB Munich 2012

Einführung in Hadoop – Die wichtigsten Komponenten von Hadoop (Teil 3 von 3)

<h2>MongoDB</h2><p><strong>MongoDB</strong> (abgeleitet vom engl. <em>hu<strong>mongo</strong>us</em>, „gigantisch“) ist eine hochperformante, schema-freie, dokumentenorientierte Open-Source-Datenbank, die in der Programmiersprache C++ geschrieben ist.<span> </span>Da die Datenbank dokumentenorientiert ist, kann sie Sammlungen von JSON-ähnlichen Dokumenten verwalten. So können viele Anwendungen Daten auf natürlichere Weise modellieren, da die Daten zwar in komplexen Hierarchien verschachtelt werden können, dabei aber immer abfragbar und indizierbar bleiben. Eine kurze Einleitung, die die ersten Schritte mit MongoDB erklärt, gibt <a href="/wissens-hub/blog/spring-data-mongodb-2" target="_blank">dieser Artikel</a> .</p><p><span></span></p><p>Bei MongoDB handelt es sich um eine NoSQL-Datenbank, wobei NoSQL ein Sammelbegriff für eine Vielzahl von unterschiedlichen Datenbanklösungen ist, welche sich besser als „Nicht-relationale Datenbanken“ beschreiben lassen. Ihren Ursprung hatten diese Lösungen in der Erkenntnis, dass gerade für Big Data Probleme „traditionelle“ relationale Datenbanken (RDBMS) mit ihren meist starren Schemas und normalisiert in Tabellen gepressten Daten nicht die ideale Lösung sind. Zudem ist man in Sachen der Skalierbarkeit von RDBMS immer häufiger an Performance- und Kostengrenzen gestoßen. Entsprechend hat man nach anderen Lösungen für diese Probleme gesucht. Ein großer Treiber hinter der NoSQL-Bewegung ist sicherlich das Internet und die Bedürfnisse von Webapplikationen, da gerade dort die Datenmengen immer größer werden, gleichzeitig werden diese Daten aber auch immer vernetzter und gerade durch die zunehmende Benutzerinteraktion des Web 2.0 werden die Daten auch immer individueller und nicht mehr klar strukturiert. Bekannteste Beispiele für auf diesen Überlegungen basierende NoSQL-Lösungen sind dabei sicherlich Google mit ihrem 2004 entstandenen <a href="http://de.wikipedia.org/wiki/BigTable" target="_blank">BigTable-Ansatz</a>  zur Speicherung ihres Suchmaschinen-Indexes sowie Amazon mit seinem 2007 publizierten <a href="http://de.wikipedia.org/wiki/Amazon_Dynamo" target="_blank">Dynamo-Ansatz</a> , welcher die Basis für die Amazon Web Services bildet. Ebenso ist auch die Erfolgsgeschichte von sozialen Netzwerken auf der technischen Seite eng mit der NoSQL-Bewegung verbunden.</p><p>Ich persönlich finde die NoSQL-Bewegung sehr spannend, da sie meiner Meinung nach stark dazu beigetragen hat, das jahrelang vorherrschende und selten hinterfragte Mantra „Datenhaltung = RDBMS“ aufzubrechen und man sich nun noch intensiver mit der eigentlichen Struktur der Daten und den Anforderungen an eine Datenhaltungslösung beschäftigt. Und die NoSQL-Bewegung gibt einem dazu eine Vielzahl von unterschiedlichen Lösungen und Ansätzen an die Hand, welche zum großen Teil auch noch als Open-Source verfügbar sind. Der Markt für NoSQL-Datenbanken ist dabei über die Jahre auch immer mehr gereift und erreicht meines Erachtens nach langsam die Spitze seines <a href="http://en.wikipedia.org/wiki/Hype_cycle" target="_blank">Hype Cycles</a> . Gleichzeitig ist der Markt für NoSQL-Lösungen aber trotzdem immer noch recht dynamisch, neue NoSQL-Lösungen entstehen und manche vielversprechende Projekte wurden auch schon wieder eingestellt. Bei dieser Entwicklung hat sich MongoDB als die gemessen an der Anzahl der Downloads <a href="http://gigaom.com/cloud/theres-a-lotta-mongodb-out-there-hadoop-too-infographic/" target="_blank">populärste NoSQL-Lösung</a>  herauskristallisiert und wird aufgrund seiner Einfachheit in der Handhabung und der breiten Funktionalität auch gerne als „Einstiegsdroge“ in die NoSQL-Welt bezeichnet. Doch auch bei allem gegenwärtigen Hype um NoSQL, darf man nicht vergessen, dass auch NoSQL-Datenbanken keine eierlegenden Wollmilchsäue sind und allein deren Einsatz automatisch alle Probleme löst. Auch sind deswegen „traditionelle“ RDBMS und SQL  noch lange nicht tot, sondern haben in vielen Anwendungsgebieten nach wie vor unschlagbare Vorteile. Sicher ist aber, wenn es heutzutage um die Architektur von Datenhaltungslösungen geht, dass man nicht mehr einäugig sein darf und sich mit den Vor- und Nachteilen von NoSQL auseinander setzen sollte, um so die passende Lösung für sein spezifisches Problem zu finden.</p><h2>MongoDB User-Gruppe Frankfurt</h2><h2><a href="https://media.graphassets.com/gCubYypDSkuNNJ4bunki"><img loading="lazy" title="Title Image MongoDB User-Gruppe Frankfurt" src="https://media.graphassets.com/gCubYypDSkuNNJ4bunki" alt width="734" height="55" /></a> </h2><p>codecentric ist seit April dieses Jahres stolzer Consulting & Service Partner von 10gen, der Firma hinter MongoDB. Weiterhin wurden im Mai dieses Jahres bereits die ersten <a href="https://www.codecentric.de/2012/05/11/mongodb-trainings-in-deutschland/" target="_blank">Schulungen zum Thema Entwicklung und Administration von MongoDB</a>  erfolgreich in Zusammenarbeit mit Trainern von 10gen durchgeführt. Diese sind auf reges Interesse gestoßen und es werden sicherlich nicht die letzten Schulungen dieses Jahr bleiben.</p><p>Aufgrund des Interesses habe ich daher vor kurzem in Zusammenarbeit mit 10gen die regionale User-Gruppe zum Thema MongoDB in Frankfurt gegründet. Diese folgt der bereits von meinem Kollegen Tobias Trelle initiierten MongoDB User-Gruppe in Düsseldorf , welche bereits ihr ersten Treffen mit einem hochinteressanten Beitrag zu „Spring Data MongoDB“  von <a href="https://twitter.com/#!/olivergierke" target="_blank">Oliver Gierke</a>  (SpringSource) hatte.</p><p>Ziel der User-Gruppe ist der regelmäßige Informationsaustausch und die Vernetzung zwischen MongoDB-Usern aus dem Großraum Frankfurt (und auch gerne darüber hinaus). Dazu bieten sich zum einen die Foren in XING zum virtuellen Austausch an, zum anderen schlägt aber natürlich nichts den persönlichen Austausch. Daher wird es monatliche Treffen der User-Gruppe im Raum Frankfurt geben, auf welchen wir Vorträge rund um das Thema MongoDB anbieten wollen und hoffentlich auch in rege Diskussionen kommen. Ich bin aktuell noch an der Planung des ersten Treffens, die Ankündigung findet zeitnah auf XING statt.</p><p>Ich freue mich auf neue interessierte Mitglieder und den gemeinsamen Erfahrungsaustausch. Let’s MongoDB!</p>

MongoDB User-Gruppe Frankfurt

<p>So lässt sich die Fragestellung dieses zweiten Teils gut zusammenfassen und wird noch ergänzt durch die Frage „Und wie viel davon?“. Tatsächlich gibt es so etwas wie ein allgemein anerkanntes „Standard“-Hadoop nicht und am nächsten dran sind hier noch die Open Source Projekte der Apache Foundation. Aber zu Apache Hadoop gehören eine Vielzahl von Projekten und welche sind nun sinnvoll und welche braucht man? Weiterhin gibt es darauf aufbauend die Hadoop-Distributionen, die einen Teil dieser Open Source Projekte bündeln und teilweise noch um eigene Komponenten erweitern. Aber natürlich unterscheiden sich die Distributionen in Umfang, Unterstützung des Betriebs und Services für den Geschäftseinsatz – und natürlich auch im Preis. Letztendlich gibt es auch noch den Bereich der Big Data Suiten, die nochmal weitere Funktionalität wie etwa die Visualisierung der Daten und erweiterte Möglichkeiten für den Import & Export der Daten hinzufügen.<span></span></p><p>Die folgende Grafik stellt dieses Spektrum dar und im Folgenden wollen wir uns diesen drei Kategorien widmen und sie näher darstellen.</p><p><a href="https://media.graphassets.com/5zrjxoOkQUChltezgS9S"><img src="https://media.graphassets.com/5zrjxoOkQUChltezgS9S" alt="übersicht_hadoop_pakete" width="672" height="504" /></a> </p><p> </p><h2>Apache Hadoop</h2><p>Die Komponenten von Hadoop sind bei der Apache Foundation angesiedelt und stehen unter der <a href="http://www.apache.org/licenses/LICENSE-2.0" target="_blank">Apache License 2.0</a> . Bei Hadoop handelt es sich nicht nur um ein einzelnes Projekt, sondern um eine Vielzahl von zusammenhängenden und aufeinander aufbauenden Projekten. In diesem Zusammenhang spricht man gerne von den Kernkomponenten von Hadoop, welche die Grundlage für Hadoop und alle anderen Projekte bilden, die man als das Hadoop Ökosystem bezeichnet. Die Kernprojekte sind die folgenden:</p><ul><li><b>Hadoop Distributed File System (HDFS): </b><span>Ein verteiltes Dateisystem für die Speicherung und Verwaltung großer Datenmengen</span></li><li><b>Hadoop MapReduce: </b>Ein Framework zur verteilten und parallelen Verarbeitung von in HDFS gespeicherten Datenmengen</li></ul><p>Während sich Apache Hadoop recht einfach auch in einem lokalen Modus auf einem einzelnen Rechner für die Entwicklung installieren lässt, ist die Installation und der Betrieb in Clustern deutlich komplexer. Zum einen gibt es keine eingebaute Unterstützung bei der Installation von Hadoop in einem Cluster und ebenso gibt es auch keine Unterstützung zur Überwachung des Clusters im laufenden Betrieb. Zum zweiten beschränkt sich Apache Hadoop tatsächlich auf den Kern dessen, was Hadoop ausmacht. Das gesamte darum entstandene Ökosystem ist nicht enthalten und möchte man weiteren Komponenten nutzen, so müssen diese alle von Hand installiert werden. Und hier steht man schon vor dem ersten Problem, dass man sich die jeweils miteinander kompatiblen Versionen selbst aussuchen muss. Schließlich gibt es keinerlei kommerziellen Support und Firmen müssen alle ihre Hadoop-Probleme selbst lösen, wozu vor allem der meist langwierige Aufbau von entsprechendem Know-how gehört.</p><p>Daraus ist ersichtlich, dass sich Apache Hadoop insbesondere für Experimente oder für interessierte Entwickler eignet. Während ein Einsatz im Clusterbetrieb für mittelgroße Firmen durchaus möglich ist, empfiehlt es sich je nach Geschäftsmodell aber durchaus zumindest auf eine Hadoop-Distribution zu setzen – und sei es alleine schon wegen der kürzeren Einarbeitung und dem professionellen Support.</p><p> </p><h2>Hadoop Distributionen</h2><p>Hadoop-Distributionen sind ganz klar auf den Einsatz im Enterprise-Umfeld ausgelegt. Der Markt ist zwischen einer Handvoll etablierter Anbieter aufgeteilt, wobei natürlich immer wieder neue Anbieter versuchen diese Phalanx zu durchstoßen. Der Umfang der Distribution unterscheidet sich natürlich von Anbieter zu Anbieter leicht, aber die wichtigsten Komponenten aus dem Hadoop-Ökosystem wie Pig, Hive und HBase sind bei allen dabei und werden teilweise noch um spezifische Entwicklungen der Anbieter ergänzt. Die Releasezyklen zwischen verschiedenen Versionen der Distributionen liegen typischerweise bei 3 bis 6 Monate und die Distributionen enthalten nicht immer die aktuellsten Versionen aller Komponenten. Dafür wird aber Sorge dafür getragen, dass auch alle Komponenten und Systeme miteinander kompatibel sind und entsprechend wird viel Wert auf den Test und die Sicherstellung des Zusammenspiels gelegt. Alle etablierten Distributionen bieten zudem Werkzeuge zur Clusterinstallation und -administration und zudem bieten die Anbieter optionalen kommerziellen Support an.</p><p>Die wichtigsten Anbieter von Hadoop-Distributionen sind die folgenden:</p><p><b><a href="http://www.cloudera.com/" target="_blank">Cloudera</a> </b><br /> Die am weitesten verbreitete Distribution mit den meisten Referenzinstallationen. Es gibt leistungsfähige, aber proprietäre Werkzeuge zur Clusteradministration. Mit Impala treibt Cloudera zudem ein quelloffenes Projekt zur Echtzeitabfrage von großen Datenmengen voran. Es gibt zwar eine kostenfreie Version der Distribution, für den kommerziellen Einsatz fallen allerdings Lizenzgebühren in Abhängigkeit der Größe des Clusters an, die dann aber auch professionellen Support beinhalten.</p><p> </p><p><b><a href="https://media.graphassets.com/qvGspYbR22SXfRibj26w"><img loading="lazy" src="https://media.graphassets.com/qvGspYbR22SXfRibj26w" alt="Hadoop Distribution Hortonworks" width="100" height="100" /></a> </b></p><p><a href="http://hortonworks.com/" target="_blank"><b>Hortonworks</b></a> <br /> Die einzige Distribution am Markt, die 100% quelloffen ist und keine Lizenzgebühren verlangt. Alle Weiterentwicklungen, die Hortonworks vornimmt, fließen direkt in die Open Source Projekte von Apache Hadoop ein und Hortonworks ist eine treibende Kraft hinter der Entwicklung von Hadoop 2.0. Zudem bietet Hortonworks in Kooperation mit Microsoft als einziger Anbieter Hadoop für Windows und Azure an. Während für die Distribution selbst keine Lizenzgebühren anfallen, bietet Hortonworks aber auch Business-Support an und die Höhe der Supportgebühren richtet sich auch hier nach der Clustergröße.</p><p> </p><p><b><a href="https://media.graphassets.com/UXIvHyncRnOQz8aLxFMZ"><img loading="lazy" src="https://media.graphassets.com/UXIvHyncRnOQz8aLxFMZ" alt="Hadoop Distribution MapR" width="100" height="100" /></a> <a href="http://www.mapr.com/" target="_blank">MapR</a> </b><br /> Die Besonderheit dieser Distribution besteht darin, dass MapR direkt auf das Unix-Dateisystem aufsetzt und damit proprietär eine Alternative zu HDFS anbietet. Auch hier gibt es eine kostenfreie Version der Distribution, für den kommerziellen Einsatz fallen allerdings Lizenzgebühren in Abhängigkeit der Größe des Clusters an, die dann aber auch professionellen Support beinhalten.</p><p> </p><p><b><a href="https://media.graphassets.com/9D7VGt87Tb6DDwOEYa5g"><img loading="lazy" src="https://media.graphassets.com/9D7VGt87Tb6DDwOEYa5g" alt="Hadoop Distribution Amazon" width="100" height="100" /></a> </b> <a href="http://aws.amazon.com/de/elasticmapreduce/" target="_blank"><b>Amazon Elastic Map Reduce</b></a> <br /> Amazon bietet seine eigene Hadoop-Distribution auf der Basis der Cloudlösungen EC2 und S3 an, wobei die Distribution speziell darauf ausgerichtet ist, S3 anstelle von HDFS als Speicher zu verwenden. Kunden haben den Vorteil, dass Amazon das komplette Clustermanagement übernimmt, bezahlen dies aber auch mit dem Nachteil, dass S3 als Speicher nur bedingt geeignet und daher wesentlich langsamer als HDFS ist. Die Bezahlung richtet sich wie bei Amazon üblich nach den tatsächlich genutzten Ressourcen wie CPU und Speicherplatz.</p><p> </p><p>Es gibt noch weitere Distributionen, z.B. von <a href="http://gopivotal.com/pivotal-products/pivotal-data-fabric/pivotal-hd" target="_blank">Pivotal</a>  oder Intel, die aber jeweils relativ speziell sind und bisher noch eine geringe Verbreitung haben. Die Auswahl der Distribution hängt nur zum Teil davon ab, welche Features man benötigt, denn in dieser Hinsicht ähneln sich die Distributionen doch sehr. Die wichtigsten Fragen, die man sich während der Evaluierung der Hadoop-Distributionen stellen sollte, sind die folgenden:</p><ul><li>Möchte man sich an einen Anbieter binden (Vendor-Lock-In)?</li><li>Wie hoch sind die Lizenzgebühren für den eigenen Anwendungsfall?</li><li>Möchte bzw. kann man den Hadoop-Cluster selbst betreiben?</li><li>Welcher Grad an professionellem Support wird benötigt?</li></ul><p> </p><h2>Big Data Suiten</h2><p>Die Verwendung einer Big Data Suite zielt darauf ab, den Analysten und Endanwendern im Unternehmen die Arbeit mit Hadoop wesentlich zu erleichtern und ihnen zu erlauben, Werkzeuge zu verwenden, die sie gewohnt sind. Folgende zusätzliche Leistungen bieten Big Data Suiten:</p><p><b>Integrierte Umgebung</b></p><p>Es gibt eine integrierte grafische Benutzerumgebung, meist basierend auf dem bekannten Eclipse mit eigenentwickelten Plugins, aus der heraus viele Funktionen aufgerufen werden können und welche somit die Entwicklung vereinfacht.</p><p><b>Visualisierung</b></p><p>Mit den Bordmitteln von Apache Hadoop ist man bei der Anzeige der Daten meist auf Kommandozeilentools beschränkt. An dieser Stelle erweitern Big Data Suiten den Funktionsumfang und bringen eigene Tools zur Visualisierung und Aufbereitung der in HDFS gespeicherten Daten mit.</p><p><b>Echtzeitanalyse</b></p><p>Gerade zur Exploration von Daten wollen Analysten Antworten auf Anfragen idealerweise in Echtzeit bekommen und nicht erst immer auf langlaufenden MapReduce-Jobs warten, nur um dann festzustellen, dass irgendwo noch ein kleiner Fehler war. Daher benutzen Big Data Suiten verschiedene Techniken wie Vorkompilation und Datenauszüge, um erst mal ein Rapid Prototyping auf einer kleinen, möglichst repräsentativen Datenmenge zu ermöglichen, bevor die MapReduce-Jobs auf der gesamten Datenmenge ausgeführt werden.</p><p><b>Modellierung & Codegenerierung</b></p><p>Analysten wollen (und können meist) keine MapReduce-Anwendungen schreiben, welche aber die Basis jeglicher Datenverarbeitung in der aktuellen Version von Hadoop sind. Und auch wenn Apache Hadoop und die Hadoop Distributionen mit dem skriptähnlichen Pig und dem SQL-ähnlichen Hive bereits abstrakte Abfragesprachen bieten, gehen viele Big Data Suiten noch einen Schritt weiter und bieten graphische Oberflächen zum Erstellen von MapReduce-Anwendungen, welche den zugehörigen Code dann automatisch generieren.</p><p><b>Scheduling</b></p><p>Auf großen Clustern spielt die Verwaltung von MapReduce- Jobs und die Modellierung ihrer Abhängigkeiten eine große Rolle. Zwar gibt es in Apache Hadoop mit dem Fair und Capacity Scheduler bereits zwei unterschiedliche Strategien mit rudimentären Weboberflächen und auch das Hadoop Ökosystem hält mit Apache Oozie eine Workflow-Lösung parat, allerdings erweitern die Big Data Suiten auch diese Funktionalitäten teilweise um komfortablere Werkzeuge.</p><p><b>ETL & Konnektoren</b></p><p>Daten stammen aus verschiedensten Quellen, aus SQL- und NoSQL-Datenbanken, aus Logdateien, aus B2B-Systemen wie Salesforce und SAP oder von sozialen Medien wie Facebook und Twitter. Big Data Suiten bieten dazu Konnektoren an, damit Datenquellen einfach an Hadoop angeschlossen und Daten ausgetauscht werden können. Das Schreiben von Schnittstellencode wird so vermieden.</p><p>Angeboten werden Big Data Suiten einerseits von spezialisierten Anbietern wie etwa <a href="http://de.talend.com/" target="_blank">Talend</a> , Teradata<b>, </b>Pentaho, <a href="http://www.datameer.com/" target="_blank">Datameer</a> , etc.<b> </b>und auf der anderen Seite erweitern mittlerweile auch Softwareanbietern wie <a href="https://www.microsoft.com/de-de/sql-server/sql-business-intelligence" target="_blank">Microsoft</a> , <a href="http://www-01.ibm.com/software/data/infosphere/hadoop/" target="_blank">IBM</a> , <a href="http://www.oracle.com/de/technologies/big-data/index.html" target="_blank">Oracle</a>  ihre Produktpalette um entsprechende Angebote.</p><p>Und so breit wie hier das Angebot an Lösungen ist, so unterschiedlich sind auch viele dieser Big Data Suiten und reichen von spezialisierten Produkten bis hin zu viele Bereiche abdeckende Produkten. Die Entscheidung für eine Suite hängt daher von einer Reihe von Faktoren ab und man sollte sich zuerst diese grundlegenden Fragen stellen:</p><ul><li>Erfüllt die Big Data Suite die jeweiligen Anforderungen?</li><li>Ist sie für technisch nicht so versierte Endbenutzer intuitiv benutzbar?</li><li>Welche Softwareanbieter sind im Unternehmen schon vorhanden?</li><li>Wie integriert sich die Big Data Suite mit der bestehenden Unternehmenssoftware?</li><li>Wie steht man zum Open-Source-Ansatz?</li><li>Welche Lizenzkosten sind zu erwarten?</li></ul><p>Diese Übersicht über das Universum an Hadoop-Plattformen zeigt, wie groß die Auswahl ist. Dadurch wird aber auch deutlich, dass man seine jeweiligen Anforderungen möglichst genau kennen sollte, um dann zu entscheiden, ob Apache Hadoop, eine Hadoop-Distribution oder eine Big Data Suite am besten passt. Die Auswahl des passenden Anbieters folgt erst danach. Dabei werden neben der Eignung für das jeweilige Projekt sicherlich auch weitere individuelle, unternehmensübergreifende Kriterien eine Rolle spielen.</p><p>Weiter geht es in <a href="/wissens-hub/blog/einfuhrung-in-hadoop-die-wichtigsten-komponenten-von-hadoop-teil-3-von-5">Teil 3 mit den wichtigsten Komponenten von Hadoop, hier lang…</a> </p>

Einführung in Hadoop – Welches Hadoop hätten’s denn gern? (Teil 2 von 3)

<h2>Was ist Big Data?</h2><blockquote><p><strong>„Big Data ist, wenn die Daten selbst Teil des Problems werden“</strong></p></blockquote><p>Diese kurze Definition in Anlehnung an ein Zitat des Verantwortlichen für Marktforschung bei O’Reilly Media, Roger Magoulas, ist in meinen Augen die beste Charakterisierung von Big Data, gerade weil sie so kurz und prägnant ist und trotzdem den Kern des Problems – und der Herausforderungen – so zeitlos umfasst. Hier wird gar nicht erst probiert, das aktuelle Hype-Thema Big Data anhand reiner Zahlen wie „Big Data ist alles über 1, 5, 10, 50, … GB, TB, PB, …“ festzuzurren. Big Data in Zahlen zu fassen scheint aber anscheinend trotzdem ein menschliches Grundbedürfnis zu sein, ich weiß nicht wie viel Zeit ich auf User Groups , Open Spaces, Konferenzen, etc. allein mit der Diskussion der „Größe“ von Big Data verbracht habe. Und diese Diskussion ist eigentlich nie zielführend gewesen, viel wichtiger ist es in meinen Augen, die Prinzipien hinter den Technologien zu verstehen und welche Möglichkeiten sich dadurch ergeben. Und genau das möchte ich in dieser Blog-Serie versuchen zu beleuchten, wohl wissend, dass Big Data nicht nur Hadoop ist, auch wenn die aktuelle Berichterstattung dies häufig zu suggerieren scheint. Aber Hadoop ist zumindest ein nicht unbedeutender Teil von Big Data, daher fangen wir einfach mal damit an und andere Themen werden sicherlich folgen.</p><h2>Das 3V-Prinzip<span></span></h2><p>Zurück zum Thema: Das ursprüngliche Zitat von Roger Magoulas bezog sich lediglich auf die Größe der Daten und ich denke wie so viele, dass diese Hervorhebung zu einseitig ist und zu kurz greift. Natürlich ist die Größe der Daten einer der offensichtlichsten Faktoren bei Big Data – der Name kommt schließlich nicht von ungefähr. Trotzdem wäre das zu eindimensional und verkennt die weiteren Dimensionen des Phänomens Big Data. Dies sehen auch die Analysten von Gartner so, wie sie nicht müde werden zu betonen, und ihr 3V-Prinzip ist sicherlich die populärste Definition von Big Data und ich denke, dass Sie diese auf jeden Fall  zumindest kennen sollten. Die Definition ist mittlerweile von diversen Autoren und Marketingabteilungen noch um einige V’s erweitert worden, ich will mich aber auf die ursprüngliche Definition beschränken:</p><blockquote><p><b>Volume (= Größe der Daten)</b></p><p><b><span>Mit den exponentiell steigenden Datenvolumen, die von Unternehmen angesammelt werden, geht es in der Regel darum, große Datenmengen zu speichern und zu analysieren. Wir reden dabei heutzutage typischerweise über Daten im Terabyte- bis Petabyte-Bereich, die traditionelle Systeme an ihre Grenzen bringen bei dem Versuch diese Datenflut effizient zu verarbeiten.</span></b></p><p><b>Velocity (= Geschwindigkeit der Daten)</b></p><p><b>Die Geschwindigkeit der Datenerzeugung nimmt ständig zu. Bei neu entstehenden Datenquellen wie mobilen Geräten, sozialen Netzwerken, Sensordaten, RFID, etc. werden die Daten kontinuierlich in Echtzeit generiert. Aber auch die Speicherung über mehrere Kanäle hinweg und die nachfolgende Datenanalyse soll möglichst in Echtzeit stattfinden, um schnelle Entscheidungen zu treffen und so Wettbewerbsvorteile zu sichern.</b></p><p><b>Variety (= Vielfalt der Daten)</b></p><p><b>Die Dimension „Vielfalt“ bezieht sich nicht nur auf unterschiedliche Datenformate, die von verschiedenen Datenquellen erzeugt werden. Mit dem Einsatz von RFID-Sensoren, Roboter und der explosionsartigen Verbreitung von  sozialen Netzwerken werden Daten in zahllosen Formaten wie Text, Video, Audio, Sensordaten, Tweets, Logausgaben usw. generiert. Auch die Notwendigkeit mit unterschiedlichen Datentypen wie strukturierte, semistrukturierte und unstrukturierte Daten arbeiten zu müssen, trägt zur Komplexität der Lösung bei.</b></p></blockquote><h2>Und was ist mit NoSQL?</h2><p>Im Zusammenhang mit Big Data stößt man häufig ebenfalls auf den Begriff <b>NoSQL</b> – auch Sie sind sicherlich in diesem Zusammenhang schon mal über die dokumentenbasierte Datenbank <a href="http://www.mongodb.org/" target="_blank">MongoDB</a> , den verteilten Key-Value-Store <a href="http://basho.com/riak/" target="_blank">Riak</a> , die Graph-Datenbank <a href="http://www.neo4j.org/" target="_blank">Neo4</a> j und weitere Lösungen gestolpert. Und auch wenn diese technische Lösungen meist auf den Grundprinzipien der vertikalen Skalierbarkeit und der Verwendung von Commodity Hardware aufbauen und sich somit ebenfalls für die Speicherung und Verarbeitung von großen Datenmengen eignen, so ist der Begriff Big Data heutzutage doch fast synonym mit <a href="http://hadoop.apache.org/" target="_blank">Apache Hadoop</a>  verknüpft.</p><p>Ich will diese Verknüpfung auch gar nicht erst bewerten, denn auf Basis von NoSQL-Datenbanken sind ebenfalls eine Vielzahl von innovativen Lösungen entstanden und sie haben Ihre ganz eigenen Einsatzzwecke und sind somit Teil des Big Data Lösungsraums. Der Grundsatz ist dabei wie immer „Wähle das richtige Tool für deine Aufgabe“ und Hadoop ist eben für viele Aufgaben im Bereich von Big Data das richtige Tool. Das können Sie nach der Lektüre dieser Serie aber hoffentlich selbst bewerten und ich vertraue auf Ihr Interesse als Leser, sich tiefer in das Thema hineinzuarbeiten, z.B. mit der Lektüre des sehr empfehlenswerten Buchs (mit dem sperrigen Titel) <a href="http://www.amazon.de/Big-Data-f%C3%BCr-IT-Entscheider-gewinnbringend/dp/3446433392/" target="_blank">„Big Data für IT-Entscheider: Riesige Datenmengen und moderne Technologien gewinnbringend nutzen“</a>  meines Kollegen und Big Data Experten <a href="http://www.amazon.de/Pavlo-Baron/e/B0045B2NBY/" target="_blank">Pavlo Baron</a> .</p><h2>Nun aber zu Hadoop…</h2><p>Fokussieren wir uns nun also auf Hadoop: Das von der Apache Software Foundation geleitete Open Source Projekt Hadoop ist ein Framework zum verteilten Speichern und parallelen Verarbeiten von großen Datenmengen in horizontal verteilten Umgebungen. Die <strong>horizontale Skalierung</strong> („Scale out“) ist dabei eines der Grundprinzipien von Hadoop, welche es ermöglicht große Datenmengen sicher und fehlertolerant auf bis zu mehreren Tausend Servern  innerhalb eines Clusters zu verteilen. Dabei kommen nicht mehr teure und spezielle Server („Scale up“) zum Einsatz, sondern es wird auf kostengünstige Commodity Hardware gesetzt.</p><p>Neben dem Speichern von großen Datenmengen ist das verteilte und parallele Verarbeiten dieser Daten eine weitere Kernaufgabe von Hadoop. Dafür hat Hadoop viele intelligente und effiziente Mechanismen entwickelt, wobei das <strong>Prinzip der Datenlokalität</strong> das Wichtigste ist. Dabei werden nicht wie in klassischen Systemen die Daten zu den Servern transportiert, die dann den Programmcode ausführen, sondern der Programmcode wird auf die Server im Cluster mit den zugehörigen Daten verteilt, dann dort verteilt ausgeführt und die (Teil-)Ergebnisse wieder zusammengeführt. Auf diese Weise werden zeitintensive Datentransfers über das Netzwerk minimiert, der Cluster skaliert sehr gut und insgesamt wird dadurch die Geschwindigkeit der Datenverarbeitung erhöht bzw. in vielen Fällen überhaupt erst ermöglicht! Dieser Ansatz der Verarbeitung bewirkt aber auch, dass <strong>Hadoop im Grundsatz ein Batch-System ist</strong> und somit z.B. weniger für Aufgaben im Realtime-Bereich oder für iterative Algorithmen geeignet ist, sondern eher den Fokus auf die – meist nachträgliche – parallele Verarbeitung und Aggregation von Daten legt. Ein Umstand den man trotz allen aktuellen Bemühungen und auch Erfolgen, Hadoop immer mehr in Richtung (Near-)Realtime zu entwickeln, niemals vergessen sollte.</p><p>Nach der kurzen Einführung in Big Data und Hadoop geht es im nächsten Teil weiter mit einer Übersicht über die <a href="/wissens-hub/blog/einfuhrung-in-hadoop-welches-hadoop-hattens-denn-gern-teil-2-von-5">Hadoop-Plattformen, folgen Sie mir einfach…</a> </p>

Einführung in Hadoop – Was ist Big Data & Hadoop? (Teil 1 von 3)

Cloud Security Architect

<p>In der Praxis treten innerhalb von Projekten häufig Schwierigkeiten auf, die auf unklare oder unscharfe Abgrenzung von Fachlogik zurückzuführen sind. Ursache häufig: die Problemdomäne ist für den Kunden nicht immer klar, oder von vornherein wurde die Domäne viel zu groß oder am eigentlichen Problem vorbei abgesteckt. Mitunter entstehen dadurch Probleme beim Laufzeitverhalten – häufige, gegenseitige Aufrufe von Microservices, Nebenläufigkeitsprobleme, hohe Latenzzeiten etc. – die erhebliche Nachbesserungen und Behebungskosten nach sich ziehen.<br /> Im Extremfall ist das ganze Unternehmen als „kanonisches Datenmodell“ umgesetzt – ein absolutes <a href="https://jaxenter.de/microservices-patterns-antipatterns-73293" target="_blank">Anti Pattern</a>  für moderne Microservice-Architekturen. Und natürlich kann es zu fundamentalen Missverständnissen zwischen Fachabteilung und Entwicklern kommen, welche dazu führen, dass ein Projekt komplett am eigentlichen Ziel vorbei entwickelt wird.</p><p><a href="https://media.graphassets.com/hxCLYYb5RqiCoH2Yeq5N"><img src="https://media.graphassets.com/hxCLYYb5RqiCoH2Yeq5N" alt="Event Storming Such-Trend" width="700" height="207" /></a> </p><p>Durch die Methoden des Domain Driven Designs sollen solche Probleme vermieden werden. Es gilt, zunächst ein gemeinsames Bild von der Fachlichkeit zu finden und ein von technischen Details möglichst befreites Modell zu entwickeln, auf das in der Folge die gesamte Systemarchitektur ausgerichtet wird. Ein sinnvoller erster Schritt auf dem Weg dorthin ist Event Storming (auch: EventStorming). Von Alberto Brandolini entwickelt, erfreut sich dieses Workshop-Format großer Beliebtheit, und das Interesse an Event Storming steigt in den letzten Jahren deutlich (siehe Bild 1).</p><h2>Das Ziel von Event Storming</h2><p>Ziel von Event Storming ist es, ein gemeinsames Verständnis für die Domäne(n) zu erlangen, sowie eine gemeinsame Sprache aller an der Entwicklung beteiligten Fachleute und Softwarespezialisten zu definieren, die „Ubiquitous Language“. Über die einzelnen Abteilungs-Silos hinweg werden Business Cases modelliert und für alle Beteiligten sichtbar und verständlich gemacht. Probleme und Bottlenecks können identifiziert und die wichtigsten Bestandteile eines Business-Prozesses herausgefunden werden – z.B. für die Entwicklung eines MVPs.</p><p>Das sichtbare Ergebnis des Workshops (siehe Bild 2) ist ein großflächiges Bild der Prozesse und ihrer umgebenden Kontexte, jedoch stellt dies eher einen Anfangs- als einen Endpunkt dar: Man muss klarstellen, dass kein finales Modell der Domäne zu erwarten ist, sondern immer nur ein „Snapshot“ der mit den Teilnehmern und dem aktuellen Wissensstand entwickelten Sicht auf das fachliche Problem. Das eigentliche Domänen-Modell entsteht später innerhalb des Codes der Anwendung.</p><p>Noch wichtiger ist aber, dass losgelöst vom Artefakt ein einheitliches Wording für die verschiedenen Konzepte innerhalb der identifizierten Domänen entsteht. Durch den initialen Fokus auf Events wird die Komplexität maximal reduziert, und es kann sich leicht auf die ablaufenden Prozesse konzentriert werden. Entwicklungsteams können so schnell in eine Domäne eingearbeitet werden, und durch den Austausch mit den Domänenexperten frühzeitig Unklarheiten klären oder vermeiden.</p><p><a href="https://media.graphassets.com/l0h1gDC1Qta9FyOw8ZbT"><img loading="lazy" src="https://media.graphassets.com/l0h1gDC1Qta9FyOw8ZbT" alt width="700" height="197" /></a> </p><h2>Der Workshop in Kürze</h2><p><span>Innerhalb eines codecentric-internen Trainings unter Anleitung von Tobias Goeschel konnten wir erste Erfahrungen mit Event Storming sammeln. Dabei wurde ein (fiktives) Szenario als Rollenspiel modelliert und durch die 4 grundlegenden Schritte von Event Storming vertieft: </span></p><ul><li><span>Big Picture</span></li><li><span>The Picture That Explains Everything</span></li><li><span>Process Modelling</span></li><li><span>Software Design</span></li></ul><p>Im Folgenden beschreibe ich kurz meine dabei gesammelten Eindrücke und Erkenntnisse.</p><h3>Das Setup</h3><p>Eine Stärke des Event Stormings ist, dass fachliche Experten (Stakeholder, POs, evtl. Nutzer) und Entwickler im selben Raum sind. Dabei ist auf eine gleichmäßige Verteilung zu achten: Es sollten annähernd die gleiche Anzahl Fachexperten und Implementierer anwesend sein. Idealerweise umfasst die Gruppe nicht mehr als 15 Personen, der “Sweet Spot” liegt bei etwa der Hälfte, also 8-10 Personen.</p><p>Der Moderator stellt am Anfang des Workshops eine “unendlich” große Fläche zur Verfügung (z.B. auf einer Papierrolle), um später darauf die Klebezettel platzieren zu können. Ein Raum mit viel glatter Wandfläche ist hierfür am besten geeignet. Dazu wird eine ebenfalls “unendliche” Anzahl an Klebezetteln in unterschiedlichen Farben und Ausprägungen, sowie passende Stifte, für die Teilnehmer bereitgestellt.</p><p>Die Wandfläche repräsentiert – in der Regel von links nach rechts – den zeitlichen Horizont für die zu entdeckenden Prozesse. Klebezettel sind als Modellelemente ideal, denn man kann sie frei sortieren, verschieben und wegschmeißen. Nichts ist “in Stein gemeißelt” – im Gegenteil werden im Laufe des Workshops immer wieder Teile des Modells verworfen, verschoben oder erweitert. Der Moderator greift in die Diskussionen nur minimal lenkend ein, um den Workshop erfolgreich ins Ziel zu führen, lässt aber ansonsten den Teilnehmern möglichst viel Freiraum. Eine Legende mit den verschiedenen „Building Blocks“ des Workshops entsteht während der Arbeit und steht jederzeit zur Verfügung.</p><h3>Das Vorgehen</h3><p>Das Vorgehen zu Beginn des Event Storming Workshops ist explorativ und bewusst nicht darauf ausgelegt, dass von Anfang an alles „perfekt“ wird. Das Wording muss noch nicht immer stimmen, die Events – zunächst der einzige verfügbare Baustein – nicht immer „korrekt“ formuliert sein. Wichtig ist, dass der Einstieg leicht fällt, und dadurch die Gruppe schnell in einen Flow kommt und kreativ aktiviert wird. Die Domäne wird anschließend iterativ erkundet und das Modell Schritt für Schritt immer weiter ausgearbeitet. Im weiteren Verlauf des Workshops stellt der Moderator nach und nach weitere Tools und Bausteine zur Verfügung, um die Teilnehmer nicht mit Informationen zu überladen. Dies hat den Nebeneffekt, dass durch veränderte Bedingungen auch unterschiedliche Aspekte der Fachlichkeit beleuchtet werden, was Schärfung und Detailreichtum des Modells fördert.</p><h4><em>„The Big Picture“</em></h4><p>Der Workshop startet damit, dass die Aufgaben der Teilnehmer klargestellt werden: Die Domänenexperten dürfen Ereignisse auf Klebezettel schreiben, die Entwickler müssen sie auf der Modellfläche platzieren und in eine sinnvolle Reihenfolge bringen. Werden diese „falsch“ angebracht, sollen die Fachexperten einschreiten und verbessern. Sind Zusammenhänge unklar, werden durch die Entwickler Fragen gestellt und von den Experten beantwortet. Alle sollen dabei ausgiebig miteinander über die Events diskutieren, diese in Frage stellen und Verbesserungsvorschläge machen.</p><p>Zuerst werden – wie bereits angedeutet – nur <i>Domain Events</i> auf der Fläche verteilt: Fachliche Ereignisse, die im zu erkundenden Problemraum zu beobachten sind. Den Anfang zu machen, ist dabei vielleicht das Schwerste – der Moderator kann etwas nachhelfen. Danach kommt man schnell in eine regelrechte Flut von neuen Events, welche zeitlich vor, parallel zu, oder nach dem ersten Event stattfinden.</p><p>Natürlich können „falsche“ (also vermeintlich schlecht benannte) oder doppelte Events angebracht werden. Der Moderator kann darauf hinweisen, dass diese Events nicht unbedingt der Konvention entsprechen, aber sollte nicht unbedingt dadurch den Fluss an neuen Events verlangsamen. Wichtig ist, ein ganzheitliches Bild des Prozesses zu erlangen. Später können Events nachgeschärft oder verbessert werden.</p><p>Teile des Prozesses werden größere Diskussionen auslösen: über Probleme, Risiken oder Entscheidungen. Man kann diese mit<i>Hot-Spot</i>-Zetteln (in lila) markieren, welche später genauer betrachtet oder nochmal geklärt werden müssen. Auf diese Weise werden allzu lange Pausen vermieden und der Arbeitsfluss bleibt konstant schnell.</p><p>Je größer das Bild wird, um so mehr bilden sich auch zusammenhängende Ketten und „Cluster“ heraus, die mittels Klebezetteln deklariert und benannt werden können.</p><p>Am Ende des „Big Picture“ ist ein Überblick über das „große Ganze“ entstanden – die Gruppe hat eine Vorstellung der Dimensionen und Zusammenhänge entwickelt und bereits jetzt viele Abstimmungen und Einigungen erzielt.</p><h4><b><i>„The Picture That Explains Everything“</i></b></h4><p>Sobald sich ein klareres Bild ergibt, der Fluss an neuen Events langsamer wird und auch die Diskussionen weniger werden, stellt sich die Frage nach dem Ursprung der Ereignisse: Akteure  (Strichmännchen) werden identifiziert und benannt, sowie „Commands“, also Befehle, eingeführt. Dabei gilt der Befehl nicht etwa anderen Akteuren, sondern ergeht an das System. Ein Befehl verändert den Systemzustand – und die Veränderung wird als Ereignis sichtbar.</p><p>Durch die Einführung der neuen Elemente entstehen neue Diskussionen, es wird ein verfeinertes Bild der Abläufe erzeugt. Ein Command kann durch verschiedene (auch mehrere) Akteure ausgelöst werden, welche aus ganz unterschiedlichen Gründen eine Entscheidung treffen. Es stellt sich ggf. heraus, dass einige Events unnötig sind, oder andere wiederum unter falschen Annahmen erstellt wurden. Es beginnt ein stetiges Herausfordern der vorherigen Annahmen über die Prozesse.</p><p>Zum Treffen von Entscheidungen werden Daten benötigt – Read Models werden eingeführt.</p><p>Nun können die benötigten Informationen spezifiziert und diskutiert werden. Interessant ist hier, dass der Fokus vollständig auf der <i>Verwendung</i> der Daten liegt, nicht auf deren Erfassung oder Speicherung – Stammdaten, Tabellen und Verknüpfungen sind Implementationsdetails und werden „ausgeblendet“. Es ergeben sich verblüffende Erkenntnisse über die Struktur und Relevanz der Daten, die signifikante Auswirkungen auf die Lösungsarchitektur haben können:</p><p>Aus diesen neuen Informationen lässt sich bspw. leicht eine Event-Driven Architecture ableiten. Man kommt einem ganzheitlichen Bild des späteren Modells für die einzelnen Prozesse immer näher.</p><p>Automatisierbare oder eindeutig regelbasierte Entscheidungen werden als „Policies“ markiert und benannt. Hier entfällt der Akteur, da das System eigenständig agieren kann. Die genauen Geschäftsregeln werden aber zunächst noch nicht eingepflegt, da dies sowohl die Übersichtlichkeit gefährden, als auch den Arbeitsfluss unterbrechen würde. Am Ende des Workshop-Abschnitts sollte jedem Event entweder ein Command oder eine Policy zugeordnet, alle benötigten Daten identifiziert und die Akteure benannt sein – damit ist „everything explained“, also der Gesamtzusammenhang erschlossen.</p><p>Es sollte zu diesem Zeitpunkt auch deutlich werden, welche Teilprozesse untereinander kommunizieren oder in zeitlichen Abhängigkeiten stehen. Außerdem können über gezeichnete Begrenzungen die einzelnen Prozesse isoliert werden, der <a href="https://martinfowler.com/bliki/BoundedContext.html" target="_blank"><i>Bounded Context</i></a>  wird sichtbar und bildet das Ergebnis dieses Schrittes.</p><h4><b><i>Process Modelling</i></b></h4><p>Als nächster Schritt werden die einzelnen Prozesse, bestehend aus Commands, Events, Policies usw. näher betrachtet und verfeinert. Es werden Namen für die Prozesse vergeben und Teilprozesse identifiziert. Die für die Benennung der einzelnen Bausteine verwendete Sprache wird noch einmal besonders kritisch geprüft, d.h. es wird z.B. auf eine bessere Namensgebung geachtet und Konsistenz hergestellt. Das kann erneut dazu führen, dass umgruppiert und ausgetauscht wird. Kernprozesse des Geschäftsmodells (Core Domain) werden von Hilfsdomänen (Supporting Domain, z.B. Notifications, Buchhaltung, Dokumentendruck) separiert und so der Blick auf das eigene Unternehmensprofil geschärft. Nicht zuletzt werden noch „externe Systeme“, wie bspw. Email oder Payment Provider, eingefügt und in die Prozesse mit einbezogen.</p><h4><b><i>Software Modelling</i></b></h4><p>Im letzten Schritt werden die Prozesse innerhalb eines Bounded Contexts aufgelöst und die darin enthaltenen Events und Commands nach ihrer Benennung gruppiert. Zusammengehörige Elemente („Vertrag aufgesetzt“, „Vertrag zugeschickt“, „Vertrag abgeschlossen“) weisen auf die grundlegenden Bausteine des Domänenmodells hin: Sogenannte „Aggregates“, d.h. in der Regel aus mehreren einfacheren Objekten zusammengesetzte Strukturen, die die wesentlichen Bestandteile der Geschäftslogik ausmachen (in diesem Fall: „Vertrag“). Diese Objekte kapseln Zustände und Transaktionen und bilden später in der Implementation die Grundstruktur des modularen Systems. Nun zahlt sich aus, wie akribisch der bisherige Workshop durchgeführt wurde: Je präziser die Benennung, umso leichter ist es, auf die richtigen Strukturen zu stoßen.</p><p>Objekte, die Aufgaben erledigen („Dokument drucken“, Vertrag drucken, “F„ormular drucken“), jedoch keinen eigenen Zustand enthalten, stellen die letzten noch fehlende Bausteine dar: Domain Services sind hier interne Dienste („DruckService“), die innerhalb des Domänenkerns verortet sind – im Gegensatz zu klassischen Services, die bekanntlich fertig implementierte Komponenten darstellen. Ihre Identifikation läuft analog und zeitgleich mit dem Entdecken der Aggregates, lediglich durch den Inhalt der Ereignisse und Commands wird die Unterscheidung deutlich.</p><h2>Ausblick</h2><p>Abschließend kann mit dem Gesamtergebnis aus identifizierten (Sub-)Domänen, Prozessen und Softwarebausteinen ein Plan für die Umsetzung erstellt werden: Es gilt, wichtige und unwichtige Prozessschritte zu finden, und diese voneinander zu isolieren. Einzelne Teilprozesse können dabei als Namensgeber für User Stories dienen, die in einem anschließenden Story Mapping Workshop den Start einer Produktumsetzung entscheidend erleichtern. Vor allzu großem Enthusiasmus über die Fülle der Ergebnisse sei jedoch an dieser Stelle noch einmal gewarnt: Während es in jedem Fall deutlich zu bevorzugen ist, eine Projektplanung auf den Ergebnissen aus dem Event Storming aufzubauen, als über ein im klassischen Requirements Engineering erarbeiteten Backlog (oder gar Pflichtenheft), so ist und bleibt das Modell eine – wenn auch detailreiche – Momentaufnahme. Während der Entwicklung ist es durchaus nicht ungewöhnlich, dass stellenweise nachkorrigiert oder auch mal größere Systemteile verändert werden müssen, wenn neue Erkenntnisse entstehen. Das lässt sich in komplexen Zusammenhängen weder vermeiden, noch wäre eine Vermeidungsstrategie wünschenswert. Vielmehr sollte in  regelmäßigen Abständen das Event Storming wiederholt und damit geprüft werden, ob das gemeinsame Bild immer noch mit dem letzten modellierten Stand kongruent ist, oder ob sich inzwischen Änderungen ergeben haben, die Berücksichtigung verlangen. Aber selbstverständlich kann dies auch durch viele andere Mechanismen erreicht werden. Es bietet sich mithin an, die Methoden zu variieren, da sich sonst möglicherweise Automatismen einschleichen, die die Ergebnisse verwässern.</p><h2>Fazit</h2><p>Durch das gemeinsame Brainstorming und das Reduzieren auf rein fachliche Events kann der Workshop manche Schwierigkeiten klassischer Softwareprojekte lösen: Die Einstiegshürde ist denkbar niedrig (jede*r kann am Workshop teilnehmen und auch ohne methodische Vorkenntnisse sofort produktiv einsteigen), der Wissenstransfer ist unmittelbar und umfassend. Doch es ist keineswegs nur ein Transfer in eine Richtung: Aus dem Zusammenspiel von Domänenexperten, Entscheidern, Entwicklern und Moderator können komplexe Zusammenhänge für alle Beteiligten erarbeitet und verfeinert werden. Nicht selten werden dabei Fehleinschätzungen und Missverständnisse aufgedeckt, die unerkannt über Jahre für Probleme sorgten.</p><p>Der Moderator führt während des Workshops Stück für Stück neue Konzepte ein, um die Diskussionen am Leben zu erhalten und gleichzeitig die Teilnehmer nicht mit Informationen zu überladen. Das sorgt für ein konstant hohes Energielevel und verblüffend detailreiche Ergebnisse.</p><p>Am Ende des Workshops herrscht ein gemeinsames Verständnis über die besprochene Domäne, und es kann nun ein erstes Modell erstellt und verifiziert werden. Dieses sollte im Verlauf des Projektes an neue Erkenntnisse und Learnings iterativ angepasst und immer wieder verfeinert werden.</p><p>Der Blogbeitrag vermag natürlich nur einen kurzen Überblick über Event Storming und dessen Durchführung zu geben. Den besten Einblick erhält der Leser beim Ausprobieren und Selbst-Erleben der Methode. Voraussetzung für das bestmögliche Ergebnis ist allerdings unbedingt eine professionelle Unterstützung bei der Moderation – die Dynamik des Formats und die vielen kleinen Hinweise und Anregungen, die sonst verloren gehen, machen die Investition auf jeden Fall wett.</p><p>Als Grundlage für das Entwerfen komplexer Geschäftsanwendungen hat sich dieses Vorgehen hundertfach entscheidend bewährt und ist nach meiner Einschätzung uneingeschränkt zu empfehlen.</p><p>Mein Dank gilt Tobias Goeschel für das Training, für die tollen Diskussionen über Event Storming und seine Unterstützung beim Schreiben dieses Blog Posts.</p><p><a href="https://info.codecentric.de/eventstorming-workshop-with-alberto-brandolini"><img loading="lazy" src="https://media.graphassets.com/q1XcUx2RaepsS1ftTGRY" alt="EventStorming Masterclass mit Alberto Brandolini" width="700" height="394" /></a>  Vom EventStorming-Erfinder persönlich lernen? – <a href="https://info.codecentric.de/eventstorming-workshop-with-alberto-brandolini">Jetzt Ticket sichern!</a> </p>

Event Storming – Gemeinsam die Domäne entdecken

<p>In diesem Blogpost zeigen wir an verschiedenen Situationen (welche heutzutage leider noch viel zu häufig in der Realität vorkommen), warum Projekte scheitern oder eine agile Transformation fehlschlägt.<br /> Wir merken immer häufiger, dass für eine „korrekte” (worüber sich vortrefflich streiten lässt) Umsetzung von agiler Entwicklung oder DevOps die <a href="/wissens-hub/blog/kulturkampf-digitalisierung-eine-un-success-story">Kultur des Managements und der Mitarbeiter entscheidend</a>  ist. Gerade in großen Unternehmen fällt das Mitnehmen und Motivieren der Mitarbeitenden eher zu knapp aus und so gibt es zwar immer wieder Initiativen zur Transformation des Unternehmens, aber diese verpuffen an der Einstellung der Belegschaft oder des Managements.<br /> <strong></strong></p><blockquote><p>„Wir sind doch agil!”</p></blockquote><p><br /> Agil ist ein <a href="/wissens-hub/blog/unternehmen-im-wandel-der-mensch-im-fokus">überstrapazierter Begriff</a>  geworden. In diesem Beitrag betrachten wir Agilität aus der Perspektive der Unternehmenskultur, welche durch die Mitarbeitenden gelebt werden muss. Diese Kultur muss von Vorgesetzten gelebt werden und die Transformation dahin ist mühevoll, denn es müssen alte Strukturen und Verhaltensweisen aufgebrochen werden.<br /> Meist wird Agilität mit Scrum gleichgesetzt. Es wird angenommen, wenn Scrum praktiziert wird, ist agile Entwicklung automatisch vorprogrammiert. Nach Scrum zu arbeiten klingt dabei nach einer einfachen Aufgabe und dennoch passieren viele Fehler bei der Durchführung von Scrum in Bezug auf einge gute agile Praxis. Außerdem: Scrum muss dabei mitunter gar nicht so wichtig sein. Wichtiger ist es, Agilität in der Projektkultur zu leben.<br /> Eine agile Kultur beinhaltet einen Fokus auf Transparenz über alle getroffenen Entscheidungen und eine Stärkung des Informationsflusses sowohl innerhalb des Teams als auch nach außen. So kann jedes Teammitglied maximal zum Erfolg des Projektes beitragen kann, indem es bei Planung, Design und Verbesserung des Projektes einbezogen wird. Agile Methoden sind Frameworks, um dies kontinuierlich und iterativ zu ermöglichen. Im Folgenden gehen wir auf häufige agile Anti-Patterns in Zusammenhang mit Scrum ein.</p><p><strong>Das „Agile-Wasserfall“-Projekt:</strong> Häufig zu beobachten ist, dass agile Projekte ähnlich wie ein Wasserfall-Projekt am Anfang durchgeplant werden: ein Zeit- und Projektplan wird festgelegt und das Budget muss bestimmt werden. Für die einzelnen Features werden Deadlines bestimmt. Dann werden Requirements in User Stories verpackt und diese in einem großen Batch auf das Projekt losgelassen. Die User Stories sind im schlimmsten Fall von schlechter Qualität, z. B. weil sie viel zu groß geschnitten oder spezifiziert sind.<br /> Features werden entwickelt, aber eine Validierung und ein Feedback durch die eigentlichen Endnutzer:innen findet, wenn überhaupt, viel zu spät statt. Das Projekt fällt immer weiter hinter den eigentlichen Plan zurück und scheitert letztlich an den gleichen Gründen wie frühere Wasserfall-Projekte: Der anvisierte Launch wird mehrmals verschoben und wenn dann endlich das Release da ist, fehlt die Nutzerakzeptanz. Ein Big Bang, wie er im Buche steht und ganz und gar nicht einer agilen Kultur entsprechend.</p><p><strong>„Chef-Programmierer“ gibt die Richtung vor:</strong> Scrum wird als Vorwand genutzt, um Agilität vorzutäuschen. Das Pattern: Bspw. ein PO (z. B. ein früherer Projektleiter, nun umgeschult) gibt jedem einzelnen Teammitglied genau vor, welche Aufgaben es zu welchem Zeitpunkt zu erledigen hat. Scrum Tools und Meetings werden nur zum Micromanagement des Teams genutzt. Ein eigenständiges Arbeiten ist für das Team unmöglich. Prioritäten werden oft während des Sprints gewechselt, z. B. weil Features nicht nach maximalem Nutzen für das Produkt priorisiert werden, sondern nach politischen Aspekten (z. B. weil ein Feature für das nächste Release dem Kunden versprochen wurde). Als Konsequenz kommt es zu immer größeren Beeinflussungen des Teams durch den “Chef-Programmierer” bei eigentlich teaminternen Entscheidungen.<br /> Scrum wurde nicht entwickelt, um Teams besser kontrollieren zu können. Es sollte klar sein, dass nicht jede:r alles wissen kann und daher eine Lösung im Team erarbeitet werden muss. Wenn alle im Team zusammenarbeiten und jeder einen guten Überblick über das Projekt und die zukünftige Entwicklung hat, kann vielleicht eine bessere Lösung gefunden werden.</p><p><strong>Fehlender dedizierter Scrum Master:</strong> Gute Scrum Master sind teuer, aber wichtig. Es ist oft zu hören: „Dabei produzieren die doch nicht einmal Code!“ Als Schluss folgt: Dann kann doch auch einfach ein Teammitglied das Ganze übernehmen.<br /> Es kommt dadurch häufig zu Frustration und Blockaden innerhalb des Teams, da z. B. Retrospektiven nicht oder schlecht durchgeführt werden oder kein dedizierter Mensch sich um die Beseitigung von Blockaden kümmert. Es folgt darauf eine sinkende Entwicklungsgeschwindigkeit und die vorher eingesparten Kosten sind dahin.<br /> Hierfür gibt es nur eine Lösung: Setzt dedizierte Scrum Master ein. Sie sorgen für einen Schutz des Teams vor externer Beeinflussung, organisieren die Meetings und lösen interne Probleme. Das Team muss ungestört arbeiten können!</p><p><strong>Zu große Teams:</strong> Teams sollten nicht zu groß sein, da sonst einige negative Effekte zu bemerken sind. Meetings ziehen sich aufgrund der Teilnehmerzahl in die Länge, Entscheidungsfindung wird aufgrund vieler zu berücksichtigender Parteien träger und es wird komplizierter, psychologische Sicherheit im Team aufrecht zu erhalten.<br /> Der Wissenstransfer zwischen den einzelnen Teammitgliedern wird immer schwieriger. Außerdem verbringt das Team 30-50 % der Zeit des Sprints in Meetings, die Zeit für das Entwickeln wird immer knapper.<br /> Bei großen Projekten wird für so ziemlich jede Entscheidung oder Blocker erstmal ein Meeting einberufen und am besten müssen immer alle mit dabei sein, es könnte ja jeden betreffen. Im schlimmsten Fall wird sich dadurch minutenlang angeschwiegen.<br /> Teams sollten möglichst unabhängig miteinander agieren können und nicht zu groß sein. Es sollten ihre gemeinsamen Abhängigkeiten und Schnittstellen herausgefunden werden und sie sollten dem jeweiligen anderen Team ein „Produkt“ zur Verfügung stellen. Dies führt zu einer Entkopplung der einzelnen Teams und die Teams können wieder selbstbestimmt arbeiten. Größere Meetings zwischen den Teams sollten nur noch mit einzelnen „Abgesandten“ der jeweiligen Teams stattfinden. Hier hat sich auch das Pattern der Communities of Practice bewährt.<br /> <strong></strong></p><blockquote><p>„Wir sind agil, wir machen doch DevOps!“</p></blockquote><p><br /> DevOps ist als Buzzword im Management angekommen. Dennoch werden fundamentale Konzepte von DevOps nicht oder nur teilweise umgesetzt. Wenn DevOps-Praktiken nicht funktionieren, ist dies auch häufig auf eine fehlende Anpassung der Gewohnheiten, Prozesse und Methoden durch Management und Mitarbeiter zurückzuführen.<br /> Unter anderem werden Teams nicht dazu ermutigt, eine DevOps-Kultur zu leben. Stattdessen existieren weiterhin silo-artige, abgekapselte Abteilungen oder Teams mit unterschiedlichen Zuständigkeiten, Budgets und somit auch ganz eigenen politischen Zielen.<br /> So wird z. B. fälschlicherweise DevOps nicht als Praxis, sondern als eine Abteilung innerhalb des Unternehmens etabliert. Ein DevOps-Team als Enabler innerhalb der Organisation wäre dabei keine schlechte Sache, doch stellt diese Abteilung in der Realität nicht Unterstützung für Teams, sondern ist verborgen hinter Beantragungen und langwierigen Prozessen. Das Team kommt nicht von den Zwängen der alten Plan-Build-Run-Kultur los. Um z. B. die dringend benötigte Build Pipeline zu bekommen, ist nicht etwa ein Klick innerhalb eines Tools nötig, sondern es müssen langwierige Anträge ausgefüllt und von mehreren übergeordneten Stellen abgesegnet werden, damit die Pipeline dann vom sogenannten DevOps-Team erstellt wird.<br /> Diese Prozesse sind in Unternehmen über lange Zeit gewachsen, vielleicht aus guten Gründen. Dennoch hindern sie die Entwickler an einer effektiven Arbeit am Projekt. Das Credo muss sein: Alles und jeder im Unternehmen muss darauf hinarbeiten, dass die Entwickler effektiv und störungsfrei arbeiten können. Nur dann können sich Entwickler darauf konzentrieren, Werte für das Unternehmen zu schaffen, also z. B. das Produkt der Firma voran zu bringen. Für unser Beispiel könnte das also bedeuten, dass ein DevOps-Team eine funktionierende Self-Service-Plattform für CI/CD zur Verfügung stellt, mit der Projekte ohne großen Aufwand neue Build und Deployment Pipelines erstellen können. Sie fungieren selbst als Enabler-Team und schulen sowie supporten andere Teams, um ihre Plattform schnell in ihre Arbeit integrieren zu können.<br /> Ein agile Kultur und eine funktionierende DevOps Praxis bilden eine starke Symbiose. So unterstützt DevOps das Entwickeln nach agilen Methoden enorm. Nur wenn Teams eigenständig und selbstbestimmt mit Ressourcen umgehen können, können sie auch schnell Features in Produktion bringen.<br /> <strong></strong></p><blockquote><p>„Digitalisierungsprojekt XY hat höchste Prio!“</p></blockquote><p><br /> Fokus ist wichtig. Sehr oft erleben wir, dass Teams durch andere Aufgaben von ihrem eigentlichen Projekt abgehalten werden. Wie soll das wichtige Digitalisierungs-Projekt erfolgreich abgeschlossen werden, wenn Teammitglieder noch 50 % ihrer Zeit mit Firefighting für Altsysteme zubringen oder in sinnlose Meetings gezogen werden?<br /> Ein gutes Management hält diesen Teammitgliedern den Rücken frei und propagiert die Projektziele, um alle Mitarbeitenden auf ein gemeinsames Ziel einzuschwören. Jedem Teammitglied sind die Ziele klar und Entscheidungen des Managements sind transparent. Nur dann werden die Teammitglieder effektiv und mit großer intrinsischer Motivation arbeiten.<br /> <strong></strong></p><blockquote><p>„Ihr habt vor zwei Monaten gesagt, das braucht x Tage, nun macht mal!“</p></blockquote><p><br /> Zusätzlich geraten Teams in eine weitere Falle: Sie werden auf Zeiten und Budgets festgenagelt, die vor Monaten arbiträr festgelegt wurden, aber mit dem nun aktuellen Wissensstand absolut unhaltbar sind. Am Anfang des Projektes wurden viele technologische und architektonische Entscheidungen getroffen, die auf nun veralteten Annahmen basieren, wenn das Projekt ein oder zwei Monate läuft. Das Team versucht nun, diese Deadlines unbedingt zu halten, obwohl klar ist, dass diese nicht mehr zu halten sind: Die Motivation sinkt und der Glaube an den Erfolg geht verloren. Es sammeln sich Unmengen an Überstunden an und die technischen Schulden werden immer größer. Die Abwärtsspirale beginnt.<br /> Wichtiger wäre es, Teams nicht an Deadlines und Budgets zu messen, die in den meisten Fällen nicht eingehalten werden können, sondern auf Basis von gelieferten Features. Einschneidende Entscheidungen sollten so spät wie möglich getroffen werden, um den Lösungsraum offen zu halten und dadurch so schnell wie möglich zu Ergebnissen zu kommen, die dann evaluiert und getestet werden können. Kleine, portionierte Entscheidungen sollten dagegen schnell getroffen werden, um schnell mittels Feedback validiert zu werden.<br /> <strong></strong></p><blockquote><p>„Das ist doch alles Jugend forscht hier.“</p></blockquote><p><br /> Diese Aussage ist extrem und haben wir so schon öfter gehört. Sie ruft starke Verwunderung bei uns hervor. Für uns ist ein exploratives Vorgehen selbstverständlich und ein kontinuierliches Entwickeln von Hypothesen und deren Validierung durch Tests unabdingbar.<br /> In der Realität sieht es oft so aus: Die genauen Anforderungen an das Produkt erscheinen klar. Also wird (nur ohne Lasten/Pflichtenheft) losgelegt und User Stories werden erstellt und ein Zeitplan ausgearbeitet. Beispielsweise werden dann Features aus den zu ersetzenden Altsystemen übernommen, die augenscheinlich unbedingt benötigt werden. Außerdem ist man sich einig, dass das Altsystem zwar gut war, aber nun mal durch etwas Besseres ersetzt werden muss. Man möchte von vornherein alles „richtig“ machen. Doch der Weg dahin ist oft unklar und wir stellen fest, dass die Kunden selbst nicht so genau wissen, welche Features wirklich den größten Business Value produzieren. Anstatt also bei Null anzufangen, wird meist ein kanonisches Datenmodell entwickelt (oder übernommen), die Architektur wird festgelegt und statt herauszufinden, womit in der Neuentwicklung der größte Wert geschaffen werden kann, wird ein großer Feature-Katalog abgearbeitet.<br /> Das Gegenteil ist aber meistens der Fall und die Anforderungen sind alles andere als klar. Die Ziele werden dann meistens nicht erreicht, es entsteht ein immer größerer Verzug zu den Deadlines und die Endnutzer:innen werden nicht um Feedback gefragt. Die Motivation der Entwickler:innen bricht weg und niemand glaubt noch an den Erfolg des Projektes. Man befindet sich wieder in einer Abwärtsspirale und das Projekt wird früher oder später scheitern.<br /> Ein exploratives Vorgehen kann dies verhindern, kommt aber nicht ohne vermeintliche Schmerzen. Denn es sieht am Anfang danach aus, als ob keine Erfolge zu verbuchen wären. Annahmen werden getroffen, es werden Features entwickelt und später wird viel wieder verworfen. Je früher jedoch Annahmen validiert oder invalidiert werden können, desto besser.<br /> Es ist wichtig, von vornherein offen für Veränderung zu sein! Dies ist Teil einer agilen Kultur. Veränderung muss sich in der Architektur und der Implementierung der Software widerspiegeln. Es wird passieren, dass das Datenmodell sich nach jeder Iteration erneut ändert und der Code jedes mal stark refactored werden muss. Dennoch kann man durch solch ein Vorgehen die eigentlich wichtigen Features implementieren und erhält früh das nötige Feedback der Nutzer:innen. Es ist wichtig, den Erfolg des Teams nicht anhand von geschafften Deadlines zu messen, sondern anhand der getesteten und validierten Entscheidungen.<br /> <strong></strong></p><blockquote><p>„Ja, wir wollen so schnell wie möglich produktiv gehen.“</p></blockquote><p><br /> Diese Aussage hören wir leider viel zu oft in Projekten, die meistens schon verzögert sind, z. B. aufgrund der oben bereits genannten Situationen. Das bedeutet manchmal, dass ein Projekt schon Monate oder Jahre hinter dem eigentlichen Zeitplan zurückliegt. Dennoch wurde während der Entwicklung noch nicht einmal erfolgreich auf Produktion ausgerollt.<br /> Es muss eines deutlich gesagt werden: Wenn das Feature/Produkt nicht produktiv gegangen ist, wurde noch kein Wert geschaffen. Dennoch erleben wir es immer wieder, dass Teams weiter mit Feature Requests bombardiert werden: Der Fokus liegt nicht darauf, bestehende Features auf Produktion zu bringen und an Endnutzer:innen zu testen und Feedback einzuholen. Also wird weiter und weiter entwickelt, Geld verbrannt, und am Ende werden die Kunden vor vollendete Tatsachen gestellt. Wenn es überhaupt jemals zu einem Kontakt der Endnutzer:innen mit dem fertigen Produkt kommt.<br /> Wenn es dann soweit ist, und es kann auf Produktion deployed werden, fehlt im Team das Wissen, welche firmenspezifische Compliance-Regeln und Prozesse eingehalten werden müssen, um überhaupt das neue „Cloud-native Digitalisierungsprojekt“ auf Produktion zu deployen. Beispielsweise werden Cloud-Teams als Enabler im Unternehmen eingesetzt (ähnlich wie zuvor beschrieben bei DevOps), um die jeweiligen großen Cloud-Anbieter innerhalb des Unternehmens einzuführen, aber später sind diese Teams entweder nicht dafür ausgelegt, andere Teams bei ihrem Weg zur Produktion zu unterstützen oder sind mit ihren Aufgaben völlig ausgelastet.<br /> Wie schon bei dem schlecht durchgeführten DevOps mangelt es bei der fehlenden Produktionsreife wieder am Service-Gedanken gegenüber den Projekten. Weiterhin sollte es selbstverständlich für DevOps-praktizierende Teams sein, auch mehrmals täglich auf Produktion zu deployen. Nur so ist es möglich, einen kontinuierlichen Flow und Feedback zu erhalten.</p><h2>TL;DR</h2><p>Dieser Blogpost beleuchtete verschiedene Situationen und Szenarien, die in agilen Projekten vorkommen können und diese dann zum Scheitern verurteilen.<br /> Fassen wir kurz zusammen:</p><ul><li>„Agilität“ ist oft eine leere Worthülse und zieht sich nicht durch die ganze Unternehmenskultur. Scrum wird eingeführt und mit agil gleichgesetzt. Ein kultureller Wandel findet nicht statt.</li><li>DevOps-Praktiken sind wichtig, um agile Projekte zu ermöglichen, werden nicht richtig umgesetzt und versinken z. B. in einem Dschungel aus Anträgen und Berechtigungen.</li><li>Teams können nicht selbstständig, unabhängig und fokussiert arbeiten.</li><li>Kontinuierliches Lernen, Feedback und Verbessern findet nicht oder nur wenig statt.</li><li>Es wird nur selten oder gar nicht auf Produktion deployed, Erfahrungen können nicht gesammelt werden und es kann nicht daraus gelernt werden. Es wurde dadurch auch kein Wert geschaffen.</li></ul>

Scheitern auf Ansage – Szenen aus der agilen Transformation

<p><span>Industrial IoT (IIoT) as a buzzword gained traction within recent years. However, implementing common use cases like real-time monitoring of PLCs may involve a huge amount of money and effort. For example, current approaches implementing such a monitoring solution require complex architectures. Examples and </span><a href="https://www.elastic.co/use-cases/mm-karton" target="_blank"><span>show-cases</span></a> <span> for real-time monitoring often use OPC-UA as an interface to connect to the PLCs. However, this leaves out a huge number of older PLCs in factories all over the world with no support for OPC-UA.</span></p><p><span>We are presenting an approach involving less effort and way less money needed to implement near-real-time IIoT monitoring. This is realized by utilizing </span><a href="https://plc4x.apache.org/" target="_blank"><span>Apache PLC4X</span></a> <span> and the </span><a href="https://www.elastic.co/what-is/elk-stack" target="_blank"><span>ELK Stack</span></a> <span>. Apache PLC4X is integrated into Logstash as a Logstash plugin. This is used to connect to the PLCs and transfer the incoming data into ElasticSearch. Kibana serves as the data analysis and monitoring user interface.</span></p><h2><span>Showcase overview</span></h2><p><span>The showcase implements a rather simple scenario with two conveyor belts within a factory containing temperature sensors for each conveyor belt. A conveyor belt consists of three workstations (or stages). </span><span>The conveyor belt processes items through the workstations. The temperature of the processed items is monitored by the sensors at every stage. </span><span>During each workstation, errors may occur due to high temperatures (it’s a rather theoretical </span><span>example). These errors may produce faulty material, so we are eager to monitor the temperature on each workstation and get insights if anomalies happen.<a href="https://media.graphassets.com/eif5qSLhS3WpRJXjYOqW"><img src="https://media.graphassets.com/eif5qSLhS3WpRJXjYOqW" alt="Sensors on Conveyor Belt" width="415" height="146" /></a> </span></p><p><span>The showcase consists of three main components. First, there is a simulated (virtual) factory with two servers as data sources for our scenario. </span><span>The servers are polled by Logstash (with integrated Apache PLC4X) as the second component. Logstash pushes the data to ElasticSearch, with Kibana as the frontend for data analysis and display.</span></p><p> </p><p><span><a href="https://media.graphassets.com/pWvANtEStmLxX00zgkXQ"><img loading="lazy" width="250" height="287" src="https://media.graphassets.com/pWvANtEStmLxX00zgkXQ" alt="Components overview" /></a> </span></p><h3><span>What is Apache PLC4X?</span></h3><p><span><a href="/wissens-hub/blog/apache-plc4x-industrial-innovation">Apache PLC4X</a>  serves as a universal protocol adapter for different types of PLCs. The project’s goal is to easily access many types of PLCs by having a standardized interface for the PLCs’ protocol, e.g. Siemens S7 or Beckhoff ADS.</span></p><h3><span>Logstash integration</span></h3><p><span>The simplicity of the presented approach is achieved by the integration of Apache PLC4X into Logstash as a plugin. We implemented an easy and convenient way to leverage the power of PLC4X with a well-known ETL tool like Logstash. <a href="/wissens-hub/blog/plc4x-logstash-java-input-plugin">This blog post</a>  (German only) presents our challenges in building the Logstash integration.</span></p><h2><span>The showcase</span></h2><p><span>The showcases example implementation is available within a </span><a href="https://github.com/stefah/plc4x-elasticsearch-demo" target="_blank"><span>GitHub repository</span></a> <span>. You can run and try out the example with all components in a few seconds by executing <em>docker-compose</em>.</span></p><p><span>This will spin up several Docker containers for ElasticSearch, Kibana, Logstash, and 2 simulated OPC-UA servers. Everything is preconfigured to show the demo.</span></p><p><a href="https://media.graphassets.com/izPJpY4GQrquJrJjce2k"><img loading="lazy" width="250" height="260" src="https://media.graphassets.com/izPJpY4GQrquJrJjce2k" alt="Implementation Overview" /></a> </p><h3><span>The simulated OPC-UA server</span></h3><p><span>For the first iteration of our showcase, we quickly needed a simulated PLC to demonstrate the capabilities of Apache PLC4X with Logstash. As PLC4X’s greatest advantage over OPC-UA is that it seamlessly supports different kinds of legacy PLCs (i.e. PLCs without support for OPC-UA), we wanted to use a simulated PLC. However, we didn’t have such a simulated PLC at hand. Therefore, we used a </span><a href="https://github.com/FreeOpcUa/opcua-asyncio" target="_blank"><span>free implementation of an OPC-UA server</span></a> <span> and because of the OPC-UA protocol support of Apache PLC4X, we can demonstrate our use case.</span></p><p><span>The server consists of three temperature sensors, continuously emitting temperature data with little variations in the temperature value (Gaussian distributed) and introduces randomized temperature variations into the data.</span></p><h3><span>Demo Implementation</span></h3><p><span>The implementation of our showcase is done by configuring the Logstash PLC4X plugin within a pipeline:</span></p>

```
input {
	plc4x {
		jobs => {
			job1 => {
				rate => 200
				sources => ["sensors1", "sensors2"]
				queries =>  {
					PreStage => "ns=2;i=3"
					MidStage => "ns=2;i=4"
					PostStage => "ns=2;i=5"
					ConveyorBeltTimestamp => "ns=2;i=7"
				}
			}
		}
		sources => {
			sensors1 => "opcua:tcp://opcua-server-1:4840/freeopcua/server/"
			sensors2 => "opcua:tcp://opcua-server-2:4841/freeopcua/server/"
		}
	}
}
```

<p><span>Afterward, we configured three Timelion visualizations to display the three different temperature sensors for each conveyor belt. You can configure many more useful visualizations if needed. The picture below shows the configuration of a time series diagram for one stage.</span></p><p><a href="https://media.graphassets.com/HYoYSNemTZIlNlB41gbJ"><img loading="lazy" width="250" height="129" src="https://media.graphassets.com/HYoYSNemTZIlNlB41gbJ" alt="Timelion Visualization" /></a> </p><p><span>The 3 Timelion visualizations are combined within a dashboard and already present a nice overview of the temperature data.</span></p><p><a href="https://media.graphassets.com/LdWmaRRu2sdOsWMd2egK"><img loading="lazy" width="250" height="129" src="https://media.graphassets.com/LdWmaRRu2sdOsWMd2egK" alt="Dashboard" /></a> </p><p><span>You may already see some of the detected anomalies at first sight. However, smaller anomalies, with narrower outliers, are harder to manually discover within such a view. </span><span>This is where Kibana’s machine learning features (part of the platinum license) come in place. We are able to automatically detect anomalies within our factory, simply by configuring a new machine learning job.</span></p><p><span>You can configure the machine learning job by navigating to the machine learning tab and clicking on the “<em>create new job</em>” button. Then you have to select the <em>plant</em> index and choose the wizard for multi-metric anomaly detection. Next, choose the time range for your job data. In our case, we had the example running for about four hours, which produced around 140.000 data points.</span></p><p><a href="https://media.graphassets.com/jctzeKZBS521SFybZVGo"><img loading="lazy" width="250" height="137" src="https://media.graphassets.com/jctzeKZBS521SFybZVGo" alt="ML Job Creation" /></a> </p><p><span>In the job settings area, select the fields on which the job runs: <em>values.PreStage</em>, <em>values.MidStage </em>and <em>values.PostStage</em> with the max aggregation operation. As the split data field, select the sensor name by choosing the <em>sourceName </em>field.</span></p><p><span>The bucket span describes the size of the generated buckets for the max aggregation and should be set to one second for a finer resolution. Last but not least, configure a job name and description. By clicking on the  “<em>create job</em>” button, the machine learning job gets started. </span></p><p><a href="https://media.graphassets.com/gJMTKvITbWyrpiQQzT2G"><img loading="lazy" width="250" height="208" src="https://media.graphassets.com/gJMTKvITbWyrpiQQzT2G" alt="ML job results" /></a> </p><p><span>After the job finished, you can view the results. As you can see in the screenshot, the model detected several anomalies and even scores them with a severity measure.</span></p><p><span>It’s also possible to configure a watcher (alerting) for a continuously running job. This allows for e-mail notifications when anomalies occur.</span></p><h3><span>Key takeaways</span></h3><p><span>In this blog post, we built a near-real-time monitoring and anomaly detection for a simulated factory showcase.</span></p><p><span>The benefits of this solution are its low cost and effort compared to similar solutions on the market. Although we used a simulated PLC, the demo is easily applicable to a real PLC. Monitoring, alerting, and machine learning is usually just a matter of configuring the available components and therefore quickly implemented. </span></p><p><span>For the demo setting with only three sensors on two servers, machine learning seems a bit overpowered. However, with thousands of PLCs within multiple factories, manually configuring alerting and thresholds can be a tedious task. Scaling up our example is easily manageable, all it takes is an ElasticSearch cluster and Logstash with the PLC4X plugin on small machines close to the PLCs.</span></p><p><span>So what’s next? We want to improve our showcase by using real or simulated PLCs without OPC-UA to demonstrate the real power of Apache PLC4X. We will further improve the PLC4X Logstash plugin and get it ready for production. It is on our roadmap to extend the showcase scenario to a more production-like setting with an ElasticSearch cluster and a scalable, variable amount of PLCs. </span></p>

Using Apache PLC4X and ElasticSearch for IIoT monitoring and anomaly detection

<p>In this blog post, we want to show why agile transformations fail, illustrating various situations that unfortunately still occur far too often in reality today.<br /> More and more often, we notice that the company culture lived by the management and the employees is crucial for a successful implementation of an agile transformation or agile development. Particularly in large companies, onboarding employees and motivating them tends to be neglected. For example, there are initiatives to transform the company, but they falter and fail due to the attitude of the workforce and/or management, i.e. the company’s culture.<br /> When a healthy agile culture can’t be established in an organization, the following situations may appear:</p><blockquote><p>“But, we are agile! We are doing Scrum!”</p></blockquote><p>Agile has become an overused term. In this article, we look at agile from the perspective of corporate culture. A healthy agile culture has to be lived by employees and their superiors (who act as role models). The transformation to it is laborious, because old structures and behaviors need to be broken up.<br /> Often, <em>Agile</em> is equated with Scrum. It is assumed that if Scrum is practiced, agile software development follows. Working according to Scrum sounds like an easy task, and yet many mistakes happen in the implementation of Scrum in terms of a good agile practice. We have noticed that Scrum does not have to be that important at all. It is more important to live agile in the project culture.<br /> An agile culture includes a focus on transparency, e.g. about all project decisions made, and strengthening the flow of information both within the team and externally. This allows each team member to contribute fully to the success of the project by being involved in the planning, design and improvement of the project. Agile methods (e.g. Scrum) are frameworks to enable this to happen continuously and iteratively.<br /> In the following, we will address common agile anti-patterns related to Scrum.</p><p><strong>The “agile waterfall” project:</strong> It is often observed that agile projects are planned similarly to a waterfall project at the beginning: a time and project plan is defined and the budget must be determined. Deadlines are determined for the individual features. Requirements are packaged into user stories and these are unleashed in the project in one big batch. In the worst case, the user stories are of poor quality, e.g. because they are sliced into too large chunks or are soon outdated.<br /> What follows is that features are implemented, but validation or feedback from the actual end users takes place far too late, if at all. The project falls further and further behind the planned schedule and ultimately fails for the same reasons as usually waterfall projects fail: the planned launch is postponed several times, and when the release finally arrives, it lacks user acceptance. The textbook example of a Big Bang – not at all in line with an agile culture.</p><p><strong>“Chief programmer” sets the direction:</strong> Scrum is used as an excuse to pretend to be Agile. Example Pattern: a product owner (e.g. a former project manager, now retrained) tells each individual team member exactly what tasks to do and when to do them. Scrum tools and meetings are only used to micromanage the team. It is impossible for the team to work independently. Priorities are often changed during the sprint, e.g. because features are not prioritized according to maximum benefit for the product, but according to political aspects (e.g. because a certain feature was promised to a manager for the next release). As a consequence, the team’s decisions are influenced by the “chief programmer” on actual team-internal decisions, therefore it gets impossible for the team to commit to a (sprint) goal.<br /> One thing needs to be made clear: Scrum was not developed to control teams better. It should be clear that not everyone can know everything and therefore a solution must be worked out with the team. If everyone in the team works together and everyone has a good overview of the project’s goals and the future product development, perhaps a better solution can be found.</p><p><strong>Lack of dedicated scrum master:</strong> Good scrum masters are expensive, but they are important. We often hear: “But they don’t even produce code! Well, then a team member can just take over the whole thing.”<br /> This often leads to frustration and impediments within the team, because, for example, retrospectives are poorly conducted or omitted. There is no dedicated person who takes care of removing impediments. This is followed by a decreasing development speed and the previously saved costs are gone.<br /> There is only one solution for this: employ dedicated scrum masters! They take care of protecting the team from external influence and pressure, organize the scrum meetings and solve internal problems. The team must be able to work undisturbed!</p><p><strong>Overly large teams:</strong> Teams should not be too large, otherwise some negative effects can be noticed: meetings drag on due to the number of participants, decision-making becomes increasingly difficult due to many parties to consider, and it becomes more complicated to maintain psychological safety in the team.<br /> Also, knowledge transfer between team members is more challenging. In addition, the team spends 30-50% of the sprint time in meetings, and the time for development becomes increasingly scarce.<br /> In large projects, a meeting is called for pretty much every decision or blocker, and preferably everyone has to be there, because it could affect everyone. In the worst case, this leads to minutes of silence and a lot of wasted time.<br /> Teams should be able to act as independently as possible and they should not be too large. Shared dependencies and interfaces should be discovered and teams should provide a “product” to the respective other team. This leads to a decoupling of the individual teams and the teams can work in a self-determined manner again. Larger meetings between the teams should only take place with individual “emissaries” of the respective teams. The “community of practice” pattern has also proven itself here.</p><blockquote><p>“Well, we are agile! We are doing DevOps!”</p></blockquote><p>DevOps (as a buzzword) has arrived in management. Nevertheless, fundamental concepts of a healthy DevOps practice are not or only partially implemented. When DevOps practices do not work, this is also often due to a lack of alignment of habits, processes and methods by management and employees.<br /> Among other things, teams are not encouraged to live a DevOps culture. Instead, siloed departments or teams continue to exist, with different responsibilities, budgets, and therefore their very own political goals.<br /> For example, DevOps is mistakenly established as a department within the company rather than a practice. A DevOps team as an enabler within the organization would not be a bad thing in this regard, but in reality this department does not provide support for teams, but is hidden behind ticketing systems and lengthy processes. The teams cannot get away from the constraints of the old plan-build-run culture. For example, getting the much-needed CI pipeline doesn’t require one click within a tool, but rather lengthy application forms must be filled out and signed off on by multiple higher-ups so that the pipeline can then be created by the so-called DevOps team.</p><p>These processes have grown in companies over a long time, perhaps for good reasons. Yet they prevent developers from working effectively on the project. The credo must be: <em>Everything and everyone in the company must work toward enabling developers to work effectively and without disruption.</em> Only then can developers focus on creating value for the company and advance the company’s product.<br /> So for our example, this could mean that a DevOps team provides a working self-service platform for CI/CD, which allows projects to create new build and deployment pipelines without much effort. They act as an enabler team and train and support other teams to quickly integrate their platform into their work.<br /> An agile culture and a functioning DevOps practice form a strong symbiosis. DevOps supports development according to agile methods enormously. Only when teams can handle resources independently and in a self-determined manner are they able to also quickly bring features into production.</p><blockquote><p>“Digitization project XY has the highest priority!”</p></blockquote><p>Focus is important. Very often, we see that teams are distracted from their current project by other tasks. How can the important digitization project be successfully completed if team members still spend 50% of their time firefighting for legacy systems or are dragged into pointless meetings?<br /> Good management keeps these team members on task and propagates the project goals to keep all employees focused on a common goal. Goals need to be clear to each team member and management decisions need to be transparent. Only then will team members work effectively and with great intrinsic motivation.</p><blockquote><p>“You said two months ago that it would take X days, now get on with it!”</p></blockquote><p>In addition, teams fall into another trap: they are nailed down to schedules and budgets that were arbitrarily set months ago, but are absolutely untenable with the current knowledge of the product or domain. At the beginning of the project, many technological and architectural decisions were made based on now outdated assumptions when the project had been running for a month or two. The team now tries to meet these deadlines at all costs, even though it is clear that they can no longer be met: motivation drops and the belief in success is lost. Huge amounts of overtime accumulate and the technical debts become bigger and bigger. A downward spiral begins.<br /> It would be more important to measure teams not on deadlines and budgets, which in most cases cannot be met, but on the basis of delivered features. Big decisions should be made as late as possible in order to keep the solution space open and thereby achieve results as quickly as possible, which can then be evaluated and tested. On the other hand, small portioned decisions should be made quickly in order to be validated quickly and to receive feedback fast.</p><blockquote><p>“Are we at a science fair?”</p></blockquote><p>This statement is extreme but we have heard it more often than we would have liked to. It really astonishes us. For us, an explorative approach is a matter of principle and a continuous development of solutions out of hypotheses and their validation through user tests is indispensable.<br /> In reality, it often looks like this: the exact requirements for the product seem to be clear. So we get started (but without requirements specifications, because we are agile!) and user stories are created and a schedule is worked out. For example, features are then taken from (to-be-replaced) legacy systems which are obviously absolutely needed. In addition, it is agreed that the old system was great, but must now be replaced by something better, but the new system must do exactly the same things as the old one.<br /> One wants to do everything right from the start. The way to get there is often unclear and we observed that the customers themselves are not so sure which features really produce the greatest business value for the new product. But instead of starting from scratch, a canonical data model is usually developed (or adopted), the architecture is defined, and instead of figuring out what will create the most value in the new product, a large feature catalog is worked through.</p><p>Again, a downward spiral starts, because the opposite is usually the case: the requirements are anything but clear. What usually happens: the project’s goals are not achieved, there is an ever-increasing delay to the deadlines and the end users are not asked for feedback. The developers’ motivation declines and nobody believes in the success of the project. The project will fail sooner or later.<br /> An explorative approach can prevent this, but it does not come without pain. After all, at the beginning it looks like there are no successes made and that there is a slow development speed. Assumptions are made, features are developed and later much is discarded. However, the earlier assumptions can be validated or invalidated, the better and the higher the development speed will be later on.</p><p>It is important to be open to change from the start! This is part of an agile culture. Change must be reflected in the architecture and implementation of the software. It will happen that the data model will change again after each iteration and the code will have to be heavily refactored each time. Nevertheless, such an approach allows for implementing the actually important features and for getting the necessary feedback from the users early on. It is important to measure the success of the team not on the basis of deadlines met, but on the basis of tested and validated decisions.</p><blockquote><p>“Yes, we want to be in production as soon as possible!”</p></blockquote><p>Unfortunately, we hear this statement far too often in projects that are usually already delayed, e.g. due to the situations already mentioned above. This sometimes means that a product is already months or years behind the actual schedule. Yet, during development, it has not even been successfully rolled out to production.<br /> One thing must be clearly stated: if the feature/product has not deployed to production, no value has been created. Yet, we see it time and time again that teams continue to be bombarded with feature requests: the focus is not on getting existing features into production and testing on end-users and getting feedback. Development goes on and on, money is burned, and in the end customers are presented with a fait accompli.<br /> When the time comes, and the product can be deployed to production, the team lacks the knowledge of which company-specific compliance rules and processes must be adhered to in order to even deploy the new “cloud-native digitization project” to production. For example, cloud teams are deployed as enablers within the company (similar to DevOps teams described earlier) to introduce the respective major cloud providers within the company, but later on these teams are either not designed to support other teams on their way to production and/or are completely busy with other political tasks.<br /> As with a poorly executed DevOps practice, the lack of production readiness again shows a poor “as a service” mindset towards a project. Furthermore, it should be natural for DevOps-practicing teams to also deploy to production several times a day. Only in this way is it possible to obtain a continuous development flow with constant feedback.</p><h3>TL;DR</h3><p>This blog post highlighted various situations and scenarios that can occur in agile projects and then doom them to failure.<br /> Let’s summarize briefly:</p><ul><li>“Agile” is often an empty word and it does not permeate the entire corporate culture. Scrum is introduced and equated with agile. A cultural change does not take place.</li><li>DevOps practices are important to enable agile projects, but are not implemented properly and may drown in a jungle of application forms and politics.</li><li>Teams cannot work autonomously, independently and with focus.</li><li>Continuous learning, feedback, and improvement do not take place, or take place only infrequently.</li><li>It is rarely or not at all deployed to production, experiences cannot be gathered and no lessons can be learned from them. No value has been created as a result either.</li></ul>

Failure on demand – Scenes from an agile transformation

IT Consultant

Business Consultant & Agile Coach

Software Developer and Consultant

Software Developer & Consultant

Infrastructure as Code in AWS: Keine Silver Bullet

IT Consultant & Developer

<p>Während es im Betrieb von Containern in den letzten Jahren sehr viele Entwicklungen gab, ist die Erstellung von Images im Prinzip gleich geblieben. Viele benutzen nach wie vor Docker zur Erstellung von Images. In diesem Artikel wollen wir u. a. mit Google Jib und Kaniko ein paar Alternativen dazu aufzeigen, die das Erstellen von Images deutlich erleichtern können.</p><p>Am Einsatz von Docker zur Erstellung von Images ist erst einmal nichts auszusetzen. Allerdings gibt es hierbei einige Randbedingungen architektonischer und sicherheitstechnischer Art, die den Einsatz zum Beispiel in Kubernetes erschweren. Der Docker-Daemon, der dafür genutzt wird, ist eine monolithische Anwendung. Dadurch müssen diesem immer die Rechte gegeben werden, die für alle möglichen Operationen nötig sind. Des Weiteren benötigt er einen privilegierten Zugang zum Linux Kernel zur Erstellung von Images. Wer sich an dieser Stelle für die technischen Hintergründe interessiert, sei auf <a href="https://blog.jessfraz.com/post/building-container-images-securely-on-kubernetes/" target="_blank">einen Artikel von Jessie Frazelle</a>  dazu verwiesen.</p><p>Aufgrund der etwas unhandlichen Konstruktion von Docker mit einem Daemon als ausführender Einheit stellt sich die Frage, wie man diesen nun für die Erstellung von Images aus einem Docker-Container innerhalb eines Kubernetes-Clusters benutzen kann. Eine Variante ist es, über den Volumes-Mechanismus den Socket für die Kontrolle des Daemons in den Build-Container weiterzureichen.</p><p>Dies hat natürlich Folgen für die Systemsicherheit, da man hier die Kontrolle über Teile des Host-Systems in Container abgibt. Von daher ist dies in vielen Umgebungen keine Option. Eine weitere Möglichkeit ist die Nutzung von Docker-in-Docker-Images. Dabei wird ein Docker Daemon in einem separaten Container gestartet und aus dem Build-Container heraus angesteuert. In einem Kubernetes-Cluster kann dies zum Beispiel als ein weiterer Container desselben Pods erfolgen. Hiermit hat man die Abgabe von Kontrolle über das Host-System entschärft. Allerdings benötigt auch die Docker-in-Docker-Konstruktion privilegierten Zugriff auf den Linux-Kernel.</p><p>Beim Betrieb innerhalb einer Docker-Infrastruktur wie Kubernetes muss man daher abwägen, ob das Risiko, Containern privilegierten Zugang zu gewähren, tragbar ist. Eine organisatorische Lösung kann darin bestehen, seine Infrastruktur in mehrere Cluster aufzuspalten oder für den Build der Images eigene Infrastruktur auf getrennten Hosts vorzusehen. Zum Teil stellen Cloud-Provider mit Produkten wie <a href="https://cloud.google.com/container-builder/docs/" target="_blank">Google Cloud Container Builder</a>  oder <a href="https://docs.microsoft.com/de-de/azure/container-registry/container-registry-tutorial-quick-build" target="_blank">Azure Container Registry Build</a>  diese Funktionalität auch als Service bereit.</p><h2>Docker Layers</h2><p>Die Begriffe “Container” und “Image” vermitteln stets den Eindruck eines einheitlichen Binärformats, das am Stück ausgeliefert wird. In Wirklichkeit besteht ein Image aus mehreren Schichten. Intern sind dies Tarballs mit jeweils einem Teil des Image-Dateisystems. Wenn man mit Docker eine Dockerfile baut, entspricht eine Schicht einem Befehl innerhalb der Dockerfile und der daraus resultierende Blob (Tarball) enthält jeweils die Änderungen, die im Rahmen dieses Befehls am Image vorgenommen werden. Docker gibt die angelegten Layer dabei auch aus:</p><p><img width="913" height="472" src="https://media.graphassets.com/OARbhn0jRLq8OJji5zFe" alt="Docker Layers" /></p><p>Neben den Schichten enthält ein Image noch Metadaten in JSON-Dateien. Diese enthalten u. a. die Architektur und das Betriebssystem, für die die jeweiligen Layer bestimmt sind. Layer werden durch diese Metadaten anhand ihrer Hashsumme referenziert und man findet diese auch in der Verzeichnisstruktur von Docker wieder.</p><p><img loading="lazy" width="1296" height="458" src="https://media.graphassets.com/bkzLpSAiRISK16PDb3PY" alt="docker inspect" /></p><p><img loading="lazy" width="1736" height="422" src="https://media.graphassets.com/rbQwYg3JRBKomONPKqAU" alt="ordnerstruktur docker daemon" /></p><p>Da es sich letztendlich nur um Tarballs und JSON-Dateien handelt, lässt sich ein großer Teil der Erstellung eines Images völlig ohne Docker-Daemon und erhöhte Privilegien im Userspace erstellen – vor allem, wenn es sich lediglich um die Installation eines JARs für eine Java-Applikation in ein vorbereitetes Image handelt. Hier kommt Jib ins Spiel.</p><h2>Jib</h2><p>Das neue Tool von Google besteht aus einer Bibliothek sowie Plugins für <a href="https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin#quickstart" target="_blank">Maven</a>  und <a href="https://github.com/GoogleContainerTools/jib/tree/master/jib-gradle-plugin#quickstart" target="_blank">Gradle</a> , die bestimmte, auf viele Java-Applikationen anwendbare Annahmen trifft und damit basierend auf einem vom Entwickler bestimmbaren Java-Basisimage Applikationen containerisiert und zu einer Registry hochlädt, ohne dass die Build-Umgebung dafür lokal oder remote Zugriff auf einen Docker-Daemon benötigt.<br /> Die Plugins sind denkbar einfach in eine reguläre Java-Build zu integrieren sind, wie hier am Beispiel des Maven-Plugins gezeigt. Mit diesem Schnipsel im POM eines Projekts</p><div>

```xml
<build>
  <plugins>
    <plugin>
      <groupId>com.google.cloud.tools</groupId>
      <artifactId>jib-maven-plugin</artifactId>
      <version>0.9.6</version>
      <configuration>
        <to> 
          <image>zielRegistry/repository/meinimage</image>
        </to>
      </configuration>
    </plugin>
  </plugins>
</build>
```

</div><p>lässt sich mittels</p><div>

```bash
mvn compile jib:build
```

</div><p>ein Image bauen und direkt an die angegebene Zielregistry senden, ohne dass ein Docker-Daemon im Hintergrund läuft. Möchte man doch gegen einen lokalen Docker-Daemon bauen, um mit dem Image zu spielen, lässt sich dies mit</p><div>

```bash
mvn compile jib:dockerBuild
```

</div><p>bewerkstelligen. Als Basisimage wird hierbei ein Java-Image aus Googles <a href="https://github.com/GoogleContainerTools/distroless">distroless-Familie</a>  von minimalen Docker-Containern verwendet. Nebenbei spart man sich somit im Übrigen auch komplett das Schreiben einer eigenen Dockerfile. Weitere Details zur Verwendung eines eigenen Basisimages sowie zur Authentifizierung gegenüber einer Docker Registry lassen sich den Seiten der Plugins entnehmen.</p><p>Anstatt sich für das zu verpackende Java-Artefakt einfach auf eine Fat Jar zu verlassen, wie sie zum Beispiel bei Spring Boot beliebt ist, packt Jib Abhängigkeiten, Ressourcen wie HTML oder CSS und die eigentliche Applikation in getrennte Layer des Images. Dadurch können bei Änderungen an nur einer dieser Schichten die Uploads an die Docker-Registry kleiner gehalten werden.</p><p>Was sind also die Einschränkungen, die sich daraus ergeben? Nun, Jib kann zwar eine Java-App zusammenpacken und entsprechende Layer schreiben, nicht aber Befehle im Kontext des Containers ausführen. Besitzt die eigene Applikation zum Beispiel noch externe Abhängigkeiten, erwartet z. B. die Präsenz bestimmter nativer Binaries im Image, so müssen diese bereits im Basisimage vorhanden sein. Befehle im Kontext eines Containers ausführen kann Jib mangels Docker-Daemon nicht. Außerdem geht Jib im Moment fest von Applikationen in ausführbaren JAR-Dateien aus. Das Containerisieren von WARs wird im Moment nicht unterstützt, jedoch hat das Team um Jib dies bereits auf dem <a href="https://github.com/GoogleContainerTools/jib/issues/431" target="_blank">Schirm</a> .</p><h2>Kaniko</h2><p>Wer allerdings erweiterte Ansprüche an den Buildprozess seiner Docker-Images hat oder sich nicht im Java-Universum bewegt, ist an dieser Stelle nicht auf den Docker-Daemon angewiesen. Für den Build von Docker-Images hat Google im Frühjahr <a href="https://github.com/GoogleContainerTools/kaniko" target="_blank">Kaniko</a>  veröffentlicht. Bei der Benutzung von Kaniko kann wie gewohnt mit Dockerfiles weiter gearbeitet werden. Durch die Konzentration auf die Erstellung von Images konnte eine Vielzahl nötiger Rechte auf dem Linux-Kernel entfernt werden.</p><p>Um dies zu erreichen, haben die Entwickler die Befehle aus den Dockerfiles für ihre Umgebung nach implementiert. Nach der Ausführung jedes Befehls wird dann ein Snapshot des Dateisystems erzeugt. Durch einen Vergleich mit dem letzten Snapshot können dann die geänderten Dateien gefunden werden und daraus die entsprechenden Image Layer erzeugt werden.</p><p>Aktuell befindet sich Kaniko noch in einem relativ frühen Stadium, weswegen die einfachste Nutzung sicherlich in der Kombination mit Google Cloud und dem <a href="https://github.com/GoogleContainerTools/kaniko#running-kaniko-in-google-container-builder" target="_blank">Google Container Builder</a>  liegt. Aktuell befinden sich in diesem Bereich viele interessante Neuerungen in Entwicklung, so dass hier in Zukunft sicherlich noch mit der einen oder anderen interessanten Idee gerechnet werden kann.</p>

Docker Images sicher bauen mit Google Jib & Kaniko

<p>Frühling! Die Temperaturen steigen langsam, das Leben in der Natur beginnt sich wieder zu regen und die meisten Menschen machen in ihren Haushalten klar Schiff. Aber wieso sollte man den Frühjahrsputz auf den eigenen Keller oder Schuppen beschränken? Da aktuell das Büro für die meisten keine Option ist, haben wir uns mal angeschaut, wie man die eigenen AWS-Accounts wieder auf Vordermann bringt und ganz nebenbei noch einiges an AWS-Kosten sparen kann.</p><h2>Sofortmaßnahmen</h2><p>Solch eine Aufräumaktion startet man am besten durch die Prüfung der teuersten Ressourcen beim Cloud-Anbieter. Erste wichtige Anhaltspunkte kann dabei ein Blick in den <a href="https://aws.amazon.com/de/aws-cost-management/aws-cost-explorer/" target="_blank">AWS-Kosten-Explorer</a>  liefern. Dort kann man sehen, welche Dienste welche Kosten verursacht haben.<br /> <a href="https://media.graphassets.com/UORVJldVTQ6NbFssBtLU"><img width="1461" height="767" src="https://media.graphassets.com/UORVJldVTQ6NbFssBtLU" alt="AWS Kosten Explorer" /></a> <br /> Einen Klassiker unter den unnötigen Kosten bilden dabei unnötig laufende EC2-Instanzen im AWS-Umfeld. Die virtuellen Maschinen sind schnell erstellt und können je nach gewählter Ausstattung schnell signifikante Kosten erzeugen. Einer der Spitzenreiter hierbei ist aktuell die <code>p2.16xlarge</code>-Instanzgröße, die bei einem Dauerbetrieb über 15.000 Dollar pro Monat kostet. Hierbei kann neben der Löschung unnötiger Instanzen auch das Reduzieren der Instanzgröße eine Einsparung bringen.</p><p>Dieselben Maßnahmen können natürlich auch für andere Instanz basierte Angebote wie zum Beispiel den relationalen Datenbank-Service RDS durchgeführt werden. Dort kann man ebenfalls die nicht genutzten Instanzen löschen oder andere Instanzen auf ein vernünftiges Maß eindampfen.</p><p>Ein weiterer potentieller Treiber können die automatischen Datenbank-Backups sein. Diese werden nach genutztem Speicherplatz bepreist. Und mal ehrlich: Brauchen wir wirklich die Historie der Backups des ganzen letzten Jahres?</p><p>Ebenso lohnt sich oft ein Blick in Richtung selbsterstellter Artefakte. Für die Erstellung von EC2-Instanzen wird oft ein spezifisches AMI mit der benötigten Anwendung und allen Abhängigkeiten auf Betriebssystemebene kreiert. Hier stellt sich ebenfalls die Frage, ob alle jemals erstellten Images aufgehoben werden müssen. Selbst in regulierten Umgebungen ist oft nur die Aufbewahrung von Images vorgeschrieben, die auch in Produktion genutzt wurden. Ein weiterer Dienst, der erstellte Artefakte beinhalten kann, ist zudem mit dem <a href="https://aws.amazon.com/de/ecr/" target="_blank">Elastic Container Registry</a>  für Container Images vorhanden.</p><p>Neben dem durch Entwicklungsartefakte belegten Speicherplatz kann es sich auch lohnen, den Storage für Produktionsumgebungen unter die Lupe zu nehmen. Vor allem virtuelle EBS-Festplatten können hier schnell zu Buche schlagen. Von diesen können wiederum ebenfalls Snapshots erstellt werden, die ebenfalls begutachtet werden sollten. Eine Betrachtung der S3 Buckets kann sich hier ebenfalls lohnen.</p><p>Weitere Potenziale gibt es auf Netzwerkebene im Bereich der Load Balancer und Elastic IPs, deren Ausführung an dieser Stelle zu weit führen würde.</p><h2>Organisatorische Maßnahmen</h2><p>Die laufenden AWS-Kosten von allen Accounts sollten überwacht werden. Das ist die erste Regel, die Unternehmen und Privatpersonen auf <a href="https://www.codecentric.de/partner/aws">AWS</a>  beachten sollten. Trotzdem werden Billing Alerts, obwohl Teil aller grundlegenden AWS-Zertifizierungen, gerne vergessen. Vor allem, wenn es den Entwickler*innen freisteht, in ihren Firmenaccounts zu testen und zu experimentieren, sollte ab einer gewissen Grenze eine Benachrichtigung bei den Verantwortlichen eingehen. Oft deuten hohe Rechnungen in einzelnen Entwickleraccounts schlicht auf vergessene Test-Infrastruktur hin und die verantwortlichen Entwickler*innen drehen die Kostenquelle von selbst ab, wenn sie benachrichtigt werden.</p><p>Ein weiterer wichtiger Schritt, um seine AWS-Kosten unter Kontrolle zu bekommen, ist, jede Ressource in jedem AWS-Account der Organisation zuordenbar zu machen. Neben der grundlegenden Sortierung in getrennte AWS-Accounts für verschiedene Projekte empfiehlt AWS die Nutzung von Tags an jeder erstellten Ressource, um sie zu einem Projekt oder einer Kostenstelle zurückverfolgen zu können. Diese Tags lassen sich auch im Cost Explorer und den monatlichen Kostenreports darstellen. Gleichzeitig stellen veraltete Tags an einem abgeschlossenen Projekt oder gar die komplette Abwesenheit von solchen einen starken Indikator für die Überflüssigkeit einer Ressource dar.</p><p>Unsere Empfehlung: So gefundene Ressourcen mit “Obsolete: Datum” taggen und eine Rückmeldung an die für den Account verantwortlichen Personen geben, zusammen mit einem Ultimatum, nach dem diese Ressourcen gelöscht werden, sollte das Tagging nicht korrigiert worden, d. h. die Nutzung der Ressource klargestellt sein. Diese Behandlung von Ressourcen lässt sich auch mit Tools wie etwa Swabbie lösen, das Netflix intern verwendet, um mit Spinnaker deployte AWS-Ressourcen wieder aufzuräumen.</p><p>Zuletzt ein gerne vergessener Aspekt der AWS-Organisation: Offboarding. AWS-Accounts von abgeschlossenen Projekten oder ausscheidenden Mitarbeiter*innen bleiben erst einmal unangetastet stehen, wenn die Löschung nicht Teil des Offboardingprozesses oder gar automatisiert erfolgt. Damit bleibt alle in jenen Accounts befindliche Infrastruktur erst einmal erhalten und verursacht weiter Kosten. Sollten dort gar von außerhalb erreichbare Komponenten deployed sein, ist dies zusätzlich auch ein Sicherheitsrisiko. Daher sollte die Löschung überflüssig gewordener Accounts zu einem Prozess werden, der zeitnah und systematisch verfolgt wird, nach Möglichkeit noch mit den Accountverantwortlichen zusammen, um sicherzustellen, dass keine noch irgendwo benutzten Ressourcen mit dem Account abgeräumt werden.</p><h2>Fazit: Nachhaltiges AWS-Kosten-Management ist unverzichtbar</h2><p>Die hier geschilderten Maßnahmen können natürlich nur an der Oberfläche der über 160 AWS-Services kratzen. Wer seine Cloud-/AWS-Kosten aber langfristig reduzieren will, kommt um ein nachhaltiges Kostenmanagement nicht herum.</p>

Cloud-Frühjahrsputz: AWS-Kosten sparen

AWS Cloud Specialist

IT-Security Consultant


> Keycloak ist ein Open-Source-Identitätsanbieter. Du kannst mit minimalem Aufwand Authentifizierung zu Anwendungen und sicheren Diensten hinzufügen. Dabei musst du dich nicht mit der Speicherung oder der Authentifizierung von Benutzern befassen. Keycloak bietet eine Benutzer-Föderation, starke Authentifizierung, Benutzerverwaltung, feingranulare Autorisierung und mehr.
> <a href="https://www.keycloak.org/" target="_blank" rel="noopener noreferrer">~ Keycloak</a>

In diesem Blogpost werde ich meinen Lernweg zu Keycloak und die Ressourcen, die mir auf diesem Weg geholfen haben, mit dir teilen.
Vielleicht hilft dir auch das von mir verwendete Material, Identity and Access Management (IAM) und Keycloak zu verstehen.

Es hat mich einige Zeit gekostet, Keycloak zu erlernen und in Gang zu bringen.
Ich bin wenig vertraut mit dem Java-Ökosystem, da seit meinem letzten Java-Projekt einige Zeit vergangen ist.
Daher fiel mir das Lernen vielleicht etwas schwerer. Wenn du aber ein routinierter Java-Entwickler bist, hast du Glück, denn Keycloak ist in Java geschrieben.
Ich möchte darauf hinweisen, dass ich noch nicht alles erlernt habe, aber ich fühle mich sicher bei der Bereitstellung, Erweiterung und Integration von Keycloak.

## Einstieg in Keycloak
Meine Keycloak-Reise begann in einem Kundenprojekt, in dem wir ein Log-in Theme für Keycloak gebaut und in unsere Frontend-Anwendungen integriert haben.
Sicherlich ist es nur eine kleine Teilmenge dessen, was Keycloak zu bieten hat, aber die anfänglichen Ressourcen sind ein guter Ausgangspunkt für jeden.
Nach einem ersten Besuch der Website, um einige grundlegende Informationen zu finden, zeigen folgende zusätzliche Videos kompakt die Leistungsfähigkeit von Keycloak:

- <a href="https://www.youtube.com/watch?v=mdZauKsMDiI" target="_blank" rel="noopener noreferrer">Securing apps and services with Keycloak authentication | DevNation Tech Talk </a> von Stian Thorgersen (Keycloak Project Lead)
- <a href="https://www.youtube.com/watch?v=KrOd5wIkqls" target="_blank" rel="noopener noreferrer">How to secure your Spring apps with Keycloak von Thomas Darimont @ Spring I/O 2019</a> von Thomas Darimont (Keycloak Maintainer)

## Ressourcen jenseits der Keycloak-Doku: Was ist IAM?
Ich habe eine interessante Beobachtung bei mir selbst gemacht:
Als ich mit Keycloak anfing, war die offizielle Dokumentation überhaupt nicht hilfreich.
Zum Glück hat sich das geändert, und jetzt finde ich die Dokumentation ganz anständig.
Kollegen, die ebenfalls mit Keycloak in Kontakt kamen, hatten das gleiche Problem.
Ich lernte, meine seltsame Beziehung zur Keycloak-Dokumentation entstand aufgrund einer Lücke zwischen meinem Wissen und den Informationen die die Dokumentation bereitstellt.
Die Dokumentation erklärt nicht, was IAM oder OpenID Connect ist und wie es intern funktioniert. Das wird vorausgesetzt.

Ich habe gelernt: Es gibt den IAM-Sektor und Keycloak als Produktlösung.
Die Keycloak-Dokumentation konzentriert sich auf die wichtigsten Teile der Bereitstellung, Verwaltung und Anpassung von Keycloak.
Es wird erwartet, dass einem die IAM-Grundlagen und die Funktionsweise der entsprechenden Protokolle geläufig sind.
Für viele (mich eingeschlossen), die in Keycloak einsteigen, ist das wahrscheinlich nicht der Fall.
Bevor die Keycloak-Dokumentation also eine Hilfe für uns ist, müssen wir zunächst Grundwissen über IAM aufbauen.

Wenn du vor demselben Problem stehst, ist es vielleicht eine gute Idee, einen Schritt zurückzugehen und sich auf die Grundlagen von IAM zu konzentrieren, bevor wir tiefer in Keycloak einsteigen.
Es ist sinnvoll, sich über den IAM-Sektor im Allgemeinen zu informieren, aber sich auch mit den Protokollen vertraut zu machen, die wir verwenden möchten.
In meinem Fall sind das hauptsächlich OAuth2 und OpenID Connect (OIDC).

Das wirft die Frage auf, worum es bei IAM eigentlich geht.
RedHat (der Sponsor von Keycloak) hat einen guten Artikel, der den IAM-Kontext beschreibt:
> Identitäts- und Zugriffsmanagement (IAM) ist eine zentralisierte und konsistente Methode zur Verwaltung von Benutzeridentitäten (d. h. Personen, Dienste und Server) zur Automatisierung von Zugriffskontrollen und zur Erfüllung von Compliance-Anforderungen in herkömmlichen und containerisierten Umgebungen.
> <a href="https://www.redhat.com/en/what-identity-and-access-management-iam" target="_blank" rel="noopener noreferrer">~What is identity and access management (IAM)?</a>

Es gibt eine großartige Ressource, die die Lücke zwischen dem Erlernen der Grundlagen und dem Erlernen von Keycloak überbrückt.
Stian, der Ersteller von Keycloak, hat letztes Jahr ein <a href="https://www.keycloak.org/2021/06/book.adoc" target="_blank" rel="noopener noreferrer">Buch über Keycloak</a> geschrieben.
Ich finde, dieses ist der perfekte Startpunkt.
Er erklärt die Grundlagen des OpenID-Connect-Protokolls und zeigt, wie es mit Keycloak benutzt wird.
Darüber hinaus erklärt er eine Menge Funktionen von Keycloak in kurzen Abschnitten.
Es verschafft uns einen guten Überblick, welche Funktionalitäten Keycloak alles bietet.
Von dort aus können wir die Funktionen auswählen, die den Anforderungen unserer Projekte entsprechen.
Nun können wir zur Keycloak-Dokumentation springen, um einen tieferen Einblick in die Verwendung der einzelnen Funktionen zu erhalten.

> Eine Anmerkung beim Lesen des Buches:
> OAuth2 – die Grundlage von OpenID Connect – ist nicht der Schwerpunkt des Buches.
> Es deckt die Grundlagen ab, aber in meinem Fall war es nicht ganz ausreichend.
> Ich empfehle dir daher, dich während dem Lesen des Buches nach Blogartikeln umzusehen, die sich eingehender mit OAuth2 befassen.

## Lernen von alten Keycloak-Hasen
Glücklicherweise haben wir bei codecentric einige sehr talentierte Leute, die Experten für IAM und Keycloak sind (<a href="https://blog.codecentric.de/keycloak-keycloak-x" target="_blank" rel="noopener noreferrer">Sebastian Rose und Thomas Darimont</a>, euch meine ich!).
Sie um sich zu haben und die Möglichkeit, sie alles fragen zu können und von ihrer Erfahrung zu lernen, die sie in vielen Kundenprojekten gesammelt haben, hat meinen Lernprozess sehr gefördert!

Ich hatte die Möglichkeit, an einem *Keycloak Fundamentals*-Workshop von Arne Strathmann teilzunehmen.
Hier haben wir die Grundlagen von Keycloak besprochen und mit dem (inzwischen veralteten) JBoss CLI zur Konfiguration von Keycloak gearbeitet.
Danach haben wir es in andere Anwendungen integriert.

Einige Zeit später nahm ich an einem Meetup teil, bei dem Thomas erklärte, wie man Keycloak erweitern kann.
Neben einer großartigen Präsentation mit guten einfachen Beispielen und vielen Learnings aus seiner Erfahrung gab es für mich noch mehr mitzunehmen:
Kürzlich hat Thomas ein <a href="https://github.com/thomasdarimont/keycloak-project-example" target="_blank" rel="noopener noreferrer"> Keycloak Starter Repository</a> erstellt.
Dies ist ein großartiger Ausgangspunkt oder sogar ein Standard-Repository, um ein neues Keycloak-Projekt zu starten.
Als er es vorstellte, war das Repository noch recht neu und hatte eine kleine Basis.
Ich benutzte diese Vorlage für mein eigenes Keycloak-Setup.
Im Laufe der Jahre hat dieses Repo eine Menge weiterer Konfigurationsoptionen erhalten.
Es ist toll, dass man dort so viele funktionierende Kombinationen finden kann.
Wenn man mit Keycloak anfängt, kann es sinnvoll sein, einige der ersten Commits im Repo zu verwenden.
Dort gibt es nur ein Setup in einer einfacheren Form.
Wenn du dann bereit bist, Keycloak in größerem Umfang einzusetzen, könnten die letzten Updates für dich interessant sein.

Eine andere Sache, die ich gefunden habe, ist das <a href="https://github.com/thomasdarimont/keycloak-extension-playground" target="_blank" rel="noopener noreferrer">Keycloak-Repository</a> mit Erweiterungen von Thomas.
Er hat eine ganze Reihe von Keycloak-Erweiterungen entwickelt.
Vielleicht ist die Erweiterung, die du entwickeln willst, bereits vorhanden!
Ich habe eine Menge hilfreicher Extensions gefunden, und es war eine großartige Inspirationsquelle für meine eigenen Erweiterungen.

Ich würde dir auch empfehlen, den Keycloak-Blog im Auge zu behalten.
Es gibt nicht viele Blog-Einträge, aber neue Artikel liefern immer sehr hilfreiche Informationen!
Zum Beispiel wurde im Dezember letzten Jahres eine <a href=" https://www.keycloak.org/2021/12/cve.html" target="_blank" rel="noopener noreferrer">Sicherheitslücke</a>  in einem Blogeintrag bekanntgegeben.

## Erste Gehversuche
Ausgestattet mit all dem Gelernten begann ich, eigene Erfahrungen mit der Erstellung eines eigenen Keycloak-Docker-Images zu sammeln.
Mit einer Basisinfrastruktur, die ich auf AWS erstellt habe (mit VPC, ELB, ECS Fargate, RDS und SES), konnte ich mein Image bereitstellen und ausführen.
Inzwischen gibt es auch einige Open-Source-Ressourcen für Keycloak in der AWS-Infrastruktur: <a href="https://github.com/aws-samples/cdk-keycloak" target="_blank" rel="noopener noreferrer">cdk-keycloak</a>.
Nachdem die Bereitstellung abgeschlossen war, begann ich mit der Konfiguration von Keycloak.
Diese Konfiguration reicht von der Erstellung des Realms und dem Hinzufügen von Clients über die Konfiguration von Log-Einstellungen, Plugins und Realm-Einstellungen bis hin zur Bereitstellung des Login-Flows und Token-Inhalts.
Diese Konfiguration muss auf einer laufenden Keycloak-Instanz durchgeführt werden.
Wir können sie entweder über die mitgelieferte Admin UI oder die CLI vornehmen.
Da beide Optionen etwas umständlich sind, habe ich die <a href="https://github.com/adorsys/keycloak-config-cli" target="_blank" rel="noopener noreferrer">keycloak-config-cli</a> verwendet.
Sie bietet *Konfiguration als Code* über YAML- oder JSON-Konfigurationsdateien für Keycloak und funktioniert hervorragend.

Und das ist auch schon alles.

> Wenn du Terraform verwendest, um die Infrastruktur für Keycloak zu erstellen, gibt es die Option, Keycloak mit Terraform zu konfigurieren:
> <a href="https://blog.codecentric.de/keycloak-konfiguration-mit-terraform" target="_blank" rel="noopener noreferrer">Keycloak-Konfiguration mit Terraform</a>

## Fazit

Zunächst schien Keycloak kompliziert und starr zu sein.
Aber als ich mich näher mit Keycloak beschäftigte, stellte ich fest, dass es viel zu bieten hat.
Es gibt extrem viele Konfigurationsmöglichkeiten, und es ist leicht erweiterbar.

Aber ich habe auch gelernt, dass die Integration von Keycloak in eine Anwendungslandschaft mit versteckten Kosten verbunden ist.
Die Wartung eines Keycloak-Clusters in Produktion erfordert einiges an Aufwand.
Die korrekten Einstellungen und die Durchführung von Updates mit minimalen Auswirkungen auf die Benutzer sind nicht trivial.
Bevor du dich also auf Keycloak stürzt, nur weil es *kostenlos* erscheint, würde ich diese Entscheidung noch einmal hinterfragen.

In letzter Zeit ist viel Wettbewerb im IAM-Sektor entstanden.
Einige Player bieten neben einem Open-Source-Kern auch SaaS-Angebote an.
Andere Anbieter stellen wiederrum eine gehostete Keycloak-Lösung zur Verfügung.
_Managed Services_ haben den Vorteil, dass wir uns auf die Entwicklung und Auslieferung unseres Produkts konzentrieren können.

Das Team hinter Keycloak hat verstanden, dass sich die IAM-Landschaft weiterentwickelt.
Stian hat im <a href="https://www.keycloak.org/2021/10/keycloak-x-update.html" target="_blank" rel="noopener noreferrer">Keycloak.X-Update</a> – siehe auch den <a href="https://blog.codecentric.de/keycloak-keycloak-x" target="_blank" rel="noopener noreferrer">Blogpost</a> von Thomas und Sebastian zu Keycloak.X –  einige Einblicke in die Roadmap gegeben.
Man hat das Gefühl, dass sie einige der scharfen Kanten von Keycloak angehen und verbessern.
Das sind gute Neuigkeiten, und ich bin zuversichtlich, dass die Arbeit mit Keycloak in Zukunft einfacher sein wird.
Es ist jedoch wichtig zu wissen, dass dies einige Zeit in Anspruch nehmen wird und zu einigen Umstellungen für derzeit laufende Keycloak-Cluster führen wird.

Ich bin gespannt, welches Tool das Rennen machen und den Markt in Zukunft dominieren wird.
Insgesamt ist Keycloak immer noch ein sehr stabiler Identitätsanbieter, der von einer Menge großer Unternehmen genutzt wird.

Ich hoffe, ich konnte dir einige hilfreiche Ideen und Ressourcen für das Erlernen von Keycloak an die Hand geben.

Bis dann! ✌️


Meine Keycloak-Lernreise


> Keycloak is an open-source identity provider. You can add authentication to applications and secure services with minimum effort. No need to deal with storing users or authenticating users. Keycloak provides user federation, strong authentication, user management, fine-grained authorization, and more.
> <a href="https://www.keycloak.org/" target="_blank" rel="noopener noreferrer">~ Keycloak</a>

I will share my path to learning Keycloak and the resources that helped me along the way.
Maybe some material that I used will help you understand Identity and Access Management (IAM) and Keycloak, too.

It took me some time to learn and get going with Keycloak.
I’m not that familiar with the Java ecosystem because some time has passed since my last Java project.
So I might have had a harder time learning.
But if you use Java on a daily basis, you’re in luck, since Keycloak is written in Java.
I also want to emphasize that I’m still not done learning yet, but I feel confident deploying, extending, and integrating Keycloak.

## Getting started with Keycloak
My Keycloak journey started in a customer project where we built a login theme for Keycloak and integrated it into our frontend applications.
Sure this is only a tiny subset of what Keycloak has to offer but the initial resources are a good starting point for anyone.
After visiting the website to find some basic information, some additional videos briefly show the power of Keycloak:

- <a href="https://www.youtube.com/watch?v=mdZauKsMDiI" target="_blank" rel="noopener noreferrer">Securing apps and services with Keycloak authentication | DevNation Tech Talk </a> by Stian Thorgersen (Keycloak Project Lead)
- <a href="https://www.youtube.com/watch?v=KrOd5wIkqls" target="_blank" rel="noopener noreferrer">How to secure your Spring apps with Keycloak by Thomas Darimont @ Spring I/O 2019</a> by Thomas Darimont (Keycloak Maintainer)

## Resources beyond the Keycloak docs: What is IAM?
I made an interesting observation about myself.
When I started with Keycloak, the docs weren’t helpful at all.
Luckily that changed, and now I think the docs are quite decent.
Conversations with colleagues, who also came in contact with Keycloak, had the same issue.
I learned that I had this strange relationship with the Keycloak docs because there was a gap between the information that the docs provide and my knowledge.
The docs don't explain what IAM is or what OpenID Connect is and how its internals work.
They expect you to know it.

I learned: There is the IAM sector and Keycloak as an identity provider application offering.
The Keycloak docs focus on the important parts of deploying, managing, and adapting Keycloak.
They expect you to know IAM fundamentals and the inner workings of related protocols.

For many people (including me) who jump into Keycloak, this might not be the case.
So before the Keycloak docs are of any help to us, we have to build up some basic knowledge around IAM.

If you find yourself facing the same problem, it might be a good idea to take a step back and focus on the foundations of IAM before diving deeper into Keycloak.
It makes sense to read about the IAM sector in general but also dive into the protocols you want to use.
In my case, it is mostly OAuth2 & OpenID Connect (OIDC).

This raises the question of what IAM is all about.
RedHat (who sponsors Keycloak) has a good article describing the IAM context:
> Identity and access management (IAM) is a centralized and consistent way to manage user identities (i.e. people, services, and servers), automate access controls, and meet compliance requirements across traditional and containerized environments.
> <a href="https://www.redhat.com/en/what-identity-and-access-management-iam" target="_blank" rel="noopener noreferrer">~ What is identity and access management (IAM)?</a>

There is an awesome resource that bridges the gap between learning the basics and learning Keycloak.
Stian, the creator of Keycloak, wrote a <a href="https://www.keycloak.org/2021/06/book.adoc" target="_blank" rel="noopener noreferrer">book</a> last year about Keycloak.
I think it is the perfect starting point.
It explains the basics of the OpenID Connect protocol and shows how to use it with Keycloak.
Furthermore, it touches on a ton of Keycloak features in short sections to show you what's possible.
From there you can select the features that fit your requirements for your projects.
After that, you can jump to the Keycloak documentation to get a deeper insight into how to use each feature.

> One note while reading the book:
> OAuth2 – the foundation of OpenID Connect – is not the focus of the book.
> It covers the basics but in my case, it was not quite enough.
> So I recommend you have a look around for some blog articles that cover OAuth2 more deeply while reading the book.

## Learning from Keycloak experts
Luckily at codecentric, we have some very talented people that are experts in IAM and Keycloak (looking at you, <a href="https://blog.codecentric.de/keycloak-keycloak-x" target="_blank" rel="noopener noreferrer">Sebastian Rose and Thomas Darimont</a>).
Having them around and the ability to ask them anything and learn from the experience they gathered in many customer projects boosted my knowledge.

I was able to attend a *Keycloak Fundamentals* workshop by Arne Strathmann.
There we went over the Keycloak basics, and we worked with the (now old) JBoss CLI for configuring Keycloak.
After that, we integrated it into other applications.

Some time later I participated in a meetup where Thomas explained how to extend Keycloak.
Besides a great presentation with good simple examples and many learnings from his experience, there were more takeaways for me:
Lately Thomas created a <a href="https://github.com/thomasdarimont/keycloak-project-example" target="_blank" rel="noopener noreferrer"> Keycloak Starter Repository</a>.
This is a great starting point or even boilerplate repo for starting a new Keycloak project.
When he presented it, the repo was quite new and had a small baseline.
I used this boilerplate for my own Keycloak setup.
Over the years this repo got a ton of more config options.
It is great that you can find so many working combinations there.
Although when you start with Keycloak it might make sense to head to some of the first commits in the repo.
There is only one setup in a simpler form.
When you are ready to deploy Keycloak on scale, the latest updates might be for you.

Another thing I found is the <a href="https://github.com/thomasdarimont/keycloak-extension-playground" target="_blank" rel="noopener noreferrer">Keycloak Extension Repository</a> from Thomas.
He developed quite a few Keycloak extensions.
Maybe the extension you want to build is already in there!
I found a lot of helpful ones, and it was a great inspiration source for my extensions.

I would also recommend you keep an eye on the Keycloak blog.
There are not that many blog posts but new ones always provide some really helpful information.
For example, in December last year, one blog post disclosed a <a href=" https://www.keycloak.org/2021/12/cve.html" target="_blank" rel="noopener noreferrer">security vulnerabilitiy</a>.

## First in the field experience
Equipped with all the learnings, I started to gain some experience building my Keycloak Docker image.
With some baseline infrastructure I created on AWS (using VPC, ELB, ECS Fargate, RDS & SES), I was able to deploy and run my image.
By now, there are also some open-source resources for Keycloak in AWS infrastructure: <a href="https://github.com/aws-samples/cdk-keycloak" target="_blank" rel="noopener noreferrer">cdk-keycloak</a>.
After the deployment was complete, I started configuring Keycloak.
This configuration includes creating your realm, adding clients to it, configuring log settings, plugins, realm settings, and providing your login flow and token contents.
This config setup has to be done on a running Keycloak instance.
You can apply your configuration either through the provided admin UI or the CLI.
Since both options are a bit cumbersome, I used the <a href="https://github.com/adorsys/keycloak-config-cli" target="_blank" rel="noopener noreferrer">keycloak-config-cli</a>.
It offers *Configuration as Code* via YAML or JSON configuration files for Keycloak and works great.

And that's pretty much it.

> When you're using Terraform to create the infrastructure for Keycloak, there is the option to configure Keycloak with Terraform:
> <a href="https://blog.codecentric.de/keycloak-konfiguration-mit-terraform" target="_blank" rel="noopener noreferrer">Keycloak-Konfiguration mit Terraform</a>

## Conclusion

At first, Keycloak seemed complicated and rigid.
But digging deeper into Keycloak I realized it has a lot to offer.
There are tons of configuration options, and it is easily extendable.

But I also learned that there is a hidden cost attached to integrating Keycloak into your application landscape.
Maintaining a Keycloak cluster in production takes quite some effort.
Setting it up correctly and running updates with minimal user impact is not trivial.
So before jumping into Keycloak just because it seems *free*, I would question that decision again.

A lot of competition in the IAM sector has arisen lately.
Some provide SaaS offerings besides an open-source core.
Others offer a managed Keycloak solution.
Managed services have the benefit that we are able to focus on building and shipping our product.

The team behind Keycloak has understood that the IAM landscape evolves.
Stian showed some insights into the roadmap in his <a href="https://www.keycloak.org/2021/10/keycloak-x-update.html" target="_blank" rel="noopener noreferrer">Keycloak.X-Update</a> blog post, as did the <a href="https://blog.codecentric.de/keycloak-keycloak-x" target="_blank" rel="noopener noreferrer">Keycloak.X blog post</a> by Thomas und Sebastian.
It feels like they are finally tackling some rough edges of Keycloak.
This is great to hear, and I'm confident that it'll be easier working with Keycloak in the future, although it is important to note that this will take some time and lead to some breaking changes for currently running Keycloak clusters.

I'm curious about what tool will win the race and dominate the market in the future.
Overall, Keycloak is still a very stable identity provider used by a ton of big companies.

I hope I was able to provide you with some helpful ideas and resources for learning Keycloak.

See ya ✌️

My Keycloak learning journey

# Building desktop apps with web technologies

In this article I share insights into Electron and what to consider when shipping an desktop app with Electron.
After that I introduce you to a new alternative called Tauri.
It the end I provide an estimation when which tool makes more sense.

Building cross-platform desktop apps with JavaScript, HTML, and CSS became possible with <a href="https://electronjs.org/" target="_blank" rel="noopener noreferrer">Electron</a>.
It combines Node.js, Chromium (both leveraging the V8 JavaScript engine) and some wrappers for native system interfaces.

It all started with the <a href="https://github.com/atom/atom" target="_blank" rel="noopener noreferrer">Atom</a> editor developed by GitHub, where web technologies were used. They packaged it with an Atom shell as a desktop application.
The shell was eventually detached and renamed to Electron.
Over the years it became part of the OpenJS Foundation and received wide adoption from other companies and open-source apps.
Applications such as VSCode, Slack, Skype, Figma, Obsidian, <a href="https://blog.1password.com/1password-8-the-story-so-far/" target="_blank" rel="noopener noreferrer">1Password8</a> and many others use Electron to ship their applications.

![electron-apps-built-with-electron.png](https://media.graphassets.com/KIIOO9JaRISYGfPSUyx9)

> In my daily work routine I often stumble across JWT tokens, timestamps and other encoded data (base64, URI, ...).
> For debugging purposes I often need more insights or I want to transform it.
> Pasting application data into random websites is a no-go, so I needed some other tooling.
> I solved my problem by building a developer scratchpad.
> It combines tools & transform operations for everyday tasks called <a href="https://github.com/florianwiech/codewaffle" target="_blank" rel="noopener noreferrer">CodeWaffle</a>.
> You can inspect, download and use it open-sourced and free on GitHub. The downloads are in the <a href="https://github.com/florianwiech/codewaffle/releases" target="_blank" rel="noopener noreferrer">GitHub releases</a>.
> This application was built with Electron.
> The learnings from this article are applied in this codebase.

## The Electron architecture overview
### Multi-process model

![electron-process-model.png](https://media.graphassets.com/weylgvdQQ6Kc5hfpzREC)

Electron consists of a main process and one-to-many renderer processes.

The **main process** runs in a Node runtime.
All the provided Node APIs are accessible including access to the file system.
Electron provides an additional API to create native UI elements. It includes native popover dialogues, notifications or an application menu bar setup among others.
The main process exists only once per app.
When this process terminates, the app will exit.
Watch out, because <a href="https://twitter.com/NumaanAshraf/status/968496732278374400" target="_blank" rel="noopener noreferrer">blocking the main process with heavy computation will freeze the entire app</a>!
So use async code as much as possible and offload heavy computations to <a href="https://www.electronjs.org/docs/latest/tutorial/multithreading" target="_blank" rel="noopener noreferrer">another thread</a>.

Via the main process we start **one or more renderer processes**.
The renderer process is a Chromium window that runs a web app.
It uses the same browser environment as normal web pages do.
The entry point is a HTML file which loads included CSS assets and JavaScript code.

The **preload script** runs at the renderer window context creation.
This script allows for bridging custom-developed handlers from the main process to the renderer process. It uses the same sandbox as Chromium plugins.

The Electron architecture has analogies to Chrome's own browser and renderer processes.
As you might know, Chromium and V8 are quite memory-intensive, which is a drawback you'll often hear when the conversation is about Electron apps.

### Workflow & communication

![electron-inter-process-communication.png](https://media.graphassets.com/HC6FOjzzTwyC9H3yTHR9)

The startup of Electron works from a high-level perspective in the following steps:
1. In the Electron init phase the main process sets up handlers for Electron events.
2. When Electron is ready, the main process starts renderer processes and provides a preload script.
3. While setting up the window object for the renderer process, the preload script runs and injects additional APIs.
4. When the renderer process is ready, it loads and renders the web page.

When everything runs, the main and renderer processes communicate via the API created in the preload script.
Those communication options are called *<a href="https://www.electronjs.org/docs/latest/tutorial/ipc" target="_blank" rel="noopener noreferrer">Inter-Process Communication (IPC)</a>*.
With these IPC helpers it is possible to communicate back and forth between the main and renderer processes.
The communication between two renderer windows with the IPC API is only possible through the main process.

Due to this limitation, the *<a href="https://www.electronjs.org/docs/latest/tutorial/message-ports" target="_blank" rel="noopener noreferrer">MessagePorts</a>* API was introduced.
It enables the possibility to create communication channels and then pass messages directly between processes.

## Creating an Electron project setup
### Project setup

The project setup consists of two main parts: the dev environment and the bundling and shipping process.
The **dev setup** consists of things like hot-module-reloading for faster feedback loops.
The **bundling setup** packages the app ready for release.
For better code quality you can bring all the web utilities you know and use (eslint, prettier, testing-library, ...) but I won't cover them in this article (you can look them up in my linked setup though).

Based on your decision which tools you want to use, the setup complexity is different.
Using all the Browser, Node and Electron standards (only using supported ES versions, CommonJS, etc.), your setup is straightforward.
If you want to use the latest JavaScript features, use TypeScript and ESM, you'll need a transpiler and bundler, so your setup will be more complex.

For bundling your Electron apps, you'll eventually come across two libraries: `electron-forge` and `electron-builder`.
`electron-forge` is a great starting point. It's like the `create-react-app` that generates you a ready-to-use boilerplate. It takes care of the dev environment, bundling and releasing part. You can directly start coding.
When you need some more customisations or bring some of your own tools, `electron-builder` is a nice library that just helps you package the electron app. You can bring all your own tools for everything else.
Thankfully the community already provides helpful resources to get you started.
The <a href="https://github.com/cawa-93/vite-electron-builder/" target="_blank" rel="noopener noreferrer">vite-electron-builder</a> is a good boilerplate for Electron apps.

One difference I noticed is the updating process for the Electron app:
`electron-forge` works with the updater built within Electron. It works on Windows and Mac. Linux is required to update their apps with their native package managers.
`electron-builder` provides its own updater, which ships the auto-updating feature for alle three platforms.
You gain more freedom and flexibility but it also means doing the project setup yourself.

### Module support

In JavaScript we like to split our codebase across modules.
The most famous module systems are CommonJS (CJS) and <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Modules" target="_blank" rel="noopener noreferrer">JavaScript Modules (ESM)</a>.
Node did rely on CJS for a long time, but now ESM is fully supported.
With ESM support in current browsers and Node, <a href="https://github.com/sindresorhus/meta/discussions/15" target="_blank" rel="noopener noreferrer">many developers switch to ESM</a>.
Among other things, ESM provides tree-shaking options and a better readable syntax.
But there is also a fundamental <a href="https://exploringjs.com/es6/ch_modules.html#sec_modules-vs-scripts" target="_blank" rel="noopener noreferrer">difference</a> between those module systems: CJS works synchronous, ESM is asynchronous.

Due to the <a href="https://github.com/electron/electron/issues/21457#issuecomment-1099904505" target="_blank" rel="noopener noreferrer">current setup of Electron</a>, which requires some synchronous tasks, ESM is supported in version 28, but has some limitations you should be aware of. 
The switch to <a href="https://github.com/electron/electron/issues/21457#issuecomment-1159633831" target="_blank" rel="noopener noreferrer">ESM was complicated</a> and <a href="https://github.com/electron/electron/issues/21457#issuecomment-1460917316" target="_blank" rel="noopener noreferrer">took some time</a>.
This only affects the main and preload scripts.
The renderer process (Chromium window) is not affected by this limitation.
Here you can embrace ESM thanks to the browser support.

But do I have to build both main and preload code purely with CJS now?
When you are okay bringing in a transpiler/bundler, it is possible write the complete codebase in ESM and compile the main and preload scripts to CJS.

> In my app I was able to work with ESM as a default.
> I transform the main and preload scripts to CJS in the build step.
> You can configure using ESM as default for the entire codebase by setting the `"type": "module"` entry in your `package.json`.
> You can read about my decision to use ESM <a href="https://github.com/florianwiech/codewaffle/blob/v0.6.0/docs/0002-module-system-setup.md" target="_blank" rel="noopener noreferrer">here</a>.

### Testing

While developing an app, we verify everything works correct. At best we automate it.

Test the **renderer process**–a classical web app–with unit and integration tests.
You can bring and use the tool you already know and work with. With clear code patterns you make your life easier testing specific functions.
For the **main process** it makes sense to start with unit tests. You can verify that specific functions work as expected. On these layers we do not want to test external library–Electron–behaviour.

So in the first step these two processes are tested separately.
The preload script might not include and therefore require that much testing. You can still build some unit tests though. Using TypeScript, you even gain type-safety for the communication.

But the questions remains: How do I verify that my feature works from a user perspective? How do I automate it with E2E tests?

There are some toolkits that support testing Electron apps. The ones I found:
- <a href="https://playwright.dev/docs/api/class-electronapplication" target="_blank" rel="noopener noreferrer">Playwright</a> *still experimental*
- <a href="https://webdriver.io/docs/desktop-testing/electron" target="_blank" rel="noopener noreferrer">WebdriverIO</a>

I tried Playwright with my setup. Yes, it is experimental, but it worked fine.
You can start the entire Electron app and automate the usage from a user perspective.
It's a great way to make sure that features work throughout the entire app.

## Road to production of Electron apps

So with the setup in place, how do I ship the app?

> For CodeWaffle I only have a macOS deployment. Windows is a bit different in terms of the code signing process (you'll read about it shortly).

### Security in Electron

Due to numerous security vulnerabilities in the way Electron apps have been developed in the past, there are some aspects to look out for when shipping an app.
It was commonsensical to use the Node native system APIs in the renderer process. 
One process to load and execute remote resources has full native system access. Bad idea. So we got the preload script.

Among other things they introduced the <a href="https://www.electronjs.org/docs/latest/tutorial/sandbox" target="_blank" rel="noopener noreferrer">Process Sandboxing</a> and <a href="https://www.electronjs.org/docs/latest/tutorial/context-isolation" target="_blank" rel="noopener noreferrer">Context Isolation</a>.
Those are closer to the Chromium security architecture and introduce a context bridge to prevent sharing global objects across processes.

Besides those internal structures, it is recommended to load only secure content from external sources.
Even better, bundle assets and code directly with the app.
Bundled data is part of the app signing and therefore spared from various attacks that can happen to a remote server.
But it means the continuous deployment looks very different than the pipeline for a web app. App updates require some user interaction.

This is just an short outline and some highlights.
To really make sure your app aligns with the latest security standards, Electron provides a big <a href="https://www.electronjs.org/docs/latest/tutorial/security" target="_blank" rel="noopener noreferrer">security checklist</a> to go through.
Thankfully there are more helpful resources for learning and validating your setup:
With the launch of 1Password 8 they shared their <a href="https://www.youtube.com/watch?v=_P6qI4ahBVk&t=5156s" target="_blank" rel="noopener noreferrer">learnings building secure Electron apps</a> and provide a helpful <a href="https://github.com/1Password/electron-secure-defaults" target="_blank" rel="noopener noreferrer">secure-defaults example setup</a>.
The tool <a href="https://github.com/doyensec/electronegativity" target="_blank" rel="noopener noreferrer">electronegravity</a> can help you identify misconfigurations and security anti-patterns in Electron applications.
It leverages AST and DOM parsing to look for security-relevant configurations.
But there are limitations of the AST/DOM parsing which means you may encounter false positive results.
It is a really nice helper, but you have to do the verification yourself!

### User experience

Coming from an web app development background, you have to consider more things when building a desktop app that feels native to each operating system.
Here are some highlights you want to consider:
- Multiple windows: Most platforms show the app preferences in a separate window. Doing this in you Electron app as well brings a native app feeling.
- The window position and size is restored when reopening a window. You need to take care of the positioning yourself.
- Each app has a Menu with items like "File", "Edit", "View", "Window", "Help", etc. in der top left corner.
- Dropdowns – context menus – on an operating system layer have their native theme and design. You should integrate those instead of using your own (as you might solve it in your web app).

There are some great blog articles and talks to help you with you setup:
- <a href="https://www.youtube.com/watch?v=p4PyzDzppiY" target="_blank" rel="noopener noreferrer">Make Your Electron App Feel at Home Everywhere | Kilian Valkhof | Conf42 JavaScript 2021</a>
- <a href="https://dev.to/vadimdemedes/making-electron-apps-feel-native-on-mac-52e8" target="_blank" rel="noopener noreferrer">Making Electron apps feel native on Mac</a>

Surely there are some things you already know. Page speed and performance optimisations are some of them.
Primarily the first window load is about getting the window rendered as fast as possible. A great talk covers how it is handled inside VSCode: <a href="https://www.youtube.com/watch?v=r0OeHRUCCb4" target="_blank" rel="noopener noreferrer">CovalenceConf 2019: Visual Studio Code – The First Second</a>

### Shipping includes bundling, code signing and releasing

With the bundle process and package step, the app is ready to use.
Unfortunately others are not able to install it directly.
Desktop apps on Windows and macOS require an app sign and notarize process before others are able to install the app.
To do that, we need a <a href="https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution" target="_blank" rel="noopener noreferrer">code signing certificate</a>.
You get macOS certificates via an Apple Developer account (includes a yearly fee).
Windows certificates can be purchased by various vendors.
For each platform you have to purchase an appropriate certificate.

This extra step is required, but you can automate it and include it in your release pipeline.
Since others already figured that part out, here are the articles that helped me:
- <a href="https://kilianvalkhof.com/2019/electron/notarizing-your-electron-application/" target="_blank" rel="noopener noreferrer">Notarizing your Electron application</a>
- <a href="https://dev.to/rwwagner90/signing-electron-apps-with-github-actions-4cof" target="_blank" rel="noopener noreferrer">Signing Electron Apps with GitHub Actions - DEV Community</a>
- <a href="https://felixrieseberg.com/codesigning-electron-apps-in-ci/" target="_blank" rel="noopener noreferrer">Code-signing Electron Apps in CI</a>
- <a href="https://til.simonwillison.net/electron/sign-notarize-electron-macos" target="_blank" rel="noopener noreferrer">Signing and notarizing an Electron app for distribution using GitHub Actions | Simon Willison’s TILs</a>
- <a href="https://funtoimagine.com/blog/electron-mac-sign-and-notarize/" target="_blank" rel="noopener noreferrer">How I sign and notarize my Electron app on MacOS | Fun to Imagine</a>
- <a href="https://blog.borodutch.com/how-to-deploy-an-electron-app-with-auto-updates-enabled-for-free-in-2021/" target="_blank" rel="noopener noreferrer">How to deploy an Electron app with auto-updates enabled for free in 2021 with just one command</a>

## The new kid on the block: Tauri

With the popularity of Electron and its drawbacks – heavy memory consumption, more effort to nail security and licensing issues – new tools emerged.
One tool I want to highlight is <a href="https://tauri.app/" target="_blank" rel="noopener noreferrer">Tauri</a>.
They saw the popularity of Electron and built a new foundation based on learnings from past mistakes.
Instead of Node and Chromium, they use Rust for the core process and WebView for the renderer processes.
Security is not an afterthought, but directly baked into the core architecture.

### So what should I go with?

As always, it depends.
Electron is the save bet. You can be pretty sure that it will work or there is already a ticket with an open discussion.
Tauri, on the other hand is bleeding edge. *Meaning you will be bleeding.* But it has some advantages that might be worth it.

Here's my evaluation:
- You want to be safe that everything you need is supported (and you have some special needs)? *Go with Electron. Over the years they shipped many native systems APIs you can rely on. Tauri is catching up fast, but there might still be some differences.*
- You are really worried about security (who wouldn't be)? *Both win. Electron has way more cycles gone through. Tauri's overall architecture is better and learned from the mistakes happened in Electron.*
- You are worried about the application performance? *Go with Tauri. You have less dependencies, no Node, no Chromium, no V8. With Rust you have a foundation for a fast runtime.*

FYI: 1Password8 has shown that they shipped their Rust codebase with Electron – the more mature platform. That way you can use both worlds together until Tauri is fully ready. Their solution leverages <a href="https://neon-bindings.com/" target="_blank" rel="noopener noreferrer">`neon-bindings`</a>.

Cheers.

Building desktop apps with web technologies

<p>Ca. zwei Monate nach meinem Einstieg bei codecentric hatte ich ein wirklich interessantes Gespräch mit einem Kollegen. Ich glaube, es verlief folgendermaßen:</p><p>Kollege: Hey, hast Du schon mal von YAGNI gehört?<br /> Ich: Gesundheit.<br /> Kollege: Was?<br /> Ich: Du hast doch gerade geniest?<br /> …</p><p>Ich bin mir ziemlich sicher, dass das Gespräch so verlief. Aber im Ernst, er sagte mir, dass es für die effektive Entwicklung von Software entscheidend ist, YAGNI (You aren’t gonna need it) zu verstehen und anzuwenden. Ich sollte es ausprobieren und es in meinen aktuellen und nächsten Projekten verbreiten. Aber was in aller Welt ist YAGNI und warum sollte es mir bei der Software-Entwicklung helfen? Ich möchte euch in diesem Artikel einen kurzen Überblick geben und einige Erfahrungen mit euch teilen.</p><h2>You aren’t gonna need it!</h2><p>Er gab mir einen Website-Link [<a href="http://c2.com/xp/YouArentGonnaNeedIt.html" target="_blank">http://c2.com/xp/YouArentGonnaNeedIt.html</a> ], um mehr über YAGNI zu lesen. YAGNI ist also eine Extreme-Programming-Technik. Und eines der ersten Zitate auf der Website sagt eigentlich alles aus, was man wissen muss:</p><blockquote><p>Implementiere die Dinge immer dann, wenn du sie tatsächlich brauchst, niemals, wenn du nur voraussieht, dass du sie brauchen könntest.</p></blockquote><p>Moment, was? Das ist einfach und genial zugleich. Als ich diesen Satz las, hatte ich direkt ein euphorisches Gefühl und war sofort vom YAGNI-Virus infiziert.</p><p><a href="https://media.graphassets.com/P854jxRGNxPAjjz4GWgP"><img src="https://media.graphassets.com/P854jxRGNxPAjjz4GWgP" alt="softwarepiece" width="1024" height="683" /></a> </p><p>Wie oft habe ich in der Vergangenheit, bevor ich diesen Ansatz kannte, so etwas gedacht: „Was könnte mit meiner Software in der Zukunft passieren? Oh ja, vielleicht dies und das. Lass uns einfach all diese Dinge implementieren, da wir sowieso gerade daran arbeiten. Dann ist es zukunftssicher.“ Und was geschah dann? Richtig, die implementierten Funktionen, die auf Annahmen basierten, funktionierten nicht wie vom Kunden oder Benutzer erwartet. Also mussten wir am Ende einige Teile der Software neu implementieren, um das zu beheben. Und manchmal kommt es vor, dass ein Teil der Software aus bestimmten Gründen zukünftig nicht mehr benötigt oder verwendet wird.</p><p>Hier kann YAGNI helfen: indem ihr Dinge erst dann implementiert, wenn sie gebraucht werden. Damit könnt ihr euch Zeit und unnötige Arbeit bei der Implementierung sparen und unnötige Wartung des Codes vermeiden.</p><p>Das gleiche Prinzip gilt sowohl auf der geschäftlichen Ebene, wie z. B. bei den Produktfunktionen, als auch auf der Implementierungsebene, wie z. B. bei den Software-Abstraktionen. Schreibt ihr nur eine Klasse oder erstellt ihr bereits eine abstrakte Klasse mit einer Child-Klasse, weil ihr vermutet, dass in Zukunft noch mehr Child-Klassen kommen werden?</p><h2>Würde YAGNI in den Projektalltag passen?</h2><p>Kurze Antwort: Auf jeden Fall. Bei einem kürzlich durchgeführten Projekt waren der oben genannte Kollege und ich in der glücklichen Lage, demselben Team beizutreten. Und er hat auch dort das YAGNI-Prinzip gleich zu Beginn dem Rest des Teams vorgestellt. Es war interessant zu beobachten, wie diese Technik zu einer Art Herausforderung wurde. Sehr oft hörten wir jemanden sagen: „Warte, brauchen wir das wirklich jetzt?“. Das war sehr cool. Sie waren alle mit diesem YAGNI-Virus infiziert. Eines unserer neuen Teammitglieder schuf sogar einen Post-It-Schrein an der Wand des Büros.</p><p><a href="https://media.graphassets.com/9op4M3EeThe3O8ib5anS"><img loading="lazy" src="https://media.graphassets.com/9op4M3EeThe3O8ib5anS" alt="yagni do-we-really-need-it" width="1024" height="265" /></a> </p><p>Ein großer Vorteil von YAGNI ist es, unnötige Entwicklungen zu vermeiden. Wenn man darüber nachdenkt, entwickelt man sicherlich oft Software auf der Grundlage von Annahmen. Wenn man über zukünftige Funktionen nachdenkt, kann es auch manchmal Unklarheiten geben. Ich habe die Erfahrung gemacht, dass auch der Kunde sagte: „Ja, wir brauchen jetzt die Funktion X“, und wenn man nach den Anforderungen an diese Funktion fragte, hörte man als Antwort manchmal so etwas wie „Oh, das ist im Moment nicht hundertprozentig klar“. Das sollte eine Warnung sein. Diese Dinge sind genau das, wofür YAGNI steht. Verschiebt diese Anforderung auf einen späteren Zeitpunkt des Projekts. Dann könnten die Anforderungen klarer sein und ein Feature könnte genauer bzw. gezielter entwickelt werden.</p><p><a href="https://media.graphassets.com/nB3onXLgQRGYRXOmVn7h"><img loading="lazy" src="https://media.graphassets.com/nB3onXLgQRGYRXOmVn7h" alt="yagni-mindset" width="1024" height="383" /></a> </p><p>Aber … es gibt immer ein „aber“ … es ist manchmal nicht so einfach. Es ist harte Arbeit, eine YAGNI-Mentalität in einem Team und bei einem Kunden zu verbreiten. Ihr solltet immer wieder versuchen, euer Gegenüber herauszufordern. Fragt euch selbst, euer Team und den Kunden: „Brauchen wir das wirklich (jetzt)?“. Wenn euer Gegenüber Schwierigkeiten hat oder nicht klar ist, warum etwas benötigt wird, dann ist dies ein Indikator, dass YAGNI helfen kann. Und dann solltet ihr auch darüber nachdenken, es zu verschieben oder auf Eis zu legen, bis es wieder wichtig wird. Das bedeutet nicht, dass die Dinge nicht wichtig sind, aber sie sind vielleicht zu einem frühen Zeitpunkt noch unklar. Wenn sie zu einem späteren Zeitpunkt wichtiger werden, dann könnte auch die Reife dieses Themas ausgeprägter sein. Es könnte für den Kunden relevanter werden, und es könnten genug Details für eine Umsetzung geben.</p><p>Was YAGNI nicht bedeutet, ist, dass ein Feature niemals implementiert wird, nur weil es jetzt nicht notwendig ist. Es soll euch nur dabei helfen, Prioritäten zu setzen und zu vermeiden, dass ihr jetzt auf der Grundlage von Annahmen arbeitet, mit der Gefahr, es später zweimal zu tun, weil es im Moment falsche oder zu wenige Informationen gibt.</p><p>Wenn ihr YAGNI verwendet, könntet ihr auch das Gefühl bekommen, dass es euch davon abhalten könnte, Experimente durchzuführen. Das wäre richtig, wenn ihr die YAGNI-Methodik bei der Erstellung von Prototypen ignoriert. Der bessere Weg ist, wenn ihr die Technik zum Fokussieren verwendet. Quasi während ihr einen Prototyp erstellt. Und hier wäre es völlig in Ordnung, wenn man dieselbe Arbeit zweimal machen würde. Dann könnt ihr aus dem Feedback lernen, und vielleicht ist der Prototyp auch manchmal nicht das, was der Benutzer oder Kunde erwartet. Das führt sehr schnell dazu, dass die Idee verworfen wird und man es noch einmal implementiert. Aber das ist völlig in Ordnung, und während der Durchführung von Versuchen solltet ihr auch YAGNI einsetzen, um euer Ergebnis nicht zu überfrachten. Wie auch immer, beim Prototyping geht es darum, etwas auszuprobieren und sich bewusst zu sein, dass es am Ende weggeworfen wird.</p><h2>Fazit</h2><p>Für mich ist YAGNI eine ausgezeichnete Möglichkeit, den Software-Entwicklungszyklus zu verbessern. Es hilft sehr, sich auf die notwendigen Funktionen und Software-Artefakte zu konzentrieren. Ihr solltet es für Experimente (Prototyping) verwenden und euch dabei bewusst sein, dass Software-Artefakte möglicherweise mehrfach implementiert werden müssen. Ich finde, dass YAGNI und Prototyping perfekt zusammenpassen. Und nun sucht euch etwas, was vereinfacht werden muss!</p>

YAGNI – Eine kurze Einführung und ein Erfahrungsbericht

<p>About two months after I joined codecentric, I had a really interesting conversation with a colleague. I think it went like this:</p><p><em>Colleague: Hey, have you ever heard of YAGNI?</em><br /> <em>Me: Bless you!</em><br /> <em>Colleague: What?</em><br /> <em>Me: Did you just sneeze?</em><br /> <em>…</em></p><p>I am pretty sure that the conversation was like that. But seriously, he told me that in order to develop software effectively, it’s critical to understand and apply YAGNI, which is short for: “You Aren’t Gonna Need It”. I should try it and use it inside my current and upcoming projects, he said. But what on earth is YAGNI and why should it help me in software development? In this article, I would like to give you a quick overview and share some experiences.</p><h2>You aren’t gonna need it!</h2><p>My colleague gave me a website link [<a href="http://c2.com/xp/YouArentGonnaNeedIt.html" target="_blank">http://c2.com/xp/YouArentGonnaNeedIt.html</a> ] to read more about YAGNI. So, YAGNI is an extreme programming technique. And one of the first quotes on the website tells you everything you need to know:</p><p><em>“Always implement things when you actually need them, never when you just foresee that you need them.”</em></p><p>Wait, what? That is simple and genius at the same time. When I read that sentence it gave me a mind-blowing feeling and I was instantly infected with the YAGNI virus.</p><p><a href="https://media.graphassets.com/P854jxRGNxPAjjz4GWgP"><img src="https://media.graphassets.com/P854jxRGNxPAjjz4GWgP" alt="softwarepiece" width="1024" height="683" /></a> </p><p>Often, in the past, before I knew that approach, I thought something like: “What could happen with my software in the future? Oh yeah, maybe this and that. Let’s implement all these things since we are working on this part anyway. That way it’s future-proof” And what happened afterwards? Right, the implemented features, based on assumptions, didn’t work as expected by the customer or user. So in the end we had to reimplement some parts of the software to fix that. And sometimes it happens that a piece of the software is not needed or used in the future, because of reasons.</p><p>This is where YAGNI can help. By not implementing things until you need them, you can save time and prevent useless work implementing and maintaining this code.</p><p>This same principal applies on both a business level, such as product features, and on an implementation level, like software abstractions. Do you just write a class, or do you already create an abstract class with one child class because you suspect more children will come in the future?</p><h2>Would YAGNI fit into your daily project life?</h2><p>Short answer: absolutely. In a recent project, the above mentioned colleague and I were in the lucky situation to join the same team. And he also introduced the YAGNI principle to the rest of the team at the very beginning. It was interesting to observe how this technique was a kind of a challenge. Very often we heard someone say: “Wait, do we really need that now?”. That was amazing. They were all infected with that virus, too. One of our new team members also created a Post-It shrine at the office wall.</p><p><a href="https://blog.codecentric.de/files/2020/02/img_2990-scaled.jpg"><img loading="lazy" src="https://media.graphassets.com/9op4M3EeThe3O8ib5anS" alt="yagni do-we-really-need-it" width="1024" height="265" /></a> </p><p>A big advantage of YAGNI is that you avoid unnecessary development. If you think about it, you certainly often develop software on the basis of assumptions. Also, sometimes when you think about future features, there could be obscurities. I have heard customers say “Yeah, we need feature X now”, and when you ask what the requirements for this feature are, you sometimes get an answer like “Oh, that is not 100% clear at the moment”. This should alert you. Those things are exactly what YAGNI stands for. Postpone them to a later state of the project when requirements are more clear and a feature can be developed more accurately.</p><p><a href="https://media.graphassets.com/nB3onXLgQRGYRXOmVn7h"><img loading="lazy" src="https://media.graphassets.com/nB3onXLgQRGYRXOmVn7h" alt="yagni-mindset" width="1024" height="383" /></a> </p><p>But … there is always a “but” … sometimes it is not that easy. It is hard work to spread a YAGNI mindset in a team and propagate it to a customer. Over and over, you should try to challenge your opposite. Ask yourself, your team, and your client: “Do we really need this (now)?”. Whenever your counterpart struggles or doesn’t have a clear standing why something is needed, it’s clearly time for YAGNI. Then you should also think about discarding it or put it on hold until it becomes relevant again. This doesn’t mean that things aren’t important, but they are maybe still unclear at an early point in time. When they become more important at a later point, the maturity of this issue might also have grown. It might become more relevant for the client and there could be enough details for an implementation.</p><p>What YAGNI does not mean is that a feature will never be implemented only because it is not necessary at present. It should just help you to prioritise your work and prevent you from doing work that is based on assumptions. You’ll only risk having to re-do it later because the information you had earlier was wrong or not sufficient.</p><p>When using YAGNI, you might get the impression that it will prevent you from doing experiments. This would be right if you ignored the YAGNI methodology while doing prototyping. It’s best to use the technique for focusing while you create a prototype. In that case it is totally OK to do the work twice. You can then learn from the feedback. After all, your prototype might not always be what the user or client expects, so you will need to discard your idea and re-do it. This is totally fine, and while implementing trials, you also should adopt YAGNI in order not to overload your outcome. Anyway, prototyping is about trying something while being aware that it may be dismissed in the end.</p><h2>Conclusion</h2><p>For me, YAGNI is an excellent way to improve your software development cycle. It helps you a lot to focus on necessary features and software pieces. You should use it for experiments (prototyping) and be aware that software pieces might have to be implemented multiple times. YAGNI and prototyping fit together perfectly. Now, go find something and simplify it down to essentials right now!</p>

YAGNI – A quick introduction and field report

Team oriented developer

<p>Scala erlaubt die Nutzung des Keywords <code>lazy</code> in Verbindung mit <code>val</code>, um die Initialisierung bei Bedarf auszuführen. Bedarfsauswertung für <code>val</code> hört sich gut an, allerdings hat die konkrete Implementierung in <code>scalac</code> dem Scala Compiler ein paar sehr subtile Probleme, auf die man nicht immer gefasst ist. Dieser Artikel wirft einen Blick hinter die Kulissen und zeigt einige der Stolperfallen auf: neben einem Blick auf die Implementierung in <code>scalac</code> werden wir Szenarien vorstellen, in denen bei Bedarf ausgewertete <code>val</code> das komplette Programm abstürzen lassen, parallele Auswertung verhindern oder anderes Unerwartetes Verhalten zeigen.</p><div><div><h2>Einführung</h2><div><p>Dieser Beitrag wurde ursprünglich inspiriert von dem Talk <a href="https://www.youtube.com/watch?v=aftdOFuVU1o">Hands-on Dotty</a>  (<a href="https://d-d.me/scalaworld2015/#/">slides</a> ) von Dmitry Petrashko, vorgetragen während der Scala World 2015. Dmitry hielt dort einen wunderbaren Talk über Dotty und erklärt einige der Fallstricke die durch Bedarfsauswertung entstehen, sowie die geänderte Implementierung in Dotty. Wir werden im Folgenden die Bedarfsauswertung von <code>val</code> diskutieren, uns einige der Beispiele von Dmitry genauer ansehen und zusätzliche Szenarien betrachten.</p></div></div><div><h2>Wie <code>lazy</code> funktioniert</h2><div><p>Das prägende Merkmal von <code>lazy</code> ist, dass das <code>val</code> nicht sofort initialisiert wird sondern <b>einmalig</b><sup><a href="#fn.1">1</a> </sup>, bei Bedarf. Wenn der erste Zugriff erfolgt wird der Ausdruck ausgewertet und das Ergebnis dem Namen des <code>val</code> zugewiesen. Nachfolgende Zugriffe führen nicht zu wiederholter Auswertung: es wird stattdessen sofort das gespeicherte Ergebnis zurückgegeben.</p><p>Mit der oben stehenden Beschreibung, scheint es, als ob „Auswertung bei Bedarf“ harmlos ist und keine negativen Effekte hat, also warum fügt man <code>lazy</code> nicht immer hinzu, sozusagen als eine spekulative Optimierung? In Kürze werden wir sehen warum eben das meist keine gute Idee ist, aber bevor wir dieses Thema vertiefen, sollten wir erst einen genaueren Blick auf die Semantik von <code>lazy val</code> werfen.</p><p>Wenn wir wie folgt einen Ausdruck einem <code>lazy val</code> zuweisen:</p><div>

```src src-scala
lazy val two: Int = 1 + 1

```

</div><p>erwarten wir, dass der Ausdruck <code>1 + 1</code> an den Namen <code>two</code> gebunden wird, jedoch noch keine Auswertung stattfindet. Beim ersten, und nur beim ersten Zugriff auf <code>two</code> wird der gespeicherte Ausdruck <code>1 + 1</code> ausgewertet und das Ergebnis zurückgegeben. Nachfolgende Zugriffe auf <code>two</code> führen <b>nicht</b> zu weiteren Auswertungen: stattdessen wurde das Ergebnis der Auswertung gespeichert und wird nun jedes Mal zurückgegeben.</p><p>Die Eigenschaft, das Auswertung nur <b>einmal</b> stattfindet ist dabei sehr wichtig. Insbesondere wird dies deutlich, wenn man an Szenarios denkt, bei denen nebenläufige Ausführung stattfindet. Wie, zum Beispiel, soll das Verhalten aussehen, wenn zwei oder mehr Threads gleichzeitig auf ein <code>lazy val</code> zugreifen wollen? Die oben erwähnte Eigenschaft, dass Auswertung nur einmal stattfindet, bedingt eine Form der Synchronisierung um mehrfache Auswertungen zu vermeiden. In der Praxis wird also ein Thread die Auswertung durchführen, während alle anderen Threads warten müssen. Erst wenn die Auswertung des zugewiesenen Ausdrucks abgeschlossen ist, können die wartenden Threads das Ergebnis lesen.</p><p>Und wie ist das in <code>scalac</code>, dem aktuellen Standard Scala Compiler implementiert? Dazu können wir ein Blick auf <a href="http://docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html">SIP-20</a>  werfen. Im Beispiel wird dort eine Klasse <code>LazyCell</code> mit einem <code>lazy val</code> „value“ definiert:</p><div>

```src src-scala
final class LazyCell {
  lazy val value: Int = 42
}

```

</div><p>Eine handgeschriebene Version des Codes, den der Compiler für <code>LazyCell</code> generiert sieht in etwa so aus:</p><div>

```src src-scala
final class LazyCell {
  @volatile var bitmap_0: Boolean = false                   // (1)
  var value_0: Int = _                                      // (2)
  private def value_lzycompute(): Int = {
    this.synchronized {                                     // (3)
      if (!bitmap_0) {                                      // (4)
        value_0 = 42                                        // (5)
        bitmap_0 = true
      }
    }
    value_0
  }
  def value = if (bitmap_0) value_0 else value_lzycompute() // (6)
}

```

</div><p>In <code>(3)</code> sehen wir die Verwendung eines Monitors via <code>this.synchronized {...}</code> um zu garantieren, dass die Auswertung auch bei der Verwendung durch mehrere Threads nur einmal stattfindet. Der Compiler verwendetet eine Booleschen Variable (<code>(1)</code>) um den Initialisierungsstatus (<code>(4)</code> & <code>(6)</code>) der Variablen <code>value_0</code> (<code>(2)</code>) zu verwalten. Diese speichert das finale Ergebnis der Auswertung und wird nach der initialen Auswertung gesetzt (<code>(5)</code>).</p><p>In der obigen Implementierung wird außerdem deutlich, dass ein <code>lazy val</code> – anders als ein normales <code>val</code> – bei <b>jedem</b> Zugriff zuerst den Status des Booleschen Flags überprüft (<code>(6)</code>). Das sollte man auf jeden Fall im Hinterkopf behalten, bevor man (versucht) <code>lazy val</code> als kostenlose Optimierung zu verwenden.</p><p>Nun da wir ein besseres Verständnis der zugrunde liegenden Mechanismen des <code>lazy</code> Keywords haben, können wir einen Blick auf eine Handvoll Szenarios werfen, bei denen es interessant wird.</p></div></div><div><h2>Szenario 1: Nebenläufige Initialisierung von mehreren unabhängigen vals geschieht sequenziell</h2><div><p>Um dieses Szenario zu verstehen ist es wichtig die oben erwähnte Verwendung von <code>this.synchronized { }</code> im Hinterkopf zu haben. Durch diese Zeile bedingen wir, dass wir ein exklusives Lock der momentane Instanz haben. Werden mehrere <code>lazy val</code> in der gleichen Instanz (z.B. in einem <code>object</code>) definiert, so führt der Zugriff auf <b>eine</b> der <code>lazy val</code> innerhalb der Instanz dazu, dass <b>alle</b> Threads warten müssen. Das ist auch der Fall, wenn diese auf unterschiedliche <code>lazy val</code> zugreifen.</p><p>Das folgende Codebeispiel demonstriert genau das: es werden zwei <code>lazy val</code> (<code>(1)</code> & <code>(2)</code>) innerhalb des <code>ValStore</code> <code>object</code>. Im <code>object</code> <code>Scenario1</code> greifen wir nun auf beide <code>val</code> innerhalb eines <code>Future</code> (also separater Thread) zu. Zur Laufzeit wird der Zugriff auf die beiden <code>lazy val</code> aber sequenziell stattfinden. Im konkreten Fall, in dem die Berechnung der <code>lazy val</code> einige Zeit dauert, ist das besonders unerfreulich.</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

def fib(n: Int): Int = n match {
  case x if x < 0 =>
    throw new IllegalArgumentException(
      "Only positive numbers allowed")
  case 0 | 1 => 1
  case _ => fib(n-2) + fib(n-1)
}

object ValStore {
  lazy val fortyFive = fib(45)                   // (1)
  lazy val fortySix  = fib(46)                   // (2)
}

object Scenario1 {
  def run = {
    val result = Future.sequence(Seq(            // (3)
      Future {
        ValStore.fortyFive
        println("done (45)")
      },
      Future {
        ValStore.fortySix
        println("done (46)")
      }
    ))
    Await.result(result, 1.minute)
  }
}

```

</div><p>Das Szenario kann sehr einfach in der Scala REPL getestet werden. Dazu den obigen Code kopieren und per <code>:paste</code> in der REPL wieder einfügen und per Aufruf von <code>Scenario1.run</code> starten. Wenn alles funktioniert wird zuerst die Auswertung von <code>ValStore.fortyFive</code> stattfinden, dann der Text „done (45)“ und erst danach die Auswertung von <code>ValStore.fortySix</code>, natürlich ist auch die umgekehrte Reihenfolge möglich.</p></div></div><div><h2>Szenario 2: Gefahr des Deadlocks bei Zugriff auf lazy vals</h2><div><p>Im vorigen Szenario litten wir „nur“ unter unerwarteten Performance Problemen, falls mehrere <code>lazy val</code> innerhalb einer Instanz definiert sind und durch mehrere Threads Zugriff erfolgt. Im folgenden Szenario sind die Konsequenzen etwas problematischer:</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

object A {
  lazy val base = 42
  lazy val start = B.step
}

object B {
  lazy val step = A.base
}

object Scenario2 {
  def run = {
    val result = Future.sequence(Seq(
      Future { A.start },                        // (1)
      Future { B.step }                          // (2)
    ))
    Await.result(result, 1.minute)
  }
}

```

</div><p>Wir definieren drei <code>lazy val</code> in zwei verschieden <code>object</code> <code>A</code> und <code>B</code>. Die Abhängigkeiten unter den <code>lazy val</code> sind hier noch mal visualisiert:</p><div><p><a href="https://media.graphassets.com/RBOO6bxgTpKTmAq6Hv8b"><img width="417" height="204" src="https://media.graphassets.com/RBOO6bxgTpKTmAq6Hv8b" alt="dep" /></a> </p></div><p>Der Wert von <code>A.start</code> ist abhängig von <code>B.step</code>, welcher von <code>A.base</code> abhängt. Wichtig: hier ist keine <b>zyklische</b> Beziehung vorhanden ist, trotzdem führt die Ausführung des obigen Szenarios via Scala REPL zu einem Deadlock (sollte es zufällig beim ersten Mal funktionieren, einfach noch einmal probieren):</p>

```example
scala> :paste
...
scala> Scenario2.run
java.util.concurrent.TimeoutException: Futures timed out after [1 minute]
  at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
  at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)
  at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)
  at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
  at scala.concurrent.Await$.result(package.scala:190)
  ... 35 elided

```

<p>Was passiert hier? Wir haben einen Deadlock, weil die beiden <code>Future</code> in <code>(1)</code> und <code>(2)</code> beim Zugriff auf <code>A</code> bzw. <code>B</code> wieder den exklusiven Zugriff haben durch Verwendung des Monitors. Damit die Ausführung fortgesetzt werden kann, braucht der Thread der exklusiven Zugriff auf <code>A</code> hat, auch Zugriff auf <code>B</code> wegen <code>B.step</code>. Der andere Thread dagegen hat exklusiven Zugriff auf <code>B</code>, braucht aber <code>A.base</code>. Wir haben also einen Deadlock. Im obigen Szenario ist die Situation recht leicht erkennbar, aber bei komplexeren Szenarien ist es ungleich schwerer auf die Ursache zu kommen. Die gleiche Situation kann auch bei Verwendung von <code>class</code> entstehen, obwohl es schwerer ist eine Situation wie die obige zu konstruieren. Im Allgemeinen sollte man aber auch erwähnen, dass die Deadlock Situation recht unwahrscheinlich ist, da es recht exaktes Timing beim gleichzeitigen Zugriff voraussetzt. Umso schwieriger ist es aber auch dieses Szenario zu reproduzieren, falls man es (gelegentlich) im Betrieb feststellt.</p></div></div><div><h2>Szenario 3: Deadlock in Kombination mit Synchronisierung</h2><div><p>Durch die Verwendung eines Monitors bei der Initialisierung von <code>lazy val</code> gibt es aber neben dem Problem aus Szenario 2 noch mehr Fälle, in denen es zu Problemen kommen kann. Zum Beispiel im folgenden Code:</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

trait Compute {
  def compute: Future[Int] =
    Future(this.synchronized { 21 + 21 })        // (1)
}

object Scenario3 extends Compute {
  def run: Unit = {
    lazy val someVal: Int =
      Await.result(compute, 1.minute)            // (2)
    println(someVal)
  }
}

```

</div><p>Ausführung in der Scala REPL führt zu folgendem Ergebnis:</p>

```example
scala> :paste
...
scala> Scenario3.run
java.util.concurrent.TimeoutException: Futures timed out after [1 minute]
  at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
  at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)
  at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)
  at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
  at scala.concurrent.Await$.result(package.scala:190)
  at Scenario3$.someVal$lzycompute$1(<console>:62)
  at Scenario3$.someVal$1(<console>:62)
  at Scenario3$.run(<console>:63)
  ... 33 elided

```

<p>Der <code>Compute</code> trait allein betrachtet ist zunächst harmlos, allerdings verwendet er einen Monitor via <code>synchronized</code> in <code>(1)</code>. Kombiniert man <code>Compute</code> mit <code>lazy val</code> befindet man sich in einer Deadlock Situation. Der Zugriff auf <code>someVal</code> (<code>(2)</code>) im <code>println(someVal)</code> erzwingt die Auswertung des <code>lazy val</code>, was dazu führt, dass der momentane Thread exklusiven Zugriff auf das <code>Scenario3</code> <code>object</code> bekommt. Beim Auswerten des Ausdrucks für <code>someVal</code> versucht die Methode <code>compute</code> ebenfalls exklusiven Zugriff zu bekommen – erneut befinden wir uns in einer Deadlock Situation.</p></div></div><div><h2>Zusammenfassug</h2><div><p>In den verschieden Szenarien wurden <code>Future</code> und <code>synchronized</code> als Beispiel benutzt. Wichtig ist aber, dass die Probleme unabhängig sind von den zwei konkret genutzten Arten Threads zu starten (<code>Future</code>) und Zugriffe zu synchronisieren (<code>synchronized</code>).</p><p>In diesem Artikel haben wir einen Blick hinter die Kulissen der <code>scalac</code> Implementierung von Scala’s <code>lazy val</code> geworfen und einige überraschende Szenarien genauer betrachtet:</p><ul><li>sequenzielle Initialisierung aufgrund der internen Verwendung<br /> eines Monitors</li><li>Deadlock während des nebenläufigen Zugriffs auf <code>lazy vals</code></li><li>Deadlock in Kombination mit anderen Synchronisierungsmitteln</li></ul><p>Wie man sehen kann, ist <code>lazy</code> <b>keine</b> kostenlose Optimierung, welche man ohne weiteres Betrachten des konkreten Falles einfach anwenden kann. Im Gegenteil, vermutlich würde es bei vielen der <code>lazy val</code> mehr Sinn machen sie durch normale <code>val</code> oder <code>def</code> zu ersetzen. Die gute Nachricht ist, dass die <a href="https://github.com/lampepfl/dotty/wiki/Getting-Started">Dotty</a>  Plattform bereits eine alternative Implementierung für die Initialisierung von <code>lazy val</code> verwendet (von Dmitry Petrashko), welche <b>nicht</b> die oben erwähnten Probleme hat. Für mehr Informationen über Dotty sind in den Referenzen Links zu Dmitry’s Talk und die GitHub von Dotty zu finden.</p><p><i>Alle Beispiele wurden mit Scala 2.11.7 getestet.</i></p></div><div><h3>Referenzen</h3><div><ul><li><a href="https://www.youtube.com/watch?v=aftdOFuVU1o">Hands-on Dotty</a>  (<a href="https://d-d.me/scalaworld2015/#/">slides</a> ) by Dmitry Petrashko</li><li><a href="http://docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html">SIP-20</a>  – Improved Lazy Vals Initialization</li><li><a href="https://github.com/lampepfl/dotty">Dotty</a>  – The Dotty research platform</li></ul></div></div></div><div><h2>Fußnoten</h2></div><div><div><div><sup><a href="#fnr.1">1</a> </sup>Das ist nicht ganz richtig. Falls bei der ersten Initialisierung eine Exception geworfen, werden darauf folgende Zugriffe erneut versuchen die Initialisierung vorzunehmen.<div></div></div></div></div></div>

Lazy Vals in Scala: Ein Blick hinter die Kulissen

<p>Scala allows the special keyword <code>lazy</code> in front of <code>val</code> in order to change the <code>val</code> to one that is lazily initialized. While lazy initialization seems tempting at first, the concrete implementation of lazy vals in <code>scalac</code> has some subtle issues. This article takes a look under the hood and explains some of the pitfalls: we see how lazy initialization is implemented as well as scenarios, where a lazy val can crash your program, inhibit parallelism or have other unexpected behavior.</p><p><span></span></p><div><div><h2>Introduction</h2><div><p>This post was originally inspired by the talk <a href="https://www.youtube.com/watch?v=aftdOFuVU1o" target="_blank">Hands-on Dotty</a>  (<a href="https://d-d.me/scalaworld2015/#/" target="_blank">slides</a> ) by Dmitry Petrashko, given at Scala World 2015. Dmitry gives a wonderful talk about Dotty and explains some of the lazy val pitfalls as currently present in Scala and how their implementation in Dotty differs. This post is a discussion of lazy vals in general followed by some of the examples shown in Dmitry Petrashko’s talk, as well as some further notes and insights.</p></div></div><div><h2>How <code>lazy</code> works</h2><div><p>The main characteristic of a <code>lazy val</code> is that the bound expression is not evaluated immediately, but <b>once</b> on the first access<sup><a href="#fn.1">1</a> </sup>. When the initial access happens, the expression is evaluated and the result bound to the identifier of the <code>lazy val</code>. On subsequent access, no further evaluation occurs: instead the stored result is returned immediately.</p><p>Given the characteristic above, using the <code>lazy</code> modifier seems like an innocent thing to do, when we are defining a <code>val</code>, why not also add a <code>lazy</code> modifier as a speculative “optimization”? In a moment we will see why this is typically not a good idea, but before we dive into this, let’s recall the semantics of a <code>lazy val</code> first.</p><p>When we assign an expression to a <code>lazy val</code> like this:</p><div>

```src src-scala
lazy val two: Int = 1 + 1

```

</div><p>we expect that the expression <code>1 + 1</code> is bound to <code>two</code>, but the expression is not yet evaluated. On the first (and only on the first) access of <code>two</code> from somewhere else, the stored expression <code>1 + 1</code> is evaluated and the result (<code>2</code> in this case) is returned. On subsequent access of <code>two</code>, <b>no evaluation happens</b>: the stored result of the evaluation was cached and will be returned instead.</p><p>This property of “evaluate <b>once</b>” is a very strong one. Especially if we consider a multithreaded scenario: what should happen if two threads access our <code>lazy val</code> at the same time? Given the property that evaluation occurs only once, we have to introduce some kind of synchronization in order to avoid multiple evaluations of our bound expression. In practice, this means the bound expression will be evaluated by one thread, while the other(s) will have to wait until the evaluation has completed, after which the waiting thread(s) will see the evaluated result.</p><p>How is this mechanism implemented in Scala? Luckily, we can have a look at <a href="http://docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html" target="_blank">SIP-20</a> . The example class <code>LazyCell</code> with a <code>lazy val value</code> is defined as follows:</p><div>

```src src-scala
final class LazyCell {
  lazy val value: Int = 42
}

```

</div><p>A handwritten snippet equivalent to the code the compiler generates for our <code>LazyCell</code> looks like this:</p><div>

```src src-scala
final class LazyCell {
  @volatile var bitmap_0: Boolean = false                   // (1)
  var value_0: Int = _                                      // (2)
  private def value_lzycompute(): Int = {
    this.synchronized {                                     // (3)
      if (!bitmap_0) {                                      // (4)
        value_0 = 42                                        // (5)
        bitmap_0 = true
      }
    }
    value_0
  }
  def value = if (bitmap_0) value_0 else value_lzycompute() // (6)
}

```

</div><p>At <code>(3)</code> we can see the use of a monitor <code>this.synchronized {...}</code> in order to guarantee that initialization happens only once, even in a multithreaded scenario. The compiler uses a simple flag (<code>(1)</code>) to track the initialization status (<code>(4)</code> & <code>(6)</code>) of the var <code>value_0</code> (<code>(2)</code>) which holds the actual value and is mutated on first initialization (<code>(5)</code>).</p><p>What we can also see in the above implementation is that a <code>lazy val</code>, other than a regular <code>val</code> has to pay the cost of checking the initialization state on <b>each</b> access (<code>(6)</code>). Keep this in mind when you are tempted to (try to) use <code>lazy val</code> as an “optimization”.</p><p>Now that we have a better understanding of the underlying mechanisms for the <code>lazy</code> modifier, let’s look at some scenarios where things get interesting.</p></div></div><div><h2>Scenario 1: Concurrent initialization of multiple independent vals is sequential</h2><div><p>Remember the use of <code>this.synchronized { }</code> above? This means we lock the whole instance during initialization. Furthermore, multiple <code>lazy vals</code> defined inside e.g., an <code>object</code>, but accessed concurrently from multiple threads will still all get initialized <b>sequentially</b>. The code snippet below demonstrates this, defining two <code>lazy val</code> (<code>(1)</code> & <code>(2)</code>) inside the <code>ValStore</code> object. In the object <code>Scenario1</code> we request both of them inside a <code>Future</code> (<code>(3)</code>), but at runtime each of the <code>lazy val</code> is calculated separately. This means we have to wait for the initialization of <code>ValStore.fortyFive</code> until we can continue with <code>ValStore.fortySix</code>.</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

def fib(n: Int): Int = n match {
  case x if x < 0 =>
    throw new IllegalArgumentException(
      "Only positive numbers allowed")
  case 0 | 1 => 1
  case _ => fib(n-2) + fib(n-1)
}

object ValStore {
  lazy val fortyFive = fib(45)                   // (1)
  lazy val fortySix  = fib(46)                   // (2)
}

object Scenario1 {
  def run = {
    val result = Future.sequence(Seq(            // (3)
      Future {
        ValStore.fortyFive
        println("done (45)")
      },
      Future {
        ValStore.fortySix
        println("done (46)")
      }
    ))
    Await.result(result, 1.minute)
  }
}

```

</div><p>You can test this by copying the above snippet and <code>:paste</code>-ing it into a Scala REPL and starting it with <code>Scenario1.run</code>. You will then be able to see how it firsts evaluates <code>ValStore.fortyFive</code>, then prints the text and afterwards does the same for the second <code>lazy val</code>. Instead of an <code>object</code> you can also imagine this case for a normal <code>class</code>, having multiple <code>lazy vals</code> defined.</p></div></div><div><h2>Scenario 2: Potential dead lock when accessing lazy vals</h2><div><p>In the previous scenario, we only had to suffer from decreased performance, when multiple <code>lazy vals</code> inside an instance are accessed from multiple threads at the same time. This may be surprising, but it is not a deal breaker. The following scenario is more severe:</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

object A {
  lazy val base = 42
  lazy val start = B.step
}

object B {
  lazy val step = A.base
}

object Scenario2 {
  def run = {
    val result = Future.sequence(Seq(
      Future { A.start },                        // (1)
      Future { B.step }                          // (2)
    ))
    Await.result(result, 1.minute)
  }
}

```

</div><p>Here we define three <code>lazy val</code> in two objects <code>A</code> and <code>B</code>. Here is a picture of the resulting dependencies:</p><div><p><a href="https://media.graphassets.com/RBOO6bxgTpKTmAq6Hv8b"><img width="417" height="204" src="https://media.graphassets.com/RBOO6bxgTpKTmAq6Hv8b" alt="Dependencies" /></a> </p></div><p>The <code>A.start</code> val depends on <code>B.step</code> which in turn depends again on <code>A.base</code>. Although there is no cyclic relation here, running this code can lead to a <b>deadlock</b>:</p>

```example
scala> :paste
...
scala> Scenario2.run
java.util.concurrent.TimeoutException: Futures timed out after [1 minute]
  at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
  at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)
  at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)
  at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
  at scala.concurrent.Await$.result(package.scala:190)
  ... 35 elided

```

<p>(if it succeeds by chance on your first try, give it another chance). So what is happening here? The deadlock occurs, because the two <code>Future</code> in <code>(1)</code> and <code>(2)</code>, when trying to access the <code>lazy val</code> will both lock the respective object <code>A</code> / <code>B</code>, thereby denying any other thread access. In order to achieve progress however, the thread accessing <code>A</code> also needs <code>B.step</code> and the thread accessing <code>B</code> needs to access <code>A.base</code>. This is a deadlock situation. While this is a fairly simple scenario, imagine a more complex one, where more objects/classes are involved and you can see why overusing <code>lazy val</code> can get you in trouble. As in the previous scenario the same can occur inside <code>class</code>, although it is a little harder to construct the situation. In general this situation is unlikely to happen, because of the exact timing required to trigger the deadlock, but it is equally hard to reproduce in case you encounter it.</p></div></div><div><h2>Scenario 3: Deadlock in combination with synchronization</h2><div><p>Playing with the fact that <code>lazy val</code> initialization uses a monitor (<code>synchronized</code>), there is another scenario, where we can get in serious trouble.</p><div>

```src src-scala
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent._
import scala.concurrent.duration._

trait Compute {
  def compute: Future[Int] =
    Future(this.synchronized { 21 + 21 })        // (1)
}

object Scenario3 extends Compute {
  def run: Unit = {
    lazy val someVal: Int =
      Await.result(compute, 1.minute)            // (2)
    println(someVal)
  }
}

```

</div><p>Again, you can test this for yourself by copying it and doing a <code>:paste</code> inside a Scala REPL:</p>

```example
scala> :paste
...
scala> Scenario3.run
java.util.concurrent.TimeoutException: Futures timed out after [1 minute]
  at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
  at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)
  at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)
  at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
  at scala.concurrent.Await$.result(package.scala:190)
  at Scenario3$.someVal$lzycompute$1(<console>:62)
  at Scenario3$.someVal$1(<console>:62)
  at Scenario3$.run(<console>:63)
  ... 33 elided

```

<p>The <code>Compute</code> trait on it’s own is harmless, but note that it uses <code>synchronized</code> in <code>(1)</code>. In combination with the <code>synchronized</code> initialization of the <code>lazy val</code> inside <code>Scenario3</code> however, we have a deadlock situation. When we try to access the <code>someVal</code> (<code>(2)</code>) for the <code>println</code> call, the triggered evaluation of the <code>lazy val</code> will grab the lock on <code>Scenario3</code>, therefore preventing the <code>compute</code> to also get access: a deadlock situation.</p></div></div><div><h2>Conclusion</h2><div><p>Before we sum this post up, please note that in the examples above we use <code>Future</code> and <code>synchronized</code>, but we can easily get into the same situation by using other concurrency and synchronization primitives as well.</p><p>In summary, we had a look under the hood of Scala’s implementation of lazy vals and discussed some surprising cases:</p><ul><li>sequential initialization due to monitor on instance</li><li>deadlock on concurrent access of <code>lazy vals</code> without cycle</li><li>deadlock in combination with other synchronization constructs</li></ul><p>As you can see, <code>lazy vals</code> should not be used as a speculative optimization without further thought about the implications. Furthermore you might want to replace some of your <code>lazy val</code> with a regular <code>val</code> or <code>def</code> depending on your initialization needs after becoming aware of the issues above.<br /> Luckily, the <a href="https://github.com/lampepfl/dotty/wiki/Getting-Started" target="_blank">Dotty</a>  platform has an alternative implementation for <code>lazy val</code> initialization (by Dmitry Petrashko) which does <b>not</b> suffer from the unexpected pitfalls discussed in this post. For more information on Dotty you can watch Dmitry’s talk linked in the “references” section and head over to their <a href="https://github.com/lampepfl/dotty" target="_blank">github page</a> .</p><p><em>All examples have been tested with Scala 2.11.7.</em></p></div><div><h3>References</h3><div><ul><li><a href="https://www.youtube.com/watch?v=aftdOFuVU1o" target="_blank">Hands-on Dotty</a>  (<a href="https://d-d.me/scalaworld2015/#/" target="_blank">slides</a> ) by Dmitry Petrashko</li><li><a href="http://docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html" target="_blank">SIP-20</a>  – Improved Lazy Vals Initialization</li><li><a href="https://github.com/lampepfl/dotty" target="_blank">Dotty</a>  – The Dotty research platform</li></ul></div></div></div><div><h2>Footnotes:</h2><div><div><sup><a href="#fnr.1">1</a> </sup>This is not completely true, initialization will be tried again in case of exceptions during the first access until the first successful initialization.</div><div></div></div></div><p> </p></div>

Lazy Vals in Scala: A Look Under the Hood

<div><div><div><p>Tired of writing hundreds of unit tests manually? Write <i>properties</i> and let the test cases be generated automatically! We introduce the ScalaCheck library and demonstrate the benefits of property-based testing, an approach that is very different from the traditional unit testing, because we focus on writing general properties instead of specific test cases.</p></div></div></div><p><span></span></p><div><div><div><p>If you want to look at the full code for the post while reading, you can find it at <a href="https://github.com/markus1189/intro-to-scalacheck">github</a> .</p></div></div><div><h2>Property-based Testing</h2><div><p>Writing good tests is an important building block for high software quality. On the developer side however, it is also well-known that writing <i>good</i> tests is extremely hard. As an example, even a basic unit test has to consider the intended use, possible edge cases of the test input, as well as the expected behavior if something goes wrong. This in turn leads to a huge number of individual tests, which make it hard to identify the original property.</p><p>Wouldn’t it be nice to have test cases <i>automatically</i> generated and the results checked if they match the specification? <a href="http://www.scalacheck.org/">ScalaCheck</a>  does exactly this, given a property describing the expected behavior, it will generate random input data, covering many edge cases, and check the result. This form of testing is called <i>property-based testing</i>, originally invented in Haskell in the form of the <a href="https://hackage.haskell.org/package/QuickCheck">QuickCheck</a>  library, which was later ported to Scala and many other languages.</p><p>In this post, we provide an introduction to ScalaCheck and use it to write and test a simple program that checks whether a given input is a palindrome. The purpose of this post is to get a quick overview of the how and why of ScalaCheck, not (yet) a complete overview of available features.</p></div></div><div><h2>Checking Palindromes</h2><div><p>Before we can use ScalaCheck to test our implementation, we obviously first need an implementation. As our toy example, we use a simple problem: checking whether a string is a palindrome.</p><p>For simplicity, we consider only single words (instead of whole sentences or other units) and define a palindrome as:</p>

```example
A given word is a palindrome, iff it reads the same forwards and backwards.

```

<p>Given this definition, we can translate it into Scala code easily:</p><div>

```src src-scala
def checkReverse(s: String): Boolean = s == s.reverse

```

</div><p>This naive implementation is not the most efficient, but it has the advantage of obvious correctness by simplicity. This is a common situation: we have a very simple and naive solution, but we might want to replace it with a better implementation later on, using less memory and/or a faster algorithm. Before we start to develop alternative implementations to check palindromes, let’s have a first look at ScalaCheck.</p></div></div><div><h2>Using ScalaCheck</h2><div><p>Testing with ScalaCheck and using property-based testing in general, consists of two important activities:</p><ol><li>formulating properties that hold for our implementation</li><li>writing generators, creating random test data for which the property has to hold</li></ol><p>ScalaCheck then generates a (configurable) number of test input sets and checks, whether the property holds for all of them. Finding <i>good</i> properties is the point where developer creativity plays a big role, as thinking of tests in form of properties is different from the unit testing mindset. However, in this post we focus on a special case where ScalaCheck can be used without requiring us to find a good set of properties for our implementation: replacing algorithms with alternatives that are better (with regard to an aspect like memory allocation, runtime, etc.).</p><p>Writing a generator for your data is made easy, because ScalaCheck ships with a large number of predefined generators for a lot of standard types, as well as a rich library of combinators. Generators are represented as <code>Gen[+T]</code> which is a generator for values of type <code>T</code>. In order to test our implementation of <code>checkReverse</code> we need to generate palindromes, so let’s start with that.</p><div>

```src src-scala
val palindromeGen: Gen[String] = for {
  base <- arbitrary[String]
  middle <- Gen.option(arbitrary[Char])
} yield base + middle.getOrElse("") + base.reverse

```

</div><p>We have a palindrome generator, where palindromes are normal <code>Strings</code> . <code>Gen</code> implements <code>map</code>, <code>flatMap</code> and friends, which allows us to use Scala’s for comprehensions as syntactic sugar. A palindrome is built from two other generators: <code>base</code> which is the part that is repeated in reversed form at the end (the very definition of a palindrome) and an optional <code>middle</code> of type <code>Char</code> to allow palindromes with an odd number of characters:</p><div><p><a href="https://media.graphassets.com/1k9fs1rQGYUvGrcmfzYA"><img width="550" height="154" src="https://media.graphassets.com/1k9fs1rQGYUvGrcmfzYA" alt="kayak" /></a> </p></div><p><code>Gen.option</code> takes as an argument a generator and returns another generator that may or may not generate a value. In order to provide default generators for types, ScalaCheck uses the <code>Arbitrary</code> type class, which defines the <code>arbitrary</code> method. Using <code>arbitrary</code>, we can make use of an implicitly defined generator for the given type. If we want to have this for our own types, we can do this by writing instances of the <code>Arbitrary</code> class.</p><p>To get an idea of the palindromes generated, we can sample our <code>palindromeGen</code> like this:</p>

```example
scala> palindromeGen.sample
res1: Option[String] = Some(㳺ᢨȕ❓❓ȕᢨ㳺)
scala> palindromeGen.sample
res2: Option[String] =
  Some(⻧᲎ჹ쩄颧㱵댤扛峌甔ᩡ잉ᇐ醢徉⧭༐跍멅跍༐⧭徉醢ᇐ잉ᩡ甔峌扛댤㱵颧쩄ჹ᲎⻧)

```

<p>Not the palindromes you would have come up with in unit tests, right? This is where property-based testing really shines, because when writing unit tests, we have to make dedicated effort in order to come up with test cases that exercise corner cases and abnormal behavior, while here we can lean back and let ScalaCheck come up with them instead. Of course, we could have written our palindrome generator <code>palindromeGen</code> in a way, such that it does not use unicode chars, for example by using <code>Gen.alphaStr</code> or other predefined generators in the companion object for <code>Gen</code>.</p></div></div><div><h2>Testing Our Implementation and Generator</h2><div><p>As a first test, let’s check that our naive palindrome checker from above coincides with our palindrome generator. We do this by writing our very first property:</p><div>

```src src-scala
property("checkReverse coincides with generator") =
  forAll(palindromeGen) { palindrome =>
    checkReverse(palindrome)
  }

```

</div><p>Our new property takes as an argument a description and consists of a check that <code>forAll</code> palindromes generated from our palindrome generator <code>palindromeGen</code>, <code>checkReverse</code> returns true. If we run the tests in sbt, we get:</p>

```example
> test
[info] + Palindrome.checkReverse: OK, passed 100 tests.

```

<p>This means that our property held for all of the randomly generated test inputs. Not unexpected, but good to know in any case.</p></div></div><div><h2>A Better Palindrome Checker</h2><div><p>Our <code>checkReverse</code> method does the job and the nice thing is that the implementation is very simple. As hinted earlier, at some point, though, we might want to exchange the implementation for a better version. One problem of the naive reverse approach is that for every string we check, we need <i>twice</i> the memory to perform the actual equality check. With growing adoption of our palindrome-checking-service however, users want to have larger and larger strings checked for palindromicity, reaching millions of chars in length! When we want to check such a large string, it is unthinkable to just allocate twice the memory, certainly we can do better than that!</p><p>After a quick round on the white board, we come up with an alternative way to check for palindromicity: we keep track of two indices, starting from the very left and the very right of the palindrome. The idea is to then work our way towards the middle, comparing the characters as we go:</p><div><p><a href="https://media.graphassets.com/Yghvb2ljT4mTnTwpegPz"><img loading="lazy" width="700" height="196" src="https://media.graphassets.com/Yghvb2ljT4mTnTwpegPz" alt="racecar" /></a> </p></div><p>We start with an implementation and on the first try, we come up with this:</p><div>

```src src-scala
def checkIndices(s: String): Boolean = {
  @tailrec
  def loop(i: Int, j: Int): Boolean = (i,j) match {
    case (i,j) if i == j => true
    case (i,j) if s(i) != s(j) => false
    case (i,j) if s(i) == s(j) => loop(i+1,j-1)
  }

  loop(0,s.length-1)
}

```

</div><p>To test this, we need a property. As we are pretty sure that <code>checkReverse</code> is a correct implementation, why not use that as reference:</p><div>

```src src-scala
property("checkIndices") = forAll(maybePalindrome) { s =>
  checkReverse(s) == checkIndices(s)
}

```

</div><p>We say that for all strings generated by <code>maybePalindrome</code>, our <code>checkIndices</code> method should return the same result as <code>checkReverse</code>. We define <code>maybePalindrome</code> as:</p><div>

```src src-scala
val maybePalindrome: Gen[String] = Gen.oneOf(palindromeGen,arbitrary[String])

```

</div><p>Note the use the <code>oneOf</code> method from <code>Gen</code> to create a generator that will sometimes produce palindromes and sometimes arbitrary strings. Now let’s test our new palindrome checker:</p>

```example
> test
[info] ! Palindrome.checkIndices: Exception raised on property evaluation.
[info] > ARG_0: ""
[info] > Exception: java.lang.StringIndexOutOfBoundsException:
  String index out of range: 0

```

<p>We forgot about the empty string! Okay that’s easy, let’s fix that and just run the tests again:</p>

```example
> test
[info] ! Palindrome.checkIndices2: Exception raised on property evaluation.
[info] > ARG_0: "꫖꫖"
[info] > Exception: java.lang.StringIndexOutOfBoundsException:
  String index out of range: 2

```

<p>Another error, this time when handling palindromes with an even number of chars. Investigating this, we come to the conclusion, that we forgot to consider what happens when the two indices never meet because they pass each other, due to an even number of chars:</p><div><p><a href="https://media.graphassets.com/V9hRmrCxS3q07XPwnCtQ"><img loading="lazy" width="450" height="224" src="https://media.graphassets.com/V9hRmrCxS3q07XPwnCtQ" alt="noon" /></a> </p></div><p>Here in the next step, our current algorithm would continue with <code>i</code> and <code>j</code> in swapped position and then continue both indexes until we run out of chars, leading to the <code>StringIndexOutOfBoundsException</code> from above. To fix this, we add another case to our implementation:</p><div>

```src src-scala
def checkIndices(s: String): Boolean = {
  @tailrec
  def loop(i: Int, j: Int): Boolean = (i,j) match {

    // additional case: check for adjacent indices
    case (i,j) if i+1 == j => s(i) == s(j)

    case (i,j) if i == j => true
    case (i,j) if s(i) != s(j) => false
    case (i,j) if s(i) == s(j) => loop(i+1,j-1)
  }

  // additional check: "" is a palindrome
  s.isEmpty || loop(0,s.length-1)
}

```

</div><p>Feeling lucky, we run our tests again:</p>

```example
> test
[info] + Palindrome.checkReverse: OK, passed 100 tests.
[info] + Palindrome.checkIndices: OK, passed 100 tests.
[info] Passed: Total 2, Failed 0, Errors 0, Passed 2

```

<p>Success! For 100 randomly generated strings, our implementation of <code>checkIndices</code> returned the same result as our reference implementation <code>checkReverse</code>.</p></div></div><div><h2>Conclusion</h2><div><p>Properties do not have to be used exclusively, instead they can be combined with regular unit tests. Sometimes explicit examples in the form of unit tests are still desirable, for documentation purposes. In Scala, most testing frameworks have support for ScalaCheck properties, e.g. <a href="http://www.scalatest.org/">ScalaTest</a>  and <a href="https://etorreborre.github.io/specs2/">specs2</a> , making it easy to combine unit tests and properties.</p><p>This little demo of ScalaCheck only scratches the surface, but gives a brief glimpse of the strength of property-based testing. We wrote only one single property, to check a more complex implementation against a reference. By randomly generating test input we are able to cover a wide range of corner cases, which are easy to miss or cumbersome to enumerate with unit tests. The pattern of using a simple but slow implementation as reference for a better version is only one powerful scenario where property-based testing makes your life as a developer easier.</p><p><i>Exercise for interested readers:</i> Download the code from <a href="https://github.com/markus1189/intro-to-scalacheck">github</a> . Write another version that checks whether a given string is a palindrome. You can use any algorithm you want, alternatively, try to write a recursive version that proceeds by dropping chars from both ends until the check is done. Write a property that compares your implementation with our reference implementation <code>checkReverse</code> and see if you got it right by running the tests.</p><p>You can find more about ScalaCheck on the official <a href="http://www.scalacheck.org/">website</a> , including a <a href="https://github.com/rickynils/scalacheck/wiki/User-Guide">user guide</a>  and the API documentation.</p><p>The code in this post (<a href="https://github.com/markus1189/intro-to-scalacheck">github</a> ) was tested with Scala <code>2.11.7</code> and ScalaCheck <code>1.12.5</code>.</p></div></div></div><p></p><p></p><p> </p>

Introduction to Property-based Testing using ScalaCheck

Ich habe mich gefragt, wie Workload und Infrastruktur-Deployment als eine Einheit betrachtet werden können. Gute Software ist schließlich erst dann wertvoll, wenn sie stabil mit der dazugehörigen Infrastruktur betrieben werden kann. Dabei sollen interne Developer-Plattformen helfen. Bei meiner Suche nach einer Lösung für dieses Problem im Aufbau von Developer-Plattformen bin ich auf den Platform Orchestrator gestoßen.

**Was ist ein Platform Orchestrator?**  
Man kann sich den Platform Orchestrator als einen Rule-Engine vorstellen, die versteht, was die Entwickler\*innen benötigen und es basierend auf den Konfigurationen und Templates, die vom Platform-Team bereitgestellt werden, anbietet. [Humanitecs Platform Orchestrator](https://humanitec.com/products/platform-orchestrator) ist eine solche Regel-Engine. Neben dem SaaS Produkt von Humanitec gibt es noch andere explizite Platform Orchestrator wie z.B. [Kratix](https://www.kratix.io/) oder [KusionStack](https://www.kusionstack.io/zh/). Thoughtworks hat Platform Orchestrator als Tool-Kategorie 2023 in ihr bekanntes [Technologie-Radar](https://www.thoughtworks.com/en-de/radar/techniques/platform-orchestration) aufgenommen. Wie einen Platform Orchestration Layer ebenfalls implementieren kann, erklärt mein Kollege Jonas Hecht in seinem Artikel [Going full GitOps with Crossplane & ArgoCD](https://www.codecentric.de/wissens-hub/blog/full-gitops-with-crossplane-and-argocd).

Wir sehen immer wieder, dass sich fast jedes Plattform-Design im Wesentlichen darauf konzentriert, vorgefertigte Git-Repository Templates mit unterschiedlichsten Konfigurationsdateien über ein vermeintliches Developer-Portal bereitzustellen. Danach bleibt es den Entwickler\*innen überlassen, das “Skriptchaos” zu warten. Wenn sie damit überlastet sind, übertragen sie dieses Chaos an die IT-Operations-Teams. Das Ergebnis ist, dass die Entwickler\*innen langsamer werden, auf andere warten müssen und die IT-Operations-Mitarbeitenden sich durch unzählige Tickets kämpfen müssen. Dabei leidet die Time-to-Market, das Lebenselixier jedes Softwareentwicklungsprozesses.

![Developer Platform - Frontend Backend.png](https://media.graphassets.com/WzcOGA2jSEG9Z8oOKXGt)

Platform Architekturen sollten in Front- und Backend unterteilt werden. Platform Orchestrator bilden den Kern eines solchen Backends. Die Idee ist es, die gesamte Anwendung inklusive ihrer Infrastruktur-Ressourcen \- Datenbanken, Objekt-Storage oder DNS etc. \- bei jedem einzelnen Deployment neu zu konfigurieren. Ein Platform Orchestrator liest im Wesentlichen ein Rezept von Entwickler\*innen und erstellt dynamisch Anwendungs- und Infrastruktur-Konfigurationen bei jedem Deployment. Auf diese Weise gibt es im Deployment keinen Unterschied zwischen dem ersten und dem x-ten Mal. Dieser Ansatz ermöglicht ein hohes Maß an Standardisierung und ermöglicht es den Plattform Engineers, hoch skalierbare sogenannte Golden-Paths zu erstellen, die standardmäßig alle Ressourcen, Konfigurationen und Richtlinien enthalten. Außerdem führt dies zur deutlichen Reduzierung der Anzahl an Konfigurationsdateien.

**Der Platform Orchestrator schafft klare geteilte Verantwortung**  
Der Orchestrator integriert sich in die Pipeline, ist an die Image-Registry und das Secret-Management angebunden und möglicherweise auch an ein Developer-Portal und Service-Katalog \- Post-CI also. Was genau der Orchestrator dort macht, basiert auf den Eingaben von zwei in der Regel unterschiedlichen Benutzergruppen. Die erste Gruppe sind die Entwickler\*innen. Sie wissen am besten, welche Infrastruktur-Ressourcen ihre Workload benötigt, wie diese Ressourcen angebunden werden müssen und möglicherweise auch, wie sie mit anderen Workloads kommunizieren soll. Um dies zu beschreiben, gibt es für jede Workload ein kleines Rezept, die sogenannte Workload-Specification. In diesem Fall ist das [score](https://score.dev/). Wenn die Workload beispielsweise von einer PostgreSQL-Datenbank abhängt, dann wird genau das und nur das in die Workload-Specification eingetragen. Diese Rezepte sind umgebungsagnostisch und um es möglichst einfach zu machen, basieren sie auf der YAML-Syntax und liegen im gleichen Repository wie der Applikations Code selbst.

Wir wissen jetzt, dass die Workload von einer PostgreSQL-Datenbank abhängt. Wir wissen nicht, ob wir diese Workload an eine vorhandene Datenbank anschließen oder eine neue erstellen sollen. Wir wissen auch nicht, wie wir die Konfiguration für das Anwendungs-Deployment erstellen sollen. Wie viel Rechenleistung benötigen wir? Brauchen wir Sidecars, Labels und Annotationen? Welche Security- und Compliance Anforderungen gibt es an diese Infrastruktur Ressourcen? Diese fehlenden Informationen werden vom Platform Team, unserer zweiten Benutzergruppe, bereitgestellt. Das Platform Team hinterlegt im Orchestrator vorher sogenannte [Resource Definitions](https://humanitec.com/marketplace#resource-definitions). Das ist sozusagen der Capability-Katalog, den die Plattform zur Verfügung stellt und an dem sich Entwickler\*innen bedienen können. Über gängige Infrastructure as Code Tools wie Terraform oder Crossplane wird beschrieben, wie in unserem Beispiel Postgres Datenbanken auszusehen haben.

Um den Ablauf jetzt einmal greifbar zu machen, gehen wir ihn Schritt für Schritt einmal durch.  
Im ersten Schritt pushen wir unseren Applikations Code und unser kleines Rezept, die Workload Spezifikation, in unsere CI-Pipeline. Die CI-Pipeline pusht das Image in die Image-Registry und das Rezept an den Platform Orchestrator. Der Orchestrator erhält die Information, dass ein neues Image erstellt wurde, sowie den Pfad zu diesem Image und das Rezept selbst. Daraufhin startet nun das sogenannte RMCD-Execution Pattern. RMCD steht für Read, Match, Create and Deploy. Im Read-Schritt liest der Orchestrator das Rezept und erkennt in unserem Beispiel, dass die Workload von einer Postgres-Datenbank abhängt. Im Match-Schritt versteht er den Kontext, z.B. dass die Bereitstellung für eine Entwicklungsumgebung oder die Produktivumgebung erfolgt. Er findet dann heraus, welche Resource Definitions und Regeln, Ressource Criterias, das Platform Team in dieser Situation anwenden möchte. In der Create-Phase erstellt der Orchestrator die Anwendungskonfigurationen. Dann findet er heraus, ob die Workload an eine vorhandene Ressource angeschlossen werden soll oder ob eine neue erstellt werden muss. Wenn eine neue erstellt werden muss, kann er dies mithilfe der hinterlegten Resource Definition tun. 

Anschließend ruft er die Anmeldeinformationen für die Ressource ab und indiziert sie zur Laufzeit über Secrets in den Container. In der Deploy-Phase wird die Workload bereitgestellt und wir sind fertig. Diesen Prozess wiederholt der Orchestrator bei jeder Bereitstellung. Das hat einen erheblich positiven Einfluss auf die Standardisierung, Benutzerfreundlichkeit und Wartbarkeit der Applikations- und Infrastruktur Ressourcen über ihre gesamte Lebenszeit. 

![humanitec Platform Orchestrator - RMCD Pattern.png](https://media.graphassets.com/yQ1kYybNRYWFyoszwkQ4)

**Fazit**  
Bei Internal Developer Platforms geht es nicht darum, die initiale Bereitstellung von Services und ihre Infrastruktur Abhängigkeiten durch ein paar Templates oder ein schickes Developer-Portal zu optimieren. Tag fünfhundert, tausend oder zweitausend im Lebenszyklus dieser Komponenten sind die, wo am häufigsten zeitraubende Probleme entstehen. Deswegen liegt da auch der Hebel, um wirklich langfristig mehr Effektivität im Softwareentwicklungsprozess zu schaffen. Durch weniger und einfachere Konfigurationsdateien, klare, geteilte Verantwortlichkeiten zwischen Entwickler\*innen und dem Platform Team, kann die kognitive Last in den Teams reduziert, die Hürden für die Nutzung der Plattform niedrig gehalten und folglich die Adaption der Plattform gefördert werden. Der Humanitec Platform Orchestrator kann für diese Herausforderung eine unterstützende Komponente sein. 

Wenn du dich für den Aufbau interner Entwickler Plattformen oder speziell für den Platform Orchestrator von Humanitec interessierst, schau doch mal [hier](https://www.codecentric.de/leistungen/platform-engineering) vorbei. Dort erklären wir unseren Ansatz für erfolgreiche Plattform Initiativen. 


Der Platform Orchestrator von Humanitec

Service Lead Platform Engineering

Keycloak.X, aber sicher – ohne bekannte Sicherheitslücken!

From Keycloak to Keycloak.X

Keycloak.X, but secure – without vulnerable libraries

Stream Processing mit Kafka Streams und Spring Boot

<p>Hyperledger Fabric ist eine hervorragende DLT-Plattform und bietet großartige Anpassungsmöglichkeiten. Eine Möglichkeit davon ist es, verschiedene Datenbanken zur Speicherung von <a href="https://www.codecentric.de/innovation/blockchain/">Blockchain</a> -Daten zu nutzen. Die empfohlene und am besten unterstützte Option ist die Verwendung einer CouchDB. Sie erlaubt es komplexe Abfragen auf Blockchain-Daten durch Hyperledger Fabric Chaincode mittels verschiedener Programmiersprachen, wie etwa go, JavaScript oder Java, durchzuführen. Um mehr über Hyperledger in Kombination mit CouchDB zu erfahren, werfe einen Blick in die <a href="https://hyperledger-fabric.readthedocs.io/en/release-1.4/couchdb_tutorial.html">offizielle Dokumentation</a> .</p><p><span>Im Bild unten findet man eine CouchDB-Übersicht anhand eines Hyperledger-Fabric-Knotens mit dem Channel „compactionchannel“ und dem Chaincode „cdbc“. Dies ist nur ein Beispiel, um die CouchDB-Struktur zu demonstrieren und enthält noch nicht viele Daten.</span><a href="https://media.graphassets.com/U9K64D7cRDCHs2s9yICr"><img title src="https://media.graphassets.com/U9K64D7cRDCHs2s9yICr" alt="CouchDb Übersicht mit Hyperledger" width="700" height="162" /></a> </p><p><span>Blockchains wie Hyperledger speichern Daten auf unbestimmte Zeit und somit wächst die Gesamtmenge der Daten kontinuierlich an. Um die genannten komplexen Abfragen zu ermöglichen, wird der aktuelle „world state“ in CouchDB abgelegt. Wenn sich Daten ändern, ändert sich auch der entsprechende „world state“. CouchDB fügt den neuen Wert nur an seine interne Repräsentation an und entfernt den alten Wert zunächst nicht. Normalerweise würde die automatische Compaction unbenutzte Daten kontinuierlich entfernen und die Größe der Datenbank klein halten.</span></p><p><span>Unter Umständen startet die automatische Compaction nicht, solch eine Situation haben wir bei einem unserer Kunden festgestellt. Dies führte zu einem kontinuierlichen Wachstum der Datenbank und zu Unmengen unnötiger GBs an Speicherplatz. In diesem Fall hast du nun zwei Möglichkeiten: Du kannst die Compaction neu konfigurieren oder manuell starten.</span></p><h2>Status der Hyperledger CouchDB Compaction</h2><p><span>Mit dem folgenden Befehl kannst du den Compaction Status abfragen:</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" http://<CouchDB>:5984/_node/nonode@nohost/_config

{
  ...
  "compactions": {
    "_default": "[{db_fragmentation, \"30%\"}, {view_fragmentation, \"30%\"}]"
  },
  "compaction_daemon": {
    "check_interval": "300",
    "min_file_size": "256000"
  }
}

```

<h3>Manuelle Compaction</h3><p><span>Du kannst die manuelle Compaction folgendermaßen anstoßen:</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" -X POST http://<CouchDB>:5984/<channel-name>_<chaincode>/_compact

{"ok":true}

```

<p><span>Um den Status des Prozesses zu überprüfen:</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic_Auth>" http://<CouchDB>:5984/<channel-name>_<chaincode>

{
  ...
  "compaction_running": true,
  ...
}

```

<p><span>Darüber hinaus können nicht nur die Datenbank, sondern auch CouchDB Views komprimiert werden. Dazu kann folgender REST-Aufruf verwendet werden:</span></p>

```
curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" -X POST http://<CouchDB>:5984/<channel-name>_<chaincode>/_compact/<view-name>

{"ok":true}

```

<p><span>Abhängig von der Größe der Hyperledger-Fabric-Datenbank oder der Views kann die Compaction einige Zeit in Anspruch nehmen.</span></p><p><span>Weitere Informationen über Compaction sind in der </span><a href="https://docs.couchdb.org/en/stable/maintenance/compaction.html"><span>offiziellen Dokumentation</span></a>  von CouchDB <span>zu finden.</span><br /> <strong>Tipp: Auf unsere Website haben wir umfassende Informationen zusammengestellt, wie wir dir dabei helfen können, das Thema Blockchain und Ledger-Technoligie im eigenen Kontext einzusetzen. <a href="https://hubs.ly/H0mxqSd0" target="_blank">Alle Angebote zu Blockchain</a> .</strong></p>

Hyperledger Fabric CouchDB lässt meine Cloud-Rechnung explodieren

<p><span>Hyperledger Fabric is a nice DLT platform and offers great customization options. One of which is the ability to choose different databases to store blockchain data. The recommended and best supported option is to use a CouchDB. It offers the ability to use complex queries on the blockchain data via Hyperledger Fabric Chaincode via different programming languages like go, JavaScript or Java. To find out more about Hyperledger with CouchDB take a look at the <a href="https://hyperledger-fabric.readthedocs.io/en/release-1.4/couchdb_tutorial.html">offical documentation</a> .</span></p><p><span>In the picture below you can see the CouchDB overview of an example Hyperledger Fabric node with one channel “compactionchannel” and the chaincode “cdbc”. This is just an example to demonstrate the CouchDB structure and doesn’t contain much data.</span><a href="https://media.graphassets.com/U9K64D7cRDCHs2s9yICr"><img title src="https://media.graphassets.com/U9K64D7cRDCHs2s9yICr" alt="CouchDb overview for Hyperledger" width="700" height="162" /></a> </p><p><span>Blockchains like Hyperledger store data indefinitely and so the overall amount only increases. To enable the mentioned complex queries the current “world state” is represented in CouchDB. When data changes the corresponding “world state” also changes – CouchDB only appends the new value to its internal representation. Normally the automatic compaction would remove unused data continuously and keep the size of the database small. </span></p><p><span>In some circumstances the automatic compaction will not start. We encountered this situation at one of our customers. This lead to continuous growth of the database and tons of unnecessary GBs of storage. In this case you have two options, reconfigure the automation trigger or start the compaction manually.</span></p><h2>Status of your Hyperledger CouchDB compaction</h2><p><span>You can query your compaction configuration with the following command:</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" http://<CouchDB>:5984/_node/nonode@nohost/_config

{
  ...
  "compactions": {
    "_default": "[{db_fragmentation, \"30%\"}, {view_fragmentation, \"30%\"}]"
  },
  "compaction_daemon": {
    "check_interval": "300",
    "min_file_size": "256000"
  }
}

```

<h3>Manual compaction</h3><p><span>You can start the compaction manually via the following REST command.</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" -X POST http://<CouchDB>:5984/<channel-name>_<chaincode>/_compact

{"ok":true}

```

<p><span>To check the process of compaction:</span></p>

```
$ curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic_Auth>" http://<CouchDB>:5984/<channel-name>_<chaincode>

{
  ...
  "compaction_running": true,
  ...
}

```

<p><span>Furthermore not only the database but also views can be compacted. To do so another REST call can be used.</span></p>

```
curl -H "Content-Type: application/json" -H "Authorization: Basic <Basic-Auth>" -X POST http://<CouchDB>:5984/<channel-name>_<chaincode>/_compact/<view-name>

{"ok":true}

```

<p><span>Depending on the size of the Hyperledger Fabric database or view the compaction can take quite some time.</span></p><p>Detailed information about CouchDB compaction can be found in the <a href="https://docs.couchdb.org/en/stable/maintenance/compaction.html">compaction page</a>  of the official documentation. The German version of this post can be found <a href="/wissens-hub/blog/hyperledger-fabric-couchdb-laesst-meine-cloud-rechnung-explodieren">here</a> .</p>

Hyperledger Fabric CouchDB is killing my cloud storage bills

Senior IT-Berater

People Solutions Partnerin Frankfurt

Constanze Thomas, People Solutions Partnerin Frankfurt, codecentric AG

IT consultant (Frontend)

IT-Consultant & Developer

Office Management

Frankfurt am Main | 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 Frankfurt

Jetzt für unseren Newsletter anmelden