Von Spring Boot nach AWS Lambda – Teil IV

AWS Lambda versus Spring Boot – wer gewinnt?

Oliver Wronka

(c) Shutterstock / MaluStudio

 

Wie praktikabel ist es, eine Microservices-Anwendung nach AWS Lambda zu migrieren und „serverless“ zu betreiben? Dieser Frage gehen wir in dieser Artikelreihe nach. Im vierten Teil wollen wir uns die Präsentationsschicht anschauen, die von Spring Boot nach AWS Lambda portiert werden soll.

Von Spring Boot nach AWS Lambda

In dieser Artikelreihe versuche ich eine Antwort auf die Frage zu geben, ob der Ansatz des Serverless Computing die logische Fortsetzung der Microservice-Architekturen darstellen. Dafür soll ein vollständiges Beispiel für eine auf AWS Lambda betriebene Webanwendung implementiert werden.

 

Teil IV: Präsentation

Bei der Präsentation wird es wiederum angenehm. Da die Weboberfläche der Microservices aus HTML5 Singlepage-Webseiten besteht, muss diese nur auf S3 zur Verfügung gestellt werden, und schon ist man fertig. Bei S3 handelt es sich um den Amazon eigenen Storage Service. Hier kann man Dateien hochverfügbar und –skalierbar ablegen. Es bietet sich also an, hier nicht nur die Webseiten abzulegen, sondern auch den Content – in unserem Fall also die Bilddateien, die den eigentlichen Content darstellen. Das Ganze sieht dann in der entsprechenden AWS-Konsole so aus:

Bild 18: Inhalt des S3 Bucket für die Domäne

Dies ist die eigentliche Singlepage-Webanwendung, während der Content unterhalb des Folders content/img abgelegt ist:

Bild 19: Der eigentliche Content

 

Für unsere Demo reicht das bereits. Für eine Anwendung, die nicht nur hochverfügbar, sondern auch beliebig skalieren soll, muss man dann noch das Amazon eigene CDN CloudFront davor schalten. Zusätzlich kann man über CloudFront seine Anwendung noch mit einem eigenen Zertifikat absichern. Da wir hier ja klotzen und nicht kleckern wollen, habe ich das einmal auf die Schnelle durchgeführt.

Zuerst muss die Domäne beantragt werden. Hierfür gibt es bei Amazon den Dienst Route 53. Über diesen kann man, wie man sieht, für kleines Geld eine Domäne beantragen.

Bild 20: Beantragen einer Domäne via Route53

 

Dieser Dienst bietet auch so praktische Dinge wie ein Autorenew. Man muss sich also keine Sorgen mehr darum machen, dass die eigene Domäne irgendwann einmal abläuft und durch einen Händler gehijackt wird.

Sobald man die Domäne sein Eigen nennt, kann man den Amazon eigenen Zertifikatmanager nutzen, um sich für die URL ein Zertifikat ausstellen zu lassen.

In diesem muss man lediglich die URL eintragen:

Bild 21: Ausstellen eines Zertifikats für die Domäne via Zertifikatmanager

Sobald man den Antrag abschickt, erhält man eine E-Mail, um zu beweisen, dass man der Besitzer der URL ist. In dieser den Link anklicken, und schon hat man ein Zertifikat.

Nun muss noch das eigentliche CDN unter CloudFront eingerichtet werden. Der Vorgang ist gut beschrieben, daher hier nur die entscheidende Stelle, an welcher man das Zertifikat einbindet:

 

Bild 22: Bereits eingerichtete Distribution auswählen

 

 

Bild 23: Distributionsdetails auswählen

 

Bild 24: Zertifikat der Distribution hinzufügen

Nach diesen Schritten ist die eigene Anwendung unter https zu erreichen: https://www.axx2sls.de.

Zwischenstopp

Mit der Einrichtung der Präsentationsschicht sind wir bereits ein gutes Stück voran gekommen in unserem Migrationsprojekt. Im letzten Teil der Serie geht es um die Bereiche Authentisierung und Autorisierung, die uns nochmals vor eine gewichtige Herausforderung stellen. Außerdem steht dann die abschließende Bewertung unserer Eingangsfrage an, ob AWS Lambda denn nun tatsächlich das bessere Spring Boot darstellt.

Es bleibt also spannend – versprochen!

Weiter mit Teil V der Serie:

Serverless versus Microservices: Ist AWS Lambda das bessere Spring Boot?

 

Geschrieben von
Oliver Wronka
Oliver Wronka
Oliver Wronka befasst sich mit Java seit der Version 1.0. Schwerpunkt in seiner Funktion als Principal-Softwarearchitekt bei der axxessio GmbH mit Sitz in Bonn sind Java-basierte Backend-Systeme.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.