Die wachsende Komplexität von Geschäfts- und Internetanwendungen und gestiegenen Erwartungen an die Agilität der Entwicklung verlangen einen neuen, effizienteren Ansatz zur Systementwicklung im Team. Automatisierung in hochskalierenden Umgebungen werden vom üblichen Push-Deployment-Ansatz ausgebremst. Das z2-Environment addressiert beide Problembereiche.

1. Buildfrei skalieren für Big Data mit Z2
Henning Blohm
ZFabrik Software KG
5.6.2013
1

2. Teil 1:
Buildfrei entwickeln und skalieren
Teil 2:
Big Data, Cloud, und wie es zusammenpasst
2

3. 1. Teil
BUILDFREI ENTWICKELN UND
SKALIEREN
3

4. Masterfrage:
Warum braucht man mehr als das?
Source code and
configuration
Execution Environment
4

5. Bzw. wäre es nicht schön…







wenn große Projekte so einfach zu ändern wären wie kleine?
wenn Hotfixes ohne Build & Deployment gingen?
keinen lokalen Build haben zu müssen?
wenn Integration auf Knopfdruck ginge?
keinen Appserver installieren zu müssen?
nicht mehr deployen zu müssen?
wenn Java mit den Roundtripzeiten von Skripten ginge?
5

6. So funktioniert Z2
Z2-Environment:
■ Pull von verschiedenen Quellen
■ Tut was nötig ist (inkl. Kompilation)
6

7. Entwickeln mit Z2
7

8. Ausskalieren mit Z2
Siehe auch http://www.z2-environment.net/blog/2013/01/z2-deployment-potpourri/
8

9. Vorteile
■
Kein build engineering
Keine lokale build config, schnelles setup
Keine Build-Infrastruktur!
■
Kleine Checkouts, kein Deployment
Weniger re-compiling, schnelle roundtrips
■
System-zentrisch
Immer aktuell, immer integriert
■
Pull-Ansatz
Einfacher Scale-out
9

10. Einsparungen*
Pro Entwickler:
Kleines Entwicklungsteam
<=10
Grosses Entwicklungsteam
> 10
Lokale Buildkonfiguration
2%
1%
Integration mit Änderungen (sync,. build, re-deployment)
5%
10%
Kommunikation mit Build-Engineer, Anpassen von zentralem
Build
2%
4%
Summe
9%
15%
* geschätzt
10

11. Weitere Zutaten
■
Add-On Repositories erweitern Fähigkeiten
Spring, Hadoop, Vaadin, …
■
Klares, einfaches Modularisierungskonzept
Trennung von API und Implementierung
■
Erprobte Architektur
Für z. B. modularisierte Spring/Hibernate Anwendungen
11

12. Update einer Web Anwendung
ERSTE DEMO
12

13. Welches Problem wird denn hier eigentlich
gelöst?
13

14. Wenn es größer und modular wird:
Projekt- und Repositorystruktur
≠
Ausführungs- & Deploymentmodell
=>
14

15. Mit anderen Worten:
Die beiden verstehen sich
nicht.
Deshalb die ganze
Maschinerie!
15

16. 2.1. Teil
BIG DATA MACHT SINN, WENN…
16

17. Entscheidungswege NoSQL*
Dokumentenartig
Graphen
Dokumente
/ Blobs
Nicht-relationale
Daten
“Zuviele” Daten
Kein RDBMS, weil…
* brutal simplifiziert
Tabellen
artig (Big
Table)
17

18. Zuviele Daten?
Problem ist hierbei in der Regel nicht primär die
Ablage, sondern die effiziente Analyse.
Hier gilt:
■
■
Parallelisierung ausnutzen, um O(1) zu bleiben
Lokales streamen > verteilter Query
=> Der Klassiker: Map/Reduce
18

19. Problemstellung:
Wie kommt der Code zum Knoten?
Was kann der Code dort machen?
19

20. Alternativen:
■
Nativ: Map/Reduce API, jar bauen, deploy
Sehr bare-metal. Kein Container-support
■
Vielleich andere Sprache benutzen - Z. B. Pig
oder JavaScript M/R?
Gut weil einfacher – aber eingeschränkt!
20

21. Mit z2@hadoop
Hadoop wird natürlicher Teil der Lösung:
■
Ausführung von Z2 in embedded mode als Hadoop task
■
M/R Job „lebt“ im gleichen Modulraum wie der Rest der Lösung
■
Einfachstes Job scheduling: Ohne build und programmatisch
21

22. Update und Ausführung eines Map/Reduce Jobs
ZWEITE DEMO
22

23. 2.2. Teil
UND JETZT ALLE ZUSAMMEN
23

24. Cloud-Provisionierungs-Rezept
■
Knotentypen definieren
Frontend, Datenknoten, Masterknoten, RDBMS,…
Diese müssen vollautomatisch am Leben gehalten werden
■
Welche sind Skalierungsrelevant?
Frontend, Datenknoten
Diese müssen vollautomatisch installierbar sein
■
Konfiguration mit Policies:
■
■
Alle Konfiguration zentral im SCM
Alle paar Minuten überprüfung der Knotenpolicy
24

25. Provisionierung mit CfEngine+Z2
Bemerke: Der Pull Ansatz zieht immer alles gerade!
25

26. Push der Änderungen ins Produktivsystem
DRITTE DEMO
26

27. Z2 ist Open Source Software!
Interessiert? Ideen?
Wir zeigen gerne mehr Details vor Ort
Bitte einfach bei contact@zfabrik.de melden
27

28. Hier geht’s weiter:
Wiki:
redmine.z2-environment.net
Blog:
www.z2-environment.net/blog
Site:
www.z2-environment.eu
28

29. Abstract
Die wachsende Komplexität von Geschäfts- und Internetanwendungen und gestiegenen Erwartungen an die Agilität der Entwicklung haben
in den letzten Jahren zu einer beeindruckenden Entwicklung im Bereich der Build- und Integrationswerkzeuge geführt.
Mit Ansätzen wie Continuous Delivery über eine Tool Chain aus Continuous Integration Servern, Artefact Repositories und Build-Werkzeugen
wie Maven gelingt es, vollständige Build- und Testautomatisierung für Java-basierte Software-Lösungen zu erreichen.
Mit den Anforderungen an massive und flexible Skalierung in Cloud und Big Data Szenarien hat sich ein weiteres Problemfeld aufgetan:
Automatische Verteilung und Konfiguration von Software im Großen. Hier finden Configuration Management Werkzeuge wie Apache Puppet
und CFEngine ihre Anwendung.
Die Automatisierung hat allerdings ihren Preis: Je mehr Komplexität in die Werkzeuge wandert, desto Fehleranfälliger wird der Prozess,
desto schwieriger wird es, strukturelle Änderungen der Software vorzunehmen.
Dies trifft insbesondere auf den traditionellen „Push“-Deploymentansatz in der Java Entwicklung zu. Ändert sich die Menge der Deployables,
so ergeben sich häufig auch nicht-triviale Änderungen entlang der gesamten Prozesskette – vom Entwickler bis zur Konfiguration der
Produktivsysteme. Kann die Laufzeitumgebung sich aber selber an Änderungen von Quellen und Konfiguration seiner Systemdefinition
anpassen, so entfällt nicht nur ein Großteil der Produktionsinfrastruktur, es werden auch Entwicklungszyklen beschleunigt und frühe
Integration gefördert.
Die Open-Source Umgebung z2-Environment implementiert einen solchen “Systemzentrischen” Ansatz, der keine Build-Infrastruktur
benötigt, Entwicklersetup minimiert und gleichzeitig Deployment-Updates dramatisch vereinfacht und beschleunigt.
Ein solcher Pull-Deployment Ansatz bewährt sich auch bei der Entwicklung und Ausführung von verteilten Map-Reduce Algorithmen, da kein
gesondertes Deployment mehr vonnöten ist und JobImplementierungen mit anderen Anwendungskomponenten gleichgestellt sind. Da
keine Applikationskomponenten zu verteilen sind wird auch die automatische Konfiguration mit Hilfe von Configuration Management
Werkzeugen einfacher und robuster.
Der Vortrag enthält eine Live-Demonstration auf Basis von CFEngine, Z2 und Apache Hadoop.