Cloud-Native

Data & KI

Produktentwicklung

Resilienz & IT-Security

Leistungen

Arbeitsweise

Projekte

Berlin

Bielefeld

Dortmund

Erfurt

Frankfurt am Main

Hamburg

Karlsruhe

Leipzig

München

Münster

Nürnberg

Solingen

Stuttgart

Standorte

Blog

Softwerker

Fachmedien

Webinare

Events

Wissens-Hub

Unsere Kultur

Deine Entwicklung

Jobs

Karriere

Über uns

Aktuelles

Kontakt

International contact

Alle Standorte

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

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/gxJl5zQzRpGyPUbS59zS"><img width="700" height="174" src="https://media.graphassets.com/gxJl5zQzRpGyPUbS59zS" 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/8AMEIWaPRhGC9O7fBQ97"><img loading="lazy" width="700" height="462" src="https://media.graphassets.com/8AMEIWaPRhGC9O7fBQ97" 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/rmZ74i1Tki4RbXkfK3CA"><img loading="lazy" width="700" height="334" src="https://media.graphassets.com/rmZ74i1Tki4RbXkfK3CA" 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/qKQKQD9RHmU4U3XA4DDQ"><img loading="lazy" width="250" height="635" src="https://media.graphassets.com/qKQKQD9RHmU4U3XA4DDQ" 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/ggaN8uPQBecJN41zL8VK)

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/ucGhioSqyN8puFwAVsCg)

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 

IT Consultant & 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/K9pYN0ZQnK83YwtV1k8Z"><img src="https://media.graphassets.com/K9pYN0ZQnK83YwtV1k8Z" 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/qTmC9u2TM2zsgNlRdzNw" 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/axm9xuktS7S1BixGhgHk"> </p><p> </p><p>Weiterführende Links für die heutige Folge mit Nils Wloka:</p><p><a href="https://www.codecentric.de/leistungen/loesungen/wir-bauen-erfolgreiche-software/digitization-labs/">Die codecentric Digitization Labs</a>  bieten die Möglichkeit, digitale Produktideen<br /> unmittelbar mittels Software zu validieren.</p><p><a href="https://info.codecentric.de/sw-spezial-digitalisierung">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/Fo2aM7UISleN8QNaTdXn" 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/axm9xuktS7S1BixGhgHk"> </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/iVgg7CztQkWApAYjV8Y8" 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/axm9xuktS7S1BixGhgHk"> </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="https://blog.codecentric.de/2017/09/fraud-analyse-mit-data-science-techniken/">Fraud-Analyse mit Data-Science-Techniken von Shirin Glander</a> </p><p><a href="https://blog.codecentric.de/2017/03/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/DkCU3cx8SWKyntDS5UAg" 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/axm9xuktS7S1BixGhgHk">
<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/iCFeWrFZRHe5VDPDeNua" 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/axm9xuktS7S1BixGhgHk">
 <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/U2zHb8vRz64i8IftUViL" 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/axm9xuktS7S1BixGhgHk">
 </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

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](/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](/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 q: 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 q: Quotes)(
  tree: quotes.reflect.Definition
): List[quotes.reflect.Definition] = {
  import q.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](/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

Backend 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/dCcEXE76Sry07IprBnFM"><img src="https://media.graphassets.com/dCcEXE76Sry07IprBnFM" 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/nQlX4jEsQK6NCtabk45Q"><img loading="lazy" src="https://media.graphassets.com/nQlX4jEsQK6NCtabk45Q" 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/pmb5PQinRL6YYjgW2IIg"><img loading="lazy" src="https://media.graphassets.com/pmb5PQinRL6YYjgW2IIg" 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="https://blog.codecentric.de/2020/03/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/2ytsF8sJQVShhXRW7bw3"><img loading="lazy" src="https://media.graphassets.com/2ytsF8sJQVShhXRW7bw3" 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/0SMIWxylS1C2Kwmws2zN"><img loading="lazy" src="https://media.graphassets.com/0SMIWxylS1C2Kwmws2zN" 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/ktPI88BJSmC5Ogjl9LA6"><img loading="lazy" src="https://media.graphassets.com/ktPI88BJSmC5Ogjl9LA6" 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/D90bLA51SCGe9TfeDg4A"><img loading="lazy" src="https://media.graphassets.com/D90bLA51SCGe9TfeDg4A" 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/vcASUP2US3ypx1fWG0x6"><img src="https://media.graphassets.com/vcASUP2US3ypx1fWG0x6" 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/TcK4szlwRg2bBnWxfRXX"><img loading="lazy" src="https://media.graphassets.com/TcK4szlwRg2bBnWxfRXX" 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/VTdOSJtJQeiS1WqvFls9"><img loading="lazy" src="https://media.graphassets.com/VTdOSJtJQeiS1WqvFls9" 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/sVvcOf0SgiV23REl1cib"><img loading="lazy" src="https://media.graphassets.com/sVvcOf0SgiV23REl1cib" 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/oEQjn2jRbq6UtqaQlPLf"><img loading="lazy" src="https://media.graphassets.com/oEQjn2jRbq6UtqaQlPLf" 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://blog.codecentric.de/files/2020/02/break_unsplash_alex-scaled.jpeg"><img loading="lazy" src="https://media.graphassets.com/hLRSuRTtSsyMGTgQQsIZ" 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/Tt1WsMZmRXqkIkE4VKy0"><img loading="lazy" width="250" height="117" src="https://media.graphassets.com/Tt1WsMZmRXqkIkE4VKy0" 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/aLFbgfSTSeKvUiNeZHiY"><img loading="lazy" width="250" height="125" src="https://media.graphassets.com/aLFbgfSTSeKvUiNeZHiY" 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/EcCuXNZcSF2VpSwJA6Nk"><img loading="lazy" width="250" height="116" src="https://media.graphassets.com/EcCuXNZcSF2VpSwJA6Nk" 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/SrV9dxGXSGyzdVIp9Add"><img loading="lazy" width="250" height="101" src="https://media.graphassets.com/SrV9dxGXSGyzdVIp9Add" 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/KFqQBkvTTfqLFBKTqnyM"><img loading="lazy" width="250" height="100" src="https://media.graphassets.com/KFqQBkvTTfqLFBKTqnyM" 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/5tS8fye9Qjmn0EXwcxw7"><img loading="lazy" width="250" height="115" src="https://media.graphassets.com/5tS8fye9Qjmn0EXwcxw7" 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/qBaDhPZkS7ux2HNwRiRK"><img loading="lazy" src="https://media.graphassets.com/qBaDhPZkS7ux2HNwRiRK" 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/8Ysta1r5TZWw3MBAoSB1"><img src="https://media.graphassets.com/8Ysta1r5TZWw3MBAoSB1" 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 <a href="https://blog.codecentric.de/en/author/florian-schneider/">Florian Schneider</a> .</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/pxV941eXSZGsMx24wKcI"><img loading="lazy" src="https://media.graphassets.com/pxV941eXSZGsMx24wKcI" 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/19egvtXbS3mS0oIQqVva"><img loading="lazy" src="https://media.graphassets.com/19egvtXbS3mS0oIQqVva" 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/vcASUP2US3ypx1fWG0x6"><img src="https://media.graphassets.com/vcASUP2US3ypx1fWG0x6" 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/TcK4szlwRg2bBnWxfRXX"><img loading="lazy" src="https://media.graphassets.com/TcK4szlwRg2bBnWxfRXX" 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/VTdOSJtJQeiS1WqvFls9"><img loading="lazy" src="https://media.graphassets.com/VTdOSJtJQeiS1WqvFls9" 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/sVvcOf0SgiV23REl1cib"><img loading="lazy" src="https://media.graphassets.com/sVvcOf0SgiV23REl1cib" 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/oEQjn2jRbq6UtqaQlPLf"><img loading="lazy" src="https://media.graphassets.com/oEQjn2jRbq6UtqaQlPLf" 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/hLRSuRTtSsyMGTgQQsIZ"><img loading="lazy" src="https://media.graphassets.com/hLRSuRTtSsyMGTgQQsIZ" 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://blog.codecentric.de/files/2020/02/break_unsplash_alex-scaled.jpeg"><img loading="lazy" src="https://media.graphassets.com/Tt1WsMZmRXqkIkE4VKy0" 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/aLFbgfSTSeKvUiNeZHiY"><img loading="lazy" src="https://media.graphassets.com/aLFbgfSTSeKvUiNeZHiY" 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/EcCuXNZcSF2VpSwJA6Nk"><img loading="lazy" src="https://media.graphassets.com/EcCuXNZcSF2VpSwJA6Nk" 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/SrV9dxGXSGyzdVIp9Add"><img loading="lazy" src="https://media.graphassets.com/SrV9dxGXSGyzdVIp9Add" 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/KFqQBkvTTfqLFBKTqnyM"><img loading="lazy" width="250" height="101" src="https://media.graphassets.com/KFqQBkvTTfqLFBKTqnyM" 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/5tS8fye9Qjmn0EXwcxw7"><img loading="lazy" width="250" height="100" src="https://media.graphassets.com/5tS8fye9Qjmn0EXwcxw7" 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/qBaDhPZkS7ux2HNwRiRK"><img loading="lazy" width="250" height="115" src="https://media.graphassets.com/qBaDhPZkS7ux2HNwRiRK" 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/JH8qK7MYRqiTgqGXXrdz"><img loading="lazy" src="https://media.graphassets.com/JH8qK7MYRqiTgqGXXrdz" 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

Software Team Enabler

<div><a href="https://media.graphassets.com/GkggFAqFTpORBnSMauzP"><img loading="lazy" title="MongoDB World Tour 2012" src="https://media.graphassets.com/GkggFAqFTpORBnSMauzP" 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 <a href="https://www.xing.com/net/mongodb-dus/" target="_blank">Düsseldorf</a>  und <a href="https://www.xing.com/net/mongodb-ffm/" target="_blank">Frankfurt</a>  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/VpBmiVWnQlCtaeofKERz"><img loading="lazy" title="Tobias Trelle @ MongoDB Munich 2012" src="https://media.graphassets.com/VpBmiVWnQlCtaeofKERz" 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/w0C4Ks3zTpWZoKYNbHlX"><img loading="lazy" title="Uwe Seiler @ MongoDB Munich 2012" src="https://media.graphassets.com/w0C4Ks3zTpWZoKYNbHlX" 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/hgcwTLzcRdsIRhS4l4gr"><img loading="lazy" title="Highlights of MongoDB 2.4" src="https://media.graphassets.com/hgcwTLzcRdsIRhS4l4gr" 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="http://blog.codecentric.de/2012/02/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/yTym55CRS8euH6hl7vGj"><img loading="lazy" title="Title Image MongoDB User-Gruppe Frankfurt" src="https://media.graphassets.com/yTym55CRS8euH6hl7vGj" 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 <a href="https://www.xing.com/net/mongodb-dus/" target="_blank">MongoDB User-Gruppe in Düsseldorf</a> , 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>Die Homepage der Frankfurter MongoDB User-Gruppe finden Sie unter:</p><p><a href="https://www.xing.com/net/mongodb-ffm/" target="_blank"><img loading="lazy" title="Logo MongoDB User-Gruppe Frankfurt" src="https://media.graphassets.com/IBI3WCRLuBnwnszXZMg6" alt="Logo MongoDB User-Gruppe Frankfurt" width="233" height="69" /></a> </p><p><a href="https://www.xing.com/net/mongodb-ffm/" target="_blank">https://www.xing.com/net/mongodb-ffm/</a> </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/cWLHqLF7R8aKSDFMKQVV"><img src="https://media.graphassets.com/cWLHqLF7R8aKSDFMKQVV" 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/MoShsXHzSBmzqYqdTqXX"><img loading="lazy" src="https://media.graphassets.com/MoShsXHzSBmzqYqdTqXX" 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/WmDO87qCRGCt4Wzq7bIQ"><img loading="lazy" src="https://media.graphassets.com/WmDO87qCRGCt4Wzq7bIQ" 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/Yfa3iwKR3aOXENNKZs9r"><img loading="lazy" src="https://media.graphassets.com/Yfa3iwKR3aOXENNKZs9r" 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="http://blog.codecentric.de/2013/08/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 <a href="https://www.xing.com/net/hugrheinmain/">User Groups</a> , 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="http://blog.codecentric.de/2013/08/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)

<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/lHJNctzSDW4bFFAzs7og"><img src="https://media.graphassets.com/lHJNctzSDW4bFFAzs7og" 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/qTyIY1lWRxqc6e69UjXJ"><img loading="lazy" src="https://media.graphassets.com/qTyIY1lWRxqc6e69UjXJ" 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/C2QFARBTHWegsKsAHgYa" 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="https://blog.codecentric.de/2019/04/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="https://blog.codecentric.de/2019/11/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/cWk2CuWoRf29n61jPRdm"><img src="https://media.graphassets.com/cWk2CuWoRf29n61jPRdm" 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/3o6uPaOMQQCgddG6mdeO"><img loading="lazy" width="250" height="287" src="https://media.graphassets.com/3o6uPaOMQQCgddG6mdeO" alt="Components overview" /></a> </span></p><h3><span>What is Apache PLC4X?</span></h3><p><span><a href="https://blog.codecentric.de/en/2019/04/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="https://blog.codecentric.de/2019/10/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/a3w8yNurTpaWBkNN35rN"><img loading="lazy" width="250" height="260" src="https://media.graphassets.com/a3w8yNurTpaWBkNN35rN" 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/CzKp9CB0TOW4jYD72DdE"><img loading="lazy" width="250" height="129" src="https://media.graphassets.com/CzKp9CB0TOW4jYD72DdE" 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/3lW9OUX9R2auqLFTxzAr"><img loading="lazy" width="250" height="129" src="https://media.graphassets.com/3lW9OUX9R2auqLFTxzAr" 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/qDFzprrZRYqAPVWhOGqi"><img loading="lazy" width="250" height="137" src="https://media.graphassets.com/qDFzprrZRYqAPVWhOGqi" 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/roQ9ZllwQaO8YIh5d5gs"><img loading="lazy" width="250" height="208" src="https://media.graphassets.com/roQ9ZllwQaO8YIh5d5gs" 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

Senior Development Consultant

Office Managerin

Business Consultant & Agile Coach

Software Developer and Consultant

Software Developer

IT-Berater

Infrastructure as Code in AWS: Keine Silver Bullet

<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/cUr2EjBkSay73HBAqJ9L" 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/VGkL9FpdRnmzKeP7k01U" alt="docker inspect" /></p><p><img loading="lazy" width="1736" height="422" src="https://media.graphassets.com/AjA1WfzCTZiTmLjCYGRy" 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/UQ1dyYNjQ6mEboG615Sm"><img width="1461" height="767" src="https://media.graphassets.com/UQ1dyYNjQ6mEboG615Sm" 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

Senior Software Engineer


> 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

<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/QHjlhPSQuiHC2P3Q2QqW"><img src="https://media.graphassets.com/QHjlhPSQuiHC2P3Q2QqW" 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/T0Jmv5Sp28pXEWlGVb1w"><img loading="lazy" src="https://media.graphassets.com/T0Jmv5Sp28pXEWlGVb1w" 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/VKCb1HQfR6GFi4arY9DW"><img loading="lazy" src="https://media.graphassets.com/VKCb1HQfR6GFi4arY9DW" 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/QHjlhPSQuiHC2P3Q2QqW"><img src="https://media.graphassets.com/QHjlhPSQuiHC2P3Q2QqW" 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/T0Jmv5Sp28pXEWlGVb1w" 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/VKCb1HQfR6GFi4arY9DW"><img loading="lazy" src="https://media.graphassets.com/VKCb1HQfR6GFi4arY9DW" 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/W8msC3eeS8Wnf1W6mriT"><img width="417" height="204" src="https://media.graphassets.com/W8msC3eeS8Wnf1W6mriT" 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/W8msC3eeS8Wnf1W6mriT"><img width="417" height="204" src="https://media.graphassets.com/W8msC3eeS8Wnf1W6mriT" 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/VQZHRUlaRKCGkiNwOU79"><img width="550" height="154" src="https://media.graphassets.com/VQZHRUlaRKCGkiNwOU79" 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/EqF4UHGnRdGJW18Bl61S"><img loading="lazy" width="700" height="196" src="https://media.graphassets.com/EqF4UHGnRdGJW18Bl61S" 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/u4LNM8MGT6WRDKC9LRGP"><img loading="lazy" width="450" height="224" src="https://media.graphassets.com/u4LNM8MGT6WRDKC9LRGP" 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

Scrum Master & Agile Consultant

## Overview

We walk through the process of digitally synthesizing a White Noise sound. To begin we provide the audible outcome, general context and motivation. Then technical information and coding samples follow.

![generated-noise.jpg](https://media.graphassets.com/CXYf6EZITM6lx8MnWKey)

## Contents

* [What Is White Noise?](#1)
* [How Does It Sound Like?](#2)
* [Noise and Pure Waves](#3)
* [Applications](#4)
* [Randomness and Independence](#6)
* [Code Samples](#6.1)
* [Audio Stream](#7)
* [WAV File Header](#10)
* [WAV File](#11)
* [Summary](#12)

## <a name="1">What Is White Noise?</a>

Noise is a special kind of signal. As an audio signal it is neither just a high nor just a low sound but a mixture of a lot of frequencies. White noise contains all audible frequencies from lowest to highest. It is named in analogy with white light which is a mixture of all visible wavelengths of light. The picture of a prism breaking up white light into its colour components illustrates this well. 

![prism-breaks-light.png](https://media.graphassets.com/ynNbODztQWm1rFi4vgeA)

## <a name="2">How Does It Sound Like?</a>

What does white noise sound Like? You already know sounds similar to white noise. It's reminiscent of rain and ocean waves. Sounds of wind and rustling of leaves are also noisy in our sense and can be very enjoyable nonetheless. Here are three examples of noise-like sound.

Rain

<audio controls>
  <source src="https://media.graphassets.com/WUR0mR0QPaREDKAtCWaq" />
</audio>

Flowing Air

<audio controls>
  <source src="https://media.graphassets.com/IDXFPjLuSIaHzqHdCggz" />
</audio>

Flowing Water

<audio controls>
  <source src="https://media.graphassets.com/PLwK2lFT42SiryFB2zJO" />
</audio>

## <a name="3">Noise and Pure Waves</a>

White Noise contains all frequencies at once. It corresponds to the beam of white light that enters the prism in our introductory image. The opposite extreme is a single selected frequency only. It corresponds to one of the coloured light components that leave the prism separately. These two sounds are nothing alike. Have a listen to a single frequency wave in contrast to white noise. 

Sine Wave

<audio controls>
  <source src="https://media.graphassets.com/9OySir8Se4x2DJDPDJAM" />
</audio>

White Noise

<audio controls>
  <source src="https://media.graphassets.com/cELPs4aRBin0LBjlHOLV" />
</audio>

Their waveforms look very different too. To generate white noise, we will use a random stream of bits. For the sound of a pure frequency a sine wave would have to be encoded instead. 

Sine Waveform

![sine-wave.png](https://media.graphassets.com/qeVbMMRDuvJVU6GcPXYA)

Random Waveform

![random-waveform3.png](https://media.graphassets.com/5oWLlfkRweZOuKdNyfhR)

## <a name="4">Applications</a>

White noise is used as a test signal by audio engineers. The signal to noise ratio is a key measurement in signal processing. Audiophiles care a lot about the signal to noise ratio. Some people swear by noise sounds as a sleeping aid or for relaxation. Others feel it helps with concentrated work and improves focus. It is even used for masking tinnitus. White noise is a fundamental building block of both analogue and digital synthesizers for musical and more general sound design. It can be shaped into snare and hi-hat drum sounds for example.

## <a name="6">Randomness and Independence</a>

We generate the white noise sound digitally from scratch. To do so we build a signal in which each data point bears no connection to its previous data points. Each point is independent from rest of data points. This contrasts the case of a pure sine wave in which you can predict the continuation of the periodic wave once you know its general form. A random signal with uniformly distributed amplitude features the characteristics we need.

## <a name="6.1">Code Samples</a>

The code samples are given in C++ as it is widely used in audio applications and digital signal processing. If you would like to see the code in a different language, we encourage you to do the transfer. The general ideas and concepts remain the same.

## <a name="7">Audio Stream</a>

The C++ standard library provides us with a number generator that produces a uniformly distributed sequence of values. The `default_random_engine` is to be found in `<random>`.

```cpp
random_chars_engine engine = 
    independent_bits_engine<default_random_engine, CHAR_BIT, unsigned char>;
```

We wrap the `default_random_engine` in a `independent_bits_engine` to take control of the type of values that are generated. We would like to obtain byte sized values. A standard engine produces unsigned integer types so choose `unsigned char`. `CHAR_BIT` is the number of bits that is used to represent values of this type. It specifies that all bits of the generated values shall become random. If we had chosen a smaller number, the remaining bits would always be zero. 

```cpp
vector<unsigned char> audioStream(bytesPerSecond*lengthOfAudioInSeconds);
```

The vector `data` is our container for the values we generate with the `random_chars_engine`. Let us assume that `bytesPerSecond` is the number of bytes that are used to encode one second of audible audio and that the size of `unsigned char` is one byte. To contain the data for an audio clip of a duration `lengthOfAudioInSeconds` we choose the length of the vector `data` to be `bytesPerSecond*lengthOfAudioInSeconds`.

```cpp
generate(begin(audioStream), end(audioStream), ref(engine));
```

We have prepared a `random_chars_engine` as a generator of random values and a suitable `vector` as a container to receive the generated values. The helper function `generate` now fills the container `data` from beginning to end with values from the `random_chars_engine` called `engine`. 

```cpp
random_bytes_engine engine = 
independent_bits_engine<default_random_engine, CHAR_BIT, unsigned char>;
vector<unsigned char> audioStream(bytesPerSecond*lengthOfAudioInSeconds);
generate(begin(audioStream), end(audioStream), ref(engine));
```

This results in a vector filled with random values of type 'unsigned char' such that their combined binary representation encodes an audio stream of our desired duration. 

We will write this binary representation to a file eventually. This bitstream is to be played back by a media application as the sound it was meant to represent that is as white noise in our case.

## <a name="10">WAV Header</a>

Common media players as are not meant to play back a raw bitstream of encoded audio data. To handle it additional information about how to interpret the bitstream are in order. We package the necessary additional metadata together with the raw random bitstream as a WAV (Waveform Audio) file. As such the WAV file is suitable for play back via common media applications. Here we need to take care of the details to satisfy the WAV file format specification. Otherwise upon violation media players may reject the WAV file as invalid and rightfully so. The technical details follow.

We represent the necessary metadata as a `struct` in C++ code. It contains the information that make up the metadata.

```cpp
typedef struct WAV_HEADER {
    uint8_t RIFF[4] = {'R', 'I', 'F', 'F'};
    uint32_t ChunkSize;
    uint8_t WAVE[4] = {'W', 'A', 'V', 'E'};

    uint8_t fmt[4] = {'f', 'm', 't', ' '};
    uint32_t Subchunk1Size = 16;
    uint16_t AudioFormat = 1;
    uint16_t NumOfChan = 1;
    uint32_t SamplesPerSec = 44100;
    uint32_t bytesPerSec = 44100 * 3;
    uint16_t blockAlign = 2;
    uint16_t bitsPerSample = 24;

    uint8_t Subchunk2ID[4] = {'d', 'a', 't', 'a'};
    uint32_t Subchunk2Size;
} wav_header;
```

The WAV file format tells us what information is necessary as metadata and how many bytes each piece of information should occupy. 

The WAV file header is structured into a main chunk `RIFF` that contains two subchunks 'fmt' and 'data'. Each chunk or subchunk has a name and a size. The names of C++'s fixed integer types `uint8_t`, `uint16_t` and `uint32_t` indicate their respective sizes in bits. These types are used to represent integers as well as characters. We use these types to guarantee that their assigned values occupy the correct number of bytes for the WAV file header to be valid. 

A WAV file is a special kind of RIFF file. To be a valid RIFF file it has to start with the four bytes that make up the chunk name `RIFF`. Next the 'ChunkSize' of the RIFF-chunk is given. It has to contain the size of the remaining header plus the size of the audio bit stream that follows the header in the WAV file. We will fill in this value once we have these sizes at hand. Then the specific kind of the RIFF file is given which is 'WAVE' in case of a WAV file.

Next The first of two subchunks begins. The name of the `fmt` subchunk contains a space since it needs to occupy four bytes to be in accordance with the specification. The size of the `fmt` subchunk is given as 'Subchunk1Size'. The following six entries are concerned with the details of digital representation of audio data. There are different ways to digitally represent audio data, but we choose the canonical uncompressed format LPCM (Linear Pulse Code Modulation) which is what the value `1` of `AudioFormat` stands for. By setting 'NumOfChannels' to one we state that our bit stream will represent a mono audio signal. 'SamplesPerSecond' is the number of data points within a duration of one second that are described by our bit stream and 'bitsPerSample' is the number of bits used for the description of one such data point. The value of 'bytesPerSec' result from the values of 'NumOfChan', 'bitsPerSample' and 'SamplesPerSec'. 'blockAlign' is the number of bytes in a sample across all channels. Its value is derived from 'NumOfChan' and 'bitsPerSample'. 
  
The second and last subchunk 'data' again has a name and a size. Its size is the size of the audio bit stream that follows the header in the WAV file. 

To complete the WAV file header, we now set the remaining values that depend on the size of the audio stream and the size of the header itself.
```cpp
wav_header meta_data;
meta_data.ChunkSize = audioStreamSize + sizeof(wav_header) - 8;
meta_data.Subchunk2Size = audioStreamSize;
```

## <a name="11">WAV File</a>

We have prepared both the audio bitstream and the WAV file header. The two parts combined comprise the WAV file.

![wav-file-container-2.png](https://media.graphassets.com/SDy5UD9dQo6nofDY9E7y)

The header and audio stream can be written to the WAV file as follows.

```cpp
out.write(reinterpret_cast<char *>(&meta_data), sizeof(meta_data));
out.write(reinterpret_cast<char *>(&audioStream[0]), audioStream.size());
```
## <a name="11.1">Modifications</a>

Modifications of bit depths and sample rate lead variations in sound. Feel free to go extremely low for a pronounced effect. A stereo white noise signal will also sound different. For this to work make sure to generate different white noise signals for the right and left channels as our random engine as it stands will produce exactly the same data again when used a second time which is not what you want for the stereo case.

## <a name="12">Summary</a>

We got to know the idea and concept of noise in general and more specifically white noise. Then we saw how its sound information can be represented as random data. We added metadata and packaged it together with the audio bitstream as a WAV file for play back.

Synthesize White Noise

Agile Coach/ Scrum Coach

Infrastructure & DevOps Consultant

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

From Keycloak to Keycloak.X

Keycloak.X, but secure – without vulnerable libraries

IAM Consultant

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.

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.

Ich habe die \nDatenschutzbestimmungen\n und die Einwilligung in die Datenverarbeitung gelesen und stimme diesen zu.*

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.

Kontakt

Absenden

Willkommen im Team Frankfurt

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Unsere Leistungen

Hilf uns, noch besser zu werden.

Zu den Jobangeboten