• Amazon Web Services AWS

    Amazon Web Services ist eine Plattform für Clouddienste. Die Dienste umfassen die Bereiche Computing, Speicherung und Networking auf verschiedenen Abstraktionsebenen. Die Steuerung der einzelnen AWS-Dienste wird über eine grafische Oberfläche (GUI) oder über PaaS Dienste für diverse Programmiersprachen und eine Kommandozeile angeboten. Als Kunde von Amazon Web Services hat man die Auswahl zwischen verschiedenen Regionen weltweit. Amazon betreibt Rechenzentren in den Vereinigten Staaten, Europa, Asien und Südamerika. Die Dienste können in mehreren Regionen betrieben werden. Somit ist die Konfiguration einer global einheitlichen Infrastruktur möglich. 

     

  •  

    Der Begriff Cloud Computing ist zurzeit in der Informationstechnik allgegenwärtig. Es gibt viele Interpretationen, aber keine standardisierte oder gar einheitliche Definition. Cloud Computing erlaubt die Bereitstellung und Nutzung von IT-Infrastruktur, von Plattformen und von Anwendungen aller Art als im Web elektronisch verfügbare Dienste. Der Begriff Cloud soll dabei andeuten, dass die Dienste von einem Anbieter im Internet erbracht werden. Obwohl es keine standardisierte, einheitliche Definition für Cloud Computing gibt, sind die grundlegenden Konzepte als auch die generellen Ziele des Cloud Computing unbestritten. Cloud Computing nutzt Virtualisierung und das moderne Web, um Ressourcen verschiedenster Art als elektronisch verfügbare Dienste dynamisch bereitzustellen. Die Dienste sollen dabei von mehreren Konsumenten verlässlich und skalierbar nutzbar sein, d. h. sowohl auf Abruf als auch nach Bedarf verfügbar sein. Aus der Sicht des Cloud-Anbieters impliziert dies in der Regel eine Multi-Mandanten Architektur und ein nutzungsabhängiges Abrechnungsmodell. Das Konzept der Virtualisierung erlaubt eine abstrakte, logische Sicht auf physische Ressourcen und umfasst sowohl Server, Datenspeicher, Netzwerke als auch Software. Die zu Grunde liegende Idee ist, physische Ressourcen in Pools zusammenzufassen und gemeinsam zu verwalten. Nach C. Braun definiert sich Cloud Computing demnach wie folgt: 

     

     

    Unter Ausnutzung virtualisierter Rechen- und Speicherressourcen und moderner Web-Technologien stellt Cloud Computing skalierbare, netzwerk-zentrierte, abstrahierte IT-Infrastrukturen, Plattformen und Anwendungen als on-demand Dienste zur Verfügung. Die Abrechnung dieser Dienste erfolgt nutzungsabhängig.

     

    Je nach Zugriffsschicht teilt man Cloud Computing in verschiedene Ebenen der Bereitstellung ein. 

    Infrastructure as a Service (IaaS)

    In der IaaS-Schicht wird den Benutzern eine abstrahierte Sicht auf Hardware angeboten, d. h. auf Rechner, Massenspeicher, Netzwerke etc. Hierfür wird ihm in der Resource Set-Unterschicht eine Benutzerschnittstelle zur Verwaltung einer Menge von Ressourcen bereitgestellt, die ermöglicht, Teile davon für die eigene Verwendung zu allokieren. Typische Funktionalitäten an der Benutzerschnittstelle sind das Anlegen bzw. Beseitigen von Betriebssystem-Abbildern, die Skalierung von beanspruchten Kapazitäten oder die Definition von Netzwerktopologien. Die Schnittstelle bietet darüber hinaus die erforderlichen Funktionalitäten für den operativen Betrieb, wie z. B. das Starten und Stoppen der Betriebssystem-Instanzen.

     

    Platform as a Service (PaaS)

    Die Cloud-Dienste in der PaaS-Schicht richten sich meist nicht an Endkunden sondern an Entwickler. Es sind Entwicklungs- und Laufzeitumgebungen, in denen sich eigene Software in einer bestimmten Programmiersprache entwickeln bzw. ausführen lässt.

     

    Software as a Service (SaaS)

    Software-Anwendungen in der Cloud, die den Endkunden direkt adressieren, gehören zur SaaS-Schicht. Auf der Kundenseite entfällt in dieser Klasse die lokale Software-Installation und mithin auch die Bereitstellung der erforderlichen Ressourcen. Aus Perspektive der beschriebenen Cloud-Architektur kann das SaaS Angebot auf Basis eines Angebots in PaaS oder IaaS beim Anbieter entwickelt und betrieben werden. Innerhalb der SaaS-Angebote lässt sich unterscheiden zwischen Anwendungsdiensten, deren Funktionalität im Wesentlichen auf einer einzigen einfachen Anwendung basiert und vollwertigen komplexen Anwendungen. 

     

    Lesen Sie auch unseren Artikel zu Cloud Computing beim Blickpunkt Rosenheim

  •  

    Hintergrund: Das Backend unserer Produktidee „croGoDeal“ basiert in Teilen auf dem serverless Framework und Amazon Web Services (AWS). Wir nutzen hinter dem API Gateway eine AWS Lambda Funktion, die als GraphQL Schnittstelle dient. Die komplette Nutzerverwaltung wird mit dem AWS Dienst Cognito abgebildet. Damit wir die Schnittstellen in den einzelnen Entwicklungsstufen hinter dem API Gateway testen können, ohne, dass wir die Autorisierung ausbauen müssen, haben wir ein Desktoptool mit Electron entwickelt, dass uns JSON Web Tokens (JWT) generiert. 

      

    Funktionsweise 

    Der Screenshot zeigt die Funktionen der Applikation. Als Input sind lediglich der Cognito UserPool, die ClientId sowie die Benutzeranmeldedaten nötig. Der Token wird nach der Anmeldung rechts angezeigt und kann in ein anderes Entwicklungswerkzeug kopiert werden. Um nicht bei jedem Start die Daten eingeben zu müssen, werden die Einstellungen im Anwendungskontext persistent gespeichert. 

    Technologien 

    Die Anwendung wurde komplett mit der JavaScript-Bibliothek React programmiert, mit der man normalerweise Single Page Applikationen entwickelt. Um eine React App auf einem Desktop-PC nutzen zu können, verwenden wir das Framework „Electron“.

    Electron liefert unsere React-App mit Hilfe von Chromium und Node.js als Desktopapplikation aus. 

    Für die Anbindung zum AWS Cognito Service verwenden wir das offizielle aws-sdk für JavaScript. 

    AWS Cognito Token Generator Software Architektur

     

    Die Datenhaltung und Zustandsänderungen in der Anwendung werden durch Redux nach der Flux-Architektur umgesetzt.  Damit die Eingabedaten persistent erhalten bleiben, werden sie via Key-Value Paaren in den JSON-Storage geschrieben. Dies übernimmt immer der jeweilige Redux-Reducer bevor er den neuen Zustand zurückgibt: 

    // user reducer 

    export default function user(state: any = {}, action: actionType) { 
      switch (action.type) { 
        case SET_USER: 

          if (!action.data.rememberPassword) { 
            delete action.data["password"]; 
          } 

          // save user state persistently 
          storage.set("user", action.data, (err) => { if (err) { console.log(err) } }) 
          return action.data 

        default: 
          return state; 
      } 

    Bei diesem Vorgehen muss man bedenken, dass jede State-Änderung auch einen Schreibzugriff auf die Festplatte mit sich zieht. Sobald man eine App mit sehr vielen State-Änderungen und evtl. großen Objekten entwickelt, sollte man besser auf eine periodische Datenspeicherung zurückgreifen, so wie es auch das Framework redux-persist macht. 

    Der Sourcecode des Projekts ist OpenSource und auf unserer GitHub Seite verfügbar. 

     

    https://github.com/innFactory/aws-session-token-gui  

  • Heute haben wir ein neues Projekt auf der github Seite von innFactory und auf dem npm innFactory Account veröffentlicht. Mithilfe von „react-native-aws-mobile-analytics“ lässt sich AWS Mobile Analytics kinderleicht in react-native Apps integrieren. 

    Das SDK wurde von Anton für unsere croGoDeal App in Anlehnung an das originale AWS Mobile Analytics JS SDK entwickelt und jetzt OpenSource veröffentlicht. Der Einstieg sollte auch für neue Entwickler sehr einfach sein. Bei Fragen und Problemen stehen wir euch natürlich über den Issue-Tracker in github zur Verfügung. 

    SDK in croGoDeal

    Wie bereits erwähnt verwenden wir das SDK selbst für die Analyse und das UI/UX Tracking unserer User in croGoDeal. Neben den gängigen KPI wie "Daily Active User" oder "Monthly Users", können wir mit AWS Mobile Analytics auch A/B Tests und UI/UX Tests über das Toolkit auswerten. Die Tests sind für unsere croGoDeal App und die Strategie der Softwareentwicklung sehr wichtig, damit wir in unsere Hypothesen aus unseren Minimal Viable Products (MVP - Lean Startup) schnell verifizieren oder falsifizieren können. Eine ausführliche Studie, ob sich der geplante Nutzen so eingestellt hat wie erhofft, veröffentlichen wir zu einem späteren Zeitpunkt nach den ersten paar Releases der App.

    Projekt auf github:

    https://github.com/innFactory/react-native-aws-mobile-analytics

     

    Komplettes Beispiel:

    https://github.com/innFactory/react-native-aws-mobile-analytics-demo

     

    NPM Package:

    https://www.npmjs.com/package/react-native-aws-mobile-analytics

     

  • Heute fand das AWS Artificial Intelligence Bootcamp in den VW:Datalab in München statt. Wir waren selbstverständlich vor Ort und haben viel Neues über Deep Learning bei Amazon Web Services gelernt. Neben den AWS AI Diensten Polly, Lex, Recognition und der Machine Learning Plattform selbst, wurde viel über die Technik hinter den Diensten erzählt. Auch das Recommendation System von Amazon basiert auf modernen Deep Learning Algorithmen. Ähnlich wie die anderen großen Hersteller hat auch Amazon ein Open Source Framework für diese Aufgabe.

    MXNet als KI Treiber von Amazon

    Amazon ist der größer Contributor von Apache MXNet. MXNet ist ein skalierbares Deep Learning Framework, das stark an TensorFlow, Caffe, und co. erinnert. Ein Deep Learning Framework zeichnet sich meist dadurch aus, dass es besonders gut mit Matrizen bzw. "Tensoren" umgehen und rechnen kann. MXNet optimiert ähnlich wie Spark auch den Computationgraph und verbessert so die Laufzeit um ein vielfaches.

    Künstliche Intelligenz ersetzt Maschinen 

    Insgesamt war der Tag in München ein voller Erfolg für uns. Teile des neu erworbenen Wissens können wir direkt in unserer Plattform croGoDeal verwenden, auch wenn diese in Scala und nicht in Python programmiert ist/wird. 

    Abschießend zum Event hat einer der Speaker von Amazon Web Services noch interessante Rechenexempel zur künstlichen Intelligenz bzw. zur Singularität gezeigt:

    Ein Mensch kann ca. 10^15 Operationen/s ausführen. Wollte man diese Kapazität mit einem Deep-Learning Netz bei AWS buchen, würde dies knapp 105.000$/h kosten. Alleine für das Training für ein gutes Deep-Learning Model wären schon 3 Wochen nötig. Dieses Beispiel zeigt sehr gut, dass der Mensch wohl doch noch nicht von Maschinen ersetzt wird. Man sollte aber dennoch nicht die „Moorschen Gesetze“ vergessen.

     

  • Wir haben auf github eine erste Alpha Version unseres Machine Learning Tools "akka-lift-ml" unter der Apache 2.0 Lizenz veröffentlicht. Das Tool setzt nach der Arbeit eines Data Scientist an und übernimmt einen Großteil der Aufgaben im Betrieb von ML Systemen. Häufig spricht man auch von Data Engineering. akka-lift-ml ist in Scala geschrieben und erweitert eine lokale Spark Instanz für die Trainingsresultate. Das Training selbst kann auf jedem über das Netzwerk erreichbare Spark Cluster durchgeführt werden.

    Damit das Tool die Machine Learning Aufgaben erfolgreich umsetzten kann, müssen die Daten vollständig bereinigt worden sein. Dies lässt sich beispielsweise mit Spark Streaming oder akka Streaming in nahezu Echtzeit erledigen (FastData Processing). Wenn die Daten im richtigen Format, zum Beispiel csv auf HDFS oder S3, abgelegt worden sind, kann das Training direkt beginnen. Das gesamte Tool wird im Betrieb über REST Schnittstellen oder Aktoren gesteuert und als Docker Container ausgeliefert. So können beispielsweise über HTTP POST neue Trainingsläufe gestartet werden, neue beste Parameter gefunden werden und auch mit HTTP GET auf die Ergebnisse der vergangenen Trainingsdurchläufe zugegriffen werden. Sollte der Microservice abstürzen, wird automatisch das letzte trainierte Model von einer Quelle wie S3 oder HDFS geladen. 

    Derzeit unterstützt das Tool lediglich den ALS (Alternating Least Squares) Algorithmus für Collaborative-Filtering. Dieser wird sehr häufig im Bereich Recommendersysteme eingesetzt. Weiter Algorithmen wie für lineare Regression sollen ergänzt werden. 

    Wünsche, Anregungen und Verbesserungsvorschläge können Sie uns gerne über github zukommen lassen.

    Weitere Informationen und eine QuickStart Guide finden sie in der Beschreibung oder im Wiki System auf github:

    https://github.com/innFactory/akka-lift-ml

     

  • Der nachfolgende Blogbeitrag soll den Einstieg in die DevOps Welt mit Amazon Web Services vereinfachen. Wir werden alle notwendigen Schritte anhand von Screenshots in der AWS Konsole durchgehen und eine Pipeline mit AWS CodePipeline aufbauen. Die Pipeline soll mit einem GitHub Repostiory beginnen, mit CodeBuild gebuildet werden und über CodeDeploy im Echtbetrieb in einer Elastic Beanstalk Umgebung enden. Als Referenzprojekt für eine Microservice kann unser giter8 Template für akka-http oder akka-graphql verwendet werden. Bei beiden müssen allerdings kleine Änderungen vorgenommen werden. Die Pipeline soll akka Microservices, die das Buildtool sbt verwenden, in den Betrieb überführen. Für Java Server, wie Payara Micro oder Wildfly Swarm, können nur ein paar Schritte verwendet werden. Vor allem die Vorbereitung des Projektes auf GitHub unterscheidet sich von einem Scala/Java akka Projekt.


    Bevor wir mit den Anpassungen unserer Dateien in unserem GitHub Repository beginnen, müssen wir zuerst ein Docker Repository anlegen. Dazu wechseln wir in die Elastic Container Service Oberfläche und klicken auf „Create Repository“. Wir vergeben hier lediglich den Namen unseres Projektes (innfactory-akka-http-ci-test) und schreiben uns die Repository URI auf. Mehr müssen wir in diesem Dienst nicht machen.

    EC2 Container Registry


    Als nächstes benötigen wir eine neue Datei Dockerrun.aws.json für AWS CodeDeploy. Die Werte bei Image – Name müssen entsprechend unseres ECR Repositorys angepasst werden. In diesem Beispiel pushen wir unserer Docker Container immer auf latest. Für mehrere Branches in github sind weitere Anpassungen notwendig.

      "AWSEBDockerrunVersion": "1",
      "Image": {
        "Name": "149805022439.dkr.ecr.eu-central-1.amazonaws.com/innfactory-akka-http-ci:latest",
        "Update": "true"
      },
      "Ports": [
        {
          "ContainerPort": "8080"
        }
      ]
    }
    

    Für den Buildprozess mit AWS CodeBuild benötigen wir nun noch eine buildspec.yml Datei die wie folgt aussehen kann. Die Variablen bleiben leer, denn sie werden später mithilfe von Umgebungsvariablen von AWS ersetzt. Unsere giter8 Templates sind für Docker vorbereitet, somit können die benötigten Parameter beim sbt docker:publish Aufruf übergeben werden. 

    version: 0.2
    
    env:
      variables: 
        STAGE: "dev"
        SQLURL: ""
        SQLUSER: ""
        SQLPASSWORD: ""
    
    phases:
      install:
        commands:
          - echo "continuous delivery for stage[$STAGE]"
          - echo "selected db=$SQLURL"
          - echo "$(lsb_release -cs)"
          - apt-get update -y
          - apt-get install -y apt-transport-https ca-certificates software-properties-common
          - add-apt-repository -y ppa:openjdk-r/ppa
          - sudo apt-get update -y
          - apt-get install -y openjdk-8-jdk
          - echo "deb https://dl.bintray.com/sbt/debian /" | sudo tee -a /etc/apt/sources.list.d/sbt.list
          - apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823
          - apt-get update -y
          - apt-get install -y sbt
          - pip install --upgrade awscli
      pre_build:
        commands:
          - $(aws ecr get-login --no-include-email --region eu-central-1) 
      build:
        commands:
          - sbt test
          - sbt -DSTAGE=$STAGE -DSQL_URL=$SQLURL -DSQL_USER=$SQLUSER -DSQL_PASSWORD=$SQLPASSWORD docker:publish
      post_build:
        commands:
          - echo Build completed on `date`
    artifacts:
      files:
        - Dockerrun.aws.json 

    Einrichtung einer Elastic Beanstalk Umgebung

    Bevor wir mit der Continuous Delivery Pipeline beginnen, starten wir zuerst eine neue Elastic Beanstalk Umgebung, da diese ein paar Minuten zum Start benötigt. 

    Hierzu wechseln wir in der AWS Konsole zum Dienst Elastic Benastalk und erstellen eine neue Applikation.

    Create new Elastic Beanstalk application

    In dieser Applikation erstellen wir wiederum eine neue Umgebung (Web server environment) und konfigurieren diese als Docker Platform und lassen erst einmal die Sample Application von Amazon darauf laufen. 

    Beanstalk Environment Tier wählen

    Wir müssen keine weiteren Anpassungen mehr vornehmen und können die Umgebung mit einem Klick auf „Create environment“ erstellen. Alle nicht vorhandenen, aber benötigten, Informationen werden von AWS automatisch ergänzt. 

    AWS Beanstalk Environment Einstellungen

    Sollten wir weitere Anpassungen vornehmen wollen, können wir dies unter „Configure more options“ tun. Hier können wir unter anderem die zu startenden Instanzengrößen wählen, die Load Balancer mit https konfigurieren, das Monitoring anpassen, das richtige VPC Netzwerk auswählen, eine RDS Datenbank hinzufügen und noch vieles mehr. Als Hinweis dazu sei erwähnt, dass man niemals eine RDS Datenbank für den produktiven Betrieb in Beanstalk konfigurieren sollte. Diese hängt sonst an der Umgebung und wird gegebenenfalls zusammen mit der Umgebung gelöscht. 

    Nach ein paar Minuten sollte unsere Elastic Benastalk Umgebung mit der Sample Application von AWS gestartet sein.

    Elastic Beanstalk Übersicht


    Erstellung der Pipeline mit AWS CodePipeline

    Beginnen wir mit der eigentlichen Pipeline. Zuerst müssen wir einen Namen vergeben. Dieser kann später nicht mehr verändert werden und sollte er sinnvoll gewählt werden. 

    AWS CodePipeline anlegen

    Als nächstes müssen wir die Quelle unserer Pipeline auswählen. Sollte unser Projekt in AWS CodeCommit gehostet sein, kann dies ebenso verwendet werden wie GitHub. Wir verwenden in diesem Beispiel unsere GitHub Organisation innFactory und ein beliebiges akka sbt Projekt. Unter Advanced müssen wir keine Einstellungen vornehmen und wir können die Pipeline automatisch bei einem neuen git push auf den master starten lassen.

    Code Pipeline Quelle (CodeCommit oder GitHub)

    Für die Buildphase nutzen wir CodeBuild von AWS. Hierzu wählen wir „Create a new build project“ und konfigurieren die Einstellungen wie auf den nachfolgenden Screenshots zu sehen. Wir können beliebige Umgebungsvariablen hinzufügen, die in der buildspec.yml Datei aufgelöst werden. Wir haben dies bereits für unsere Datenbankparameter verwendet und die Konfiguration unseres akka Projektes wird, wenn es als Docker Instanz läuft, mit diesen Variablen überschrieben. Für produktive Systeme sollten die Passwörter nicht als Plaintext übergeben werden, sondern ein EC2 Parameter Store verwendet werden.

    AWS CodeBuild konfiguration

    AWS CodeBuild Umgebungsvariablen für RDS Datenbank

    Auf der Seite für das Deployment können wir unsere Elastic Beanstalk Application und unsere Umgebung mit der Sample Application verwenden.

    CodePipeline Deployment zu Elastic Beanstalk

    Zum Schluss müssen wir noch noch eine Rolle für die Pipeline anlegen und alle bisher definierten Rollen über AWS IAM anpassen. Wichtig ist, dass unsere verwendeten Rollen Zugriff auf das Docker Repository und auf Beanstalk haben. Sollte dies nicht konfiguriert worden sein, wird die Pipeline mit entsprechender Meldung fehlschlagen.

    CodePipeline Service Rolle


    Nachdem wir die Pipeline nun vollständig konfiguriert haben, startet diese automatisch. Haben wir alles richtig gemacht und alle Berechtigungen richtig vergeben sollte das Ergebnis wie folgt aussehen und die Sample Application in Elastic Beanstalk durch unseren neuen Docker Container ersetzt worden sein. 

    AWS akka CodePipline Erfolgreicher Deploy

  • Das Team von innFactory war vergangene Woche in Lissabon auf der größten Technologie Messe der Welt. An drei Tagen präsentierten sich hier Startups in sämtlichen Wachstums- und Finanzierungsphasen mit ihre Ideen in Form von Messeständen und Pitches. Der beste Pitch gewann dabei ein Preisgeld von 50000 EUR, das von Mercedes Benz zur Verfügung gestellt wurde. Auch wir hatten als Startup am Dienstag einen Messestand für unseren Chatbot croGo. 

    Neben den vielen Startups waren auch die meisten großen etablierten Big-Player wie Amazon Web Services, Facebook, Google, Uber, Slack, Microsoft, BMW, Mercedes Benz und noch viele weitere aus allen möglichen Branchen auf der Websummit vertreten. Sie präsentierten sich ebenfalls mit Messeständen.

    Zusätzlich wurde die Messe durch eine Vielzahl von Vorträge von über 1200 internationale Topspeaker begleitet. Thematisch deckten die Talks alle erdenklichen Themenfelder die für Startups relevant sind ab. Von sehr technischen Schulungen für Cloud-Computing und modernen progressive Web Apps mit React und React-Native, über die Zukunft von Methoden wie Lean-Startup, bis hin zu futuristischen Ankündigungen, wie den fliegenden Taxis von Uber war auf der Messe alles vertreten.

    Da auf der Messe tausende Investoren aus allen Länder unterwegs waren, hatte auch wir als junges Startup die Chance auf eine 4-Augen Gespräch mit einem Topinvestor und konnte somit unser persönliches Profil weiter schärfen und uns durch Mentoring verbessern.

    Die Messe konnte uns somit in vielerlei Dingen unterstützen und wir planen auch 2018 wieder teilzunehmen.

    Weiter Bilder zum Messebesuch befinden sich auf unserer Instagram Seite (innfactory)