Image

Portrait John Hassan Gütensperger
von John Hassan Güntensperger
Cloud Engineer, aus Thun

#knowledgesharing #level 100

Cloud Native

Cloud Native beschreibt Architekturen, die von den maximalen Vorteilen des Cloud Providers profitieren will, indem…

  • sie ausgereifte Services des Cloud Anbieters verwendet.
  • ein Cloud natives Design bestehend aus Mikroservices in Kombination mit den Services des Cloud Anbieters verwendet.
  • eine maximale Automatisierung anhand Predicitve Analytics, Metriken und Logs der Infrastruktur anstrebt.

Das Cloud Native Maturity Model

Das dreiachsige Design von Kamal Arora stellt «Cloud Native Services», «anwendungszentriertes Design» und «Automatisierung» als grundlegende, miteinander verbundene Komponenten dar, die sich fortlaufend weiterentwickeln. Der Reifegrad der Cloud-Services beeinflusst den jeweiligen Entwicklungsstand des Kundensystems.

Image

Cloud Native erfordert selbstredend den Einsatz von Cloud-Services. Die Art dieser Services und die Art und Weise wie sie integriert werden, von grundlegenden Bausteinen wie Amazon EC2 und S3 bis hin zu fortschrittlichen Services wie AWS Lambda, hat Auswirkungen auf den Reifegrad der «Cloud-Nativität» des eigenen Systems.

Image

Wenn es um Design oder Migrationsmuster geht, verfolgt das Modell einen anwendungsorientierten Ansatz. Anstatt von Grund auf zu arbeiten, sind die Ausgangspunkte die langfristige Rolle und die Anforderungen einer Applikation. Designentscheidungen werden durch Faktoren wie Bedienbarkeit, dem Gleichgewicht von stateful / statelessness und dem Einsatz von Microservices geprägt. Dadurch wird sichergestellt, dass die Entscheidungsfindung einer kontinuierlichen Weiterentwicklung gerecht wird.

Image

Cloud-Services und anwendungsorientiertes Design sind zwar wichtig, aber sie decken nicht alle Bereiche ab. Dauerhafte Sicherheit und Skalierbarkeit hängen von der betrieblichen Automatisierung ab, die wiederum Infrastructure as Code erfordert.

Die Betriebsautomatisierung ermöglicht es internen Teams, sich auf das anwendungsspezifische Design zu konzentrieren, während der Cloud Anbieter die aufwändige Aufgabe der Ressourcenbereitstellung übernimmt.

Image

Es gibt ein Spektrum für die Automatisierung. Die frühen Phasen konzentrieren sich auf den Aufbau der Umgebung, die Ressourcenkonfiguration und die Anwendungsbereitstellung. Mit zunehmender Reife einer Lösung werden auch erweiterte Überwachungs-, Skalierungs- und Leistungsfunktionen einbezogen. Mit der Zeit werden Auditing, Compliance, Governance und Optimierung der gesamten Lösung umgesetzt.

Ist es das wert?

Tatsächlich sollte nicht jede Anwendung eine vollständige Cloud Native Neuentwicklung durchleben. Besonders bei Legacy-Systemen reicht auch ein Lift & Shift Ansatz, bei dem das Legacy-System auf EC2-VM’s betrieben wird und gegebenenfalls nur einzelne Teile des Legacy-Systems zu einer Cloud Nativen Applikation umgebaut werden. An dieser Stelle kann man sich auch damit auseinandersetzen, ob ein System oder gewisse Funktionalitäten sich für einen Umzug in die Cloud eignen oder darauf verzichtet werden sollte.

Es spricht vieles dafür, das Modell von Kamal auf Anwendungen anzuwenden, die einen Einfluss auf die Basis-Wert-Bestimmung eines Unternehmens haben. Den Cloud Nativen Weg zu gehen, erfordert ein Commitment des Unternehmens. Bevor man sich mit der Cloud-Technologie auseinander setzt, sollten allfällige, organisatorische Einschränkungen behoben werden, damit die Mitarbeiter die Vorteilen der Cloud nutzen können. Sobald jedoch die organisatorischen Voraussetzungen geschaffen werden, um Cloud-Technologien in grossem Umfang zu nutzen, bietet das Modell von Kamal einen sehr nützlichen Rahmen, um die Dynamik ihrer Cloud Nativen Reise zu verstehen. Persönlich kann ich an dieser Stelle nur zu diesem Commitment raten, denn die Kosteneinsparungen der automatisierten Skalierung, High-Availability und Fully-Managed Serverless Lösungen sind enorm und die Services der grossen Cloud Anbieter sind gut getestet, stabil und bringen einen sehr grossen Mehrwert für jedes Unternehmen.

Cloud Native bedeutet auch ein Vertrauen in die Expertise des Cloud Anbieters. Deswegen setzt Axians Amanox beim Gestalten von Cloud Nativen Architekturen auch auf Fully-Managed und Serverless Architekturen. Axians Amanox hilft Ihnen mit unserer Erfahrung und Spezialisierung auf das AWS Portfolio die sinnvollste Umsetzung von Serverless Architekturen umzusetzen und somit vom idealen Einsatz von entkoppelten Architekturen zu profitieren.

Quelle: Architecting Cloud Native Applications, Kamal Arora

Image

Vollautomatisierte MLOps-Pipeline - Teil 2

In unserem letzten Beitrag haben wir uns mit dem Training eines Prognosemodells mit SageMaker beschäftigt. In diesem Beitrag erfährst du, wie du die Leistung des Modells überwachen und die Nachschulung automatisieren kannst, um konsistente und zuverlässige Vorhersagen zu gewährleisten.
zum Artikel
Image

Vollautomatisierte MLOps-Pipeline - Teil 1

Im vorigen Blogbeitrag haben wir die Architektur und die Demo einer Pipeline für die Dateneingabe in Amazon SageMaker Feature Store in nahezu Echtzeit vorgestellt. In diesem und dem folgenden Beitrag werden wir die vollständig automatisierte MLOps-Pipeline vorstellen.
zum Artikel
Image

Nahezu Echtzeit-Dateneingabe in den SageMaker Feature Store

Dieser Blog-Beitrag ist der erste Teil einer dreiteiligen Serie über das Testen einer vollautomatischen MLOps-Pipeline für Machine-Learning-Vorhersagen auf Zeitreihendaten in AWS, die nahezu in Echtzeit vorliegen. In diesem ersten Teil konzentrieren wir uns auf die Dateneingabe-Pipeline in den Amazon SageMaker Feature Store.
zum Artikel
Image

AWS AppConfig for Serverless Applications Demo

Wäre es nicht schön, wenn die Applikationskonfiguration von der Infrastrukturkonfiguration und dem Code entkoppelt werden könnte? An dieser Stelle kann AWS AppConfig (eine Komponente von AWS Systems Manager) helfen (Artikel in Englisch)
zum Artikel