Eindrücke von der jbcnconf 2015

Die Konferenz ist vorbei und ich bin sicher wieder zuhause angekommen.
Ich versuche mal die Erinnerungen festzuhalten und hier aufzuschreiben.
Ein paar Fotos sind auch dabei.

Tag 0

Da ich einen Direktflug haben wollte, bin ich bereits einen Tag vor der
Konferenz in Barcelona angekommen. Den ersten Abend hab ich damit
verbracht, meine Sachen im Hotel abzuwerfen und anschliessend mit der
Metro zum Hafen zu fahren. Natürlich wollte ich mir den Strand und das
Meer angucken. Die Fahrt dorthin hat länger gedauert als ich dachte, vor
allem der Fussweg nach der Metro war deutlich länger als erwartet.
Anscheinend habe ich die Entfernungen auf der Karte unterschätzt,
obwohl ich mir per Google Maps die Fussweg-Routen habe anzeigen lassen.
Na gut, nachdem ich in einem Restaurant in Strandnähe etwas gegessen
habe, bin ich noch kurz den Strand entlanggelaufen und musste dann auch
schon wieder zurück in die Metro. Ziemlich müde bin ich dann im Hotel
angekommen und bei (fast) unerträglicher Hitze irgendwann eingeschlafen.

To the beach. #Barcelona IMG_20150625_205008 IMG_20150625_195720 IMG_20150626_075547 IMG_20150626_080042 IMG_20150626_074803 IMG_20150627_075733

Tag 1

Als geübter Frühaufsteher war ich natürlich erster beim Frühstück im
Hotel und bin mit ausreichend Puffer losmarschiert zur UPC. Die
Konferenz fand in den Räumlichkeiten der Universität statt. Die Hörsäle
waren klimatisiert, was die (für einen
Deutschen/Hamburger/Wintermenschen) Hitze in Barcelona erträglich
gemacht hat. Sobald ich aber die Gebäude verlassen musste, habe ich
darauf geachtet, im Schatten zu bleiben.

Der erste Tag der #jbcn15 war damit vorbei und ich bin vollauf
zufrieden. Die Talks waren sehr interessant, die Themen wie erwartet
genau in meinen Interessengebieten und die Gespräche zwischen den Talks
unterhaltsam und informativ.

Was sich bei mir verstärkt, oder eher: was ich vorher geahnt habe, wird
jetzt immer mehr zur Gewissheit: Container-based infrastructure, d.h.
Software z.B. in Docker-Images auszuliefern, wird in Zukunft der
Standard werden. Es wird wahrscheinlich noch lange dauern, bis das im
Großteil der Unternehmen angekommen ist, aber für mich ist dieser Trend
ganz klar zu erkennen. Auch die großen Unternehmen versuch sich jetzt zu
positionieren und wenn ein Projekt wie fabric8 komplett auf Container
umstellt
, sollte man sich die Technologie auf jeden Fall genauer
ansehen. Claus Ibsen ist davon überzeugt, und auch James
Strachan
hat in seiner Keynote keinen Zweifel gelassen, dass
Container für Software Deployment die gleichen revolutionären
Auswirkungen haben wird, wie die Container für die Schifffahrt.

Am Abend gab es dann noch eine lockere Runde mit Getränken. Dabei habe
ich auch noch ein paar Kollegen von Zalando kennengelernt, die am
zweiten Tag einen Talk geben – der bereits weit oben auf meiner must
see
Liste stand und jetzt noch ein wenig höher gerutscht ist. Scheint
eine sehr interessante Firma zu sein. 🙂

Auf dem Weg zum Hotel habe ich noch ein paar Schlangenlinien durch die
Strassen von Barcelona gemacht, in einem kleinen Supermarkt (ich würde
das eher als Tante Emma-Laden einsortieren, sehr nett) ein wenig
Wasser gekauft und anschliessend wieder in einem kleinen Restaurant
etwas gegessen. In den Strassen von Barcelona findet man anscheinend in
jeder Strasse ausreichend Restaurants und kleine Cafés, so dass man
nicht verhungern muss. 🙂 Anschliessend wieder zurück ins Hotel und
mit aufgedrehter Klimaanlage eingeschlafen.

Tag 2

Der zweite Tag hat wieder wie gewohnt angefangen: Frühstück im leeren
Frühstücksraum, Spaziergang durch die Strassen zur Universität. Diesmal
einen anderen Weg, und dabei musste ich feststellen, dass Crossfit
Diagonal
quasi direkt im Keller der Konferenz liegt. Da hätte ich
locker noch ein oder zwei Trainings absolvieren können. Naja, ich habe
die Zeit auch so gut verbracht und vielleicht sind ein paar Tage
Trainingspause im Moment gar nicht verkehrt.

IMG_20150627_080016 IMG_20150627_075733

Wie auch immer, der zweite Tag war wieder voll mit interessanten Talk.
In den Pausen habe ich mit einigen anderen Teilnehmern gesprochen und
festgestellt, dass sich bei mir ein wenig Skepsis breit macht. Ob die
Container wirklich das richtige sind? Ganz offensichtlich ist das
Tooling noch nicht wirklich produktionsreif, gerade die
Management-Lösungen wie Fabric8 oder Mesos bzw Marathon
scheinen mir noch nicht wirklich mit der schnellen Iteration von
Docker bzw. Rocket aufgeholt zu haben. Das Load-Balancing,
Clustering und die Unterstützung ist vielleicht noch nicht dort
angekommen, wo die Kollegen aus den Operations damit zufrieden sind
und nachts beruhigt durchschlafen würden.

Ausserdem stellt sich die Frage, ob die Firmen wirlich groß genug sind,
um auto-scaling, dynamic deployments usw wirklich zu nutzen. Gerade wenn
man eine feste Nutzerbasis hat, braucht man vielleicht gar keine voll
skalierbare Cloudlösung… naja, darüber muss ich mir noch ein paar Tage
Gedanken machen, bevor ich etwas dazu aufschreibe.

Die Konferenz wurde von Gavin King mit einem Talk
über die Begriffe aus den modernen Programmiersprachen abgeschlossen,
der einige Unklarheiten bereinigen und Begriffe erläutern wollte.
Interessantes Thema, allerdings habe ich gemerkt, dass ich mich eher mit
der praktischen Seite der Softwareentwicklung und vor allem der
Auslieferung an Kunden beschäftige, als mit der Theorie über typisierte
Sprachen und der Auswirkung von typisierung auf Tool-Unterstützung. Das
ist ein gutes Thema für das Opening oder Closing einer Konferenz – und
ich werde mir ganz sicher Ceylon (die neue Sprache, an der Gavin
King arbeitet) angucken – aber die Auswirkungen von Containern auf das
Deployment meiner Software interessiert mich deutlich mehr.

Anschliessend wurden noch ein paar Bücher verlost und ein Ticket für
eine andere Konferenz. Ich habe erstaunlicherweise auch ein Buch
gewonnen, und zwar Camel in Action – das kann ich also gleich auf
meinen Schreibtisch im Büro legen und jeden Tag reingucken. Claus
Ibsen
hat es sich nicht nehmen lasen, die Bücher zu signieren

IMG_20150628_174511 IMG_20150628_174521

Tag 3

Am letzten Tag bin ich nur noch per Aerobus zum Flughafen und habe
die letzten Stunden dort verbracht. Schatten und Klimaanlage hatten mehr
Anziehungskraft als einige Sehenswürdigkeiten in der Stadt – die bereits
um 0800h morgens heiß war, so dass ich nur im Schatten zur Metro und
zur Bushaltestelle gegangen bin. Der Sonnenbrand hält sich in Grenzen,
aber ich will nicht am letzten Tag mein Glück herausfordern. 🙂

Universelle Laufzeitumgebung für Container

Docker gibt die Laufzeitumgebung für Container frei. Aus dem Artikel:

How we create and reuse infrastructure plumbing is fundamental to the Docker
project. Our approach boils down to 3 fundamental principles which we call
the Infrastructure Plumbing Manifesto”:

  • Whenever possible, re-use existing plumbing and contribute improvements back.

  • When you need to create new plumbing, make it easy to re-use and contribute improvements back. This grows the common pool of available components, and everyone benefits.

  • Follow the unix principles: several simple components are better than a single, complicated one.

  • Define standard interfaces which can be used to combine many simple components into a more sophisticated system.

There has been lots of demand for separating this plumbing from the Docker
platform, so that it can be re-used by other infrastructure plumbers in
accordance with infrastructure plumbing best practices. Today we are excited
to announce that we are doing just that!

Heise hat auch noch eine Zusammenfassung. Das ist ein interessanter Schritt, aber auch gut
nachvollziehbar. In den letzten Jahren hat sich die Softwareindustrie so entwickelt, dass Unternehmen
ein Framework für ihre Dienstleistung gebaut haben, dieses Framework dann freigegeben haben und
anschliessend über ihre Dienste und die Dienstleistung weiter Geld verdient haben. Das Framework
als Open Source freizugeben ist quasi die Geschäftsstrategie, um den Kundenkreis weiter zu
verbreitern, ohne dass sich Kunden an die Dienste des Unternehmens binden müssen. So kann man
kostenlos einsteigen und die Software einsetzen. Wenn die Funktionen passen, wird man irgendwann
an einem Punkt sein, an dem man weiter selbst Zeit und Knowhow investiert oder sich mit dem
Anbieter der Software als Partner aufstellt.

So etwas wird auch in Zukunft weiter funktionieren, denke ich. Denn auch privat sind die Benutzer
ja an dieses Modell gewöhnt: Dienste werden einfach beim Anbieter genutzt und man akzeptiert die
angebotenen Funktionen bzw. das Nicht-Vorhanden-sein von Funktionen. Wer damit nicht zufrieden ist,
hat oft die Möglichkeit, die Software oder eine kompatible Alternative selbst zu betreiben – aber
das ist eben aufwändig und mit Einarbeitung verbunden. Also bezahlt man als Nutzer lieber ein
paar Euro, um die Funktionen zu nutzen und sich aber nicht selbst um den Betrieb zu kümmern.

Preparations for #Jbcnconf

Jbcnconf is coming close. I think I’m good with my preparations:

  • Flight, Hotel, Aerobus booked
  • Tickets printed (and stored to all kind of devices: laptop, phone, usb sticks, …)
  • Laptop prepared (I am setting up a workspace to hack on Apache Camel while I’m on the road, and I am just starting up my fabric8 environment to play with my Docker containers)

I’m also syncing my important files to all my devices with BitTorrent Sync. I will also backup my stuff to my Drobo and some USB sticks for offsite backup. When I’m back I have to review my setup, because I’m not quite sure if I have some of my (encrypted) files on unencrypted media. I usually put everything in Truecrypt containers when I’m on the road, but maybe some of the files leaked onto insecure media… And Truecrypt, well, that’s a whole different story. I want to be prepared for the next crypto wars, but I guess one day before starting a trip is not the right time to switch your backup and crypto setup.

Anyway, I’m looking forward to the conference and the talks. Maybe I’ll get the chance to do some small talk with developers of the frameworks I use and have a nice time in Barcelona. 🙂

Was ist Software Architektur

Gerade habe ich den Artikel Is This Architecture? von Gregor Hohpe gelesen. Er stellt die folgende
Definition von Software Architecture vor:

Design decisions about any system that keep implementors and maintainers from exercising needless creativity

Needless Creativity klingt erstmal komisch, stimmt aber schon irgendwie. Designentscheidungen sorgen dafür,
dass man nicht immer und überall darüber nachdenken muss, wie man Software entwickelt. Sie dienen auch dazu,
dass man nicht von immer anderen Patterns überrascht wird und gleiche Dinge auch gleich umgesetzt werden.
Diese Begrenzung der Kreativität erlaubt es, sie dort einzusetzen, wo sie gebraucht wird: bei der Beurteilung
von neuen Situationen oder der Lösung von komplexen Problemen.

Deshalb hängt gute Architektur für mich nicht von guter Dokumentation ab. Gute Architektur zeichnet sich
dadurch aus, dass sie verständlich ist und dass sie in der täglichen Arbeit nachvollziehbar und umsetzbar ist.
Natürlich muss Dokumentation sein, schliesslich will auch die neue Mitarbeiterin verstehen können, wieso
ein System so aufgebaut ist, wie sie es vorfindet. Das kann man auch in Gesprächen klären, aber wenn man ein
anschauliches Diagramm aus der Dokumentation zaubern oder auf einer Seite im Wiki die Grundstruktur und die
wichtigsten Enscheidungen nachlesen kann, dann hilft das ganz entscheidend bei schneller Einarbeitung.

Hohpe macht eine wichtige Einschränkung:

Yet, to build such a house I would not want to pay an architect. To me this house is “cookie-cutter”,
meaning I don’t see any non-obvious decisions that an architect would have made. Consequently, I would
not consider this architecture.

Am Ende des Artikels gibt es dann noch ein paar Beispiele, wie solche “cookie-cutter” Entscheidungen aussehen:

Systems architecture does not have to be something terribly complicated. It must include, however,
significant decisions that are documented and are based on a clear rationale. The word “significant”
may be open to some interpretation and depend on the level of sophistication of the organization, but
“we separate front-end from back-end code”, “we use monitoring”, or “migrating systems is risky” surely
have the ring of “my door reaches the ground so people can walk in” or “I put windows in the walls so light
can enter”. Instead, when discussing architectures let’s talk about what is not obvious or something that
involved heavy trade-offs.

Was bei mir klingelt und eine sofortige Assoziation zu früheren und aktuellen Entscheidungen herstellt, ist
der Nebensatz “something that involved heavy trade-offs”. Das sind genau die Dinge, die dokumentiert werden
sollten: Es wurde eine Entscheidung für oder gegen etwas getroffen, und daraus ergeben sich weitreichende
Folgen.

Ich werde mich jetzt auch um eine Analogie aus dem Hausbau bemühen (obwohl ich überhaupt keine Ahnung vom
Hausbau habe…), z.B eine Entscheidung wie “Wir verwenden nur Haustüren ohne Schlösser,
weil …
” – diese Entscheidung hat weitreichende Folgen für die Sicherheit und ist quasi entgegengesetzt zu
allen anderen Häusern. Was hat wohl zu dieser Entscheidung geführt?

Google vergibt Security Rewards für Android

In einem Blogartikel hat Google angekündigt, die Security Rewards auch für Bugs unter Android auszuweiten:

Today, we’re expanding our program to include researchers that will find,
fix, and prevent vulnerabilities on Android, specifically.

For vulnerabilities affecting Nexus phones and tablets available for sale
on Google Play (currently Nexus 6 and Nexus 9), we will pay for each step
required to fix a security bug, including patches and tests. This makes
Nexus the first major line of mobile devices to offer an ongoing vulnerability
rewards program.

Gibt es ähnliche Programme auch bei Apple, Blackberry oder Microsoft?

Microservices with Apache Camel – simple example

Today I decided to play with Apache Camel to create some microservices. I know, microservices are the hot stuff right now, but usually one builds them with hot technology too. Like Clojure or Scala. Anyway, sometimes it’s a good idea to stick with stable and known technology, especially if you are in an enterprise environment with strict rules. Or you want your developers to concentrate on the organisational changes that come with microservices instead of fiddling with new technology.

To get started, I decided that I want to use

  • Maven to build the services
  • Docker to deploy and run them
  • Java/Apache Camel to implement them

That mix is conservative enough for a strict setting, using Java/Camel and Maven to develop the services. But with Docker I have one of the pieces in place that – in my opinion – will get traction in the mainstream Enterprise world in the next 2 or 3 years as well. Starting with Docker now is a good idea, so you should get yourself familiar with containers. :smiley: Especially if you think about deploying microservices to your infrastructure.

Ok, let’s start with the project. I pushed my project to github, you can clone it and run it right away. I’ll go through the details now so you know what you are looking at. Let’s have a look at the two services themselves, the DateService and the TimeService. As the names suggest, they return the current date and the current time. They are both exposed via camel-jetty as HTTP endpoints. To keep this short, I’ll only show the DateServiceRouteBuilder here.

DateServiceRouteBuilder.java

I decided to split the camel service up into two small routes, one that actually gives the date and one that exposes the other route as HTTP. The port can be set via a property, which is useful when configuring the service from outside – which is a common theme for microservices or at least for deployed immutable infrastructure.

package de.kopis.microservices.routes;

import org.apache.camel.ExchangePattern;
import org.apache.camel.builder.RouteBuilder;

import de.kopis.microservices.services.DateService;

public class DateServiceRouteBuilder extends RouteBuilder {
  @Override
  public void configure() throws Exception {
    from("direct:getDate").setExchangePattern(ExchangePattern.InOut).bean(new DateService(), "getDate");
    // add HTTP interface
    from("jetty:http://0.0.0.0:/date").setExchangePattern(ExchangePattern.InOut).to("direct:getDate");
  }
}

When developing a microservice, we don’t want an application server or anything bloated around the application. It’s called micro for a reason. :smirk: So how do I run the application when I’m not deploying it into a container? Camel provides the Main class for this and here’s how I use that:

RunDateService.java

package de.kopis.microservices.app;

import org.apache.camel.main.Main;

import de.kopis.microservices.routes.DateServiceRouteBuilder;

public class RunDateService {

  private Main main;

  public static void main(String[] args) throws Exception {
    RunDateService app = new RunDateService();
    final String port = (args.length == 1 ? args[0] : "8765");
    app.boot(port);
  }

  public void boot(String port) throws Exception {
    System.setProperty("port", port);

    // create a Main instance
    main = new Main();
    // enable hangup support so you can press ctrl + c to terminate the JVM
    main.enableHangupSupport();
    // add routes
    main.addRouteBuilder(new DateServiceRouteBuilder());

    // run until you terminate the JVM
    System.out.println(String.format("Starting Camel, using port %s. Use ctrl + c to terminate the JVM.", port));
    main.run();
  }
}

I also use the Maven Shade Plugin to create an executable JAR. Here’s the configuration from my pom.xml:


	
		
			org.apache.maven.plugins
			maven-shade-plugin
			2.4
			
				
					package
					
						shade
					
					
						
							
								de.kopis.microservices.app.RunDateService
							
						
					
				
			
		
	

When the project is build, you can run the service from the command line:

java -jar date-service/target/dateservice-*.jar 5679

Now, to deploy this application with Docker I created a Dockerfile for each of the services and a docker-compose.yml to run both of them and (later) add a frontend that will use the services and displays their output in a simple HTML page. The docker-compose.yml only builds and runs the services at the moment.

You have to build the project with Maven first to create the JAR files in the target directories. This is a step that I want to automate and simplify with the Dockerfile in the parent POM directory. After building the project you can use docker-compose to start the services. Run the following comand in the top directory:

    docker-compose up

After that you can open http://localhost:8081/time or http://localhost:8080/date to see the output of the services. Now you have 2 microservices built with Apache Camel running on your computer in Docker containers, ready to be deployed to your infrastructure.

In a production environment, the Docker images would be pushed to a central registry. Or the Dockerfile would download a RELEASE version from your central Maven repository. But with my example project you got a simple project that has everything you need to start with Apache Camel and Docker. Have fun!

Wallabag – selbst-gehostete Alternative zu Instapaper

Ich bin ein großer Freund von Instapaper für besseres Lesen von Internetartikeln, vor allem wenn ich unterwegs bin. Ich finde oft interessante Artikel, die aber im Moment des Findens eher ablenkend und meistens auch viel zu lang sind. Dann speichere ich diese Artikel bisher bei Instapaper und lade sie mir zum geruhsamen Offline-Lesen auf mein Handy runter. Dabei verschwindet passenderweise auch gleich die Werbung und die meistens störenden Bilder.

Leider musste ich dafür bisher eben immer Instapaper nutzen. D.h. ich schicke die interessanten Links und meine Lesegewohnheiten an einen Anbieter irgendwo in den USA. :worried:

Gestern habe ich aber dann Wallabag gefunden. Wallabag lehnt sich stark an Instapaper an und bietet die gleichen Funktionen – inklusive Android App – in einer selbst-gehosteten Anwendung an. Die Installation ist auf einem durchschnittlichen Webspace denkbar einfach. Man braucht PHP, die Daten liegen erstmal in eine SQLite-Datenbank. Man kann aber auch auf eine MySQL wechseln.

Ich selbst will Wallabag aber in meinem Docker-Setup auf meinem Server installieren. Das Dockerfile selbst ist schnell erstellt:

FROM	php:5.6-apache

RUN	apt-get update -y && apt-get install -y curl libpng12-dev libtidy-dev libgettextpo-dev unzip git
RUN	docker-php-ext-install mbstring
RUN	docker-php-ext-install gd
RUN	docker-php-ext-install tidy
RUN	docker-php-ext-install gettext
# install composer
RUN	cd /usr/local/bin && curl -s http://getcomposer.org/installer | php
RUN	git clone https://github.com/wallabag/wallabag.git /var/www/html/
RUN	curl --silent -o /tmp/vendor.zip http://static.wallabag.org/files/vendor.zip && unzip /tmp/vendor.zip && rm /tmp/vendor.zip

# add a custom config.inc.default.php if needed
#ADD	config.inc.default.php /var/www/html/inc/poche/config.inc.default.php

# make everything writeable
RUN	chown -R www-data:www-data /var/www/html/

Anschliessend kann man den Container beherzt bauen:

docker build --rm=true -t wallabag .

Anschliessend wird die Installation wie folgt gestartet:

docker run --name wallabag -p 8080:80 -t wallabag

Jetzt nur noch im Browser die URL http://localhost:8080/ aufrufen und schon kann man die ersten Artikel fürs spätere Lesen abspeichern. 🙂 Wer die Android App nutzen will, der muss zuerst in der Konfiguration die Feeds einschalten und anschliessend die angezeigte User ID und das Token in der Android App eingeben. Anschliessend klappt auch die Synchronisierung.

Für mein eigenes Setup hatte ich noch das kleine Problem, das der Container mit Wallabag hinter einem Reverse Proxy steht und daher die öffentliche URL nicht mit der URL der Installation übereinstimmt. Leider hat Wallabag noch keine Einstellung für die base url, daher habe ich kurzerher meine rudimentären PHP-Kenntnisse ausgepackt und einen pull request gestellt. Damit kann über die config.inc.default.php eine Konfiguration-Option mit der öffentlichen Adresse gesetzt werden und die Links in den Themes funktionieren wieder:

@define ('BASE_URL', 'https://meinhostname/pfad/zu/wallabag/');
Kategorien
Sport

Auf Wiedersehen, Crossfit HH

Nach gut 1,5 Jahren beende ich meine Mitgliedschaft bei Crossfit HH mit schwerem Herzen. Mein Crossfit Training hat dort begonnen und ich habe große Fortschritt gemacht. Viel Technik gelernt, viel Olympic Lifting trainiert, die Crossfit Open 2015 mitgemacht und dabei meine ersten Muscle Ups geschafft. Wer in Hamburg eine Box für sein Crossfit Training sucht, der sollte unbedingt bei Crossfit HH vorbei schauen!

Die Fahrtzeit von meinem Wohnort bis nach Barmbek rein wurde aber nach den Monaten etwas anstrengend und nachdem ich einige Mal beim North Gym trainiert habe, werde ich jetzt mein Training dort machen. Die Open Gym-Zeiten und die wirklich kurze Anfahrt geben den Ausschlag. Die Crossfit Workouts machen Spass und das Programming ist anständig.

Zusätzlich werde ich das Garagentraining an meinem Erstwohnsitz aufgeben und in Zukunft bei CrossFormation trainieren. Kein Schneeschieben vor dem Training im Winter! 🙂

So langsam hält Functional Training auch in den eher dünn besiedelten Gegenden Einzug. Mein Trainingsbedarf ist also weiterhin gedeckt.

I’m going to JBCNconf

I’m going to #jbcnconf in Barcelona on 26 – 27 June. The list of speakers include some of the very public names of some of the large open source frameworks I use a lot:

Claus Ibsen will talk about “Microservices with Apache Camel”. Jean Baptiste Onofre will talk about “Apache Karaf for the Enterprise”. James Strachan will be there, talking about “Kubernetes for Java Developers”.

Sounds like fun, so I hope the ticket confirmation is arriving soon so I can book the flight and hotel. :-)