Kategorien
Analysen

ProfitBricks unter der Haube: IaaS aus Deutschland – man darf gespannt sein

In der vergangenen Woche hatte ich ein Briefing mit ProfitBricks, um das Infrastructure-as-a-Service (IaaS) Angebot aus Deutschland besser kennenzulernen und konkrete Fragen zu stellen. Ich habe ProfitBricks in zwei Artikeln Nummer eins hier und Nummer zwei hier in der Vergangenheit bereits kritisch begutachtet. Zum einen, weil ich einfach nicht auf Marketingphrasen stehe, die viel mehr versprechen als eigentlich dahinter steckt und zum anderen, weil auch technische Versprechen eingehalten werden müssen.

Details zu ProfitBricks

ProfitBricks stellt sich als typischer Infrastructure-as-a-Service Anbieter auf. Über eine graphische Weboberfläche lassen sich maßgeschneiderte Server zu einem Rechenzentrum formen. Anhand von komplexen Vernetzungsstrukturen soll eine echte Isolation des Kundennetzwerks im virtuellen Rechenzentrum sichergestellt werden. Für Performance sorgt eine vermaschte redundante Vernetzung mit Infiniband sowie ein hochredundanter Storage (inkl. automatischem Backup) für die Verfügbarkeit der Daten.

Zudem verfügt ProfitBricks über ein eigenes Security-Team sowie langjährig erfahrene Systemadministratoren, die einen rund um die Uhr Support liefern.

Standorte

Rechenzentren bzw. Co-Location besitzt ProfitBricks in Deutschland (Karlsruhe) und in den USA (Las Vegas). Allerdings sind beide Rechenzentren in keinster Weise physikalisch oder virtuell miteinander verbunden, wodurch kein Datenaustausch zwischen Deutschland und den USA auf diesem Weg stattfinden kann.

Die Infrastruktur-Komponenten

Server lassen sich bei ProfitBricks mit Cores zwischen 1 und 48 Cores sowie 1 GB und 196 GB RAM ausstatten. Das Maximum liegt hier derzeit allerdings bei 60 Cores und 250 GB RAM pro Server, was man sich über den Support freischalten lassen kann. Storage gibt es zwischen 1 und 5000 GB. Allerdings kann dieser immer nur direkt einem Server zugewiesen werden. Es gibt somit keinen zentralen Speicher. Um dieses zu realisieren, muss man sich eine eigene zentrale Storage-Appliance bauen und den Speicher darüber verteilen.

Innerhalb eines selbst gestalteten Rechenzentrum (siehe unten) stehen zwei Zonen (ähnlich der Availability Zones von Amazon) zur Verfügung. Damit lassen sich z.B. zwei Server so konfigurieren, dass der eine von den Problemen in der Zone des zweiten Servers nichts mitbekommt.

Es gibt keine zentrale Firewall. Stattdessen können jeweils alle Netzwerkkarten eines Servers mit eigenen Regeln konfiguriert werden. Eine zentrale Firewall lässt sich hier z.B. durch den Aufbau einer eigenen Firewall-Appliance (Linux + IPTables oder eine fertige kommerzielle Firewall als ISO-Image) realisieren.

Ein Load Balancer steht zwar zur Verfügung, allerdings empfiehlt ProfitBricks an dieser Stelle lieber einen eigenen anhand einer Appliance zu bauen, da der ProfitBricks eigene u.a. über kein Monitoring verfügt.

Weitere eigene Mehrwertservices bietet ProfitBricks nicht an. Dies soll nach eigener Aussage auch nicht passieren. Stattdessen setzt der Anbieter auf ein Partnernetzwerk, das für die Infrastrukturplattform entsprechende Services anbieten soll.

Derzeit einmalig: Der Data Center Designer

Was mich bei ProfitBricks wirklich überzeugt hat ist der „Data Center Designer (DCD)“. So einen hat in dieser Form derzeit noch kein IaaS Anbieter weltweit.

Anhand dieser graphischen Weboberfläche ist man in der Lage ein komplettes virtuelles Rechenzentrum individuell zusammenzustellen und per Mausklick die Konfiguration zu aktivieren oder beliebig zu ändern – egal ob es sich um Server, Storage, Loadbalancer, Firewalls oder die entsprechende Vernetzung handelt.

Ist ein Rechenzentrum fertig designed, lässt es sich speichern und deployen. Zuvor erhält man noch Informationen über einen Check durch das System. Hier wird geschaut, ob alles korrekt konfiguriert wurde – z.B. ob alle Server auch ein Bootlaufwerk mit entsprechenden Image haben. Anschließend werden die Gesamtkosten pro Monat für dieses virtuelle Rechenzentrum aufgeschlüsselt.

Allerdings hat der DCD derzeit noch eine Schwachstelle. Ist ein Rechenzentrum deployed, lässt sich über die Weboberfläche kein einzelner Server mehr aus dem Design entfernen bzw. diesen darüber stoppen. Dazu muss zunächst das vollständige Rechenzentrum wieder un-deployed werden. Dann wird der Server entfernt und das Rechenzentrum anschließend wieder deployed. Mittels der proprietären SOAP API, die unter anderem Java und C# unterstützt, soll ein einzelner Server jedoch entfernt werden können. Diese Web-Funktion soll, ebenso wie eine REST API, in Zukunft folgen.

Der Kunde ist größtenteils auf sich alleine gestellt

Zunächst bietet ProfitBricks einen deutschsprachigen Support, der entweder selbst jahrelang als Administrator gearbeitet hat oder an der Entwicklung des Systems beteiligt war. Der Support ist darüber hinaus kostenlos enthalten. Auch dann, wenn man die Plattform nur mit einem Testaccount evaluiert.

Ansonsten ist ProfitBricks ein gewöhnlicher Self-Service wie ihn andere IaaS Anbieter auch bieten. Das bedeutet, dass man sich über das Design seiner virtuellen Infrastruktur und wie eine Applikation auf der Infrastruktur skaliert und hochverfügbar bereitgestellt wird, selbst kümmern.

Bei weitere Fragen und Lösungsansätze, z.B. bei der Konfiguration einer separaten Firewall-Appliance oder eines eigenen Loadbalancer, helfen Partner.

Preise

Die Abrechnung erfolgt minutengenau pro Stunde. Die Kosten schlüsseln sich dabei wie folgt auf:

  • 1 Core = 0,04 EUR pro Stunde
  • (Windows Server plus 0,01 EUR pro Stunde)
  • 1 GB RAM = 0,09 EUR pro Stunde
  • 1 GB Speicher = 0,09 EUR pro 30 Tage
  • 1 GB Traffic = 0,06 EUR pro GB Traffic

Das Live Vertical Scaling

ProfitBricks unterstützt das sogenannte Live Vertical Scaling. Das bedeutet, dass sich weitere Ressourcen wie CPU und RAM im laufenden Betrieb zu einem virtuellen Server hinzufügen lassen. Diese Funktion muss für jeden Server separat aktiviert und der Server anschließend einmal neu gestartet werden.

Allerdings, und das habe ich hier angemerkt und hat mir ProfitBricks während des Briefings bestätigt, muss das Betriebssystem, die Datenbank, Software und die eigene Applikation das auch unterstützen. Die Systeme müssen erkennen, dass plötzlich mehr Kerne und RAM zur Verfügung stehen und diese nutzen. Und im umgekehrten Fall ebenfalls damit umgehen können, wenn die Ressourcen wieder herunterskalieren.

ProfitBricks ist interessant

ProfitBricks ist ein interessantes Infrastructure-as-a-Service Angebot. Insbesondere im sehr Cloud-kargen (IaaS) Deutschland mit einem Rechenzentrum in Deutschland. Besonders hervorzuheben ist der Data Center Designer (einziger USP), der derzeit weltweit einmalig ist und die entsprechende Convenience bietet, die andere IaaS-Anbieter vernachlässigen. Zwar harkt der Designer an der einen oder anderen Stelle noch (Bsp.: Server entfernen), aber das wird sich in einer zeitnahen neuen Version sicherlich ändern.

Unterm Strich ist ProfitBricks ein reiner Infrastructure-as-a-Service Anbieter, der seine Stärken im Infrastrukturbetrieb hat. Das ergab auch das Briefing. Daher irritiert mich ein Interview mit CEO Achim Weiß, welches ich vor ein paar Wochen gelesen hatte. Darin gab er als Zielkunden neben Unternehmen, ebenfalls Internet-Startups an. Das erachte ich derzeit jedoch als eine Utopie. Ohne ein Service-Portfolio wie es die Amazon Web Services bieten ist diese Zielgruppe nicht zu erreichen. Die Service Lücke kann und soll durch Service Partner geschlossen werden. Ein anderer aber durchaus legitimer Ansatz, wenn die Stärken in einem anderen Bereich liegen.

Kategorien
Kommentar

Mehrwert-Services sind die Zukunft von Infrastructure-as-a-Service

Der Titel dieses Beitrags mag ein wenig irritieren. Schließlich handelt es sich bei Infrastructure-as-a-Service (IaaS) bereits um Services. Aber ich habe meinen Grund dafür. Von Beginn an bezeichnet Gartner die Amazon Web Services, in seinem Magic Quadrant, als den führenden Anbieter im IaaS Markt. Wen ich hier mittlerweile jedoch vermisse ist Windows Azure. Aber warum ist es gerade Amazon, die den Markt anführen und warum gehört Windows Azure meiner Meinung nach ebenfalls in denselben Quadranten wie Amazon.

Frühe Präsenz und ein ausgeprägtes Angebot zahlen sich aus

Ein Grund für Amazons Erfolg liegt unumstritten in der frühen Präsenz am Markt. Als erster IaaS Anbieter (2006) haben sie den Markt geprägt und dem Cloud Computing damit die Richtung vorgegeben, an der sich viele Anbieter orientieren. Microsoft folgte mit Windows Azure zwar relativ spät (2010), hat sein Portfolio aber schnell ausgebaut.

Ein weiterer aber viel prägnanter Grund sind die Services beider Anbieter. Wie bei den anderen IaaS Anbietern am Markt, stehen bei Amazon AWS und Microsoft Windows Azure nicht nur die reine Infrastruktur im Vordergrund, sondern viel mehr Lösungen drum herum. Das Angebot beider Anbieter ist im Vergleich zum restlichen Markt sehr ausgeprägt und bietet deutlich mehr als nur virtuelle Server und Speicherplatz. Und das ist der Knackpunkt.

Die Infrastruktur nutzbar machen

IaaS bedeutet im Kern das Angebot von Rechenleistung, Speicherplatz und Netzwerkkapazitäten als Service im Pay as you go Modell. Das beherzigen die meisten Cloud Anbieter am Markt. Nur nicht Amazon AWS und Windows Azure. Beide bieten viele Mehrwert-Services um ihre Infrastruktur herum an und machen diese damit nutzbar. Kunden sind damit in der Lage die „dumme“ Infrastruktur direkt produktiv zu nutzen.

Egal welchen Anbieter man sich aus dem Public Cloud Bereich zur Brust nimmt, in der Regel besteht das Angebot aus Compute (Rechenleistung), Storage (Speicherplatz) und Database (Datenbanken). Der eine oder andere bietet zudem noch ein CDN (Content Delivery Network) und Tools für das Monitoring. Das war es dann aber auch schon. Hingegen zeigt ein Blick auf die Services von Amazon AWS und Windows Azure, wie umfangreich deren Portfolio mittlerweile ist.

Daher, Mehrwert-Services sind der Schlüssel und die Zukunft von Infrastructure-as-a-Service, mit denen sich die Infrastruktur gewinnbringender nutzen lässt.

Kategorien
Management

IaaS: Sie selbst sind für die Hochverfügbarkeit und Skalierbarkeit verantwortlich

Cloud Computing Architekturen unterscheiden sich grundsätzlich von traditionellen Systemmodellen. Aber um die Hochverfügbarkeit, Skalierbarkeit usw. der Cloud tatsächlich zu nutzen, gilt es die Prinzipien des Cloud Computing, aber vor allem die Infrastruktur des jeweiligen Anbieter, speziell im Falle von IaaS (Infrastructure-as-as-Service), bis ins Detail zu durchdringen und bestmöglich für sich und das eigene System zu nutzen.

Die Freude kommt während des Falls

Die jüngsten Ausfälle haben gezeigt, dass viele Nutzer sich nicht mit der Cloud selbst und der des jeweiligen Anbieters auseinandergesetzt haben. Andere hingegen haben direkt von Beginn an viele Anstrengungen unternommen, um ihre Systeme Cloud gerecht zu entwickeln und wurden nicht von plötzlichen bzw. unvorhersagbaren Ereignissen in die Knie gezwungen. Man sollte daher meinen, dass gute Cloud Architekten einen Freudentanz aufführen, wenn der Anbieter dann doch einmal unerwartet Probleme hat und sie sich mit ihren eigenen robusten System brüsten können.

Da gibt es doch bestimmt Lessons Learned

Wenn man selbst keine Ahnung, dann fragt man jemanden der sich damit auskennt oder schaut im besten Fall, wie die anderen mit solchen Szenarien umgehen.

Bevor sich ein Unternehmen also in die Cloud begibt, sollten die Verantwortlichen also viel Zeit damit verbringen, das System des Anbieters zu verstehen und zunächst Test-Systeme innerhalb der Infrastruktur aufzubauen, bevor es in den Produktivbetrieb geht.

Everything fails everytime

Als Verantwortlicher sollte man sich immer bewusst machen, dass irgendetwas zu jedem Zeitpunkt immer einen defekt erleiden kann. Und genau so sollte auch die Architektur des Systems auf der Cloud entwickelt werden. Jedes System muss unabhängig von den anderen Systemen einwandfrei funktionieren. Das bedeutet, dass jedes System innerhalb der verteilten Architektur so entwickelt werden muss, dass es darauf vorbereitet ist, den Ausfall anderer Teilsysteme, zu denen Abhängigkeiten bestehen, zu tolerieren.

Eigene Tools für den Betrieb des Systems

On-Demand Video Anbieter Netflix hat für den Betrieb seines Systems in der Amazon Cloud eine Reihe von eigenen Tools entwickelt, die sicherstellen, dass das Angebot zu jederzeit verfügbar ist und Instanzen, die nicht mehr einwandfrei funktionieren ausgetauscht werden. So zerstört bspw. der Chaos Monkey zufällig Instanzen und Services innerhalb der Architektur, um damit den unabhängigen Betrieb der einzelnen Komponenten fortlaufend zu testen. Der Chaos Gorilla geht sogar noch einen Schritt weiter und simuliert den kompletten Ausfall einer Amazon Availability Zone, um damit zu prüfen, dass die Systeme in einer anderen Zone die Aufgaben übernehmen.

Anforderungen und Bedürfnisse klären

Der Betrieb in einer Cloud unterscheidet sich vollständig von dem in einem traditionellen Rechenzentrum. Hochverfügbarkeit und Skalierbarkeit werden per se von einer Cloud Infrastruktur erwartet, ein Hirngespinst, dass sich noch in vielen Köpfen von Verantwortlichen befindet. Richtig ist, dass der Anbieter für die Hochverfügbarkeit seiner Infrastruktur sorgen muss. Allerdings hat er mit den Systemen, die von den Kunden auf der Cloud betrieben werden nichts zu tun.

IT-Verantwortliche müssen sich daher die Fragen stellen, wie moderne Architekturen in der Cloud sicher aufgebaut und betrieben werden können und welche Auswirkungen dies auf die Planungs- und Betriebs-Prozesse hat. Schlussendlich wird sich aber ebenfalls die Komplexität der Architektur erhöhen, wenn die Applikationen und Systeme in die Cloud verlagert werden.


Bildquelle: ©Gerd Altmann / PIXELIO

Kategorien
Analysen

Klassische Webhoster und ihr Kampf mit Infrastructure-as-a-Service

Vor ein paar Tagen hatte ich ein Briefing mit einem europäischen Webhoster, der mir seine Produktlinie, strategische Ausrichtung usw. vorgestellt hat. Ich möchte das Wort Cloudwashing dabei ungerne wieder in den Mund nehmen. Allerdings hat mir das Gespräch erneut gezeigt, dass typische Webhostinganbieter massive Probleme haben, ein echtes Infrastructure-as-a-Service (IaaS) Angebot aufzubauen.

Schwierigkeiten mit der Moderne

Es ist genau das, was ich bei so manchen Anbietern von „Cloud“ Lösungen feststellen muss. Dabei handelt es sich überwiegend um klassische Webhoster, die den Cloud Zug nicht verpassen wollten und schnell ihr Portfolio AUF DEM PAPIER Cloud-fähig gemacht haben. Es gibt wohlgemerkt Ausnahmen, diese sind aber äußerst selten. An dieser Stelle wird schlicht und einfach auf den Hype aufgesprungen und das Internet als Cloud verstanden.

Genau so zeigte sich auch das Portfolio des Anbieters, mit dem ich gesprochen habe. Es gibt Dedicated Server und Cloud Server, die vor ein paar Monaten/ Jahren noch Virtual Server hießen. Diese „Cloud Server“ gibt es als fünf unterschiedliche fixe Konfigurationsstufen mit entsprechendem 1 bis 4 Cores, Speicherplatz und RAM zu einem monatlichen Preis von x EUR. Nicht zu vergessen, dass die Bereitstellungszeit mit 1 bis 5 Werktagen angegeben wird. Weitere Nachfragen ergaben dann, dass kein on-Demand Bezug möglich ist und keine API zum Verwalten bzw. Starten und Stoppen weiterer Server zur Verfügung steht. Ebenfalls existieren keine weiteren Services oder Software Images die um das Angebot herum bestehen und die Ressourcen nicht pro Verbrauch abgerechnet werden können.

Wie die Eigenschaften eines Cloud Angebots ausschauen sollte steht hier.

Interne Struktur und Strategie vorhanden

Man muss dem Anbieter zugestehen, dass er auf Nachfrage eingestehen musste, dass bis auf das Wort selbst in den Serverangeboten, nicht sehr viel Cloud steckt. Allerdings befindet er sich auf dem richtigen Weg. Vor ca. einem Jahr wurde die interne Infrastruktur auf CloudStack umgestellt, um für sich selbst die Provisionierung der Kunden-Server zu optimieren. Davon können die Kunden bisher jedoch nicht profitieren. Zudem wurde mit KVM auf einen modernen, offenen und weit verbreiteten Hypervisor gesetzt und ebenfalls das Thema Netzwerkvirtualisierung wurde vor ein paar Wochen umgesetzt. Nach eigener Aussage sei ebenfalls eine Strategie vorhanden, in Kürze den Kunden einen on-Demand Bezug einzelner Ressourcen sowie Pay per use als Bezahlmodell anzubieten, da man sich mittlerweile selbst im Klaren darüber sei, dass dies zwingend erforderlich ist.

Dennoch, angesichts dieser Erfahrungen sollte sich jeder Nutzer, der ernsthaft in die Cloud gehen möchte, vorab intensiv informieren.


Bildquelle: ©Harald Fischer / PIXELIO

Kategorien
Analysen

Profitbricks: "Live Vertical Scaling" und die Krux mit der Parallelität

Ich hatte über Profitbricks, direkt nach deren Go-Live im Mai, geschrieben. Dabei ist das Unternehmen nicht unbedingt gut bei weggekommen. Denn ein „Infrastructure-as-a-Service (IaaS) der nächsten Generation“ konnte ich da noch nicht erkennen. Eine grafische Bedienoberfläche, freie Vernetzungsstrukturen durch echte Isolation des Kundennetzwerks im virtuellen Rechenzentrum, vermaschte redundante Vernetzung mit Infiniband, maßgeschneiderte Server und ein hochredundanter Storage, zeugen unter dem besagten Titel von mehr Marketingexpertise als großer Innovation. Ich habe mir das Angebot einmal genauer angeschaut und bin positiv überrascht. Insbesondere die Funktion „Live Vertical Scaling“ überzeugt. Allerdings steckt der Teufel im Detail.

Scale Up vs. Scale Out

Skalierbarkeit bedeutet, dass die Leistung eines Systems durch das Hinzufügen weiterer Ressourcen wie ganzer Rechnersysteme oder granularer Einheiten wie CPU und Arbeitsspeicher erhöht wird. Das System kann dann mit zunehmender beanspruchter Leistung linear mitwachsen. So lassen sich z.B. plötzliche Lastspitzen begegnen unter denen das System nicht zusammenbricht. Unterschieden wird dabei zwischen dem Scale Up und dem Scale Out.

Scale Up

Während eines Scale Up, auch vertikale Skalierung genannt, wird die Leistung des Systems gesteigert, indem weitere granulare Ressource zu einem Rechnersystem hinzugefügt werden. Dabei kann es sich um Speicherplatz, CPUs oder Arbeitsspeicher handeln. Man kann auch sagen, ein einzelner Rechner wird mit weiteren bzw. Leistungsstärkeren Komponenten aufgerüstet.

Scale Out

Ein Scale Out, horizontale Skalierung, steigert die Leistung eines Systems, indem weitere vollständige Rechner zu dem Gesamtsystem hinzugefügt werden. Man kann sich das Szenario auch so vorstellen, dass man sich einen Cluster von Rechnern aufbaut, über den skaliert wird, indem der Cluster immer um die benötigte Anzahl an Rechnern erweitert wird.

Live Vertical Scaling

Ich weise immer darauf hin, dass Anwendungen für die Eigenschaften einer Cloud entwickelt werden müssen. Also mit der Infrastruktur parallel mitwachsen müssen, wenn sich die Last verändert und weitere virtuelle Ressourcen automatisch hinzugefügt werden müssen.

Profitbricks hat nun das „Live Vertical Scaling“ vorgestellt und geht anders als bspw. die Amazon Web Services (AWS), Rackspace oder Windows Azure den Weg der vertikalen Skalierung. Die anderen drei genannten Anbieter setzen hingegen auf die horizontale Skalierung. Profitbricks beschreibt seine Lösung wie folgt:

Das Besondere dabei: Das System, beispielsweise ein Server, kann auf diese Art quasi unabhängig von der verwendeten Software und ohne deren Modifikation beschleunigt werden. Ideal ist dies beispielsweise für LAMP (Linux, Apache, MySQL, PHP)-Systeme, da MySQL ohne Anpassung die neuen Ressourcen erkennt und ohne Neustart vom Mehr profitiert.

Grundsätzlich hat Profitbricks recht. Nicht jede Software ist so implementiert, insbesondere die Legacy Anwendungen, dass sie skalierbar sind. Das hängt damit zusammen, dass diese Anwendungen nicht für den parallelen Betrieb auf mehreren Systemen entwickelt wurden. Für eine vertikale Skalierung ist, bis zu einem gewissen Grad, keine parallele Entwicklung notwendig, d.h. im Prinzip muss der Programmcode in diesem Fall nicht mehr angefasst werden, um die Leistung zu erhöhen.

Die Probleme stecken im Detail

Aber, der Teufel steckt im Detail.

Parallelität der Softwarearchitektur

Eine Anwendung muss mehrere Cores unterstützen, um die Leistungsfähigkeit des Rechners auszunutzen. Diese Problematik viel auf, als Intel seine Core 2 Duo Prozessoren auf den Markt brachte. Die Rechner verfügten zwar über zwei CPU-Kerne, die alten Anwendungen unterstützen aber nur einen. Der Vorteil eines zweiten CPU-Kerns war somit dahin. Das bedeutet, dass eine Anwendung auch auf die vertikale Skalierung vorbereitet werden muss. Was nützt es, wenn der Server bis zu 48 CPU-Kerne unterstützt, die Anwendung aber lediglich einen einzigen nutzen kann.

Die Software muss also, trotz vertikaler Skalierung, parallelisiert werden. Denn die Leistungssteigerung hängt effektiv mit dem Parallelisierungsgrad der Anwendung und dem Betriebssystem zusammen. Das Betriebssystem sorgt für das Verteilen der Prozesse und Anwendungen auf die jeweiligen Kerne. Die Anwendung muss für den Betrieb auf mehreren Prozessen zudem so parallelisiert werden, dass einzelne Threads dabei gleichzeitig auf mehreren Prozessoren laufen.

Profitbricks schreibt: „Bei anderen IaaS-Anbietern muss der Nutzer seine Server erst herunter fahren, dann die neuen Ressourcen buchen und die Systeme anschließend neustarten. Selbst im besten Fall kommt es hierbei zu einem Ausfall der Server von einigen Minuten, so dass derartige Modifikationen ohne Live Vertical Scaling nur in den Nachtstunden machbar sind.

Das ist falsch. Bei AWS, Rackspace als auch Windows Azure lassen sich die Systeme per API/ Skripte steuern. Es können also weitere Ressourcen per Scale Out ohne Unterbrechungen hinzugefügt werden. Soll eine virtuelle Ressource ausgetauscht werden, lassen sich zunächst automatisch neue Ressourcen hinzufügen und anschließend die nicht mehr gewollten herunterfahren. Und das alles ohne Ausfallzeit.

Profitbricks nennt hier als Beispiel definitiv keine IaaS Cloud-Anbieter. Denn das geschilderte Szenario darf im Cloud Computing so überhaupt nicht auftreten!

Was ist mit Design for Failure?

Profibricks schreibt zwar, „Stehen auf dem physischen Server, auf dem eine bestimmte Kunden-VM läuft, nicht genügend Ressourcen bereit, um den per DCD gewünschten Wert zu erfüllen, verschiebt der von ProfitBricks verwendete Hypervisor die virtuelle Maschine automatisch auf einen anderen Server. Dies passiert, ohne die jeweils in der VM laufenden Anwendungen negativ zu beeinflussen.

Aber wie verhält es sich, wenn der darunterliegende physikalische Host oder die virtuelle Maschine, auf der sich die Anwendung befindet ausfällt? Da sich die Anwendung lediglich auf einem einzigen System befindet und nicht über mehrere Systeme verteilt läuft, wäre ein Ausfall die Folge.

Interessante Lösung, aber…

„Live Vertical Scaling“ ist auf jedenfall eine interessante Lösung. Profitbricks versucht Infrastructure-as-a-Service (IaaS) für Anwender benutzerfreundlicher zu machen, womit sie auf dem richtigen Weg sind. Denn für die meisten IaaS-Angebote sind noch zu viele Expertenkenntnisse notwendig und manuelle Arbeit erforderlich. Einfache Automatisierung und Convenience sind die Schlagworte. Aber wie ich beschrieben habe, steckt der Teufel im Detail. Man sollte sich also zunächst über seine eigenen Bedürfnisse und die der Anwendung im Klaren sein, bevor man sich für die vertikale Skalierung entscheidet.


Bildquelle: http://krishnasblog.com

Kategorien
Kommentar

Vernichtet Cloud Computing die Enterprise IT?

Cloud Computing gehört zu den disruptivsten Technologien und Konzepten der letzten 10 Jahre. Mit dem flexiblen Bezug von quasi unendlich verfügbaren Ressourcen lassen sich zwar nicht einfacher virtuelle Infrastrukturen aufbauen, aber agiler und kurzfristig. Auch der Zugriff auf – neue – Anwendungen und Daten, die durch die Cloud ortsunabhängig zur Verfügung stehen, hat einen erheblichen Einfluss auf uns, unsere Arbeitswelt und damit auch zwangsläufig auf die Enterprise IT. Durch das Cloud Computing getriebene Themen wie Bring your own device (BYOD) und Mobile Computing, aber auch die Consumerization of IT (CoIT) hinterlassen immer mehr Spuren in den IT-Umgebungen vieler Unternehmen. Es stellt sich somit die Frage, ob das Cloud Computing und seine oben genannten Gefährten dazu beitragen werden, dass die Enterprise IT, wie wir sie kennen nicht mehr lange existieren wird.

Mitarbeiter zeigen wo es lang geht

Die CoIT sorgt dafür, dass IT-Wissen kein rares Gut mehr ist. Vorbei sind die Zeiten, in denen IT-Abteilungen dem Großteil der restlichen Mitarbeiter gleich mehrere Schritte voraus sind. Das liegt unter anderem daran, das die Informationstechnologie in unserem alltäglichen Leben einen omnipräsenten Zustand eingenommen hat. Zudem hat sich die Bedienbarkeit in den letzten Jahren deutlich vereinfacht und die Angst vor dem unbekannten Computern, Smartphones usw. schwindet stetig. Vergessen sollte man auch nicht den demographischen Wandel. Der Nachwuchs wächst mit und in die neuen Technologien herein und hat es mit der IT daher viel einfacher als die vorherigen Generationen. Das Verhältnis von Mitarbeitern die sich mit IT auskennen und denjenigen die Schwierigkeiten damit haben, wird sich immer stärker verändern, bis wir an einem Punkt angelangt sind, wo es keine nicht IT-affinen Mitarbeiter mehr geben wird.

Ständig neue Technologien, die primär für den privaten Gebrauch gedacht sind, beeinflussen die Mitarbeiter darüber hinaus im großen Stil. In Kombination mit der CoIT und dem demographischen Wandel sehen somit immer mehr Nutzer neue Möglichkeiten, diese eher privaten Technologien in ihren Arbeitsalltag einzusetzen und sich damit das Leben zu vereinfachen und die eigene Produktivität zu steigern.

Ein weiteres Problem, das sich die Enterprise IT ausgesetzt sieht: Die IT-Abteilungen sind zu langsam und sitzen weiterhin auf ihrem Thron. Es gibt viele Mitarbeiter und Projekte die innerhalb des Unternehmens und für die Außenwirkung Ideen haben. Dafür benötigen sie allerdings Ressourcen und diese in Form von IT. Dabei kann es sich von einer trivialen Angelegenheit wie Zugriffsrechte, über neue Applikationen bis hin zu Servern oder vollständigen Infrastrukturen handeln. Für jedes genannte Thema ist mindestens ein Ticket bis hin zu zahlreichen Meetings erforderlich. Oder die Antwort lautet schlicht und einfach – Nein! Im Falle von Ja! kann die Bereitstellungszeit mehrere Wochen oder gar Monate benötigen. Für ein einfaches Testsystem steht das in keinem Verhältnis, fördert die Missgunst bei den Mitarbeitern und kann im schlimmsten Fall das ganze Projekt gefährden.

Die Cloud vereinfacht den Zugang

Mitarbeiter und Projekte suchen daher Auswege, um zum einen Diskussionen aus dem Weg zu gehen und zum anderen ihre Ziele im vorgegebenen Zeitfenster zu erreichen. Dem Kunden sind die internen Machtkämpfe relativ egal und er sollte davon besser auch nichts mitbekommen.

Möglich machen es ihnen Lösungen aus der Cloud. Seien es nun vollständige Applikationen (Software-as-a-Service, SaaS), Plattformen für die Entwicklung und den Betrieb eigener Anwendungen (Platform-as-a-Service, PaaS) oder ganze Infrastrukturen für umfangreiche IT-Landschaften (Infrastructure-as-a-Service, iaaS). In der Cloud ist für jeden etwas dabei, wenn auch nicht für jede Situation.

Und auch mobile Applikationen, die ihre Daten bevorzugt in der Cloud ablegen, oder Cloud Storage Services und moderne HTML 5 Applikationen ermöglichen den ortsunabhängigen Zugriff.

Cloud Computing unterstützt die Enterprise IT

Die Enterprise IT darf nicht die Augen vor dem Cloud Computing verschließen und muss diese disruptive Technologie als Unterstützer ihrer täglichen Arbeit sehen. Ähnlich verhält es sich mit BYOD. In beiden Fällen gilt: Augen zu und durch funktioniert nicht! Proaktiv handeln und den Mitarbeiten wieder einen Schritt voraus sein ist gefragt.

Wer sich nun fragt, wie Cloud Computing ein Unterstützer sein kann, hier vier Beispiele:

Irgendwann wird der CEO/ CIO in der Tür stehen und erwarten, dass die Datenmengen die täglich im Web, in den lokalen Systemen usw. gesammelt werden, im großen Stil analysiert und unmenschliche Verknüpfungen angestellt werden sollen, da ein Informationsvorsprung einen Wettbewerbsvorteil bedeutet. Stichwort: Big Data. Wie sollen also in kurzer Zeit die Unmengen an benötigten Systemen für die Verarbeitung (Rechenleistung) und Ablage (Speicherplatz) beschafft und konfiguriert werden? Und wie sollen diese aus dem IT-Budget des laufenden Jahres finanziert werden? Selbst die Entwicklung einer eigenen Big Data Applikation kostet bereits viel Zeit und Geld. Genau, Cloud Computing. Denn Cloud Infrastrukturen sind eine ideale Lösung für die Anforderungen von Big Data. Aber ebenfalls speziell darauf ausgerichtete PaaS Lösungen können bereits helfen, „nur“ die Abfragen zu schreiben.

Das Big Data Beispiel lässt sich auf so ziemlich jeden Fall anwenden, wenn es darum geht, kurzfristig Anforderungen zu erfüllen, bei denen mehr als „nur ein paar“ virtuelle Server benötigt werden. Denn eines sollte man nicht vergessen, für jede virtuelle Ressource werden auch physikalische Ressourcen benötigt.

Auch neue Anwendungen lassen sich via SaaS kurzfristig, kostengünstig bzw. kostenlos testen, ohne dafür eigene Hardware zu nutzen oder gar die dafür notwendige darunterliegende Software zu besitzen, installieren und konfigurieren.

IT-Abteilungen können Cloud Computing zudem nutzen, um die eigene Innovationsfähigkeit und damit den Innovationsgrad des Unternehmen selbst zu erhöhen, indem sie kurzfristig auf Cloud Technologien zurückgreifen, um neue Ideen zu testen oder zu entwickeln.

Eines sollte weiterhin angemerkt werden. Cloud Computing ist kein Job Killer. Änderungen im Job und Weiterbildungen sind ein normales Phänomen, die natürlich auch die Cloud mit sich bringt. Allerdings erledigen die Cloud Infrastrukturen nicht alles von alleine. Um bspw. ein IaaS Angebot zu nutzen, müssen weiterhin die virtuellen Server Stückweit konfiguriert werden und die virtuelle Infrastruktur und Applikationen so gestaltet werden, dass sie tatsächlich skalierbar und hochverfügbar arbeiten. IT-Abteilungen müssen in der Cloud „verteilt“ denken und agieren.

Enterprise IT stirbt nicht aus

Die Enterprise IT wird nicht aussterben. Es sei denn, sie passt sich nicht den aktuellen und zukünftigen Begebenheiten und Trends an. Nicht die IT-Abteilungen werden die technologische Marschroute mehr vorgeben. Die Mitarbeiter werden zeigen und darauf aufmerksam machen, welche Technologien sie für ihre Produktivität benötigen. IT-Abteilungen sollten also verstehen, dass sie in einigen Fällen noch einen gewissen Vorsprung vor den Kollegen haben, dieser aber stetig schwindet. Umgehen können und sollten sie mit dieser Situation, indem sie

  • Auf Mitarbeiter eingehen.
  • Offen sein.
  • Innovationen von Mitarbeitern in das Unternehmen hineintragen lassen.
  • Verstehen dass es mittlerweile viele kleine CIOs/ CTOs gibt.
  • Crowdsourcing innerhalb des Unternehmens einsetzen, um Wünsche und Bedürfnisse zu erkennen.
  • Sich ebenfalls mit dem Markt für Consumer Produkte auseinandersetzen und Ideen für den Einsatz im Unternehmen ableiten.
  • Den Mitarbeitern wieder einen Schritt voraus sein.
  • Die Innovationsfähigkeit und den Innovationsgrad steigern.
Kategorien
News

Amazon Web Services präsentieren Amazon Glacier: Günstiger Cloud Storage für das Langzeit-Backup

Die Amazon Web Services (AWS) haben gestern Amazon Glacier vorgestellt. Dabei handelt es sich um einen Cloud Service für die Datenarchivierung bzw. für das Langzeit-Backup. Glacier soll Unternehmen dazu bewegen, ihre Tape Libraries aufzugeben und die Daten stattdessen kostengünstig in die Cloud zu verlagern. Dateien, die per Glacier gesichert werden, sollen laut Amazon eine Langlebigkeit von 99,999999999 Prozent aufweisen. Bei einer Speichermenge von 100 Milliarden Objekten entspricht das den Verlust von einem Objekt pro Jahr.

Amazon Web Services präsentieren Amazon Glacier: Günstiger Cloud Storage für das Langzeit-Backup

Amazon Glacier

AWS beschreibt Amazon Glacier als einen kostengünstigen Storage Service, der dafür entwickelt wurde, um Daten dauerhaft zu speichern. Zum Beispiel für die Datenarchivierung bzw, die Datensicherung. Der Speicher ist, entsprechend der aktuellen Marktsituation, sehr günstig. Kleine Datenmengen können ab 0,01 US-Dollar pro GB pro Monat gesichert werden. Um den Speicher so kostengünstig anzubieten, ist der Service, im Vergleich zu Amazon S3, für solche Daten gedacht, auf die selten zugegriffen wird und deren Zugriffszeit mehrere Stunden betragen darf.

Hintergrund: Amazon Glacier

Daten in Amazon Glacier werden als ein Archive gespeichert. Dabei kann ein Archiv aus einer einzigen oder mehreren einzelnen zusammengefassten Dateien bestehen, die in einem sogenannten Tresor organisiert werden können. Der Zugriff auf einen Tresor kann über den AWS Identity and Access Management-Service (IAM) gesteuert werden. Um ein Archiv von Glacier zu laden, ist ein Auftrag erforderlich. Die Bearbeitung so eines Auftrags benötigt, laut Amazon, in der Regel zwischen 3,5 bis 4,5 Stunden.

Tape Library Ade

Mit Amazon Glacier nimmt AWS den Kampf mit on-Premise Speichersystemen, in erster Linie mit den, im Unternehmensumfeld stark verbreiteten, Tape Libraries auf. Insbesondere die hohe Datenredundanz und der Preis sind ausschlaggebende Argumente gegen die in die Jahre gekommene Tape Technologie.

Anstatt auf gewohnte Speichersysteme, verlässt sich Amazon Glacier auf kostengünstige Commodity Hardware. (Der ursprüngliche Ansatz, Cloud Computing kostengünstig anzubieten.) Für eine hohe Datenredundanz besteht das System aus einer sehr großen Menge von Speicher-Arrays, die sich aus einer Vielzahl von kostengünstigen Festplatten zusammensetzen.

Wie Werner auf seinem Blog schreibt, wird Amazon Glacier in naher Zukunft mir Amazon S3 verschmelzen, um Daten zwischen den beiden Services nahtlos übertragen zu können.

Mit Amazon Glacier zeigen die Amazon Web Services wieder einmal, dass sie der disruptivste und mit Abstand innovativste Cloud Computing Anbieter im Bereich Infrastructure-as-a-Service sind.


Bildquelle: All Things Distributed

Kategorien
News

ProfitBricks expandiert in die USA

Nach der Markteinführung seines Infrastructure-as-a-Service (IaaS) Angebots im Mai 2012 auf dem deutschen Markt, startet der deutsche Cloud Computing Anbieter ProfitBricks mit dem Verkauf von virtuellen Rechenzentren in Las Vegas, USA

ProfitBricks: IaaS der nächsten Generation?

Die GUI weißt dem Kunden den Weg

Ein virtuelles Rechenzentrum von ProfitBricks ermöglicht es dem Kunden, komplette und beliebig komplexe Netzstrukturen zu konfigurieren und über die graphische Benutzeroberfläche „Data Center Designer“, die individuellen Anforderungen entsprechend und im laufenden Betrieb auf Knopfdruck anzupassen. Das gilt für jede Komponente des virtuellen Netzwerks: Prozessorleistung (Cores), Arbeitsspeicher (RAM), Festplattenplatz (Storage), Load Balancer oder Firewalls. Wie jedes gute IaaS Angebot reagiert die ProfitBricks Lösung auf Lastspitzen und lässt sich entsprechend skalieren.

Support aus erster Hand

Die Abrechnung der Ressourcen erfolgt minutengenau. Es wird also nur das bezahlt, was tatsächlich in Anspruch genommen wird. Zudem bietet ProfitBricks Support von eigenen deutschen und US-amerikanischen Mitarbeitern, die rund um die Uhr zur Verfügung stehen. Die Kunden haben darüber hinaus volle Kontrolle über den Standort ihrer Daten und können so auch weiterhin sicherstellen, dass ihre Daten ausschließlich in Deutschland mit deutschem Datenschutz gehostet werden.

Kategorien
News

Google präsentiert mit der Google Compute Engine seinen eigenen Infrastructure-as-a-Service. Noch keine Konkurrenz für AWS!

Nun ist es soweit und es zeigt, dass Gerüchte immer ein Stück Wahrheit mit sich bringen. Google steigt mit seiner Google Compute Engine in den mittlerweile hart umkämpften Markt der Infrastructure-as-a-Services (IaaS) ein. Der Public Cloud Service vervollständigt neben einem Platform-as-a-Service Angebot (Google App Engine) und einer Software-as-a-Service Lösung (Google Apps) das Google Cloud Portfolio zu einem vollständigen Cloud Stack.

Google präsentiert mit der Google Compute Engine seinen eigenen Infrastructure-as-a-Service

Das Cloud Portfolio wird erweitert

Mit der Google App Engine, BigQuery und dem Google Cloud Storage hat Google seit 2008 sein Cloud Portfolio stetig ausgebaut. Was noch fehlte war eine Infrastructure-as-a-Service Lösung, mit der virtuelle Maschinen bei Bedarf genutzt werden können.

Mit der Google Compute Engine steigt Google nun auch in dieses Marktsegment ein und bietet in einer geschlossenen Beta die Möglichkeit, virtuelle Maschinen (VM) mit dem Linux Betriebssystem auf der Google Infrastruktur, die auch von Google Mail und anderen Services eingesetzt wird, zu nutzen.

Rechenleistung

Hier bietet die Compute Engine zunächst die Möglichkeit Ubuntu als auch CentOS Linux Betriebssysteme auf virtuellen Maschinen mit 1,2,4 oder 8 Kernen und 3,75 GB Arbeitsspeicher pro virtueller Instanz zu nutzen.

Speicherplatz

Mit der Compute Engine können drei unterschiedliche Arten genutzt werden, um die Daten zu speichern.

Flüchtiger Speicher

Auf jeder virtuellen Instanz befindet sich ein flüchtiger lokaler Speicher, bei dem die Daten nur während des Lebenszyklus einer virtuellen Maschinen gespeichert werden. Wenn die VM gestoppt wird, werden alle Daten gelöscht. Dennoch werden alle Daten die auf die VM geschrieben verschlüsselt abgelegt.

Persistenter Speicher

Die Google Compute Engine bietet einen persistenten Speicher, der als Service (virtuelle Fesplatte) mit dem Google Storage Netzwerk verbunden ist und über dieselbe Latenz und Geschwindigkeit wie der lokale Speicher einer VM verfügt. Daten die auf diese „virtuelle Festplatte“ gespeichert werden, werden automatisch über mehrere physikalische Festplatten innerhalb eines Google Rechenzentrum repliziert. Darüber hinaus können Snapshots von den Festplatten für Backup/ Restore Zwecke erstellt werden. Zudem besteht die Möglichkeit diese virtuellen Platten als Laufwerk in mehrere virtuelle Maschinen zu mounten, um davon Daten zu lesen. Wie beim lokalen VM Speicher sind auch die Daten auf den virtuellen Festplatten verschlüsselt.

Google Cloud Storage

Der Google Cloud Storage existiert für Entwickler schon etwas länger. Er bietet die Möglichkeit, Daten persistent zu speichern und auf die Buckets (Ordner) innerhalb des Storage mit einer VM zuzugreifen.

Netzwerkkapazitäten

Über der Google Netzwerk lassen sich die virtuellen Maschinen mit der Aussenwelt und innerhalb des Netzwerks selbst verbinden.

Isolierte Bereiche

Der Netzwerk Stack ist so aufgebaut, dass sich die virtuellen Maschinen eines Nutzers in einem isolierten Bereich befinden und von Dritten nicht ohne Weiteres darauf zugegriffen werden kann.

Externe IP Adressen

Die virtuellen Maschinen können entweder mit statischen oder dynamischen IP-Adressen verknüpft werden, um anschließend über das Internet auf diese zuzugreifen.

Konfigurierbare Firewall

Mit einer Firewall können die Zugriffe auf die virtuellen Maschinen kontrolliert werden.

Management

Mit einer Benutzeroberfläche sowie einem Kommandozeilentool kann die Infrastruktur verwaltet werden.

API

Alle Management Tools basieren auf einer offenen RESTful API. Google plant darüber hinaus, alle verfügbaren Tools als Open Source zu veröffentlichen, um den Nutzern die Möglichkeiten zu geben, eigene Tools nach ihren Bedürfnissen zu entwickeln.

Ecosystem

Google arbeitet bereits mit ein paar Partner darunter RightScale, Puppet Labs, OpsCode, Numerate, Cliqr und MapR zusammen, die in Zukunft die Google Compute Engine unterstützen und integrieren werden und weitere Management-Kapazitäten anbieten.

Kosten

Virtuelle Maschinen

Konfiguration Virtuelle Kerne Arbeitsspeicher GCEU Lokaler Speicherplatz Preis pro Stunde GCEU pro Stunde
n1-standard-1-d 1 3,75GB 2,75 420GB 0,145 Dollar 0,053 Dollar
n1-standard-2-d 2 7,5GB 5.5 870GB 0,29 Dollar 0,053 Dollar
n1-standard-4-d 4 15GB 11 1770GB 0,58 Dollar 0,053 Dollar
n1-standard-8-d 8 30GB 22 2 x 1770GB 1,16 Dollar 0,053 Dollar

GCEU steht für „Google Compute Engine Unit“. Dabei handelt es sich um eine Masseinheit, mit der Google die Rechenleistung seiner Instanzen, basierend auf einem Industriestandard, misst.

Netzwerk Kapazitäten

Eingehend Kostenlos
Ausgehend in derselben Zone Kostenlos
Ausgehend zu einem anderen Cloud Service in der selben Region Kostenlos
Ausgehend in eine andere Zone in derselben Region 0,01 Dollar pro GB
Ausgehend in eine andere Region innerhalb der USA 0,01 Dollar pro GB
Ausgehender Verkehr International siehe ausgehende Internetverbindungen

Ausgehende Internetverbindungen (Amerika, EMEA)

0-1 TB pro Monat 0,12 Dollar pro GB
1-10 TB pro Monat 0,11 Dollar pro GB
10+ TB pro Monat 0,08 Dollar pro GB

Ausgehende Internetverbindungen (APAC)

0-1 TB pro Monat 0,21 Dollar pro GB
1-10 TB pro Monat 0,18 Dollar pro GB
10+ TB pro Monat 0,15 Dollar pro GB

Persistenter Speicherplatz

Speicherplatz 0,10 Dollar pro GB pro Monat
Snapshot Speicher 0,125 Dollar pro GB pro Monat
IO Operationen 0,10 Dollar pro Millionen Operationen

IP-Adressen

Statische IP-Adresse 0,01 Dollar pro Stunde
Dynamische IP-Adresse kostenlos

Ein Amazon Web Services Killer?

In der Techwelt wird schon von einem Amazon Web Services (AWS) Killer gesprochen. Fakt ist, die Google Compute Engine ist ein IaaS Angebot und Google verfügt auf Grund seines Kerngeschäfts über die Expertise, hochskalierbare Infrastrukturen aufzubauen und diese hochverfügbar zu betreiben. Die Google App Engine zeigt darüber hinaus, dass Google es versteht, Entwickler anzusprechen, auch wenn sich der Markt hier mit zunehmend attraktiven Alternativen verengt.

Noch keine Konkurrenz zu AWS!

Schauen wir uns die Compute Engine an, dann sehen wir Instanzen und Speicherplatz, mehr nicht. Wer Google nun als DIE kommende Konkurrenz zu den Amazon Web Services sieht, ist erst einmal auf dem Holzweg. Amazon hat ein riesen Portfolio an Cloud Services, an die Google erst einmal anknüpfen muss. Ich gehe allerdings davon aus, dass in den kommenden Monaten mehr passieren wird. Unter http://cloud.google.com vereint Google mittlerweile seine sämtlichen Cloud Lösungen, darunter die App Engine, Cloud Storage, BigQuery und nun auch die Compute Engine. Google wird daher nicht die Compute Engine weiter ausbauen, sondern die Cloud Plattform im Laufe er Zeit mit weiteren Services erweitern.

Herausforderung Datenschutz

Es ist bei Google nicht klar, wo sich die Cloud Ressourcen befinden. Wo Amazon und Microsoft klar herausstellen und die Möglichkeit bieten, virtuelle Maschinen explizit in einem europäischen Rechenzentrum zu starten, verhält sich Google hier, wie immer, sehr bedeckt. Da ich bisher nur auf der Warteliste stehe, um einen ersten Blick auf die Compute Engine zu werfen, kann ich nicht sagen, ob man Instanzen explizit in einem EU Rechenzentrum starten kann. In der offiziellen Dokumentation zur Compute Engine habe ich allerdings nichts gefunden. Ich vermute allerdings, dass es nicht möglich ist, da alle Anwendungen, die sich auf der App Engine befinden, auch in den USA laufen. Erst mit der App Engine Version 1.7.0 bietet Google seinen Premium Kunden die Möglichkeit auch einen europäischen Cluster zu nutzen. Allerdings nichts aus dem Grund des Datenschutzes sondern auf Grund der Latenz.

Google scheint nicht zu verstehen, dass den Europäern das Thema Datenschutz scheinbar wichtiger ist als den Amerikanern. Google muss an dieser Stelle jedoch begreifen, dass, wenn Sie auch Unternehmen davon überzeugen wollen, die Google Cloud zu nutzen, sie es in diesem Umfeld mit einem anderen Klientel zu tun haben und nicht mit Entwicklern, die „nur“ drauflos programmieren wollen.

Wie schon bei seinen Consumer Services denkt Google leider immer erst nur an die USA. Andere Länder/ Kontinente wie Europa bleiben da zunächst Außen vor, sehr schade.


Bildquelle: http://anandtech.com

Kategorien
News

Google präsentiert sein eigenes Infrastructure-as-a-Service Angebot offenbar während der Google I/O

Nachdem bereits Mitte Mai erste Gerüchte um ein Infrastructure-as-a-Service (IaaS) Angebot aus dem Hause Google aufkamen, spekuliert GigaOm weiter, dass der Suchmachinengigant den Service in dieser Woche während seiner jährlichen Entwicklerkonferenz Google I/O in San Francisco präsentieren wird.

Google präsentiert sein eigenes Infrastructure-as-a-Service Angebot offenbar während der Google I/O

Google steht im Markt zwei festen Größen gegenüber. Zum einen die Amazon Web Services, zum anderen Microsoft Windows Azure. Da auch Microsoft sein ursprüngliches Platform-as-a-Service Angebot mittlerweile zu einem vollständigen Cloud Stack mit IaaS ausgebaut hat, sieht es danach aus, dass sich ein Dreikampf um die Vorherrschaft in der Cloud entwickeln wird.

Wie Googles Strategie in der Cloud aussehen wird ist schwierig vorherzusagen. Auf der einen Seite gehört die Entwicklergemeinde zu Googles Zielgruppe, die wiederum auch zu Microsoft Schwerpunkt zählt und in dem die Redmonder wirklich sehr stark aufgestellt sind. Zum anderen wird sich Amazon als der größte Mitbewerber im IaaS Bereich herausstellen, die ebenfalls die Entwickler Communities beackern und sich zudem um Microsoft Entwickler bemühen.

Während Amazon derzeit noch verstärkt um die Startups dieser Welt bemüht ist und langsam versucht in die Unternehmen zu gelangen, bleibt der Markt für etablierte Unternehmenskunden den Public Cloud Playern dennoch weitestgehend verschlossen. Ob Google daran etwas ändern kann wird sich zeigen. Allerdings kristallisiert sich langsam der Trend heraus, dass Unternehmen sich vermehrt auf die Private Cloud konzentrieren und Entwickler sowie Startups sich zunächst die Public Cloud zu nutze machen. Letztendlich geht es immer um den Use Case.