AWS OpsWorks: Mehr PaaS-Funktionalität im Cloud-Portfolio von Amazon

[ 1 ] Februar 19, 2013 |

Korrekterweise spricht man bei den Amazon Web Services (AWS) von einem Infrastructure-as-a-Service (IaaS). Bei AWS Elastic Beanstalk spalten sich die Lager, ob der Service zu den Platform-as-a-Services (PaaS) gezählt werden dürfe. Zumindest bietet AWS seit längerer Zeit diverse PaaS-Funktionalität in seinem Cloud-Portfolio und erweitert diese nun mit “AWS OpsWorks” (noch in der Beta).

Was ist AWS OpsWorks?

AWS OpsWorks ist eine Lösung für das flexible und automatisierte Applikationsmanagement. Es richtet sich an IT-Administratoren und DevOps Entwickler, die damit den vollständigen Lebenszyklus einer Anwendung inkl. Ressourcen-Provisionierung, Konfigurationsmanagement, Softwareupdates, Monitoring und Zugriffskontrolle verwalten können. AWS OpsWorks kann kostenlos genutzt werden. Kosten entstehen für die darunter eingesetzten virtuellen AWS Infrastrukturressourcen.

OpsWorks ermöglicht das Erstellen einer logischen Architektur, die Provisionierung der benötigten Ressourcen basierend auf der Architektur sowie das Bereitstellen der Applikation und die dafür benötigte Software und Pakete für eine bestimmte Konfiguration. OpsWorks sorgt dann für den Betrieb der Applikation und unterstützt deren Lebenszyklus inkl. Autoscaling und Softwareupdates.

AWS OpsWorks Details

AWS OpsWorks unterstützt unterschiedliche Applikations-Architekturen und arbeitet mit jeder Software zusammen, deren Installation skript-basiert verläuft. Basierend auf dem Chef Framework können bereits fertige eigene Rezepte oder welche aus der Community genutzt werden, um OpsWorks einzusetzen.

Ein Event-basiertes Konfigurationssystem hilft beim Lebenszyklus-Management einer Applikation. Dazu gehören anpassbare Deployments, Rollbacks, Patchmanagement, Autoscaling sowie Autohealing. So lässt sich z.B. ein Update über das Aktualisieren einer einzigen Konfigurationsdatei ausrollen. Zudem ist OpsWorks in der Lage, AWS Instanzen basierend auf einer selbst exakt spezifizierten Konfiguration zu hosten. Dazu gehört ebenfalls die Skalierung dieser Applikation anhand der jeweiligen Last auf der Anwendung oder einer zeitbasierten automatischen Skalierung sowie der Überwachung der Applikation und dem Austausch fehlerhafter Instanzen.

Mit OpsWorks lassen sich Applikationen in sogenannte “Layer” aufbauen. Layer definieren, wie ein Teil von Ressourcen, die zusammen verwaltet werden, konfiguriert werden sollen. Ein Beispiel könnte ein Web-Layer sein. Dieser beinhaltet EC2 Instanzen, EBS Volumes inkl. einer RAID Konfiguration und Mount Points sowie Elastic IP-Adressen. Für jeden Layer kann zudem eine Software-Konfiguration erstellt werden. Darin sind Installations-Skripte und Schritte für die Initialisierung enthalten. Wird nun eine Instanz zu einem Layer hinzugefügt, sorgt OpsWorks dafür, dass diese die entsprechenden Konfigurationen erhält. OpsWorks stellt vor-definierte Layer für Technologien wie Ruby, PHP, HAProxy, Memcached und MySQL bereit. Diese können angepasst und erweitert werden.

Technologie aus Deutschland

OpsWorks ist eine Erfindung aus Deutschland und basiert auf der Scalarium Technologie des Berliner Unternehmens Peritor. Scalarium wurde bereits 2012 von Amazon gekauft.

Kommentar

Bei AWS OpsWorks handelt es sich zwar um kein konkretes PaaS Angebot. Dieses liegt allerdings an der Building Blocks Philosophie der Amazon Web Services. Das bedeutet, dass die angebotenen Services so granular wie möglich bereitgestellt werden. Der Kunde hat anschließend die Möglichkeit, die Services für seinen Use Case so zu integrieren, wie er sie benötigt. Dafür wird natürlich dementsprechend viel Eigenleistung und Wissen benötigt, welches bei einem typischen PaaS für die Infrastruktur nicht erforderlich ist. Jedoch schließt AWS OpsWorks hinsichtlich der Convenience zu den PaaS am Markt immer weiter auf und bietet immer mehr PaaS-Funktionalität in der Amazon Cloud.

Über eines sollte man sich als Kunde dennoch bewusst sein. Und das gilt nicht nur für AWS OpsWorks, sondern für die Nutzung jedes AWS Service. Der Lock-in in die AWS-Infastruktur wird mit jedem Service den Amazon veröffentlicht immer größer. Das muss nichts Schlechtes bedeuten. Ein Lock-in ist zwangsläufig nichts Negatives und kann im Gegenteil sogar von Vorteil sein, solange die eigenen Anforderungen erfüllt werden und nicht zu große Kompromisse durch den Kunden selbst gemacht werden müssen.

Man muss sich als Kunde dies nur vor Augen halten und bereits vor dem Weg in die AWS Cloud, als auch in jede andere Cloud, über mögliche Exit-Strategien oder einen Multi-Cloud Ansatz nachdenken.

Tags: , , , , ,

Category: Management

About the Author ()

Rene Buest is Senior Analyst and Cloud Practice Lead at Crisp Research, covering cloud computing and IT infrastructures. He is member of the worldwide Gigaom Research Analyst Network, top cloud computing blogger in Germany and one of the worldwide top 50 bloggers in this area. In addition, he is one of the world’s top cloud computing influencers and belongs to the top 100 cloud computing experts on Twitter. For more than 16 years he is focused on the strategic use of information technology in businesses and the IT impact on our society as well as disruptive technologies. Rene Buest is the author of numerous professional cloud computing and technology articles, speaker and participant of experts rounds. On CloudUser.de he writes about topics from the fields of cloud computing, it-infrastructures, technologies, management and strategies. He holds a diploma in computer engineering from the Hochschule Bremen (Dipl.-Informatiker (FH)) as well as a M.Sc. in IT-Management and Information Systems from the FHDW Paderborn.

Leave a Reply

You must be logged in to post a comment.