12065634_10203449309432152_5820708125374016856_n

 

Benjamin Buick

iSAQB zertifizierter Softwarearchitekt
Java Entwickler & Mobile Anwendungen

 

Auf Twitter folgen    Kontaktieren Sie mich

 

Herzlich Willkommen!

Mein Name ist Benjamin Buick und ich heiße Sie herzlich Willkommen.
Ich bin iSAQB zertifizierter Softwarearchitekt und Softwareentwickler mit Schwerpunkt Java Softwareentwicklung und Entwicklung mobiler Anwendungen.

Als Softwarearchitekt
interessieren mich vor allen Dingen die MicroService Architektur sowie Resilient (fehlertolerante) und verteilte Systeme.

Als Entwickler
beschäftige ich mich aktuell mit Themen wie Webapplikationen, mobile Anwendungen sowie 3D Programmierung und Augmented / Virtual Reality.

Neben der Programmierung konzentriere ich mich auch auf organisatorische Themen wie Rapid Prototyping, agile Softwareentwicklung (mit DevOps), Continuous Delivery und Integration.

Informationen über eigene Projekte teile ich des Öfteren über Twitter mit.
Über das Kontaktformular können Sie mich auch direkt kontaktieren.

Kompetenzübersicht

Im Folgenden finden Sie eine Aufstellung der wichtigsten Technologien und Softwarepraktiken, mit denen ich bisher gearbeitet habe.

Mobile Applikationen
iOS, Android, Blackberry

Datenabgleich in Gebieten trotz schlechter Signalqualität Dank des Einsatzes modernster Datenkompression und -transfertechnik.

Entwicklung smarter Algorithmen, die zur Erhöhung der Energieeffizienz zwischen Standortdiensten wie GPS, WiFi und Netzwerktriangulierung durchschalten.

Zugriffsautorisierung, verschlüsselte Verbindungen, Daten und Tokens durch SSL, Tunnel, oAuth2.0, SHA-512 und 256-bit AES Verschlüsselung.

Einfach zu bedienendes und anwenderfreundliches Design.

Native oder Cross-Platform (Xamarin, Xamarin.Forms).

Enterprise Software
SOA, Micro Services & Resilient Softwarearchitektur

OSGi Felix Framework & Apache Sling

Spring Framework, Boot & Grails Applikationen

REST & SOAP Webservices

Resilient Architektur: beispielsweise Überlastungsschutz durch Kurzschließen von Services und selbstheilende Systeme.

Big Data: Hadoop in Verbindung mit SQL und NoSQL (beispielsweise MongoDB und H-Base).

Rich Internet Application mit HTML5/Javascript

Entwicklung & Architektur
Softwarearchitektur, Scrum & DevOps, Continuous Delivery & Requirements Engineering

iSAQB Zertifizierter Softwarearchitekt

TOGAF, arc42 und RM-ODP

IBM Doors (Requirements Engineering Workshop)

IBM Rational Team Concert CCM (Scrum & DevOps change and configuration management)

IBM uDeploy (Continuous delivery & integration pipeline workshop)

BI & Visual Analytics Workshop (TDWI)

BPMN 2.0 Workshop

Official BlackBerry 10 Entwickler

Als PDF herunterladen 

Über Benjamin Buick

Benjamin Buick ist iSAQB zertifizierter Softwarearchitekt und erfahrener Java Softwareentwickler in Frankfurt am Main.

Als Experte in den Bereichen OSGi, Spring, Apache Sling und Microservices hat er eine Vielzahl von unterschiedlichsten Projekten umgesetzt. Seine Projekterfahrung reicht daher von mobilen Anwendungen über Softwaresysteme im Enterpriseumfeld bis hin zu sozialen Netzwerken.

Sein besonderes Interesse gilt neben dynamischen Systemen vor allen Dingen dem Resilient Architekturstil.

„Ein gutes Softwaresystem versteckt seine Komplexität vor dem Benutzer und erweckt den Eindruck von Magie.“

Zusammengefasst bin ich Ihr Ansprechpartner bei Projekten rund um

  • Spring Framework (MVC, Cloud), Grails
  • Android SDK, BlackBerry (QML+Cascades), Cordova
  • OSGi (Felix Framework, Apache Sling)
  • Oracle, MongoDB, PostgreSQL, Hadoop, Spark
  • JavaSE, JavaEE und Groovy
  • C#
  • PHP und SQL
  • JavaScript (Angular1+2, jQuery, WebGL…), HTML5 und CSS3.

Kontakt

Sie können mich gerne über das untenstehenden Kontaktformular erreichen.

Ich freue mich, von Ihnen zu hören.

 

 

Letzte Beiträge

 

  • 06 Apr

    Holo World – ein Kurzbeitrag

    Warum mich die HoloLense so fasziniert

    Mehrere Jahrzehnte haben wir uns hinter Bildschirmen unterschiedlicher Größe versteckt. Die Arbeit im natürlichen dreidimensionalen Raum haben wir größtenteils durch die Arbeit auf zweidimensionaler Fläche ersetzt. Mit Maus, teilweise auch Touchscreen navigieren und und befehligen wir. Die „Objekte“, mit denen wir tagtäglich hantieren, wieder in die natürliche Umgebung, unseren Kopf wieder weg von den Bildschirmen zu bewegen, ist ohne Frage revolutionär. Dabei ist die Idee spätestens seit den mobilen Geräten schon immer diese gewesen: unsere Realität mit Informationen aus der digitalen Welt anreichern – ein digitaler Layer sozusagen.

    Wie viele Andere kann ich es kaum erwarten, die Entwickleredition endlich in den Händen zu halten. Entwickler, die nicht in den Vereinigten Staaten oder Kanada leben, müssen sich allerdings noch unbestimmte Zeit gedulden.

    Bildschirmfoto 2016-04-06 um 11.42.24

     

  • 09 Mrz

    OSGi als Vorbild

    Ein Tipp von mir, was die Planung einer MicroServices Landschaft anbelangt:

    OSGi¹ und das Modularity Maturity Model² bieten eine gute Orientierungshilfe bei der Planung der eigenen Systemlandschaft mit MicroServices.

    logo

    ¹ Grob gesagt ist OSGi eine Spezifikation für eine dynamische Softwareplattform, die es ermöglicht Services modular und dynamisch in einem System zu verwalten. Wenn Sie ein Entwickler sind und nicht viel mit dem Begriff anfangen können, sollten Sie sich OSGi unbedingt genauer anschauen – es lohnt sich! [http://www.osgi.org]

    ² Das Modell bewertet den Grad der Modularität einer Software anhand von 7 (eigentlich 6) verschiedenen Leveln. Eine gute Orientierungshilfe um die Anforderung an die Modularität für die Softwarearchitektur festzulegen. [http://wiki.osgi.org/wiki/Modularity_Maturity_Model]

  • 19 Feb

    Microservices und Resilient – Tücken einer Architektur

    consistence

    Microservices und Resilient Architektur sind momentan sicherlich zwei der wichtigsten und heißesten Themen unter Softwareentwicklern und -architekten, passen diese beiden Konzepte doch wie die Faust aufs Auge ¹ . Einen Artikel, der gleich beide Themen umfasst, konnte ich in der Ausgabe 11/2015 im Java Magazin [MAG] lesen. Da ich leider nicht oft dazu komme, eines von den mittlerweile sich stapelnden Magazinen zu lesen, kommt dieser Beitrag mit einem Vierteljahr Verspätung, obgleich die Problematik an Aktualität nicht verloren hat. Ausschlaggebend für diesen Beitrag ist die in dem besagten Artikel beschriebene, meiner Meinung nach fehlerprovozierende Architektur des dort skizzierten Systems. Genau so sollte ein Architektur bestehend aus Microservices nicht aussehen. Ich möchte an dieser Stelle nicht spekulieren, warum dieses Beispiel so gewählt wurde. Vielmehr ist es mir wichtig darauf hinzuweisen, warum der Artikel ungewollt zu einem Negativbeispiel wird, da ich auf diese Architektur in der Realität leider des Öfteren schon stoßen musste – meist zur Aufklärung sogenannter „byzantinischer Fehler“ ² .

    Kontext: worum geht es?

    In dem Artikel ist von einem System bestehend aus mindestens vier Microservices die Rede. Bei den vier Softwarekomponenten handelt es sich um Umsetzungen der fachlichen Anforderungen

    • Registration,
    • Login,
    • Billing und
    • Shop,

    wobei wir im Folgenden unsere Aufmerksamkeit den Services Registration und Login widmen werden.

    Die Registration ist für die Registrierung eines Benutzers und die Speicherung der Benutzerdaten zuständig. Die  „Login“-Komponente nutzt die Komponente „Registration“, um „[…] Accountinformationen des Nutzers während des Logins abzufragen.“.

    Darstellung zeigt die vereinfachte Kontextsicht des Beispielsystems

    Darstellung zeigt die vereinfachte Kontextsicht des Beispielsystems

    Ich habe das Ganze in Abbildung 1 einmal versucht zu veranschaulichen, wobei tatsächlich mithilfe einer HAProxy Konfiguration zur Laufzeit zwei Instanzen der einzelnen Komponenten Login, Billing und Shop zur Verfügung stehen.

     

    Regelverstoß: hier liegt der Hund begraben!

    Ganz offensichtlich sind die Komponenten Login, Billing und Shop abhängig von Registration und dementsprechend nicht fehlertolerant gegenüber dem Ausfall dieser Komponente. Deswegen trifft der Autor die Entscheidung, diese Abhängigkeit aufzulösen, indem eine Datenredundanz geschaffen wird: die Benutzerdaten werden in gewissen Abständen von den nutzenden Komponenten gepollt und zwischengespeichert, sodass bei einem Ausfall des Dataowners „Registration“ die bereitgestellte Funktionalität von den anderen Komponenten weiter angeboten werden kann.  Damit nicht bei jedem Polling alle Daten neu kopiert werden müssen, werden die Datensätze von Registration mit einer Versionsnummer versehen. In dem Moment, in dem sich ein Datensatz bei Registration ändert,  wird diese Versionsnummer inkrementiert, sodass die nutzenden Komponenten bei dem nächsten Polling wegen der neuen Versionsnummer zu einem kopieren aller Daten veranlasst werden. Dies habe ich in Abbildung 2 versucht darzustellen.

    Darstellung zeigt das Polling und die Datenversionierung

    Darstellung zeigt das Polling und die Datenversionierung

    Diese Ansatz ist aus vielerlei Gründen extrem gefährlich, allerdings leider, wie bereits in der Einleitung erwähnt, in der Realität oft vorzufinden.

    1) Seperation of Concerns – Trennung von Verantwortlichkeiten

    Es ist Aufgabe der Komponente „Registration“ sich um die Bereitstellung des aktuellen Datensatzes zu kümmern.  Die vermeintliche (ich komme in Punkt 2 darauf zu sprechen) Ausfallsicherheit erkauft man sich dementsprechend durch stärkere Kopplung an die Datenbeschaffenheit.

    2) Datenkonsistenz und Analysierbarkeit

    Da bei nicht getaktetem Polling der einzelnen Nutzkomponenten (Billing, Shop, Login) diese zur gleichen Zeit unterschiedliche Versionen der Datenbestände vorliegen haben können, kann es dadurch zu merkwürdigem Verhalten des gesamten Systems kommen, welches, da dieser inkonsistente Zustand vielleicht nur im Millisekundenbereich liegt, schwierig zu analysieren ist.

    Darstellung zeigt die Problematik die durch Inkonsistenz der zwischengespeicherten Datensätze bei den nutzenden Komponenten entsteht.

    Darstellung zeigt die Problematik, die durch Inkonsistenz der zwischengespeicherten Datensätze bei den nutzenden Komponenten entsteht.

    Abbildung 3 zeigt diese Situation. Während die Login Komponente bereits über den neuen Benutzer „Alex“ weiß, hat Billing noch einen alten Datensatz und kann diesen wegen des Ausfalls der Registration Komponente nicht aktualisieren. Vielleicht hat die der Einfachheit wegen in der Abbildung nicht dargestellte Shop Komponente den neuen Datensatz bereits, sodass der Benutzer sich einloggen und bestellen kann, die Bezahlung allerdings nicht möglich ist.

    3) Sicherheitskritisch

    Ich halte es grundsätzlich für kritisch, wenn ein User nicht sofort innerhalb eines Systems blockiert werden kann. Bei dem Beispielsystem müsste man darauf warten, dass alle Pollingzyklen der nutzenden Komponenten abgeschlossen sind, bevor das komplette System auf dem aktuellen Stand ist und der Benutzer keinen Zugriff mehr hat.

    Lösungsvorschlag

    Insofern ist es angebrachter, die Datenredundanz durch Datenbankcluster auf Seite der Registration Komponente zu schaffen. Bei der Gelegenheit würde ich diese Komponente in „Customer Data Service“ umbenennen und die Funktionalität „Registrierung“ je nachdem in eine neue oder in der bestehenden Login Komponente unterbringen.  Bei einem Ausfall der hinterliegenden Datenbank von dieser Komponente Customer Data Service könnte ein Puffer/Cache innerhalb dieser für Ausfallsicherheit (und evtl. schnellere Antwortzeit) sorgen.

    Ich hoffe, ich konnte anhand dieses Beispiels aufzeigen, dass Situationen, die einer komplexen oder besonderen Lösung zu bedürfen scheinen, oft einfach umgesetzt werden können und dadurch Fehler unwahrscheinlicher werden.

    An dieser Stelle möchte ich noch auf das Modularity Maturity Model und OSGi verweisen um Microservices modular und dynamisch zu halten und eine fortgeschrittenere Architektur mit Microservices zu konzipieren.

    Benjamin Buick

     

    ¹ Ohne dies weiter vertiefen zu wollen, möchte ich es mir nicht nehmen lassen, an dieser Stelle anzumerken, dass Microservices im Sinne von OSGi sich ebenfalls ausgezeichnet für eine Resilient Architektur eignen.

    ² Ein byzantinischer Fehler bezeichnet einen Fehler, bei dem sich ein softwareintensives System beliebig falsch verhält. Beispielsweise liefert eine Komponente unregelmäßig falsche Informationen. Mehr Informationen: Byzantinischer Fehler – Wikipedia.

    [MAG] Wronka, Oliver: „Resilient Microservices – Mit Polling schnell zum Ziel“, Java Magazin 11.2015,  S. 86 ff.

     

     

  • 01 Jan

    Willkommen

    Herzlich Willkommen auf meinem Blog.

    Mein Name ist Benjamin Buick und ich heiße Sie herzlich Willkommen.
    Ich bin iSAQB zertifizierter Softwarearchitekt und Softwareentwickler mit Schwerpunkt Java Softwareentwicklung und Entwicklung mobiler Anwendungen. Als Softwarearchitekt interessieren mich vor allen Dingen die MicroService Architektur sowie Resilient (fehlertolerante) und verteilte Systeme.

    Als Entwickler beschäftige ich mich aktuell mit Themen wie Webapplikationen, mobile Anwendungen sowie 3D Programmierung und Augmented / Virtual Reality.

    Neben der Programmierung konzentriere ich mich auch auf organisatorische Themen wie Rapid Prototyping, agile Softwareentwicklung (mit DevOps), Continuous Delivery und Integration.

    Informationen über aktuelle Projekte teile ich des Öfteren über Twitter mit.

    Ich würde mich freuen, wenn Sie mir auf Twitter folgen.

Sie finden mich unter folgenden Stichworten:
Java Entwickler in Frankfurt am Main
Softwarearchitekt in Frankfurt am Main
Android Entwickler in Frankfurt am Main
Appentwickler in Frankfurt am Main
Microservice in Frankfurt am Main

Folgen Sie mir auf Twitter: www.twitter.com/benjaminbuick