Ich war gestern zur SAPPHIRENOW @ Walldorf, einem deutschen Parallel Event von SAP zur großen SAPPHIRENOW in Orlando, eingeladen. SAP kündigte hier seine zukünftige Cloud Strategie an und stellte in diesem Zusammenhang mehrere neue Services vor. Was ich jedoch viel spannender finde ist, ob SAP deutsche Unternehmen dazu bewegen kann, endlich die Skepsis gegenüber der Cloud abzulegen. Neben der Telekom bzw. T-Systems, die allerdings überwiegend im Infrastructure-as-a-Services Bereich tätig sind, sehe ich kein Unternehmen, dass die Marktmacht und den Einfluss besitzt, um die deutschen Unternehmen mitzureißen und damit für den Durchbruch der Cloud in Deutschland zu sorgen.

Den Cloud Gedanken hat sich SAP extern durch die Akquisiton von SuccessFactors bzw. dessen Gründer und CEO Lars Dalgaard einverleibt. Der Däne wurde nach der Übernahme als Verantwortlicher für den SAP Cloud Bereich zur treibenden Kraft hinter den SAP Cloud Services. Und diesen Job macht er augenscheinlich gut. In seiner Key Note, während der er die neue Cloud Strategie von SAP vorstellte, präsentierte Dalgaard sich als explosiver Unternehmer, der seine Startup Gene bei weitem nicht abgelegt hat. Im Gegenteil, mit seiner Motivation bringt er frischen Wind in den etablierten Konzern aus Walldorf. Es bleibt für Dalgaard und vor allem für SAP zu hoffen, dass er seine Cloud Vision verwirklichen darf und das er mit seinem Startup Charakter auf offene Türen hoffen darf. Denn SAP ist weit weg von dem, was man logischerweise als ein Startup bezeichnen kann.

Die SAP Cloud Strategie

Das SAP Cloud Portfolio konzentriert sich auf vier Bereiche, die sogenannten Line-of-Business-Lösungen, welche die Verwaltung von Mitarbeiter-, Finanz-, Kunden- und Lieferantenprozesse fokussieren und sich nahtlos in Enterprise-Resource-Planning Software einbinden lassen.

Insbesondere der bereits oben genannte Lars Dalgaard hat einen starken Einfluss auf die Cloud Neuausrichtung von SAP und hat sich und seinen Mitarbeitern das Ziel gesetzt, kreative und innovative Lösungen auf den Markt zu bringen, die mit ihrer Benutzeroberfläche begeistern sollen. Dabei will SAP die On-Premise Lösungen nicht sterben lassen, sondern die verfügbaren Inhalte in den Cloud Lösungen mit der On-Premise Unternehmenssoftware verzahnen, was SAP Co-CEO Jim Hagemann Snabe während der Pressekonferenz noch einmal herausstellte. In Zukunft wird zwar alles in der Cloud landen, jedoch wird hier zwischen der Private Cloud und den Cloud Lösungen die von SAP gehostet werden unterschieden.

Weiterhin wird SAP seine mandantenfähigen Cloud Services zerlegen und als einzeln verfügbare Lösungen anbieten, um den Kunden es zu ermöglichen, je nach den eigenen Anforderungen und nach einem eigenen Zeitplan die Anwendungen einzuführen. Trotz dieser Zerlegung wird SAP mit SAP Business ByDesign und SAP Business One OnDemand weiterhin vollständig integrierte Suites für die Cloud anbieten.

SAP NetWeaver Cloud: Platform-as-a-Service von SAP

Eine weitere Neuigkeit in der SAP Cloud Strategie ist ein eigenes Platform-as-a-Service-Angebot, das als SAP NetWeaver Cloud angekündigt wurde. Basierend auf SAP HANA stellt der Services Entwicklern eine Umgebung mit Anwendungsentwicklungs- und Laufzeitfunktionalitäten zur Verfügung. Zudem wurde eine Partnerschaft mit weiteren Drittanbietern von PaaS-Angeboten vorgestellt, darunter VMware Cloud Foundry. Das Ziel soll es sein, Kunden die Möglichkeit zu bieten, externe PaaS Lösungen zusammen mit den Plattform-Services von SAP NetWeaver Cloud zu nutzen, um damit ihre SAP-Lösungen zu erweitern.

SAP öffnet sich nach Außen

Um seinen Kunden die größtmögliche Freiheiten beim Umgang mit den Cloud Produkten zu bieten, öffnet sich SAP nach Außen. Mit einem Integration-as-a-Service Ansatz soll damit die Verknüpfung hybrider-IT-Landschaften, also die Kombination von Cloud und On-Premise Implementierungen, unterstützt werden. Neben Prozessintegration beinhaltet das Integrationsangebot weiterhin Daten-Services, um lose Cloud-Lösungen mit anderen SAP-Anwendungen zu verbinden, unabhängig davon, ob diese sich in der Cloud oder On-Premise befinden. Dazu plant SAP, eigene Cloud-basierte Integrationstechnologien anzubieten und hat strategische Kooperationen mit CloudFoundry, Dell Boomi, IBM Cast Iron und Mulesoft bekanntgegeben.

SAP konzentriert sich auf Cloud, Mobile, Social und Big Data

Neben der Cloud stellt sich SAP ebenfalls in den Bereichen Mobile, Social und Big Data auf. Allerdings nimmt die Cloud hier eine zentrale Rolle ein, da die Kommunikation, Kollaboration und der Zugriff auf Daten über sie effektiver abgewickelt werden kann. Mit integrierte Social-Collaboration Tools will SAP seinen Kunden zudem helfen, ihre Geschäftsziele schneller im Team zu erreichen, unabhängig davon ob es um die Zusammenarbeit mit global verteilten Kollegen oder mit dem Büro nebenan geht. Eine zentrale Komponente nimmt SAP HANA ein. Über die Plattform, die gleichzeitig als SAPs Technologie für die Verwaltung, Analyse und Bereitstellung großer Datenmengen (Big Data) gilt, erhalten Nutzer die Informationen, die sie benötigen, um schnelle und angemessene Entscheidungen zu treffen.

SAP: Treiber der Cloud in Deutschland?

Der größte deutsche Softwarekonzern hat die Cloud nun auch für sich entdeckt und sich das Ziel gesteckt, bis 2015 der führende Cloud-Anbieter weltweit zu werden. Zudem soll dieser Geschäftsbereich einen Umsatz von zwei Milliarden Euro erzielen.

Die spannende Frage bleibt jedoch, lassen sich auch die der Cloud eher skeptisch gegenüber stehenden deutschen Unternehmen, insbesondere die Mittelständler, von SAP in die Cloud mitreißen? Gute Gründe würde es geben. SAP verfügt in Deutschland über einen hohen Marktanteil und eine breite Kundenbasis. Insbesondere beim viel diskutierten Thema Datenschutz können die Walldorfer auftrumpfen. Die Cloud Lösungen SAP Business ByDesign und SAP Business One OnDemand werden in Rechenzentren in Deutschland, genauer St. Leon-Rot, betrieben, SuccessFactors in Amsterdam, also ebenfalls im europäischen Rechtsraum. SAP nennt seine Cloud auch „Controlled Cloud“, da nach eigenen Angaben, nicht einmal die eigenen Mitarbeiter Zugriff auf die Daten der Kunden hätten.

Ein weiterer Faktor kann das Angebot von einzeln zu beziehenden Cloud Services sein, die dennoch vollständig ineinander integriert werden können. Das Anbieten von einzelnen Services, wird auch „Building Blocks“ genannt und zeichnet eine Vielzahl von Cloud Services auf dem Markt aus. Ob SAP Bestandskunden dieses dankbar annehmen werden, wird sich zeigen, allerdings würde der Wechsel in dem ein oder anderen Fall sicherlich Sinn machen, denn warum soll man für Dinge bezahlen, die eigentlich nicht benötigt werden. Zudem erhalten damit auch noch nicht SAP-Kunden die Chance, einzelne Services für ihre Anforderungen zu selektieren, ohne ein umfangreiches Softwarepaket zu kaufen.

Bildquelle: http://www.wiwo.de

Platform-as-a-Service (PaaS) gehört mit Abstand zu den Zukunftsthemen im Cloud Computing. Im Jahr 2011 kamen neben bereits bestehenden Anbietern wie Heroku, Cloud Foundry, Engine Yard, Beanstalk, Windows Azure, Force.com, OpenShift oder cloudControl, viele weitere hinzu, was die mediale Präsenz dieses Cloud Bereichs anhob. Nur um einen Service ist ein wenig ruhig geworden: Die Google App Engine.

Die Google App Engine war bereits sehr früh verfügbar

Die Google App Engine (GAE) gehört mit der Erscheinung im Jahr 2008 zu einer der ersten PaaS am Markt und war der einzige Service der Python und Java gleichzeitig unterstützte. Aber im Laufe der Jahre hat die Innovation rund um GAE deutlich nachgelassen.

Startups und Entwickler gehörten zu den Hauptnutzern von GAE. Das lag in erster Linie an den Möglichkeiten der weitestgehend kostenlosen Nutzung und den nicht notwendigen Investitionen in SDKs und Plugins. Ein weiterer Grund war die geringe Auswahl an Angeboten. Java und Python Entwickler würden niemals Windows Azure wählen, was zu diesem Zeitpunkt die einzige Alternative war. Nach und nach entwickelte sich Heroku (mittlerweile von Salesforce aufgekauft) zu einer echten Alternative für Python Entwickler, auf Kosten der Google App Engine. Doch bereits während der Anfangsphase der GAE hat Google es verpasst die riesige Anzahl an gehosteten Anwendung an Bord zu behalten und die wichtige Entwickler Community für sich zu gewinnen. Was ist also der Grund für den Abstieg der Google App Engine?

Refactoring und Vendor lock-in

Ein Hauptproblem der Google App Engine besteht in den massiven Änderungen die vorgenommen werden müssen, wenn eine Anwendung auf die GAE portiert werden soll. Befindet sich die Anwendung dann auf der GAE, kann sie ausschließlich die proprietäre API nutzen, was es Entwickler sehr schwierig macht, später die Plattform wieder zu wechseln. Selbst Standard Java Web Anwendungen müssen an vielen Stellen angepasst werden, um auf der GAE betrieben zu werden. Während Heroku weitere Funktionen hinzufügte und für eine bessere Kontrolle sorgte, schränkte Google die Entwickler mit der proprietären API ein.

Beta-Status und Innovationen

Microsoft, das für seine langen Release-Zyklen bekannt ist, hat es geschafft das Azure SDK mehrfach zu aktualisieren und das Management Portal häufig zu verbessern. Die Google App Engine orientiert sich an Googles „Beta-Status“ Tradition. So blieb die GAE für fast drei Jahre im Beta-Status, was professionellen Entwicklern nicht die Sicherheit gab, ihre Produktionsanwendungen auf die GAE zu portieren. Während Google in der jungen Vergangenheit mit Pull Queues, Cloud SQL und der Blobstore API viele der gewünschten Funktionen umsetzen konnte, hat es lange gedauert auf die Bedürfnisse der Kunden zu reagieren.

Schlechte Unterstützung für Unternehmensanwendungen

Lange unterstützte die GAE nur zustandslose Web Anwendungen. Technologisch betrachtet können auf der GAE somit nur Web Anwendungen entwickelt werden, die keine komplexe Business-Logik benötigen. Bspw. verfügt Windows Azure über ein Rollenkonzept (Web Roles), um Web Anwendungen zu betreiben und Worker Roles, um damit lang laufende Prozesse und komplexe Geschäftsregeln ausführen zu lassen. Ähnlich verhält es sich bei Heroku, wo der Web Dyno und Worker Dyno diese Funktionen aufteilen. Bis zur Einführung von Backends in der Version 1.5.0 (Mai 2011), machte diese mangelnde Unterstützung zur Aufteilung einer Anwendung es schwierig Unternehmensanwendungen auf die GAE zu migrieren.

Der Datenzugriff

Lange nutzte die Google App Engine ausschließlich Big Table als primären Datenspeicher. Amazon zog schnell mit SimpleDB nach, führte damit weitere Funktionen ein und veröffentlichte mit RDS einen Database-as-a-Service. Zuletzt folgt dann DynamoDB. Das Fehlen eines guten Speichers für Transaktionsdaten schränkte die Entwickler bei der Nutzung der GAE stark ein. Jede Anwendung die professionell eingesetzt werden soll, benötigt zwangsläufig eine Kombination aus relationaler und NoSQL-Datenbank, um innerhalb der Cloud zu skalieren. Die GAE verfügte nicht über diese Funktionen, die für Daten-intensive Anwendungen erforderlich sind. Services wie BlobStore und Cloud SQL kamen demnach viel zu spät.

Vermarktung

Mit der Google App Engine hatte Google die ideale Position, Startups eine kostengünstige Plattform anzubieten. Sie wäre ideal gewesen, um typische Web-Anwendungen für den Markt der Endverbraucher zu entwickeln und bereitzustellen. Allerdings hat Google sich hier von Anfang nicht deutlich positioniert. Typische Low-End Web-Anwendungen, die prädestiniert für den Einsatz auf der App Engine gewesen wären, haben sich für Heroku entschieden, wohingegen High-End Anwendungen und Anwendungen mit hohen Workloads zu Amazon EC2 gegangen sind. Die Einführung der Amazon Micro Instanzen und die Free Tier Angebote haben der Google App Engine zudem weiterhin geschadet. Bis heute kann man nicht eindeutig sagen, welchen Platz die Google App Engine auf der mittlerweile großen Landkarte des PaaS einnimmt. Soll sie, aus Sicht von Google, genutzt werden, um Low-End Web-Anwendungen zu betreiben oder doch lieber für Unternehmensanwendungen?

Kosten

Natürlich mag es niemand, wenn ein vormals kostenloser Service nun bezahlt werden muss. Jedoch muss Google mit der App Engine auch irgendwann Geld verdienen. Allerdings hielten die Entwickler das neue Preismodell für äußerst unangemessen. Es gab einen riesen Aufruhr in der Community, als Google die neue Preisstruktur vorstellte. So stellten viele Kunden fest, dass ihre Kosten plötzlich um das drei- bis fünffache steigen würden. Das führte zu einem großen Bruch mit der Community, wodurch u.a. einige Startups von der Google App Engine zu Amazon EC2 bzw. zu einem klassischen Web Hoster gewechselt sind.

Sonstiges

Die GAE Entwickler Community hat den Eindruck, dass die App Engine im Vergleich zu Android innerhalb von Google schlechter angesehen wird. Das führt ebenfalls zu einer schlechten Stimmung.

Google und VMware kündigten damals auf der Google I/O im Jahr 2010 eine Partnerschaft an, um Spring auf die Google App Engine zu portieren. Trotz der Ankündigung kaufte VMware dennoch RabbitMQ und WaveMaker und brachte mit Cloud Foundry seine eigene PaaS Lösung auf den Markt. Während VMware CloudFoundry als Open PaaS positionierte, blieb die Google App Engine auf der Strecke.

Ein weiterer Rückschlag für Google war der Verlust des bekannten GAE Evangelist Patrick Chanezon, der als Head of Developer Relations zu VMware wechselte, um damit CloudFoundry zu stärken.