Cloud & Microservice Blog

Unser Blog hilft Cloud Computing, Machine Learning, Microservices und viele weitere Hypes zu verstehen...

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv

 

Wir bei innFactory setzen von Beginn an auf Microservices im Backend. Die technologische Unabhängigkeit und die flexible Skalierbarkeit zwischen den einzelnen Services sind in unseren Augen unschlagbar. Zusätzlich lassen Frameworks wie Lagom (Scala) das „Mehr-Overhead“ Argument verstummen.

Letzte Woche war ich im Rahmen der Veranstaltung „Microservices“ als Dozent zu Gast an der Hochschule Rosenheim und habe mich der Frage gewidmet, inwiefern sich das Frontend an die Microservice Architektur im Backend anpassen und integrieren lässt.

Der "klassische" Ansatz

Das Frontend wird beim klassischen Ansatz als Monolith belassen. Nach unserer Erfahrung ist das auch bislang der gängigste Weg, um ein Frontend an ein Backend mit Microservice Architektur anzubinden. Das Entwickler Team besteht dabei meist ausschließlich aus Frontend Spezialisten, die das Backend über einen sogenannten „Aggregation Layer“ (das Backend) einbinden. Der Aggregation Layer sorgt für eine spezielle API, zugeschnitten auf die jeweiligen Bedürfnisse. So kann beispielweise die App und die Website mit einer genau passenden Schnittstelle bedient werden, um den Datentransfer gering und die Klarheit hoch zu halten. Um dieses sogenannte „Backend for Frontend Pattern“ dynamischer umzusetzen, verwenden wir bei innFactory überwiegend GraphQL als Abfragesprache für die API.

Single Page Microservice UI
Klassische Microservice UI

Der "FullStack" Ansatz

Im Gegensatz zur klassischen Architektur führt der FullStack Ansatz die Idee hinter den Microservices weiter bis in das Frontend. Zwar sind die einzelnen Services nach wie vor zwischen Back- und Frontend getrennt, jedoch ergeben sich technologisch gemischte Entwickler Teams, die auf einen bestimmten Use Case gerichtet sind. Meist wirkt sich das sehr positiv auf den Knowhow-Transfer innerhalb des Entwickler-Teams aus, allerdings entstehen im Frontend auch erhebliche Hürden, die weiter unten unter „Probleme bei der UI-Ausarbeitung mit einer Microservice-Architektur“ erklärt werden.

 

FullStack Microservice UI
FullStack Microservice UI

Vergleich: Klassisch – FullStack

Folgender Vergleich soll die Tendenzen aufzeigen, nach denen sich die beiden Ansätze unserer Erfahrung nach unterscheiden:

"Klassisch"

  • Best Practise – geringes technisches Risiko
  • Schnellere Einarbeitung neuer Entwickler
  • One team, one user experience

 

"FullStack"

  • Größerer Wissenstransfer im Team
  • Flexiblere Entwickler (+ oft höhere Eigenmotivation für FullStack Projekte)
  • Fokus komplett auf einen Service gerichtet

Technische Probleme bei der UI-Ausarbeitung mit einer Microservice-Architektur

Eine besondere Herausforderung stellt der Austausch von UI-Komponenten zwischen den einzelnen Teams dar. Dies liegt allen voran daran, dass, wie in einer Microservice Architektur üblich, jedes Team unabhängig ihre Komponenten warten und deployen können soll. Einen interessanten Ansatz verfolgt OpenTable mit ihrem serverless GUI-Framework OpenComponents (https://github.com/opentable/oc).

 

Microservice UI Problems
Microservice UI Probleme

 

Im Backend sind die einzelnen Microservices technisch vollkommen unabhängig. Diese Unabhängigkeit auch im Frontend bereit zu stellen und jedem Team frei zwischen Frameworks oder Libraries, wie React, Angular oder Ember wählen zu lassen, ist nur schwer realisierbar. Hinzu kommen darüber hinaus viele verschiedene Versionen der genannten Frameworks sowie anderen Javascript Erweiterungen. Der Browser wäre bei clientseitigem Rendering gezwungen unzählige Javascript Dateien zu laden, was die Geschwindigkeit auf einen inakzeptablen Wert drücken würde. Aber auch serverseitiges Rendering mit z.B. next.js ist mit unterschiedlichen Libraries und Versionen aus Gründen der Kompatibilität nicht umsetzbar.

Different UI Libs
Unterschiedliche UI Frameworks

 

Um trotzdem eine Microservice Architektur zu realisieren bleibt nur eine einheitliche technische Basis aller Teams. Dies kann ein einziges Framework sein oder auch die Entwicklung in reinem Javascript, CSS und HTML. Ein vielversprechender Ansatz ist der WebComponents Standard, auf den sich die großen Browserhersteller derzeit vorbereiten.

Fazit

Die Frontend Architektur der Microservices anzupassen verspricht gerade bei sehr großen Projekten Vorteile in der Teamstrukturierung sowie klare Verantwortlichkeiten der Services. Technologisch wird diese Herausforderung am besten mit dem Verzicht auf externe Frameworks und Libraries bewältigt. Eine Überlegung ist, in naher Zukunft eigene HTML-Tags mit WebComponents zu implementieren, um die gewünschte Unabhängigkeit zu erreichen.

 

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv

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

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv

Reaktive Systeme sind Computersysteme die kontinuierlich auf ihre Umgebung reagieren. Der in diesem Zusammenhang geprägte Begriff des Aktorenmodells wurde erstmals in den frühen 1970er Jahren von Carl Hewitt verwendet. Sein mathematisches Model beschreibt ein universales Verfahren zur parallelen Programmierung.  Er war seiner Zeit weit voraus, da zu diesem Zeitpunkt die Rechner noch nicht leistungsfähig genug waren. Das Modell wurde erstmals 1987 in der Programmiersprache Erlang von Ericsson verwendet. Durch den Einsatz der Technologie konnte Ericsson einen Switch mit einer Zuverlässigkeit von 99,999999999% bauen. Dies entspricht einer Ausfallzeit von unter 0.65 Sekunden in 20 Jahren. In den nachfolgenden Jahrzehnten stieg die Leistung der Computer immer weiter an. Anfang des neuen Jahrtausends erreichten die Prozessoren mit den eingesetzten Materialien ihre maximale Taktfrequenz. Prozessorhersteller, wie Intel und AMD, bauten fortan Prozessoren mit mehreren Prozessorkernen bei gleichbleibender Taktfrequenz. Einerseits kann die Hitzeentwicklung bei noch höheren Taktraten mit herkömmlichen Mitteln nicht mehr bewältigt werden. Andererseits kommt es bei immer kleineren Transistoren zu quantenmechanischen Seiteneffekten. Heute erhöhen die Hersteller die Anzahl der Kerne pro CPU, um dennoch eine Leistungssteigerung der CPUs zu erreichen. Dadurch steigt die Relevanz von paralleler Programmierung, da die Berechnung der Algorithmen auf mehrere CPU-Kerne verteilt werden muss. Die Entwicklung von Software mit mehreren Threads, oder über mehrere Rechner hinweg, ist für Entwickler mit vielen Problemen verbunden und kompliziert. Dies ist unter anderem auf die Speicherverwaltung der Threads und Prozesse zurückzuführen. Als Folge entstehen in den letzten Jahren immer mehr reaktive Frameworks für moderne Programmiersprachen, wie zum Beispiel akka für Scala und Java. Reaktive Frameworks bieten dem Entwickler aber weitaus mehr, als nur einfache Parallelisierung über mehrere Prozesse und physikalische Knoten. Mithilfe der Frameworks lassen sich hochskalierbare, fehlertolerante Systeme entwerfen. In diesem Blogbeitrag, wollen wir das Aktorenmodell genauer betrachten.


Der Entwurf von nebenläufigen Anwendungen stellt seit Jahren eine Herausforderung dar, für die es keine einfache Lösung gibt. Das Aktorenmodell stellt eine erprobte und vergleichsweise einfache Weise dar, nebenläufige Algorithmen umzusetzen. Das Aktorenmodell ist ein Architekturmuster, dass auf Basis von Nachrichtenaustausch (=Message Passing) eine verteilte Applikation ermöglicht, ohne dabei einen geteilten Zustand (=Shared State) mit mehren Aktoren zu benötigen. Das Aktorenmodell ist vielfach implementiert, teils in funktionalen Sprachen wie Erlang, teils als Frameworks wie akka oder libcppa. Ein Aktor ist ein leichtgewichtiger und autonomer Prozess. Dem Aktor können Nachrichten geschickt werden, für die er ein eigenes Verhalten bereit hält, welches sich zur Laufzeit in der Regel nicht verändert. Ein Aktor arbeitet dabei immer nur eine Nachricht gleichzeitig ab. Das Aktormodell ist nicht an spezielle Datenstrukturen gebunden, sodass Aktoren lose gekoppelt untereinander kommunizieren können. Leichtgewichtig ist ein Aktor, da er kein eigenen Prozess besitzt, sondern zum Verarbeiten einer Nachricht einen Prozess zugewiesen bekommt. Aktoren nutzen die verfügbaren Ressourcen eines Threads optimal aus und blockieren die Verarbeitung nicht. 

Aktorenmodell Actors akka

Die Abbildung zeigt ein beispielhaftes Netz von Aktoren. Jeder Aktor hat seine eigene Mailbox und einen isolierten Zustand. Basierend auf seinem definierten Verhalten antwortet der Aktor mit dem versenden einer eigenen Nachricht oder erstellt eigene Aktoren und ändert sein zukünftiges Verhalten. Zusammengefasst definiert sich ein Aktorsystem durch folgende Eigenschaften:

  • Ein Aktor kann andere Aktoren erschaffen und mit ihnen kommunizieren.
  • Jeder Aktor hat einen eindeutigen Namen, der als Adresse bei der Kommunikation verwendet werden kann. (in akka)
  • Die Kommunikation zwischen Aktoren basiert auf dem Senden von asynchronen, unveränderbaren (=immutable) Nachrichten an andere Aktoren.
  • Die Nachrichten werden zur Verarbeitung in einer Mailbox gepuffert. Sie ist eine Queue mit n Produzenten (Senderaktor) und einem Konsumenten (Empfängeraktor)
  • Abhängig von der Reihenfolge, den Prioritäten oder dem internen Zustand werden die Nachrichten mittels Pattern Matching von internen Funktionen verarbeitet, die die Ergebnisse ihrerseits wieder als Nachrichten versenden. 

Akka bildet das Aktorenmodell als Framework für die JVM ab. Es wird häufig in den Programmiersprachen Scala und Java verwendet und wurde erstmals im Juli 2009 bei GitHub von Jonas Bonér veröffentlicht. Ein Aktor ist in akka die kleinste Einheit im System und übernimmt in der Regel eine bestimmte Aufgabe. Dabei kann der Aktor seinen Zustand, und damit das Verhalten beim Eintreffen bei weiteren Nachrichten, verändern. Der Zustand eines Aktors wird durch die Werte seiner Variablen definiert. Diese Werte können ausschließlich durch eingehende Nachrichten anderer Aktoren geändert werden. Da es keine gemeinsamen Speicherbereiche mit anderen Aktoren gibt, ist gewährleistet, dass der Zustand eines Aktors nicht durch Zugriffe von außen manipuliert werden kann. Sollte ein Aktor durch einen Fehler zum Absturz gebracht werden, kann der Supervisor, also der Erzeuger des Aktors, den Aktor neu initialisieren und wiederherstellen. Das Verhalten eines Aktors bezeichnet die Logik die beim Eintreffen einer Nachricht ausgeführt wird. Die Logik kann jederzeit als Reaktion auf eine Nachricht verändert werden. Jeder Aktor hat genau eine Mailbox für den Empfang von Nachrichten. Die Mailbox ist standardmäßig eine First In – First Out (FiFo) Queue. Die Queue der Mailbox kann in akka so konfiguriert werden, dass bestimmte Nachrichten priorisiert bearbeitet werden. Auch die Größe der Queue ist frei definierbar.   

akka bietet noch viele weiter Vorteile, die in vielen verschiedenen Blogbeiträgen im Internet und in einschlägigen Büchern beschrieben werden. Dazu zählen unter anderem der Remotezugriff oder das Clustering. Diese Fähigkeiten, macht akka zu einem hervorragendem Framework für moderne Microservices. Häufig findet man akka im sogenannten SMACK Stack wieder - SMACK steht hierbei für Spark, Mesos, akka, Cassandra, Kafka. Dieser Stack ist die Basis für unser Fast Data System bei croGoDeal.


Reaktive Programmierung ist aktuell wie nie zuvor. Der Begriff ist allerdings nicht genau definiert. Somit bezeichnen sich viele Applikationen als reaktiv, die es gar nicht sind. Reaktive Programmierung wird häufig mehr als Buzzword für eine spezielle Art von asynchrone Programmierung verwendet. Die vermutlich am besten passende Beschreibung einer reaktiven Architektur liefert das Reactivo Manifesto. Das möglichst einfache Erreichen der Ziele des Reactivo Manifestos verfolgen diverse Frameworks. Eines der besten für Java und Scala ist derzeit akka. Es ist mit verhältnismäßig einfachen Mitteln möglich antwortbereite, widerstandsfähige, elastische und nachrichtenorientierte Systeme auf Basis der JVM zu implementieren. Ein Java oder Scala Softwarearchitekt für skalierbare Applikationen sollte sich unbedingt erweiterte Kenntnisse in akka aneignen und das Framework in seine Planung mit einbeziehen.   

Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv

 

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

Kategorien

  • Neuigkeiten
  • Gastbeiträge
  • Data Science & Engineering
  • Softwareentwicklung
  • Innovationen aus aller Welt
  • Microservices & Cloud Computing

Blogbeiträge

Microservice Blog

Die Buzzwords Digitalisierung und Industrie 4.0 sind in aller Munde, aber was bedeutet das für die Unternehmer? Unser Blog hilft dabei, die Cloud, Machine Learning, die Blockchain und viele weitere Hypes und Trends zu verstehen. Unser Schwerpunkt liegt dabei klar auf dem Cloud Computing und der Programmierung von verteilten Softwarelösungen, da unsere Expertise dort am Größten ist.