Wir bringen eine Java-Anwendung in die Cloud - Teil 2

Migration nach AWS: Verwendung von Managed Services

Sascha Möllering, Michael Graumann

©Shutterstock / Artram

In diesem Artikel zeigen wir, wie sich eine bestehende Java-Applikation innerhalb weniger Minuten so bereitstellen lässt, dass wir uns mit dem Betrieb der Infrastruktur kaum noch auseinandersetzen müssen. Im Laufe des Artikels werden wir auf unterschiedliche Automatisierungsoptionen bei AWS Elastic Beanstalk eingehen. So können wir uns auf die Weiterentwicklung der Applikation selbst fokussieren.

Im ersten Teil unserer Artikelserie haben wir näher betrachtet, wie eine typische Lift-and-Shift-Migration aus dem eigenen Rechenzentrum nach AWS aussieht und welche Tools und Services dabei unterstützen. Dabei steht im Vordergrund, die Flexibilität im IT-Betriebsbereich zu erhöhen und den Zugriff auf Infrastrukturressourcen zu beschleunigen und zu vereinfachen. Für viele Anwendungen ist Lift and Shift der erste Schritt, auf den weitere Optimierungen hinsichtlich Sicherheit, Verfügbarkeit, Leistung, Betreibbarkeit und Kosten folgen. In Abbildung 1 werfen wir einen Blick auf unsere aktuelle Architektur.

Artikelserie

Teil 1: Warum wechseln?

Teil 2: Verwendung von Managed Services

Teil 3: Entkopplung mit Containern

Teil 4: Serverless mit AWS Lambda

Teil 5: Optimierung der Architektur

Teil 6: Sicherheit und Verschlüsselung

 

Abb. 1: Die aktuelle Architektur als Schaubild

Abb. 1: Die aktuelle Architektur als Schaubild

Der Application Load Balancer [1] empfängt alle Requests und verteilt sie auf die Apache-Webserver, die in unserem Fall statischen Content ausliefern und Requests für dynamische Inhalte an die Tomcat-Instanzen weiterleiten. Die Webserver laufen als EC2-Instanzen, also virtuelle Maschinen, die in einer eigenen Security Group stehen. Hinter den Tomcats steht eine Amazon-RDS-MySQL-Datenbank [2]. Um die Performance der Datenbankabfragen zu steigern, steht ein von Amazon ElastiCache [3] verwalteter Redis-Cache zur Verfügung.

Auch wenn wir hier bereits Managed Services für die MySQL-Datenbank und den Redis-Cache verwenden, bleiben einige operative Aufgaben, um die Infrastruktur zu betreiben, offen. Das sind beispielsweise:

  • einmaliges Aufsetzen der Netzwerkkonfiguration (Amazon Virtual Private Cloud)

    • Definition der Subnetze

    • Pflege der Routingtabelle

    • Aufsetzen der Security Groups

  • einmaliges Aufsetzen der EC2-Instanzen (bisher ist kein Auto Scaling implementiert)

    • Installation der Apache-Webserver und Tomcat

  • einmaliges Aufsetzen des Application Load Balancer

    • Definition des Routings

    • Definition des Health Checks

  • einmaliges Aufsetzen von ElastiCache

  • einmaliges Aufsetzen von RDS

  • regelmäßige Härtung sowie Updates der EC2-Instanzen

  • kontinuierliches Monitoring

Einige dieser Aufgaben können wir Elastic Beanstalk überlassen, womit wir mehr Zeit zur eigentlichen Anwendungsentwicklung gewinnen. Im einfachsten Fall – wenn wir die Standardeinstellungen von Elastic Beanstalk übernehmen – können wir die operativen Aufgaben auf die folgenden reduzieren:

  • einmaliges Aufsetzen von ElastiCache

  • einmaliges Aufsetzen von RDS

  • regelmäßige Härtung sowie Updates der EC2-Instanzen

Wie wir im folgenden Abschnitt sehen werden, steht es dem Kunden frei, diese Standardeinstellungen zu überschreiben.

Motivation zur Migration auf AWS Elastic Beanstalk

AWS Elastic Beanstalk [4] reduziert den Verwaltungsaufwand für den Betrieb von Applikationen, ohne dabei die Plattform- und Parameterauswahl oder die Kontrolle einzuschränken. Der Kunde lädt seine Anwendung hoch und Elastic Beanstalk übernimmt Kapazitätsbereitstellung, Lastverteilung, Skalierung und Überwachung des Anwendungsstatus. Alternativ können diese Komponenten durch den Kunden individuell angepasst werden. Es werden Webanwendungen unterstützt, die mit Java, .NET, PHP, Node.js, Python, Ruby, Go und Docker auf bekannten Servern wie Apache, NGINX, Passenger und IIS entwickelt wurden.

Gleichzeitig behalten Kunden die volle Kontrolle über die AWS-Ressourcen, die ihre Anwendung unterstützen, und können jederzeit auf die zugrunde liegenden Ressourcen zugreifen. Beispielsweise ist es möglich, den Instanztyp der genutzten EC2-Instanzen zu ändern, falls ein anderer Typ aufgrund geänderter Anforderungen ein besseres Preis-Leistungs-Verhältnis bietet. Elastic Beanstalk ist kostenlos – es müssen nur die AWS-Ressourcen bezahlt werden, die für die Speicherung und Ausführung der Anwendungen benötigt werden.

 

Unterschiedliche Deployment-Optionen

Ein weiterer Vorteil der Verwendung von AWS Elastic Beanstalk im Gegensatz zum klassischen Betrieb der Applikationen auf virtuellen Maschinen (EC2) besteht in der Unterstützung verschiedenster Deployment-Optionen, darunter Policies wie „All at once“ (alle auf einmal), „Rolling“ (fortlaufend), „Rolling with additional batch“ (fortlaufend mit zusätzlichem Batch) und „Immutable“ (unveränderlich). Es gibt Optionen, mit denen wir die Batchgröße sowie das Health-Check-Verhalten während der Deployments konfigurieren können. Standardmäßig stellt Ihre Umgebung alle Deployments gleichzeitig bereit. Wenn wir die Umgebung über das EB CLI (Kasten: „Amazon Elastic Beanstalk CLI“) erstellt haben und es sich um eine automatisch skalierte Umgebung handelt (d. h., wir haben die Option –single nicht angegeben), werden Rolling Deployments verwendet. Daneben werden auch Blue-Green-Deployments unterstützt.

Amazon Elastic Beanstalk CLI

Das EB CLI ist ein Command Line Interface für Elastic Beanstalk, das interaktive Befehle bereitstellt, um das Erstellen, Aktualisieren und Überwachen von Umgebungen aus einem lokalen Repository vereinfachen. Typischerweise wird das EB CLI als Teil des täglichen Entwicklungs- und Testzyklus als Alternative zur AWS Management Console genutzt, um Prozesse zu automatisieren. Nachdem das EB CLI installiert und ein Repository konfiguriert worden ist, können Umgebungen mit einem einzigen Befehl erstellt werden: ~/my-app$ *eb *create* my-env*

In unserem konkreten Beispiel haben wir eine Java-Anwendung, die im Tomcat-Servlet-Container läuft. AWS Elastic Beanstalk unterstützt mehrere Plattformversionen für Java-Anwendungen, darunter mehrere Versionen von Java mit dem Tomcat-Anwendungsserver und reine Java-Plattformversionen für Anwendungen, die Tomcat nicht verwenden (aktuell wird OpenJDK als Java Runtime für Elastic Beanstalk verwendet).

AWS bietet mehrere Werkzeuge für die Arbeit mit Java und Elastic Beanstalk. Unabhängig von der gewählten Plattformversion können mit dem AWS SDK für Java [5] AWS-Dienste aus Java-Anwendungen heraus genutzt werden. Das AWS SDK für Java ermöglicht es, AWS APIs aus dem Anwendungscode zu verwenden. Zusätzlich existiert auch das AWS Toolkit [6] für verschiedene Entwicklungsumgebungen (u. a. IntelliJ und Eclipse). Das ist ein Open-Source-Plug-in, mit dem AWS-Ressourcen, einschließlich Elastic-Beanstalk-Anwendungen und -Umgebungen, direkt in der IDE verwaltet werden können.

Die AWS-Elastic-Beanstalk-Tomcat-Plattform stellt eine Reihe von Umgebungskonfigurationen für Java-Webanwendungen auf Basis von Tomcat dar. Jede Konfiguration entspricht einer Hauptversion von Tomcat, wie Java 8 mit Tomcat 8. Die Plattform beinhaltet einen Reverse-Proxy, der Anfragen an Anwendungen weiterleitet. Der Standardserver ist Apache HTTP Server in Version 2.4. Statt Apache kann auch NGINX verwendet werden.

Java-Anwendungen müssen in einer Web-Application-Archive-Datei (WAR-Datei) zusammengefasst werden. Um mehrere Anwendungen auf demselben Webserver auszuführen, können mehrere WAR-Dateien in einem einzigen Quellpaket gebündelt werden. Elastic Beanstalk bietet auch Konfigurationsoptionen, um den Proxyserver so zu konfigurieren, dass statische Objekte aus einem Ordner im Quellcode bereitgestellt werden, um die Last auf die Anwendung zu reduzieren. In der aktuellen Iteration unserer Beispielanwendung nutzen wir diese Möglichkeit, um die Gesamtarchitektur zu vereinfachen.

In folgenden Iterationen werden wir die Auslieferung der statischen Assets wie Bilder, HTML-Dateien und JavaScript-Dateien vollständig serverless [7] mit Hilfe des Object Stores Amazon S3 und des Content Delivery Networks Amazon CloudFront durchführen. Der große Vorteil dieses Vorgehens besteht zum einen darin, dass keine eigenen Server betrieben werden müssen, zum anderen wird die Last für die Auslieferung der statischen Dateien von den Webservern in vollständig verwaltete Services verlagert.

Migration auf AWS Elastic Beanstalk

In unserem Szenario läuft die Anwendung aktuell auf selbst aufgesetzter Infrastruktur. Unser nächstes Ziel besteht in der Migration auf eine Elastic-Beanstalk-Umgebung. Die Migration der bestehenden Anwendung ist einfach möglich: Parallel zur bestehenden Infrastruktur sollte in einer Testumgebung eine Infrastruktur mit Elastic Beanstalk aufgebaut werden, um das Deployment und die fehlerfreie Funktionalität der Anwendung zu testen. Diese Elastic-Beanstalk-Umgebung kann – wie bereits skizziert – entweder mit dem Elastic Beanstalk CLI [8] oder Infrastructure-as-Code-Werkzeugen wie AWS CloudFormation [9], AWS Cloud Development Kit (CDK) [10], HashiCorp Terraform [11] oder ähnlichen aufgesetzt werden. Beim Aufsetzen einer Elastic-Beanstalk-Umgebung können umfangreiche Konfigurationsparameter angepasst werden: Instanztypen, Load Balancer, Monitoring, Datenbanken mit RDS sowie weitere Einstellungen.

Im Folgenden werfen wir einen genaueren Blick auf die Migration. Zunächst befassen wir uns mit den Infrastrukturkomponenten, um uns anschließend dem Deployment der eigentlichen Applikation zu widmen. Schließlich sehen wir uns an, wie wir über Konfigurationsdateien unsere gesamte Applikation reproduzierbar definieren können.

Load Balancer

Da wir die Hochverfügbarkeit unserer Applikation sicherstellen wollen, wird ein Load Balancer benötigt. Elastic Beanstalk unterstützt Application Load Balancer, Classic Load Balancer sowie Network Load Balancer. In unserem konkreten Fall bietet sich der Application Load Balancer an. Dieser leitet HTTP- und HTTPS-Datenverkehr basierend auf Protokoll, Port und Route zu Umgebungsprozessen weiter. Neben dem Load Balancer erstellt Elastic Beanstalk eine Auto-Scaling-Gruppe, die die Amazon-EC2-Instanzen der Umgebung verwaltet. In einer Umgebung mit einer einzelnen EC2-Instanz stellt die Auto-Scaling-Gruppe sicher, dass immer eine Instanz läuft (self-healing). Typischerweise ist in einer solchen Umgebung Load Balancing konfiguriert, was zur Folge hat, dass die Gruppe mehrere Instanzen enthält. In diesem Fall fügt Amazon EC2 Auto Scaling bei Bedarf Instanzen hinzu oder entfernt sie – je nach Last. Darüber hinaus verwaltet die Auto-Scaling-Gruppe auch die Startkonfiguration für die Instanzen in der Umgebung. Die Startkonfiguration kann definiert werden, um den Instanztyp, das SSH-Schlüsselpaar (für den Zugriff auf die EC2-Instanzen per SSH), den Amazon-Elastic-Block-Store-Speicher (Amazon EBS) und andere Einstellungen zu ändern, die nur beim Starten einer Instanz definiert werden können.

Die Auto-Scaling-Gruppe verwendet zwei Amazon-CloudWatch-Alarme [12] (Kasten: „Amazon CloudWatch“), um Skalierungsvorgänge auszulösen. Die Standardeinstellung löst eine Skalierung aus, wenn der durchschnittlich ausgehende Netzwerkverkehr jeder Instanz mehr als sechs MiB oder weniger als zwei MiB über einen Zeitraum von fünf Minuten beträgt. Typische alternative Metriken für die Skalierung innerhalb von Auto-Scaling-Gruppen sind Latenzzeit, Festplatten-I/O, CPU-Auslastung und Anzahl der HTTP Requests. Wenn eine Instanz unerwartet beendet wird, erkennt Amazon EC2 Auto Scaling die Beendigung und startet eine Ersatzinstanz.

Amazon CloudWatch

Amazon CloudWatch ist der zentrale Logging- und Monitoringdienst im AWS-Portfolio. CloudWatch liefert Daten, um Anwendungen zu überwachen, auf systemweite Leistungsänderungen zu reagieren, die Ressourcennutzung zu optimieren und einen einheitlichen Überblick über den Betriebszustand zu erhalten. CloudWatch sammelt Überwachungs- und Betriebsdaten in Form von Protokollen, Metriken und Ereignissen und bietet so einen einheitlichen Überblick über AWS-Ressourcen, -Anwendungen und -Services, die auf AWS- und lokalen Servern ausgeführt werden.

Wichtig ist, dass die Anwendung, die nach Elastic Beanstalk ausgerollt wird, den Zustand in Services, wie beispielsweise Amazon ElastiCache, ablegt und damit umgehen kann, dass einzelne Knoten im Clusterverbund dynamisch hinzukommen oder entfernt werden.

Webserver

Da wir beim Aufsetzen unserer Umgebung die Elastic-Beanstalk-Tomcat-Plattform gewählt haben, ist der Reverse-Proxy bereits auf derselben Instanz wie der Tomcat vorhanden. In vielen Fällen muss der Apache-Proxy noch konfiguriert werden. Die Standard-Apache-Konfiguration von Elastic Beanstalk kann um zusätzliche Konfigurationsdateien erweitert werden. Alternativ kann sie auch vollständig überschrieben werden.

Um die standardmäßige Apache-Konfiguration von Elastic Beanstalk zu erweitern, muss eine .conf-Konfigurationsdatei zu einem Ordner mit dem Namen .ebextensions/httpd/conf.d im Anwendungsquellpaket hinzugefügt werden (Listing 1). Die Konfiguration des Elastic Beanstalk Apache beinhaltet automatisch .conf-Dateien in diesem Ordner (im Laufe des Artikels werden wir genauer auf den .ebextension-Mechanismus eingehen).

~/workspace/my-app/
|-- .ebextensions
|   -- httpd
|     -- conf.d
|       -- myconf.conf
|       -- ssl.conf
-- index.jsp

Die Apache-2.4-Konfiguration (.ebextensions/httpd/conf.d/port5000.conf) in Listing 2 fügt beispielsweise einen Listener auf Port 5000 hinzu. Zusätzlich definieren wir noch den vollständigen Pfad zur Logdatei mit allen Fehlern.

listen 5000
<VirtualHost *:5000>
  <Proxy *>
    Require all granted
  </Proxy>
  ProxyPass / http://localhost:8080/ retry=0
  ProxyPassReverse / http://localhost:8080/
  ProxyPreserveHost on
 
  ErrorLog /var/log/httpd/elasticbeanstalk-error_log
</VirtualHost>

Um die standardmäßige Apache-Konfiguration von Elastic Beanstalk vollständig zu überschreiben, muss eine Konfiguration in das Quellpaket unter .ebextensions/httpd/conf/httpd.conf aufgenommen werden.

Mit CloudWatch Logs können Elastic-Beanstalk-Anwendungs-, System- und benutzerdefinierte Logs von Amazon-EC2-Instanzen überwacht und archiviert werden. Zudem können auch Alarme konfiguriert werden, die es erleichtern, auf bestimmte Ereignisse des Log-Streams zu reagieren. Log-Streams, die zu derselben Protokollgruppe gehören, teilen sich die gleichen Einstellungen für Aufbewahrung, Überwachung und Zugriffskontrolle.

Datenbank

Beim Aufsetzen einer Elastic-Beanstalk-Umgebung können umfangreiche Konfigurationsparameter angepasst werden: Neben Instanztypen, Load Balancer, Monitoring und weiteren Einstellungen können auch Datenbanken mit Amazon RDS aufgesetzt werden. Das ist eine sehr interessante Option für Test und Entwicklung, da beim Löschen der Elastic-Beanstalk-Umgebung auch die Datenbank entfernt wird. Das ist im produktiven Betrieb natürlich kein gewünschtes Verhalten. Aus diesem Grund empfehlen wir, in einem produktiven Set-up die Amazon-RDS-Datenbank separat aufzusetzen.

Nach Erstellen der RDS-Datenbank muss über die Security Groups der Netzwerkverkehr zwischen den Webservern und der Datenbank freigeschaltet werden. Die Verbindungsinformationen zur Datenbank können der Applikation über Umgebungsvariablen zur Verfügung gestellt werden. Für zusätzliche Sicherheit ist es auch möglich, diese Informationen verschlüsselt im AWS Secrets Manager abzulegen und die Passwörter automatisch rotieren zu lassen [13]. Dazu muss der Applikationsquelltext natürlich angepasst werden.

In-Memory-Cache

In unserer bestehenden Architektur haben wir einen Redis-Cache eingesetzt, um die Datenbank zu entlasten. Im Zuge der Migration nach AWS wurde der Redis-Cache mit Amazon ElastiCache für Redis abgebildet, den wir auch hier wieder zum Einsatz bringen. Da ein Redis-Cache nicht über Elastic Beanstalk konfiguriert werden kann, kann dieser über die AWS Management Console oder alternativ über das AWS CLI bzw. Infrastructure as Code Frameworks hinzugefügt werden.

Netzwerk

In unserem Fall, in dem mehrere VPC-Subnetze und Availability Zones für die Hochverfügbarkeit der Anwendung genutzt werden, sollte natürlich ein analoges Set-up für das Aufsetzen der Elastic-Beanstalk-Umgebung gewählt werden. Im konkreten Fall bedeutet das, eine entsprechende Netzwerkkonfiguration auch beim Aufsetzen der neuen Umgebung zu nutzen. Gleiches gilt natürlich für den Application Load Balancer: Auch in diesem Fall kann die Netzwerkkonfiguration beim Aufsetzen der Umgebung genauer spezifiziert werden.

Um eine stärkere Trennung auf Netzwerkebene zu realisieren, können zusätzlich dedizierte Subnetze für die Datenbanken eingesetzt werden. Zwischen den einzelnen Subnetzen können Network Access Control Lists (NACLs) eingesetzt werden. NACLs sind eine optionale Sicherheitsfunktion für VPCs, die als zustandslose Layer-3-Firewalls fungieren und den ein- und ausgehenden Datenverkehr von Subnetzen steuern. NACLs können mit ähnlichen Regeln wie die für Sicherheitsgruppen eingerichtet werden, um VPCs noch sicherer zu machen. So erlauben sie ein explizites „Allow“ oder „Deny“ für eingehenden oder ausgehenden Netzwerkverkehr, basierend auf dem Protokoll, dem Port Range sowie dem CIDR Range. Des Weiteren ist eine Priorisierung von Regeln über die Regelnummer möglich.

Deployment der Anwendung

Das Erstellen einer Web-App mit Elastic Beanstalk sieht im einfachsten Fall wie folgt aus:

  • Wir vergeben einen Anwendungsnamen.

  • Wir wählen die Plattform (hier Tomcat).

  • Wir laden den Source Code hoch (ZIP oder WAR).

Mit anschließendem Klick auf Anwendung erstellen wird die gesamte Umgebung provisioniert (Abb. 2).

Abb. 2: Erstellen einer Webanwendung in der Elastic-Beanstalk-Konsole

Abb. 2: Erstellen einer Webanwendung in der Elastic-Beanstalk-Konsole

Alternativ kann eine Anwendung auch in Form einer WAR-Datei mit dem bereits angesprochenen CLI und dem Befehl eb deploy ausgerollt werden. In der Konfiguration muss lediglich der vollständige Pfad zu dem Artefakt angegeben werden. Die Nutzung eines interaktiven CLI ist keine empfohlene Vorgehensweise für das Deployment von Anwendungen in die Produktionsumgebung: An dieser Stelle bietet sich die Nutzung von AWS CodePipeline an, ein Service für die Automatisierung von Continuous-Delivery-Pipelines, der eine Integration mit AWS Elastic Beanstalk bietet.

Reproduzierbare Konfiguration

Plattformspezifische Konfigurationsoptionen sind in der AWS Management Console verfügbar, um die Konfiguration einer laufenden Umgebung zu ändern. Um zu vermeiden, dass die Konfiguration der Umgebung beim Beenden verloren geht, können gespeicherte Konfigurationen verwendet werden. Diese Einstellungen können ebenso auf eine andere Umgebung angewendet werden. Für die reproduzierbare Konfiguration einer AWS-Elastic-Beanstalk-Umgebung können Konfigurationsdateien (.ebextensions [14]) zum Quellcode der Webanwendung hinzugefügt werden, um die darin enthaltenen AWS-Ressourcen anzupassen. Konfigurationsdateien sind YAML- oder JSON-formatierte Dokumente mit einer .config-Endung, die in einem Ordner namens .ebextensions abgelegt und mit dem Deployment-Paket der Anwendung ausgerollt werden. In vielen Fällen ist es so, dass die Software, von der die Anwendung abhängt, angepasst und konfiguriert wird. Diese Dateien können entweder Dependencies sein, die von der Anwendung benötigt werden – zum Beispiel zusätzliche Pakete aus dem yum-Repository – oder Konfigurationsdateien wie z. B. ein Ersatz für httpd.conf, um bestimmte Einstellungen zu überschreiben, die von Elastic Beanstalk voreingestellt sind.

In folgendem Beispiel werden Befehle und Optionseinstellungen in einer .ebextensions-Konfigurationsdatei verwendet, um Monitoringskripte von Amazon CloudWatch herunterzuladen, zu installieren und auszuführen.

Um dieses Beispiel zu verwenden, muss der Quelltext einer Datei namens cloudwatch.config in einem Verzeichnis mit dem Namen .ebextensions auf der obersten Ebene des Projektverzeichnisses gespeichert werden (Listing 3).

packages:
  yum:
    perl-DateTime: []
    perl-Sys-Syslog: []
    perl-LWP-Protocol-https: []
    perl-Switch: []
    perl-URI: []
    perl-Bundle-LWP: []
 
sources: 
  /opt/cloudwatch: https://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.1.zip
  
container_commands:
  01-setupcron:
    command: |
      echo '*/5 * * * * root perl /opt/cloudwatch/aws-scripts-mon/mon-put-instance-data.pl `{"Fn::GetOptionSetting" : { "OptionName" : "CloudWatchMetrics", "DefaultValue" : "--mem-util --disk-space-util --disk-path=/" }}` >> /var/log/cwpump.log 2>&1' > /etc/cron.d/cwpump
  02-changeperm:
    command: chmod 644 /etc/cron.d/cwpump
  03-changeperm:
    command: chmod u+x /opt/cloudwatch/aws-scripts-mon/mon-put-instance-data.pl
 
option_settings:
  "aws:autoscaling:launchconfiguration" :
    IamInstanceProfile : "aws-elasticbeanstalk-ec2-role"
  "aws:elasticbeanstalk:customoption" :
    CloudWatchMetrics : "--mem-util --mem-used --mem-avail --disk-space-util --disk-space-used --disk-space-avail --disk-path=/ --auto-scaling"

Fazit

Nach der Migration unserer selbst aufgesetzten Umgebung auf AWS Elastic Beanstalk sieht unsere finale Architektur aus, wie in Abbildung 3 gezeigt.

Abb. 3: Die aktuelle Architektur als Schaubild

Abb. 3: Die aktuelle Architektur als Schaubild

Wir haben im Laufe dieses Artikels die selbst verwaltete Infrastruktur in Form von EC2-Instanzen, Load Balancer, Auto Scaling Group und anderen Ressourcen in den verwalteten Service AWS Elastic Beanstalk überführt. Managed Services wie AWS Elastic Beanstalk können den Aufwand für die Bereitstellung und den Betrieb von Infrastruktur signifikant verringern, was dazu führt, dass sich Entwickler stärker auf die eigentlichen Kernelemente wie die Entwicklung der Businesslogik fokussieren können. Bei Elastic Beanstalk besteht der große Vorteil darin, dass eine Abstraktionsschicht über den eigentlichen Building Blocks liegt, diese aber die einzelnen Bestandteile nicht „versteckt“: Es ist jederzeit möglich, Änderungen an den einzelnen Teilen vorzunehmen.

Im nächsten Artikel werden wir uns näher mit Containern beschäftigen und damit, welche Implikationen dieses Thema auf die Architektur und die Anwendung hat.

 

Geschrieben von
Sascha Möllering
Sascha Möllering
Sascha Möllering arbeitet als Solutions Architect bei der Amazon Web Services Germany GmbH. Seine Interessen liegen in den Bereichen Automation, Infrastructure as Code, Distributed Computing, Container und JVM.
Michael Graumann
Michael Graumann
Michael Graumann arbeitet als Senior Solutions Architect bei Amazon Web Services EMEA SARL mit Kunden aus dem Healthcare- und Life-Sciences-Bereich. Vorher war er als App- und Webentwickler in der Finanzindustrie tätig. Seine ersten praktischen Erfahrungen mit AWS sammelte er bei der Programmierung einer Serverless-Architektur, die seine Investments im Cryptocurrency-Sektor trackte und automatisiert Alarme (vorwiegend) beim Unterschreiten bestimmter Schwellen versendete.
Kommentare

Hinterlasse einen Kommentar

avatar
4000
  Subscribe  
Benachrichtige mich zu: