On-Demand Webinar: Cloud Lösungen

Das erfahren Sie im Webinar:

Immer mehr businesskritische Applikationen entstehen in Public Clouds oder werden dorthin verschoben. Mit Cloud-Lösungen für Unternehmen und Software aus der Cloud für digitale Kollaboration können sehr einfach globale Konzepte umgesetzt werden. Gerade jetzt merken Unternehmen, wie wichtig eine durchgehende Online-Strategie ist – das betrifft nicht nur Marketing-Portale, sondern vor allem Onlineshops, Service-Portale und Kommunikationsplattformen mit Kunden, Partnern und Mitarbeitern. Viele Unternehmen müssen nachrüsten. Die Nachfrage nach IT-Services steigt, ebenso wie die Fragen rund um die Themen Compliance, Corporate Governance und Sicherheit. Das Webinar erläutert die Möglichkeiten des Cloud Application Managements und was zu Beginn eines Projektes beachtet werden sollte. Denn meist stellt man erst später fest, dass Public Clouds für einige Dienste keine oder nur sehr schlechte SLA’s anbieten. diva-e bietet ein 24/7 Application Management entsprechend den Erfordernissen des Kunden.

Transkript zum Webinar: Cloud Lösungen – Sichere Cloud Lösungen mit Service

Begrüßung und Vorstellung

Angela Meyer: Dann mal guten Mittag zusammen und herzlich willkommen zu unserem heutigen Webinar zum Thema Cloud Lösungen - Sichere Cloud Lösungen mit Service. Danke für Eure Teilnahme und ich freue mich, Euch heute zu unserem Webinar begrüßen zu dürfen. Ich würde sagen, wir warten noch ein bis zwei Minuten, denn es kommen noch nach und nach ein paar Nachzügler rein. (30 Sek.) So, die Teilnehmeranzahl die steigt kontinuierlich. Das sieht gut aus. (11 Sek.) Und ich begrüße Euch hier zu unserem heutigen Webinar zum Thema Cloud Lösungen. Ich würde sagen, wir starten jetzt einfach mal mit einem Technikcheckup. Sascha, möchtest Du einmal weiterklicken?

Sascha Sauer: So.

Angela Meyer: Genau. (4 Sek.) Also noch einmal herzlich willkommen zu unserem heutigen Webinar zum Thema Sichere Cloud Lösungen mit Service. (4 Sek.) Und damit wir auch sichergehen können, dass Ihr uns auch alle hört und seht, wäre es super, wenn Ihr uns ein Zeichen gebt und in der rechten Fragebox mal ein Zeichen gebt, ein kurzes Hallo reinschreibt, ob denn auch die Technik funktioniert. (5 Sek.) Das sieht gut aus. Wir bekommen sehr viele Hallos, sie freuen sich auf das Webinar. Ja, dann würde ich mal sagen, das klappt super und wir starten. Genau. Wir starten mit einer kurzen Vorstellungsrunde. Gerne noch einmal kurz weiterklicken. (10 Sek.) Genau. Mein Name ist Angela Meyer. Ich bin heute Eure Moderatorin. Ich bin seit rund vier Jahren im diva-e-Marketingteam, betreue bei uns die Webinare und die Events. Und freue mich jetzt auf den Input von unserem Cloud-Experten Sascha Sauer. Genau. Ich übergebe jetzt Dir das Wort und ich freue mich auf Deinen Input.

Sascha Sauer: Ja. Danke schön, Angela. Mein Name ist Sascha Sauer. Ich bin Gründer und Geschäftsführer bei der diva-e und ich bin selbst Internetpionier der ersten Stunde. Seit 1994 beschäftige ich mich mit Internet, Internetapplikationen und mit allem was da dran und drum herum gehört. Unser heutiges Thema ist das Thema Cloud. Cloud ist in aller Munde. Und die Frage ist: Was ist da eigentlich dahinter? Was ist für große Unternehmen, für Enterprises, von Mittelstandsunternehmen mit globaler Ausprägung, was ist da eigentlich hinter der Cloud zu beachten, zu betrachten? Ich selbst bin studierter Wirtschaftsinformatiker. Deshalb bin ich nur bedingt technisch fit und meine Sicht ist eher aus der Managementsicht, aus der Organisationssicht auf diese Dinge. Und deshalb werden wir viel reden über Services, über Service-Level-Agreements und über Lücken, die wir auch in Verträgen immer wieder gefunden haben. Und möchten hier im Prinzip darauf aufmerksam machen, was es zu beachten gilt, wenn man in die Cloud geht mit seiner Applikation. Ich habe Euch dazu einige Slides mitgebracht und würde als erstes durch diese Slides durchgehen. Im Anschluss, wenn Ihr Fragen habt, könnt Ihr Fragen stellen über die Chatfunktion und Angela kann diese Fragen dann am Ende mir auch herübergeben.

Angela Meyer: Gerne. Ja.

Public vs. Private Cloud

Sascha Sauer: Ich habe hier eine Studie mitgebracht. Da geht es um Public Cloud und Private Cloud. Das sind die weltweiten Spendings, die hier prognostiziert sind in die Zukunft. Und worauf ich Euch hier aufmerksam machen möchte ist, dass wir sehen, dass zumindest in absehbarer Zeit die Spendings für Public Cloud und Private Cloud die Spendings für das traditionelle Hardware-Hosting bei weitem übersteigen werden. Besonders interessant ist auch, dass die beiden etwa gleich groß sein werden, so jedenfalls die Prognose. Kurze Einordnung: Public Cloud sind klassischerweise die sogenannten Hyperscaler oder auch die sage ich mal Anbieter, die weltweit auftreten, um Cloud-Infrastruktur anzubieten. Die großen sind sicherlich Microsoft mit Azure, dann Amazon mit dem Amazon-Web-Service und Google mit der Google-Cloud. Alibaba wäre noch zu nennen, aber auch IBM, SAP und einige andere Unternehmen, nicht zuletzt Face-Force betreiben eigene Cloudsysteme, die sie auch als Public Cloud anbieten. Mit Private Cloud-. Unter Private Cloud verstehen wir Cloudsysteme, die für Enterprises individuell betrieben werden, also auf Anforderungen von Unternehmen erstellt werden und auch nur im Kontext des Unternehmens selbst agieren, die allerdings auf Cloud-Solutions basieren, die also Cloud-Paradigmen, Cloud-Methoden beinhalten. So muss man das eigentlich sehen. Und warum sieht dieser Markt so interessant aus? Wir haben hier eine Studie zu den Aufteilungen der drei großen Private-Cloud-Anbietern nach Kundengruppen. Und ich selbst habe recherchiert, den Review-Last-Business-Year. Ich habe das hier mal mit eingetragen, damit man eine Vorstellung hat, welche Umsätze hier auch von den Unternehmen gemacht werden. Das ist also Amazon, Microsoft und Google. Und wie man hier sieht, sind das auf jeden Fall beachtliche Umsätze, die im letzten Geschäftsjahr jedenfalls erzielt worden sind von den drei Konkurrenten in diesem Bereich. Und was man hier auch sieht ist, dass natürlich die Verteilung zwischen Großunternehmen und Kleinunternehmen sehr unterschiedlich ist. Generell die Einteilungen ist so, dass natürlich Microsoft den deutlich stärkeren Business-Fokus hat. Viel stärker auf, ja, Bürosoftware schon lange setzt, deshalb natürlich einen dicken Footprint bei mittelständischen und großen Unternehmen hat.

Microsoft hat wahrscheinlich mit jedem Unternehmen der Welt eine Kundenbeziehung und das sieht man auch hier in der Applikationsverteilung. Microsoft hat hier sicherlich die größten Anteile an Enterprise und Mid-Market, Unternehmen bis 1.000 Mitarbeitern, sind die sehr gut aufgestellt. Die anderen sind, sage ich mal, auch nicht schlecht. Amazon sicherlich als Innovator in dem ganzen Gebiet, hat mich Abstand die allermeisten Kunden. Amazon ist auch immer einen kleinen Tick vorne, wenn es um die Technik geht. Die entwickeln immer zuerst die Services und die kleinen Tools, die gebraucht werden in der Cloud. Und es dauert eine Weile, bis Microsoft nachzieht. Google ist sicherlich für Entwickler hochinteressant, spricht eindeutig einen Markt an-. Mit sage ich mal sehr guten Development-Tools, spricht Google einen Markt an, der nicht unbedingt für Enterprise-Unternehmen geeignet scheint. Man muss hier ein bisschen vorsichtig sein. Wir kennen auch einige große Firmen, die in diesem Bereich unterwegs sind und dort auf die Google-Cloud-Lösungen gegangen sind. Insgesamt muss man sagen, dass für den deutschen Markt das Azure-Angebot wahrscheinlich das attraktivste ist. Ich komme im weiteren Verlauf auch noch einmal auf eine Einschätzung zwischen diesen drei Cloud-Providern im Public-Cloud-Bereich. (4 Sek.)

Die Cloud ist modern, aber was steht eigentlich dahinter? Was verspricht man sich von der Cloud? Warum gehen Applikationen in die Cloud? Warum lieben Manager IT-Manager, CEOs und CIOs-, warum lieben die die Cloud?

Und hier gibt es natürlich von vornherein einige Punkte zu nennen: Allen voran die Flexibilität. Die Cloud ist extrem flexibel. Wir können Systeme sehr schnell installieren. Wir können Systeme sehr schnell erweitern. Und wir können Sie genauso schnell auch wieder abbauen. Das ist natürlich ein Versprechen. Da sind neue Paradigmen dahinter gelegt. Das ist ein Versprechen, was jeder Manager sicherlich gerne hört. Dazu kommt das Thema Scalability und Globality. Im Wesentlichen geht es darum, dass ich auch, wenn ich mehr Traffic bekomme, mehr Kunden bekomme, wenn Geschäftsmodelle nach oben laufen, kann ich sehr schnell skalieren und das auch mit, sage ich mal einfachen Methoden. Und auch der globale Rollout, das ist häufig das größte Problem mit klassischen Hosting-Varianten. Der globale Rollout ist sehr einfach, ist sehr modern gestaltet. Ich kann dort auch in sehr kurzer Zeit Applikationen rund um die Welt herum ausrollen, deployen. Und entsprechend den Service, den ich meinen Kunden im Internet anbieten möchte, in allen Regionen der Welt anbieten. Dazu kommen zwei wesentliche Punkte, warum sich Manager für die Cloud entscheiden: Erstens Consumption of Service: Wir sehen, dass viele Innovationen heute in der Cloud stattfinden. Ein Beispiel ist ein Service, sagen wir mal, Translation-Service. Übersetzungsservice war lange Jahre ein großes Problem. Mittlerweile mit den Translation-Services in den Public-Clouds kann man das eigentlich weitestgehend als gelöst betrachten.

Das heißt, Sprachbarrieren gibt es so gut wie nicht mehr, wenn man das clever anstellt in den Applikationen. Das heißt, ich konsumiere einen solchen Service, der auch in der Cloud weiterentwickelt wird und der natürlich davon lebt, dass viele Leute in der Cloud diesen Service auch benutzen. Dadurch wir der immer besser. Alexa ist in aller Munde. Ich glaube, Ihr wisst wovon ich an der Stelle rede. Ist nur ein Beispiel. Es gibt viele, viele andere Beispiele von Services: Machine-Learning, KI, das sind alles Themen, die sich entwickeln. Darum geht es auch. Es werden im Prinzip diese Innovationen in Zukunft auch in der Cloud stattfinden und das verspricht natürlich auch eine effiziente Nutzung von zukünftigen Services in der Cloud. Auch das ist eine wesentliche Entscheidung: Warum sollte ich ein System in die Cloud tragen beziehungsweise ein neues System in der Cloud implementieren? Es gibt da allerdings auch einige Nachteile, die die Cloud mit sich bringt. Allen voran: Die Cloud ist nicht unbedingt billig. Die ganzen Vorteile: Flexibilität, Scalability und so weiter, die erkaufe ich mir teilweise mit doch anständigen Kosten. Wenn man das vergleicht, könnte man sagen, dass ein klassisches Hostingsystem, was ohne Flexibilität und ohne diese Vorteile auskommt-. Wenn ich das vergleiche, mit einem in der Cloud betriebenen System, was auch diese Vorteile nicht nutzt, wäre das wahrscheinlich mehr als doppelt so teuer, wenn ich es in der Cloud betreibe. Umgedreht sieht man das auch: Die Cloudanbieter geben für fest gemietete Cloud-Consumtion beziehungsweise Competition geben sie sehr starke Discounts, sage ich mal in einem Bereich von 70, 80 Prozent auf ihre normalen Cloudpreise. Darin sieht man schon ein bisschen: Flexibilität, Scalability, das kostet Geld. Entsprechend, einige unserer Kunden zahlen tatsächlich jeden Monat fünfstellige Beträge an die entsprechenden Public-Cloud-Hersteller für relativ überschaubare, zwar komplex, aber relativ überschaubare Systeme. Einige Public-Clouds haben Data-Security-Issues. Die werden immer wieder genannt. Da ist viel getan worden von den Cloud-Anbietern. Da ist vor allen Dingen im Private-Cloud-Bereich sehr viel möglich, aber man muss sich darum kümmern. Man kann das nicht einfach als gegeben hinnehmen. Man muss da selbst aktiv werden und muss die entsprechenden Sachen auch so anwenden, wie das angeboten wird. Ist nicht alles Out-of-the-Box sondern man muss sich darum kümmern. Dasselbe Thema wäre Corporate-Governance.

Viele Systeme in dem Bereich verstoßen gegen die Corporate-Governance, die sich die Unternehmen selbst gegeben haben. Da geht es darum: Umgang mit Daten, Umgang mit vertraulichen Daten, was sind Datengeheimnisse, Unternehmensgeheimnisse beziehungsweise wo dürfen Daten liegen. Datenschutz spielt da auch eine Rolle, Umgang mit den Datenschutzgesetzen entsprechend ist hier zu berücksichtigen. Auch da gibt es ein Arbeitsfeld, in dem einiges passiert ist, aber auch da gibt es immer wieder Bedenkenträger, die hier natürlich auch zu Recht einige Einschränkungen in der Komplettnutzung von Cloud-Systemen anmelden. Man muss sich das so vorstellen: Wenn ich einen Translation-Service benutze, der in der Public-Cloud verfügbar ist, dann werden Daten natürlich in das Internet, in die Cloud transportiert, werden dort gegebenenfalls übersetzt, werden gegebenenfalls analysiert und in übersetzter Art und Weise zurückgegeben. Jetzt kann man sich schon vorstellen: Das ist schwer nachvollziehbar, was da wirklich mit diesen Daten passiert. An der Stelle, wie gesagt, aufpassen, was man wirklich für Services auch benutzt. Und dann habe ich natürlich das Thema der Service-Level-Agreements. Weak-or-no-Service-Level-Agreements, habe ich hier mal geschrieben. Das ist auch ein Punkt, den ich nochmal vertiefen möchte. Da sehen wir momentan sehr großen Handlungsbedarf.

Was habe ich zu tun, wenn ich in die Cloud gehe?

Ich muss natürlich meine Applikationen, egal ob es eine bestehende Applikation ist oder es ist eine Applikation, die ich gerade kreiere beziehungsweise konzeptioniere. Ich muss die Cloud ready machen. Das bedeutet, monolithische Systeme müssen häufig zerlegt werden um überhaupt Cloud-Scalability oder auch Flexibilität zu erreichen. Und die Frage ist immer: Wie stark kann ich monolithische Systeme aufspalten oder neue Systeme so strukturieren, dass sie möglichst gut skalieren? Das ist ein eindeutiges Beratungsprojekt, was ich hier vor der Nase habe. Und die Abwägung ist einfach immer die: Wie stark kann ich mich unabhängig von den Cloud-Systemen aufstellen? Was möchte ich als eigenes Asset in der Applikation auch selbst entwickeln und behalten? Beziehungsweise wie stark möchte ich cloudspezifische Systemarchitektur verwenden? Da geht es mir auch vor allen Dingen um die Services, die ich, ja, konsumieren möchte. So schön wie es ist, dass mir Services helfen, aber wenn ich nicht alle Parameter, ich hatte gerade schon gesagt, zum Beispiel Governance oder auch Security-Issues. Wenn ich die nicht alle berücksichtigen kann für einen speziellen Service oder eine entsprechende SLA wird nicht eingehalten, muss ich Services vielleicht auch unabhängig von der Cloud lösen, obwohl ich es in der Cloud betreibe. Das ist eine Beratungsaufgabe. Hier muss ich mit einem Cloud-Experten reingehen, muss eine Cloud-Architektur erarbeiten oder mich beraten lassen, wie ich eine Cloud-Architektur erzeugen kann. Ansonsten laufe ich Gefahr, ein doch relativ teures System an Ende stehen zu haben, was in keiner Weise nachher weder sage ich mal flexibel und skalierbar noch sicher oder auch von der vertraglichen Seite her durch SLAs abgesichert werden kann.

Da ist immer wieder zu sagen: Jede Minute, die man reinsteckt in eine ordentliche Konzeption und in eine anständige Cloud-Architektur ist am Ende wahrscheinlich Tage oder Wochen zu sparen an Aufwand. Wenn man sich also für die Cloud entscheidet: Was bedeutet das im Detail? Um das noch einmal greifbarer zu machen und da sprechen wir bei diva-e aus unserer Sicht auf jeden Fall immer über digitale Projekte, digitale Plattformen. Digitale Plattformen müssen in der Cloud heutzutage betrieben werden. Da gibt es mittlerweile zu viele Vorteile, aber ich muss die Hausaufgaben machen, ich muss die Nachteile der Cloud, die muss ich mir bewusst machen und muss darauf Antworten finden. Ich habe hier links mal aufgelistet, was so im Groben getan werden sollte, wenn man in der Cloud startet. Wenn man in der Cloud startet, eine digitale Plattform zu betreiben, sollte man sich um alle diese Dinge kümmern, die hier links aufgelistet sind. Und man beginnt tatsächlich überall auf der grünen Wiese.

Man muss sich das so vorstellen: Die Cloud-Infrastruktur, die Public-Cloud-Anbieter, die stellen natürlich die entsprechenden Services zur Verfügung. Die lassen sich über ein Backoffice zusammenklicken und sind betriebsbereit, aber ich muss es tun. Ich muss jeden Schritt selbst tun und ich muss natürlich auch wissen, was ich tue. Wenn ich, jetzt nehme ich mal den ersten Punkt: Authorisation-Concept: Wenn ich mir nicht klar bin, welche Regeln ich in meiner Applikation brauchen, wer hat Zugriff auf welche Daten, wie will ich die Passwort-Policy anlegen? Will ich eine Zwei-Faktor-Autorisierung verwenden oder auch nicht oder teilweise? Dann sind das alles Themen, die mir hinten wieder auf die Füße fallen, wenn ich mit dem System live bin. Weil diese Konzepte nachträglich einzubauen ist häufig extrem teuer. Also am Anfang hier schon während der Projektphase sich einen Kopf machen, hier mit reingehen, mit Beratern diese einzelnen Punkte abarbeiten, das hilft am Ende ganz viel Zeit zu sparen. Auf der rechten Seite ist das noch einmal dargestellt. Wenn wir eine Hybris oder einen Spryker-System mal als Beispiel hier benannt, in der Cloud betreiben, zum Beispiel auf einem Linux-System, einem Docer-Environment, das mit Kubernetes gemanagt wird. Dann bin ich einem Bereich unterwegs, der schnell sehr komplex wird.

Man sieht schon die Vielzahl von Kästchen, die sich hier auf der rechten Seite stapeln. Das lässt sich sehr schnell erweitern, wenn ich jetzt noch Services, Cloud-Services konsumiere, bin ich schnell bei vielen, vielen Kästchen über die ich sage ich mal ja, die eben die Aufgabe habe, mich zu kümmern. Und das kann ich nur mit Automationen machen. Wir bei diva-e implementieren Cloud-Applications immer automatisiert. Das heißt, es gibt eine-, gibt Automatisierungsskripte, Terraform oder Incibles sind da jetzt nur zwei Technologiebeispiele, die wir einsetzen. Es gibt Automatisierungsskripte, die entsprechend des-, der Konzepte, die links stehen, diese Dinge alle tun. Und dadurch bin ich dann erst in der Lage, auf Knopfdruck Systeme zu installieren oder auch wieder abzureißen oder zu skalieren oder auch Mehrfachsysteme aufzusetzen, um zum Beispiel gegebenenfalls auch Sachen zu testen. Das darf man nicht unterschätzen. Das ist für uns wahrscheinlich bei diva-e eine der hauptsächlichen, ja, Erfahrungen, die wir in den letzten drei Jahren mit der Cloud, mit den Cloud-Systemen gesammelt haben.

Diese Automatisierungsskripte sind eigene Softwareprojekte und die müssen auch wie Softwareprojekte behandelt werden von Anfang an. Diese Automatisierungsskripts sind also auf der einen Seite agil. Sie müssen sich weiterentwickeln entlang des Projektpfades müssen sie weitergezogen werden. Und sie müssen aber auch natürlich berücksichtigen, dass sie nicht nur die Antworten im Projekt, in der Applikation bedienen, sondern auf der anderen Seite auch die Anforderung der Cloud bedienen, weil auch die Cloud selbst, die Cloud-Provider aber auch die Cloud-Services entwickeln sich ja ständig weiter. Und auch da habe ich einen permanenten Update-Mechanismus, den ich berücksichtigen muss. (4 Sek.) Jetzt komme ich mal zu den SLA-Dilemma. Jetzt haben wir verstanden, was wir für normale digitale Plattformen, durchschnittliche digitale Plattformen für ein mittelständisches Unternehmen, halt schnell-, in der Cloud schnell 30, 40 Services, die da eine Rolle spielen. Die ich normalerweise in einer Cloud-Umgebung konsumiere. Beispiel ist ein DNS-Service. Ich brauche natürlich eine eigene Network-Infrastructure, die ich aufsetze und die funktioniert nur, wenn ich ein DNS-Service benutze. Das ist relativ einfach zu verstehen. Wenn wir das Beispiel von Microsoft Azure jetzt einmal hernehmen, ich habe das mal ein bisschen analysiert. Innerhalb von Microsoft Azure werden ungefähr 700 solche Services angeboten. Also wie gesagt: Vom DNS-Service ganz einfach über das Active-Directory bis hin zu komplexen Services, wie künstliche Intelligenz und Machine-Learning, eine Riesenbandbreite.

Es werden unheimlich viele Services angeboten und die kann ich natürlich alle konsumieren. Die kann ich natürlich alle nutzen. Die kann auch natürlich alle gerne bezahlen. Microsoft liebt dieses Modell. Damit verdient Microsoft das Geld und dort wird viel Innovation betrieben. Es werden viele neue Services erzeugt. Wenn man sich die SLAs, die man bei Microsoft findet, anguckt, werden von den 700 Services erst einmal nur 91 überhaupt in diesen SLA erwähnt. Jeder von den 91 wiederum hat also-. Sagen wir mal umgedreht noch einmal ganz kurz: Also über 600 Services haben erst einmal gar kein SLA. So. Von den 91 Services hat jeder irgendwie andere Regeln. Es gibt andere Verfügbarkeitszeiten. Es gibt Spezialtarife. Es gibt Abhängigkeiten. Manchmal geht es auch nur um 99,9 Prozent innerhalb von 30 Minuten. Manchmal geht es 99,9 Prozent innerhalb von fünf Minuten. Es ist sehr, sehr komplex, wenn man sich damit auseinandersetzt. Und es gibt natürlich hier zum Beispiel zu nennen: Es gibt auch 15 Services von denen ausdrücklich erwähnt wird, dass es dazu kein SLA gibt. Das heißt, es wird nur angestrebt, diesen Service bereitzustellen, aber Microsoft sieht sich nicht in der Lage, dort einen fixen SLA darauf zu geben. Jetzt habe ich mal überlegt, wie wir das greifbar machen, dass wir die drei Systeme vergleichen können.

Und ich habe 30 zufällige Services ausgewählt von diesen 91 und habe mal den SLA berechnet, der sich daraus ergibt, wenn ich diese 30 Systeme, diese 30 Services zufällig benutze. Und dann komme ich hier im Prinzip auf 98,59 Prozent. Das würde heißen-. Wenn man das als SLA für das Digitalsystem anlegt, würde es heißen, dass man hier zehn Stunden pro Monat Downtime kalkulieren müsste. Das kann jetzt jeder für sich überlegen, ob das sinnvoll ist oder nicht sinnvoll ist. Wenn ich eine businesskritische Applikation habe, die mir, ja, innerhalb von zehn Stunden mal in einem Monat ausfällt, muss sich jeder überlegen, was das für jemanden bedeutet. Das ganze Spielchen noch einmal für Amazon. Amazon-Webservice, ungefähr 750 Services sind dort gelistet auf der Webseite im AWS. Der SLA beinhaltet 107 Services. Allerdings, ich habe auch extra noch einmal nach Kubernetes geschaut. Kubernetes wird auch nicht gelistet, hat also keinen SRA, auch bei Amazon nicht. Übrigens auch bei Google nicht. Und auch hier habe ich wieder 30 zufällige Services mir herausgepickt und habe mal die Multiplikation entsprechend durchgeführt. Dann bin ich hier auf einen Wert gekommen von Systemverfügbarkeit 97,6 Prozent, entsprechend 16,7 Stunden Downtime im Monat. Das ganze Spielchen noch einmal mit der Google-Cloud. Etwa auch 700 Services in der Google-Cloud. Alle ungefähr auch wieder vergleichbar.

Auf der rechten Seite sieht man das sind ähnliche. Alles immer ähnliche Themen, sehr vergleichbare Themen, die da angeboten werden. Der SLA ist sehr dünn. Es gibt nur 38 Services, teilweise nur, eigentlich nur 99,9 als Maximum. Kubernetes gibt es auch nicht. Und wenn man das alles mal beispielhaft zusammen kalkuliert, kommt auf nur 97 Prozent oder auf 20 Stunden Downtime. Das alles ist aus unserer Sicht ein Dilemma-, ein Dilemma für businessrelevante Digitalplattformen. Man stellt sich vor, wir betreiben bei diva-e zum Beispiel IOT-Plattformen, Produkte müssen funktionieren. Wenn Produkte 20 Stunden im Monat ausfallen, schwer zu sagen, dass man da als Anbieter eines Produkts mit IOT-Komponente vom Kunden da nicht einen Anruf bekommt oder ganz und gar in Regress genommen wird. Wie gesagt, diese SLAs sind erst einmal die Standard-SLAs, die angeboten werden auf den Webseiten in dem Public-Cloud-Bereich. Im Private-Cloud-Bereich habe ich da vielleicht noch einmal ein paar andere Möglichkeiten, aber bevor man dort tiefer eingehen, noch ein Gedanke zu dem Dilemma der Standard-Produkt-Anbieter: Es gibt noch eine andere Betrachtungsweise, die wir hier sehen momentan. Immer mehr Standard-Produkt-Anbieter, wie zum Beispiel jetzt mal Bloomreach, Intershop oder auch SAP gehen dazu über und bieten ihr Produkt an im Software-as-a-Service-Modus. Ja? Das heißt auf Basis eines meistens Public-Cloud-Providers unten AWS, Azure oder Google-Cloud bietet der Standard-Produkt-Anbieter ein Standard-Produkt an und gibt darauf auch eine entsprechende SLA. Natürlich auch hier wieder die Frage der Abgrenzung ist nicht ganz sauber geklärt. Ist das alles komplett im Bauch mit drin oder nicht? Ich habe da auch sehr schwammige Aussagen auf den Webseiten leider nur gefunden. Und auch die alleinige SLAs, die die Standard-Anbieter standardmäßig zumindest anbieten, sind sehr unterschiedlich. Es gibt eine Premium-Variante bei Intershop mal als Beispiel für ein E-Commerce-System Intershop. Reaktionszeit sind da 30 Minuten.

Bei SAP-Hybris Standardvertrag wird angeboten 24 Stunden Reaktionszeit. Riesendiskrepanz und natürlich für eine E-Commerce-System vielleicht auch nicht unbedingt sinnvoll. Da muss man genau reingucken: Welche SLAs sind verfügbar? Beziehungsweise welche SLAs passen auch zu meiner businesskritischen Applikation? Dazu kommt, dass wir natürlich darüber reden, dass wir als Customized-Project haben. Kein Standard-Produkt wird so eingesetzt, wie es vom Standard-Anbieter bereitgestellt wird. Für das Customized-Project übernimmt keine Standard-Anbieter ein SRA. Dazu kommt, dass im Zusammenhang mit so einem Digitalprojekt Integration APIs Kommunikation stattfindet zu EAP-System Dritt-Party-Systems, CAM-System. Auch diese Kommunikation ist niemals Teil des SLAs des Standard-Produkt-Anbieters. Und es gibt natürlich noch die klassischen Service-Aufgaben im Zusammenhang mit Betrieb, mit Cloud-Betrieb. Ich habe jetzt hier nur mal Service-Management, Spending-Control, Security-Management und Corporate-Governance wieder aufgeführt. Auch dazu gibt es keine Aussage. Das heißt, auch hier habe ich ein SLA-Dilemma, wenn ich eine businesskritische Digitalplattform in der Cloud betreibe, habe ich eine große Lücke zwischen dem, was ich als Lizenz im Cloud-Modus mit SLA einkaufen kann und dem, was ich eigentlich brauche. Denn machen wir uns mal nichts vor: Das Gesamtsystem muss funktionieren und muss mit einem entsprechenden SLA unterlegt sein um mir im Businessbetrieb auch das zu leisten oder leisten zu können, was ich eigentlich brauche um wiederum meine Kunden glücklich zu machen. Wir bei diva-e bieten deshalb verschiedene Cloud-Services an.

Zum einen bieten wir an, die bei E-Cloud-Application-Management. Das ist mit der Option versehen, Servicelevel 24 mal sieben in vier Stunden Restorationtime abzuschließen. Das ist also nicht Reaktionszeit sondern Wiederherstellungszeit. Da sind wir sehr stolz drauf. Wir können diesen Service in dieser Ausprägung in Private-Cloud, die wir selbst bei diva-e betreiben, anbieten oder in der Public-Cloud Microsoft. Wir sind momentan dabei, reinzuschauen, ob wir das auch für AWS anbieten können. Die Entscheidung ist an der Stelle noch nicht hundertprozentig gefallen. Da müssen einfach noch ein paar Themen geklärt werden. Auf der anderen Seite bieten wir an, diva-e-Cloud-Consulting. Das ist das ganze Thema: Wie implementiere ich Projekte, damit sie nachher entsprechend funktionieren in dem entsprechend gewählten Public- oder Private-Cloud-Umgebung. Wir können Migration von Monolithen unterstützen. Wir können Dev-Ops-Systeme unterstützen. Cloud-Automation haben wir viel Erfahrung gesammelt, können wir anbieten. Dort haben wir Architekten, die beraten können. Und nicht zuletzt auch das Thema Security-Management und Corporate-Governance sind Teile, die wir als diva-e-Cloud-Consulting anbieten. Letzte Folie soweit von meiner Seite: Ein paar Kunden, für die wir diesen Service aktuell bereits anbieten. Ich habe leider auch keine Ahnung, warum das nur blaue, schwarze und rote Logos sind. Wahrscheinlich gibt es keine anderen Farben. Ich bin also sehr interessiert, weitere Kunden, insbesondere grüne und gelbe Kunden hier mal zu finden. Und an der Stelle möchte ich mich ganz herzlich bedanken für Eure Aufmerksamkeit.

Q&A

Angela Meyer: Danke, Sascha für Deinen sehr interessanten Input. Natürlich werden wir hier kein SLA-Dilemma mehr haben. Und genau. Wir freuen uns jetzt auf Eure Fragen und stehen zur Fragerunde nun bereit. Und da trudeln jetzt auch schon die ersten Fragen rein. Sascha, ich stelle sie mal direkt an Dich. Die erste Frage wäre hier:

Was kostet denn dieser Service für eine cloudtypische Weise?

Sascha Sauer: Also die, ja, also unser Service ist da jetzt wahrscheinlich gemeint, der diva-e-Kundenservice. Der beginnt ungefähr, also für eine kleine Lösung muss man schon etwa rechnen, dass der bei 2.900 Euro im Monat beginnt. Das ist so ein kleines System. Das kann natürlich nachher in der großen Ausprägung auch deutlich größer werden. Ja? Man muss das im Verhältnis sehen auch zu dem, was man in der Public-Cloud oder auch mit Private-Cloud-Infrastruktur bezahlt. Wir sind mittlerweile in der Lage, dort auch sehr attraktive Preise natürlich anzubieten. Wir haben ein Team von etwa 40 Engineers, die da zur Verfügung stehen und die den Service erbringen.

Angela Meyer: Genau. Also gerne können wir im Nachgang dann noch konkreter auf ein Angebot eingehen. So. Ich würde jetzt gerade mal die zweite Frage hier aufgreifen und ein Teilnehmer möchte wissen:

Warum machen die Cloud-Anbieter dann so etwas nicht?

Sascha Sauer: (4 Sek.) Was machen die nicht? Den SLA oder?

Angela Meyer: Ja. Da-, den Service.

Sascha Sauer: Also na ja, gut. Die haben einen anderen Fokus also-. Wenn Microsoft, Amazon, die haben natürlich eine Basisinfrastruktur, die sie sehr effizient managen können. Deshalb sind sie ja, sage ich mal auch flexibel, können da auch sage ich mal Ressourcen sehr schnell hin- und hershiften. Das ist alles so auch auf jeden Fall ein einfaches Business, was die zu bedienen haben. Aber mit-, sich mit der konkreten Applikation auseinanderzusetzen, die tatsächlich beim Kunden Mehrwert erzeugt, das ist nicht im Fokus, sondern es geht wirklich um einzelne Funktionalitäten wie eine Managed-Instance von einer Datenbank, sage ich mal eine Microsoft SQL-Datenbank, die ich als Managed-Instance bereitgestellt bekomme. Das ist natürlich ein Thema, womit sich Microsoft auseinandersetzt. Was ich direkt da drin machen, welche Daten da drin sind, welche-, ob da Verkäufe stattfinden oder ob da ein Service-Portal damit abgebildet ist, was natürlich wieder Schnittstellen hat und so weiter. Das ist alles nicht das Business und der Fokus von Microsoft. Deshalb können die in Prinzip da auch gar nicht drauf reagieren und dort, sage ich mal, solche SLAs anbieten. Das ist Teil, verstehen wir so, dass ein Dienstleister wie die diva-e dort entsprechend das Angebot abgibt im Markt. Genauso ist es für die Standardproduktanbieter. Auch so ein Standardproduktanbieter guckt sein Standardproduktsdeck an. Das was darüber hinaus individualisiert wird, das kann er nicht oder nur sehr, sehr eingeschränkt kann er das mitbetreuen. Denn er müsste das ja für alle Kunden mitbetreuen. Auch da wahrscheinlich Installierungsproblem vom Service her. Ja.

Angela Meyer: Ja. Okay. Wenn dann diese Frage so umfänglich dann beantwortet ist, würde ich noch die nächste aufgreifen.

Und hier möchte ein Teilnehmer wissen, ob er bereits bestehende Services oder eben bereits bestehende Anwendung dann von uns, von diva-e managen lassen kann?

Sascha Sauer: Das geht. Das haben wir gemacht. Wir haben auch Projekte übernommen in unsere Verantwortung, die andere Dienstleister oder der Kunde selbst implementiert haben, die auch zum Beispiel schon in der Cloud-Umgebung aufgesetzt waren. Was wir da machen ist, dass wir aber trotzdem eine gewisse Transitionsphase vorneweg brauchen, weil, wir müssen uns auseinandersetzen mit der Applikation. Wir müssen gegebenenfalls auch unsere Betriebsstandards sage ich mal gegenhalten und da überprüfen, ob wir diese Lösung betreiben können, aber prinzipiell ja. Das machen wir und wir können dann für diese Lösungen, wenn die unseren Betriebsstandards entsprechen, auch die entsprechenden SLAs anbieten.

Angela Meyer: Super. Ja, da gerne auch den Aufruf an die Teilnehmer: Wenn Ihr da weiteres Interesse habt, gerne auf den Sascha und sein Team zukommen. Die schauen dann gerne auf Eure bestehende Services und Anwendungen an. So. Es sieht gut aus. Schreiber: Also alle Fragen bestens hier beantwortet, Sascha. Dann gerne noch einmal einen Klick weiter auf die nächste Seite.

Sascha Sauer: Jawohl, Angela.

Angela Meyer: Und dann, genau, würden wir uns natürlich freuen, wenn Ihr Euch für weitere Webinare anmeldet, die wir gemeinsam mit uns dann Technologiepartnern und Kunden veranstalten. Alle Informationen dazu findet Ihr in unserem diva-e-Newsroom. Einfach unter diva-e, Newsroom eingeben und dort könnt Ihr Euch dann zu unserer nächsten diva-e-Webinaren anmelden. Genau. Ja. Dann würde ich Euch verabschieden. Vielen Dank, Sascha für Deinen Input und danke für die Teilnahme. Wir freuen uns auf das nächste Webinar und wünschen Euch dann jetzt noch einen schönen sonnigen Nachmittag.

Sascha Sauer: Tschüss.

Angela Meyer: Tschüss.