Ein Service Level Agreement (SLA) zwischen einem Unternehmen und einem Service Provider definiert die Rahmenbedingungen des zur Verfügung gestellten Services und damit auch die Vorteile, die das Unternehmen aus der Zusammenarbeit ziehen kann. Das macht die Festlegung von SLAs, beispielsweise im Zusammenhang mit Cloud-as-a-Service, zu einer strategischen Frage für Unternehmen. Bereits für die Erstellung der Service Level Agreements müssen interne Teams mit den Experten des Providers zusammenarbeiten.
Es gibt Provider, die Komplettlösungen anbieten, indem sie ihr Service Level an das durchschnittliche Leistungsniveau des Marktes anpassen oder ein deutlich höheres Leistungsniveau anbieten. Häufig lassen sie dabei jedoch die spezifische Situation und die tatsächlichen Anforderungen des Kunden außer Acht. Anstatt sich an der allgemeinen Marktsituation zu orientieren, sollten sich Provider ausreichend Zeit für die Analyse der individuellen Bedürfnisse ihrer Kunden nehmen und ihr Angebot daran anpassen.
Jedes Unternehmen sollte vor der Vereinbarung von Cloud SLAs mit seinem Partner eine Business Impact Analyse durchführen, die alle digitalisierten Prozesse erfasst. So können beide Seiten die strategischen und operativen Ziele einer Migration in die Cloud definieren und mögliche Risiken einer Unterbrechung des Prozesses oder der Einbeziehung weiterer Stakeholder ansprechen.
Cloud SLAs sind für Unternehmen zudem ein wichtiger Teil der Compliance-Risikoanalyse, da sie dazu beitragen, dass sie die geltenden Sicherheitsvorschriften einhalten. Cloud-Provider sind dazu verpflichtet, ihre Compliance-Vorgaben und internen Richtlinien in Serviceanforderungen hinsichtlich Reaktionszeit, Sicherheit und Support umzusetzen.
In diesem Zusammenhang spielt auch die Resilienz eine Rolle. Resilienz beschreibt die Fähigkeit eines Systems, den Betrieb auch bei unvorhergesehenen Vorfällen zu gewährleisten.
Nach der Business Impact Analyse können Unternehmen mit ihrem Provider die SLAs für die Cloud festlegen. Dabei ist zu beachten, dass sich die Anforderungen eines Unternehmens schnell ändern können, sodass es schwierig ist, präzise Prognosen über einen Zeitraum von fünf Jahren - der typischen Laufzeit eines Cloud-Vertrags - zu erstellen. Es ist daher von Vorteil, den Vertrag skalierbar zu gestalten oder eine Klausel zu integrieren, die eine Nachverhandlung der Vereinbarung ermöglicht. Das kann einerseits sinnvoll sein, wenn ein Unternehmen wächst und die Anforderungen an den Provider zunehmen. Andererseits kann auch das Gegenteil der Fall sein. Ein Kunde wünscht ein bestimmtes Serviceniveau, dessen Möglichkeiten das Unternehmen später nicht ausschöpft.
Wie wichtig skalierbare SLAs sind, verdeutlichen Start-up-Unternehmen, die mit einer kleinen Architektur beginnen und im Laufe der Zeit beispielsweise E-Commerce-Dienste einführen. Die Anforderungen an die ununterbrochene Verfügbarkeit der Systeme würden mit dieser Entwicklung stark ansteigen. Wenn sich die Cloud-Infrastruktur und die SLAs nicht im Gleichschritt weiterentwickeln, kann bereits ein Tag oder wenige Stunden, in denen die Systeme nicht verfügbar sind, zu potenziell erheblichen Umsatzeinbußen führen.
Um dafür zu sorgen, dass der Kunde die Leistung der vom Provider bereitgestellten Dienste überwachen und die Einhaltung der Cloud SLAs überprüfen kann, sollte der Provider während der gesamten Zusammenarbeit Berichte für den Kunden erstellen. Diese sollten neben der Erfassung der vertraglich festgelegten Service Levels auch Potenziale für weitere Optimierungen der Leistung aufzeigen.
La corretta impostazione degli SLA del cloud deve essere funzionale anche a garantire livelli di servizio e resilienza in un modello che è sempre più ibrido e multi cloud. In WIIT siamo abituati a lavorare con imprese molto fidelizzate che nel tempo possono avere l’esigenza di attivare o migrare sistemi e servizi dall’on premise al cloud pubblico, al privato o viceversa, ma che a prescindere da dove siano i sistemi hanno l’esigenza di avere SLA definiti e servizi coerenti con le loro esigenze.
Ma attenzione: non basta la buona volontà del partner per rendere semplice la migrazione fra i vari “mondi” cloud. È necessario elaborare preventivamente una cloud strategy adoption. Altrimenti il famigerato lock-in diventa un rischio, spesso per mere questioni di incompatibilità architetturale.
Prima di scegliere un partner per il cloud, infatti, un’azienda deve valutare bene il tipo di architettura che desidera e che il provider effettivamente può rendere disponibile. Molti public cloud, per esempio, sono costruiti su architetture a microservizi e offrono applicazioni cloud-native, che sono una cosa ben diversa dagli ambienti open. In questi casi, se fosse necessario, diventa poi difficile riconvertire tutto e andare su altre architetture che potrebbero invece garantire vantaggi di diversa natura, anche economica. Parliamo di progetti molto complessi, che potrebbero implicare costi di reingegnerizzazione superiori a una migrazione classica. Ecco perché la strategia va ponderata prima e, ribadisco, con estrema attenzione.
Proprio per andare incontro a questo tipo di esigenza e minimizzare l’impatto che eventuali migrazioni potrebbero avere sui nostri clienti, WIIT ha scelto e sviluppato da tempo un approccio hybrid e multicloud, in base al quale consigliamo quali ambienti ha senso implementare in private, e quali conviene ospitare nel public cloud con, a corredo, qualche microservizio. Bilanciando bene i carichi, diventa possibile evitare qualsiasi tipo di lock-in. Ma anche in questo caso parliamo chiaramente di una strategia che va definita prima, non fosse altro per assicurare una gestione omogenea dell’infrastruttura.
Die richtige Konfiguration von Cloud SLAs sollte auch Services und Ausfallsicherheit für Umgebungen beinhalten, die sich immer stärker in Richtung Hybrid- und Multi-Cloud bewegen. Zusätzlich verhindert die richtige Konfiguration, die mit der Cloud-Strategie des Unternehmens kompatibel ist, einen Lock-In. Bei einem Lock-In ist ein Unternehmen durch einen Vertrag an Services gebunden, die nicht mehr angemessen sind oder die es nicht mehr braucht.
Vor der Auswahl eines Cloud-Partners sollte ein Unternehmen sorgfältig prüfen, welche Art von Architektur es benötigt und welche der Provider tatsächlich bereitstellen kann. Viele Public Clouds basieren beispielsweise auf Microservices-Architekturen und bieten cloudnative Anwendungen, die sich von offenen Umgebungen unterscheiden. In solchen Fällen ist es schwierig, alles umzustellen und auf andere Architekturen umzusteigen, die stattdessen andere Vorteile bieten könnten. Solche Projekte sind sehr komplex und können höhere Reengineering-Kosten verursachen als eine klassische Migration.
Um diesen Anforderungen gerecht zu werden und die Auswirkungen von Migrationen für unsere Kunden so gering wie möglich zu halten, verfolgt WIIT seit langem einen Hybrid- und Multi-Cloud-Ansatz. Auf dieser Grundlage empfehlen wir, welche Umgebungen in eine Private Cloud und welche besser mit einigen Microservices in eine Public Cloud passen. Durch eine ausgewogene Lastverteilung können Unternehmen jede Art von Lock-in vermeiden.