Docker Meetup at Hypoport with “Why you’ll love managing containers with Docker” & “Docker on AWS” on Jan, 19th

Docker Berlin is back! You can now follow us on Twitter too @DockerBerlin

To init and containerize this new year properly we have two great speakers lined-up at Hypoport on Jan, 19th.

Johannes Ziemke [Docker Inc.] and Sascha Möllering [ZANOX.de AG]

Managing containers with Docker…and why you’ll love it – Johannes Ziemke

What are the challenges of today’s infrastructures, why containers are the right building blocks and Docker the right tool to manage those.

Docker is an open-source project to easily create lightweight, portable, self-sufficient containers from any application. The same container that a developer builds and tests on a laptop can run at scale, in production, on VMs, bare metal, OpenStack clusters, public clouds and more.

I’ll talk about the challenges of managing complex infrastructures based on my past experiences, why live state mutation sucks and configuration management is doomed, self-sufficient and light-weight containers are the answer and how Docker manage those.

Last but not least I’ll show how to build, ship and run containers and real world examples of what Docker is already used for.

Speaker profile: http://de.linkedin.com/in/johannesziemke

Docker in the Cloud on AWS – Sascha Möllering

In this talk, I’ll describe how to leverage the potential of Docker and Amazon Web Services to deploy Docker Containers in AWS, connect to managed services from your application and implement the immutable server pattern.

Speaker profile: https://www.linkedin.com/pub/sascha-m%C3%B6llering/2b/268/403

Agenda:

6:00 – 6:30: Networking

6:30 – 7:15: Managing containers with Docker

7:15 – 7:30: Break

7:30 – 8:00: Docker in the Cloud on AWS

8:00 – open end: Networking

This meetup is kindly sponsored by Hypoport, which provides venue, food and drinks! It would be nice if you sign up on the meetup Docker Berlin event.

Marry Xmas and a Happy New Year. See you there.

Nie wieder Monolithen! Micro Services in der Praxis.

Bei der Hypoport AG haben wir bereits drei verschiedene Modularisierungsinkarnationen erlebt. Jede Inkarnation brachte uns näher an das Ideal einer flexiblen, wartbaren Architektur. Und dennoch stellten wir nach wenigen Jahren der Produktweiterentwicklung wieder fest: Die Anwendung ist voll von unbeabsichtigter Komplexität, Innovationen sind nur schwer möglich und die Umsetzung von Funktionalität dauerte kontinuierlich länger. Der Micro-Service-Architekturstil verheißt durch die Zerlegung eines Systems in kleine, unabhängige Services nachhaltige Besserung. Wir haben’s ausprobiert und sind begeistert.

Der Artikel erschien im Java Magazin 8.2014.

Zum Artikel: http://jaxenter.de/artikel/nie-wieder-monolithen-176652

Mein Fazit von der manage agile 2014 in Berlin

manageagile14
Letzte Woche fand die Konferenz manage agile vom 27.-30.10.2014 in Berlin statt. Am Montag gab es Ganztagesworkshops, am Dienstag und Mittwoch dann Frontalvorträge und am Donnerstag Halbtagesworkshops. Ich habe mangels für mich interessanter Themen den Montag ausgelassen und bin am Dienstag eingestiegen.
Bei mir sind ein paar Aussagen hängengeblieben, die ich mehr oder weniger in allen von mir besuchten Vorträgen (17 Stück!) gehört habe.
Am eindrücklichsten war die Aussage, dass die Jobbeschreibung für Manager neu geschrieben werden muss. Und natürlich gab es viele Anregungen, damit Agilität im Unternehmen nicht nur “gespielt” wird. Allen voran ist es die Beantwortung der Sinnfrage des Mitarbeiters: Warum soll ich in dieser Firma und an diesem Produkt arbeiten? Die Antwort gibt dann die nötige Ausrichtung (Alignment), durch die ein zielgerichtetes und autonomes Arbeiten in Teams überhaupt erst möglich wird. Desweiteren entwickelt sich die Aufgabe eines Managers immer mehr in Richtung eines Coaches. Nicht Selber-Machen, sondern Befähigen zum Machen, ist die Devise. Das dabei trotzdem aber Erwartungen an und Ziele für den Mitarbeiter abgestimmt werden sollen, zeigt für mich sehr deutlich auf, dass die Agile Veränderungswelle im Management angekommen ist und wir mitten in einer Transition zu einem neuen Bild von Führung sind.
Überhaupt kam kein Zweifel während der Konferenz auf, dass Agilität als Thema für die Mitarbeiter durch, also zum Mainstream geworden ist.
Konkrete Hilfe für den veränderungswilligen Manager gab es nicht viele. Gleichwohl haben die Vorträge einige Möglichkeiten aufgezeigt, wie man mit konkreten Werkzeugen versuchen kann, die Zusammenarbeit neu zu gestalten, z. B. Peer Feedback, Management 3.0, Design Thinking, Lean Change oder Lean Startup. Ich denke, hier kann es im nächsten Jahr gut weitergehen. Das zumindest wäre mein Vortrag für nächstes Jahr ;-)
Ein wenig Konkretes gab es für mich am Donnerstag: Halbtagesworkshop in Soziokratie. Das war für mich ein willkommener Auffrischer und hat mich motiviert, davon auch etwas bei Hypoport auszuprobieren. Ein Teilnehmer nannte es gar “Agilität für die Governance”. Soweit würde ich jetzt nicht gehen, aber es fügt sich sehr wohltuend in das Agile Mindset ein, finde ich.
Insgesamt hat sich die Konferenz für mich gelohnt, wenngleich eine zweitägige Frontalbeschallung echt anstrengend und auch nicht mehr zeitgemäß ist. Das haben auch die Veranstalter gemerkt und wollen das Format nächstes Mal offener gestalten.
Bis nächstes Jahr!

Continuous Deployment with Gradle and Docker – Part 2

After a quite long holiday break we now continue our series about the Continuous Deployment Pipeline with Gradle and Docker.

This post is about the first step where our build chain creates the Spring Boot packages and publishes them to our Nexus repository manager. As shown in the high-level overview below, it is only a quite small part of the complete pipeline:
Deployment Pipeline with Gradle and Docker

Gradle and Spring Boot provide you a very convenient build and plugin system and work out of the box for standard builds. Yet, the devil is in the details. Our project consists of a multi module setup with the following subprojects:

  • backend
  • frontend
  • common
  • contract-test
  • e2e-test

The projects backend and frontend are our main modules with each being deployed as a standalone application. They share the common project which contains the security and web config. The contract-test and e2e-test projects contain more integrative tests and will be discussed later in dedicated posts.

We’ll now take a deep dive into our build scripts and module structure. You can find the example source code on GitHub, where we provide a minimal, but working project with the important parts being described here.

Gradle project setup

A build on our CI-Server TeamCity uses the Gradle Wrapper by running the tasks build and publish. These tasks are called on the root level of our project. Our Gradle root project contains the common configuration so that the subprojects only need to configure minimal aspects or special plugins.

Shared dependency versions are defined in the root project, so that all subprojects use the same dependency versions. Gradle also allows you to define sets of dependencies, so that you can reference them as complete package without known its details. We call these sets libraries and you can find an example at the root build.gradle along with its usage in the dependency closure.

Using a common definition of dependencies sometimes isn’t enough, because you also have to handle transitive dependencies. You have the option to manage transitive dependencies by manually excluding or even redefining them. Another option we often use is to override clashing dependency versions by configuring the build script’s configuration. The resolutionStrategy can be configured to fail when version conflicts are recognized. The example project shows you how we globally manage our dependencies.

Spring Boot configuration

Building a Spring Boot application with Gradle is simplified with the help of the Spring Boot Gradle Plugin. The plugin configures your build script so that running gradle build depends on the bootRepackage task.

You’ll see in the backend and frontend build.gradle scripts, that we configure Gradle to replace a token in our source files with the artifactVersion. This special token replacement aims at setting the actual version in our application.properties file, which is used to configure Spring Boot. By adding a line like info.build.version=@example.version@ we enable the /info endpoint so that we can ask a running application about its version. The version will be used later in our deployment pipeline. Details on our artifact versioning scheme will be described in the section about publishing below.

Performing Node.js build tasks

Our backend build isn’t very spectacular, but our frontend build needs some more explanation. We implemented our frontend with AngularJS, but use Spring Boot to deliver the static resources and to implement security. Before packaging the AngularJS resources in the frontend artifact, we let Gradle perform a grunt release task. Grunt is a Node.js based task runner, which lets us run unit tests, minimize our frontend code or even images and package everything. Its result then needs to be copied to the public resources folder of Spring Boot.

Configuring a Node.js build in a platform neutral way isn’t one of the trivial tasks, but we use the gradle-grunt-plugin and the gradle-node-plugin which helps a lot. Apart from delegating the grunt release to the plugin we also configure the according grunt_release task to recognize inputs and outputs in the Gradle build script. The inputs and outputs help Gradle to decide if the task needs to be executed. If there haven’t been any source changes and the output still exists, the task is regarded up to date and will be skipped.

Publishing and versioning Gradle artifacts

With both frontend and backend being packaged as artifacts, we would like to publish them to our Nexus artifact repository. Nexus needs the well known set of groupId, artifactId and version to identify an artifact. The Gradle maven-publish plugin can be configured in a very convenient way to use the project’s group, name and version as Maven coordinates. As you can see in the example source code, we already configure the group in our root project. The subproject’s name fits our needs as artifactId, which leads us to the final property, the version.

We wanted the version to be unique and sortable by the artifact’s build time. We also didn’t want to maintain a version.txt in our project. Long story short, we defined our version to look like the scheme: yyyy-MM-dd'T'HH-mm-ss_git-commit-hash. The part before the _ corresponds to the build timestamp and the second part corresponds to the latest commit hash of the project’s git repository. That way we can quickly recognize when the artifact has been build with which commit in the project’s history.

The artifact version is generated on every build. Apart from updating our application.properties, we also use the artifact version to configure the publish task in our root project. The rest works out of the box, we only need to configure the Nexus publish url with username and password.

Build on a CI-Server

Our CI Server TeamCity now only needs to execute the gradlew clean build publish tasks to compile, perform all unit tests, package the Spring Boot applications and publish them to the artifact repository. That wouldn’t be enough, because we also want to perform integration tests and deploy the applications to our internal and production stages.

TeamCity provides a feature to declare so-called build artifacts, which can be used by subsequent build goals in our build chain. We want the other build goals to know the application version, so we write it into a text file on the build agent and pass it to all build goals in our pipeline. Every build goal then uses the version to fetch the artifact from Nexus. The image below shows all build goals of our build chain:

Build Chain

The selected yellow box in the build chain corresponds to the build step we described in this article. As promised, the next article in our series will describe you in detail how we perform our integrative e2e- and contract-tests. Comments and feedback here or @gesellix are welcome!

Docker Global Hack Day #2 – Berlin Edition at Hypoport

We are proud to announce that we are part of the Docker Global Hack Day #2. Join other members of the Docker community to hack on Docker projects using the next big Docker release! You’re all invited to Hypoport HQ in Berlin for a hacking session while sharing a meal/drink with fellow Dockers. This hackathon is your last chance to win a ticket to the sold out DockerCon Europe. Please register using our meetup event page.

See you then.
Leif

Wie halte ich ein System möglichst stabil?

Wie halte ich ein System möglichst stabil?
Veränderungen sind blöd! Nicht nur, dass sie irgendwie wehtun und stören… sie fressen Energie und dazu verhindern sie auch noch das Funktionieren! Es ist doch allgemein anerkannt, dass Systeme, die sich verändern, nicht auch noch gleichzeitig funktionieren können. Veränderungen kosten also auch noch richtig Geld, weil sie Phasen des Nicht-Funktionierens hervorrufen. Und das gilt für alle Systeme! Für Organisationen und sogar für SIE als Person. Nicht gut!

Hier nun also mein ultimativer Ratgeber, mit dem sie Veränderungen am besten schon im Keim ersticken und so ihr System, für das es sich lohnt zu kämpfen, möglichst lange stabil halten können:

Ins Konkrete zwingen
Veränderungen fangen meistens mit Unklarheiten und Verwirrungen an. Das äußert sich in abstrakten Diskussionsthemen, die nicht 100%ig zu fassen sind. Nutzen Sie das! Zwingen Sie Ihren Gesprächspartner sofort ins Konkrete. Fragen Sie “Und was stellst du dir dann konkret vor? Wie soll das gehen? Mach’ mal ein konkretes Beispiel!” Philosophieren Sie auch gerne darüber, dass wir nur, wenn es konkret wird, Erfolg haben werden und andere mitziehen können.

Lösung-vor-Ursache
Hören Sie dem Störenfried zu und sobald sich das erste Problem zeigt, drängen Sie mit aller Macht auf eine Lösung und beenden das Meeting zufrieden. So verhindern Sie lange und zähe Diskussionen über Ursachen. Denn die haben ja sowieso noch nie zu einem Ziel geführt, außer, dass sie unheimlich viel Zeit kosten und am Ende alle noch mehr Fragen als Antworten haben. Also weg damit.

Mengenargument
Klappt nicht immer, aber wenn dann ist diese Taktik unwiderstehlich gut: Prüfen Sie, wieviel Prozent im System überhaupt ein Problem haben. Sobald es weniger als 33,3% sind, argumentieren Sie sofort und beharrlich, dass wir hier nicht dazu da sind Minderheiten zu optimieren. Das zieht!

Aussitzen
Ein Klassiker darf nicht unerwähnt bleiben. Ist der Störfaktor nicht wirklich beharrlich, ignorieren Sie ihn. Oder mindestens: geben Sie ihm eine ganz geringe Priorität. Also Meetings lieber mal eine Woche später als gewünscht ansetzen und “ich komme auf dich zu”. Auch passive und unpersönliche Formulierungen können hier gut eingesetzt werden: “Darum muss man sich wirklich mal kümmern!” oder “Da müsste echt mal was gemacht werden!”

Machen wir doch schon
Auch sehr schön. Schauen Sie in den Argumentationen Ihres Störenfrieds, ob Sie irgendwo eine kleine Stelle finden, die Sie heute schon genauso machen. Egal wie klein und unbedeutend! Und dann sagen Sie: “Ich verstehe, was du sagst, und das machen wir bei XY ja auch schon so!” Geben Sie sich damit zufrieden und weisen notfalls darauf hin, dass man lernen muss, auch mit kleinen Erfolgen zufrieden zu sein.

Verstehe ich, ABER…
Die Guerillawaffe gegen Veränderung. Konsequent angewandt, prallen alle Veränderungen in Zukunft von Ihnen ab. Quasi eine Nanotechnikbeschichtung gegen aufkommende Veränderungen. Verstehen Sie Ihren Gegenüber mit der ganzen Kunst der Rhetorik und des aktiven Zuhörens und machen dann mit einem kleinen Wort alles zunichte: ABER! Halten Sie dann einen langen und möglichst unverständlichen Monolog über Ihre (völlig entgegengesetzte) Meinung. Nochmal der Hinweis: Die Wirkung tritt meistens erst mit etwas Verspätung ein. Aber dann sehr nachhaltig.

Ausnahme-ist-keine-Regel
Machen Sie klar, dass es sich bei dem Problem nur um eine Ausnahme handelt. Und finden Sie ein paar Beispiele, dass das Angesprochene in der Regel ja klappt.

Selbstorganisation/Energie
Sollte Sie, wie ich, in der IT arbeiten und sie haben schon ein wenig (muss gar nicht viel sein) Erfahrung mit Scrum/Kanban und anderen veränderungsheraufbeschwörenden Techniken, so nutzen Sie dieses fundamentale Argument der Agilität doch einfach, um es gegen sich selbst zu richten. Sagen Sie großmütig, dass Sie das Problem gerne der Selbstorganisation überlassen wollen. Da die meisten Teams über kurz oder lang an der Aufgabe zerbrechen, werden sich diese Teams schnell wieder auf dem Boden der Tatsachen mit Konkreten Sachen beschäftigen. Nebenbei wirkt dieses Ereignis auch, wie eine Impfung. Ein Team, das diesen schmerzhaften und nicht erfolgreichen Prozess einmal durchgemacht hat, wird ihn in Zukunft großräumig meiden. Ich sag’ nur: Herdplatte!

Versachlichen
Kurz gesagt: Emotionen als Schwäche auslegen! Dazu immer wieder betonen, wie wichtig eine sachliche Diskussion ist. Da soll erstmal jemand kommen und Ihnen das Gegenteil beweisen. Also, weg mit den Emotionen, her mit der Sache. Wer nicht mitzieht und komische, nicht-greifbare Einwände hat, muss kalt gestellt werden. Ist Ihr Gegenüber eine Führungskraft, dann können Sie noch einen Schritt weiter gehen und sagen: Führungsschwäche! Bis jemand auf die Idee kommt, das könnte dann etwas mit dem Chef der Führungskraft zu tun haben, ist diejenige oder derjenige längst weg vom Fenster.

Schuldigen finden
Und zum Schluss darf natürlich nicht fehlen: Anstatt sich mit der Lösung oder noch grausiger mit der Ursache zu beschäftigen, suchen Sie lieber den Schuldigen! Ist ganz einfach. Eliminieren Sie dann diese “Ursache” durch z. B. Verantwortungsentzug und, Schwupps, gelten Sie als großer Problemlöser. Ein Warnung: Es spricht sich meiner Erfahrung nach zunehmend rum, dass die Suche nach einem Schuldigen nichts bringen soll. Weichen Sie dann lieber auf andere Taktiken aus.

Zusammenfassung
Es gibt viele Wege, Veränderungen im Keime unschädlich zu machen. Die Kunst besteht nun für Sie darin, situativ den passenden rauszusuchen und konsequent anzuwenden. Das braucht natürlich Erfahrung, aber lassen Sie sich nicht entmutigen, sondern schauen Sie bei den Könnern ab.
Als Essenz lässt sich sagen: Lassen Sie sich nicht auf Ihr Gegenüber ein und wenn doch, dann nur als Taktik. Bleiben Sie in der einzigen Welt, die zählt: In Ihrer! Und ganz wichtig: Nicht sagen, was sie denken! Damit würde der Verfall beginnen.
Und nun: Viel Glück ;-)
Foto: http://www.helenesouza.com, “Gemeinsam gestalten”, Quelle: www.pixelio.de

How to open async calls in a new tab instead of new window within an AngularJS app

I recently wanted to generate a PDF on users demand and show it in a new browser tab.
Sounds trivial, at first not for me :) I tried it with different “solutions” and on my way my google search result got better and better. With “open window new tab without popup blocker async” I finally found in this thread a nice and easy solution. The trick is to remember the reference to the new window and change the location of that window when your asynchron call completes.

$scope.generatePdf = function () {
  var tabWindowId = window.open('about:blank', '_blank');

  $http.post('/someUrl', data).then( function (response) {
    tabWindowId.location.href = response.headers('Location');
  });
};

If you want to see it in action open this plunker. While testing this plunker, it seems that openWindow will open a tab, as long as the async call is quick enough (less than a second). The setTimeout is therefore set to 1001.

I hope you will find this solution quicker than I did. Please let me know if you have any questions or suggestions. Either per @leifhanack or comment here.