Am veröffentlicht

AWS Neuigkeiten Oktober 2021   

Nach der Vielzahl an Ankündigungen während der Storage Days im vergangenen Monat, ist die Quantität der Änderungen in diesem Monat zwar eher gering, ihre Qualität aber umso größer.Dieser Blogbeitrag stellt einen Ausschnitt aus den Neuerungen und Ankündigungen des MonatsOktober dar, erhebt aber nicht den Anspruch auf Vollständigkeit. Das Hauptaugenmerk liegt hierbei auf Veränderungen, bei denen wir von einem direkten Einfluss auf unsere Kundenausgehen. In diesem Beitrag werden insbesondere Änderungen und Ankündigungen der Services Amazon EC2 und AWS Redshift vorgestellt. Weiterhin werden auch zwei Änderungen der beliebten Services AWS Lambda und AWS StepFunctions vorgestellt, welche bereits seit September verfügbar sind, allerdings erst nach Vervollständigung des dazugehörigen Blogbeitrags publiziert wurden.  

Compute 

Die wahrscheinlich wichtigste Neuerung in puncto Compute-Services der AWS stammt noch aus dem September und betrifft den Service AWS Lambda. Bisher wurden Lambda-Funktionen auf Intel-Prozessoren mit einer x86-Architektur ausgeführt. Dies können Kunden nun zukünftig ändern. 

AWS Lambda – Graviton2 

Für den serverless Compute-Service AWS Lambda wurde am Ende des Monats September ein eigentlich logischer nächster Schritt vorgestellt: Die Verwendung von Graviton2-Prozessoren bei der Ausführung von AWS Lambda-Funktionen. Bereits jetzt nutzen viele User der AWS Plattform die von Graviton2 gestützten EC2-Instanzen, um von den geringeren Kosten dieser, gegenüber denen der klassischen Intel- und Apple M1-Prozessoren, zu profitieren. Laut AWS können sowohl neue als auch bereits existierende Lambda Funktionen auf die Graviton2-Prozessoren migriert werden und so von bis zu 19% besserer Performance und 20 Prozent geringeren Kosten profitieren.  

AWS selbst beschreibt die Migration bereits bestehender Funktionen auf die neuen Graviton2-Instanzen wie das Umlegen eines Schalters. Es sei an dieser Stelle allerdings angemerkt, dass zumindest einzelne Code-Passagen umgestaltet werden müssen, wenn die Funktionen Binärabhängkeiten aufweisen. Bei der Verwendung einer interpretierten Sprache wie Python oder auch Node.js sollte dies aber eher selten der Fall sein.  

Die Skalierungsmöglichkeiten der Lambda-Funktionen sind bei der Verwendung von Graviton2-Prozessoren identisch mit den bisher bestehenden. Dementsprechend können auch bei der Umstellung des Prozessortyps bis zu 10 GB RAM und 6 vCPUs für eine Lambda-Funktion allokiert werden. Bisher werden die Sprachen Node.js 12 und 14, Python 3.8 und 3.9, Java 8 und 11, .NET Core 3.1 und Ruby 2.7 sowie weitere Custom Runtimes unterstützt. Verfügbar sind die Funktionen in Europa in Frankfurt, Irland und London. Für einen genaueren Kostenvergleich kann die AWS Dokumentation hinzugezogen werden, wobei hier natürlich potenzielle Zeitersparnisse nicht einkalkuliert sind: https://aws.amazon.com/de/lambda/pricing/ 

Amazon EC2 – Gaudi Accelerators 

Auch die EC2-Instanzen erlebten im Oktober eine Neuerung, denn für sie ist nun ein neuer Instanz-Typ verfügbar: Die DL1-Instances, die eine Antwort auf die TPUs von Google darstellen. 

Machine Learning, und insbesondere Deep Learning, wird immer präsenter. Das Erstellen eines ML-Models ist ein iterativer Prozess bestehend aus dem Konstruieren des Anfangsmodels, dem Trainieren und Testen mit entsprechenden Datensätzen und dem Anpassen von Parametern. In den multiplen Layer, die dem Deep Learning seinen Namen geben, werden eine Vielzahl von mathematischen Operationen ausgeführt, die die die Ressourcen einer Instanz, trotz der Verwendung von zusätzlichen GPUs, häufig vollends ausschöpfen.  

Hier sollen nun die DL1-Instanzen Besserung versprechen. Die DL1-Instanzen können in einer Größe von .24xlarge genutzt werden. In dieser Konfiguration haben die Instanzen 768GB Ram, 4 TB NVMe Speicher, 96vCPUs und 400 GB/s Netzwerk I/O, sowie 8 sogenannt „Gaudi Accelerators“, die jeweils 32 Gigabyte High Bandwidth Memory besitzen. 

Im Gegensatz zu den TPU-Units von Google wird von den AWS DL1-Instanzen neben Tensorflow auch PyTorch als Framework unterstützt. Durch den Wechsel von GPU-Basierten EC2-Instanzen auf die neuen DL1-Instanzen bewirbt Amazon eine Kostenersparnis von bis zu 40%. Die Instanzen sind allerdings zum jetzigen Stand erst in zwei Regionen verfügbar: North Virginia und Oregon. Für eine detaillierte Vorstellung von Gaudi und den neuen EC2-Instanzen sei auf die Internetseite der Entwickler verwiesen: https://habana.ai/ 

Orchestration and Control 

 

AWS StepFunctions – AWS SDK Service Integration 

Auch die im Folgendem Abschnitt vorgestellte Änderung zu den AWS StepFunctions wurde bereits im September bekannt gegeben. Bisher unterstützten StepFunctions eher wenige, aber die wichtigsten AWS Services, wie beispielsweise AWS Lambda, und dienten so zur Orchestrierung dieser Services, sodass beispielsweise die eben genannte AWS Lambda-Funktionen in einer kontrollierten Reihenfolge ausgeführt werden konnten. Neben AWS Lambda wurden noch 16 weitere Services von dem low-Code Workflow Service unterstützt und konnten orchestriert werden. Diese Zahl hat sich im Oktober mehr als verzehnfacht und es wurde bekannt gegeben, dass nun insgesamt über 200 AWS Services unterstützt werden und die Zahl der AWS API Actions von 46 auf über 9000 erhöht wurde. Diese Vervielfältigung von Möglichkeiten ist auf die Nutzung der AWS SDK Service Integration zurückzuführen.  

Die AWS SDK Service Integration – und somit auch die erneuerten StepFunctions – sind in Europa in den Regionen Irland und Mailand verfügbar, allerdings soll sie innerhalb der nächsten Zeit auch in allen anderen Regionen – und somit auch in Frankfurt – zur Verfügung stehen. 

AWS Cloud Control API 

Das Portfolio an Services, die von Amazon bereitgestellt werden, ist über die Jahre stetig gewachsen. Seit der Einführung der ersten Services vor nun über 15 Jahren ist die Zahl der nutzbaren Services auf über 200 angestiegen. Dieses stetige Wachstum an Services brachte allerdings einen Nachteil mit sich, denn bisher war es so, dass jeder Service seine eigene API samt seines eigenen Syntaxes besaß. Zur Verdeutlichung, was das bedeutet, ein kurzes Beispiel für diese unterschiedlichen Syntaxe: Möchte man einen S3-Bucket erstellen, so musste man bis dato die CreateBucket-API und für die Erstellung einer EC2-Instanz die RunInstances-API verwenden.  

Durch die verschiedenen Anwendungsgebiete der APIs der einzelnen Services, erschwert der unterschiedlichen Syntax das Management und die Wartung von Programmen, die diese nutzen. Dies macht sich insbesondere bemerkbar, wenn man generische Templates erstellen möchte zur Erstellung von Ressourcen via API-Abfragen. Durch die neue AWS Cloud Control API soll die Komplexität nun aber reduziert werden.  

Die Cloud Control API ist eine Menge von standardisierten CRUDL-APIs, also Create, Read, Update, Delete und List-APIs, und ist seit Oktober für eine Vielzahl von Services verfügbar. Derzeit besteht sie aus 5 einfachen Befehlen – CreateResource, GetResource, UpdateResource, DeleteResource, ListResource – und vereinheitlicht so die Syntax. Um auf das obige Beispiel von der Erstellung eines S3-Buckets und einer EC2-Instanz zurückzukommen, würde nun in beiden Fällen die CreateResource-API aufgerufen werden mit dem Typ der zu erstellenden Ressource und seinen Attributen als zusätzliche Parameter.  

Laut Amazon sollen die neuen und einheitlicheren Cloud Control APIs die klassischen APIs nicht vollständig ablösen, sondern parallel zu diesen existieren. Nichtsdestoweniger ist es einfacher, bei der Erstellung neuer Applikationen zukünftig auf die Cloud Control APIs zurückzugreifen. Die Cloud Control APIs sind seit Anfang Oktober in allen AWS Regionen, mit Ausnahme von China, verfügbar und es fallen keine zusätzlichen Kosten an, sodass lediglich die zugrundeliegenden AWS Ressourcen bezahlt werden müssen.  

Data Warehousing 

Amazon Redshift: Data Exchange 

Wenn man die neu hinzugekommenen Features betrachtet, hat AWS Redshift in den vergangenen Wochen und Monaten einiges an Boden gegenüber seinen Kontrahenten BigQuery und Snowflake gut gemacht. Ein Beispiel hierfür ist der von uns bereits im Mai vorgestellte Service RedshiftML, mit welchem über SQL-Abfragen Machine Learning Modelle aus Redshift heraus trainiert und abgefragt werden können. Dies war bis dato eigentlich ein Markenzeichen des Google eigenen OLAP Data Warehouses BigQuery. Analog hierzu gestaltet sich auch der Data Exchange für Amazon Redshift, wobei die Vorreiterrolle im Thema Data Sharing bisher Snowflake zuzusprechen war. 

Data Exchange für Amazon Redshift basiert schlussendlich auf dem bereits 2019 vorgestellten AWS Data Exchange, mit welchem von Drittanbietern veröffentlichte Datentöpfe abonniert und in einen eigenen S3-Bucket kopiert und weiterverarbeitet werden konnten. Die Neuerungen hier liegt nun darin, dass solche Datentöpfe direkt aus Redshift heraus abonniert und abgefragt werden können und keine zusätzliche ETL-Prozessierung notwendig ist.  

Genau wie bei Snowflake stellen die Data Provider die Daten zur Verfügung und werden über das Abonnement vergütet. Die Transaktion erfolgt automatisch durch Redshift Exchange und wird mit dem AWS Rechnungskonto verrechnet. Verfügbar ist Data Exchange für Amazon Redshift in allen Regionen, in denen auch RA3-Instanzen verfügbar sind und somit insbesondere in Frankfurt, Irland und London. 

Für weitere regelmäßige Updates zum Thema AWS Cloud, folgen Sieunserer PräsenzaufXingund Instagramoder direkt unserem Blog.