Kategorien
Analysen

Docker: Multi-Cloud Deployments werden Realität

Die Zeiten in denen Software auf lokalen Maschinen programmiert und isoliert in abgeschirmten Firmennetzwerken betrieben wurde sind längst vorbei. Im Cloud-Zeitalter steigt der Wert eines Software-Dienstes mit dessen Vernetzungs- und Verbreitungsgrad. Dies hat fundamentale Auswirkungen auf die Art und Weise wie Anwendungen heute entwickelt, getestet und betrieben werden. Ausfallsicherheit und Business Continuity sind in diesem Kontext nur zwei Schlagworte, die es dabei zu berücksichtigen gilt.

Kategorien
Analysen

Warum ich (noch) nicht an den Deutsche Börse Cloud Exchange (DBCE) glaube

Nach einem globalen „Paukenschlag“ ist es medial wieder sehr ruhig um den „Deutsche Börse Cloud Exchange“ (DBCE) geworden. Dennoch werde ich immer wieder auf den Cloud-Marktplatz angesprochen – der die Ambitionen hat, den Infrastructure-as-a-Service (IaaS) Markt zu revolutionieren – und werde dabei um eine Einschätzung zu dessen Marktpotential und Zukunft gefragt. Nun, zusammenfassend komme ich ständig zur selben Aussage, dass ich, gemessen an der heutigen Situation, noch nicht an den DBCE glaube und ihm wenig Marktpotential einräume. Warum das so ist? Weiterlesen.

Zwei Geschäftsmodelle

Zunächst sehe ich im DBCE zwei Geschäftsmodelle. Das eine wird in 2014 zur Realität. Der Marktplatz für das Angebot und die Nachfrage von virtuellen Infrastruktur-Ressourcen (Rechenleistung und Speicherplatz), die von Anwendern für den realen Einsatz (Applikationsbetrieb, Daten speichern) genutzt werden sollen.

Bei dem zweiten Geschäftsmodell handelt es sich noch um Zukunftsmusik. Der Handel von virtuellen Ressourcen wie man es von den Futures kennt. Denn sind wir ehrlich. Was ist es, was eine Börse wirklich kann? Ihre eigentliche Aufgabe? Ihr Kerngeschäft? Den Transfer von kritischen Infrastrukturressourcen und Workloads organisieren und überwachen? Nein. Die Börse kann den Preis von virtuellen Gütern bestimmen und damit handeln lassen. Der IaaS-Marktplatz ist nur der Vorbote, um den Markt an dieses Handelsgeschäft heranzuführen und das dafür notwendige Angebot und die Nachfrage zusammenzubringen.

Anbieter und Anwender

Für einen Marktplatz werden grundsätzlich zwei Parteien benötigt. Die Anbieter und die Nachfrager, in diesem Fall die Anwender. Um die Anbieter wird sich der DBCE wenig Gedanken machen müssen. Ist der finanzielle, organisatorische und technische Aufwand relativ gering, wird die Angebotsseite relativ schnell Ressourcen zu bieten haben. Die Problematik besteht auf der Seite der Nachfrager.

Ich habe mich hierzu mit Reuven Cohen unterhalten, der mit SpotCloud im Jahr 2010 den ersten weltweiten IaaS-Marktplatz veröffentlicht hat. In der Spitze hatte SpotCloud 3.200 Anbieter(!) und 100.000 Server weltweit verwaltet. Die Nachfrageseite viel eher bescheiden aus.

Auch wenn Reuven im Jahr 2010 damit viel zu früh dran war, mache ich noch heute dafür fünf Themen verantwortlich, die den DBCE hemmen werden: Das Vertrauen, die Psychologie, die Use Cases, die Technik (APIs) und das Management.

Vertrauen und Psychologie

Die Idee hinter dem DBCE klingt theoretisch klasse. Aber warum ist der DBCE nun tatsächlich vertrauenswürdiger als andere IaaS-Marktplätze? Genießt eine Börse weiterhin dass Vertrauen für das sie als Institution steht bzw. stehen sollte? Hinzu kommt, dass IT-Entscheider ganz anders ticken. Der Großteil der Unternehmen ist weiterhin mit der Public Cloud überfordert und hat Angst die IT und Daten aus der Hand zu geben. Es gibt einen guten Grund, warum die Zahlen von Crisp Research zeigen, dass in Deutschland im Jahr 2013 nur etwa 210 Millionen Euro für Public Infrastructure-as-a-Service (IaaS) ausgegeben wurde. Hingegen lagen die Investitionen für Private Cloud Infrastrukturen bei 2,3 Milliarden Euro.

Das unterstreicht ebenfalls eine Forrester Studie, die besagt:

“From […] over 2,300 IT hardware buyers, […] about 55% plan to build an internal private cloud within the next 12 months.”

Daran wird auch ein unabhängiger Marktplatz nichts ändern. Im Gegenteil, selbst wenn der DBCE für mehr transparenz sorgen soll, schafft er eine weitere Komplexitätsebene zwischen den Anwendern und den Anbietern, die von den Anwendern erst einmal verstanden und adaptiert werden muss. Das spiegelt sich auch in den Use Cases bzw. Workloads wieder, die darauf laufen sollen.

Use Cases

Warum sollte man den DBCE nutzen? Das ist eine Frage, die nicht leicht zu beantworten ist. Warum sollte man über einen Marktplatz Ressourcen einkaufen, wenn ich sie auch von einem Anbieter direkt beziehen kann, der bereits über eine globale Reichweite, viele Kunden und eine bewährte Infrastruktur verfügt? Der Preis und die Vergleichbarkeit können ein entscheidendes Merkmal sein. Wenn die virtuelle Maschine (VM) bei Anbieter A heute ein wenig günstiger ist als bei Anbieter B, dann wird die VM bei Anbieter A genutzt. Wirklich? Nein, das würde die Anwendungsarchitektur dermaßen verkomplizieren, dass die Entwicklung für dieses Szenario in keinem Verhältnis zu dessen Nutzen steht. Cloud Computing ist eh schon viel zu kompliziert, dass ein kluger Cloud Architekt davon Abstand nehmen würde. Man sollte in diesem Zusammenhang auch nicht die technischen Hürden vergessen, die Cloud-Anwender bereits heute mit sehr weit entwickelten Cloud Infrastrukturen haben.

Ein Szenario was sich mit dem DBCE gut abbilden lassen würde ist ein Multi-Cloud Konzept um technische Risiken (z.B. Ausfall eines Anbieters) zu streuen.

Wofür wir zur nächsten und der wohl größten Hürde kommen – den APIs.

API und Management

Die Diskussionen um „den“ bevorzugten API-Standard in der Cloud hören nicht auf. Zum de-facto Standard für Rechenleistung und Speicherplatz haben sich Amazon EC2 (Compute) und Amazon S3 (Storage) entwickelt, die von so gut wie allen anderen Anbietern und Projekten unterstützt werden.

Der DBCE will sich quasi als Middleware zwischen die Anbieter und die Anwender setzen und für beide Seiten eine einheitliche eigene(!) Schnittstelle bieten. Hierzu setzt der DBCE auf die Technologie von Zimory, die zwar über offene Schnittstellen verfügt, welche aber proprietär sind. Anstatt sich auf einen bekannten Standard zu konzentrieren oder einen aus der Open-Source Gemeinde (OpenStack) zu adaptieren, versucht der DBCE einen eigenen Weg zu finden.

Frage: Mit dem Hintergrund, dass wir Deutschen, was das Thema Cloud angeht, uns bisher nicht gerade mit Ruhm bekleckert haben. Warum sollte sich der Markt auf einen neuen Standard einlassen der aus Deutschland kommt und dazu auch noch proprietär ist?

Ein weiteres Problem besteht in den Managementlösungen für Cloud Infrastrukturen. Entweder haben sich potentielle Anwender bereits für eine Lösung entschieden und stehen damit vor der Herausforderung die neuen APIs in irgendeiner Form zu integrieren oder Sie befinden sich weiterhin im Entscheidungsprozess. Hier besteht die Problematik darin, dass bisher keine gängige Cloud-Managementlösung die DBCE APIs unterstützt.

Systemintegratoren und Cloud-Broker

Es gibt zwei Zielgruppen in denen Potential steckt und die gleichzeitig die Tür zu den Anwendern öffnen können. Die Systemintegratoren (Channelpartner) und Cloud-Broker.

Ein Cloud Service Broker ist ein Drittanbieter, der im Auftrag seiner Kunden Cloud Services mit Mehrwerten anreichert und dafür sorgt, dass der Service die spezifischen Erwartungen eines Unternehmens erfüllt. Darüber hinaus hilft er bei der Integration und Aggregation der Services, um ihre Sicherheit zu erhöhen oder den originalen Service mit bestimmten Eigenschaften zu erweitern.

Ein Systemintegrator entwickelt (und betreibt) im Auftrag seiner Kunden ein System oder eine Applikation auf einer Cloud-Infrastruktur.

Da beide im Auftrag der Anwender agieren und die Infrastrukturen, Systeme und Applikationen betreiben, können sie die proprietären APIs adaptieren und stellen damit sicher, dass sich der Anwender damit nicht auseinandersetzen muss. Darüber hinaus können sowohl Systemintegratoren als auch Cloud-Broker den DBCE nutzen, um für sich kostengünstig Cloud-Ressourcen einzukaufen und ein Multi-Cloud Modell nutzen. Hierbei spielt die Komplexität der Systemarchitektur wieder ein Rolle, von welcher der End-Anwender aber nichts mitbekommen darf.

Eine Frage der Zeit

Ich habe in diesem Artikel mehr Fragen aufgeworfen als beantwortet. Ich möchte den DBCE auch nicht zu negativ bewerten, denn die Idee ist gut. Aber die oben genannten Punkte sind essentiell wichtig, um überhaupt ein Fuß in die Tür der Anwender zu bekommen. Dabei wird es sich um einen Lernprozess für beide Seite handeln, den ich auf etwa fünf Jahre schätze, bis dieses Modell bei den Anwendern zu einer signifikanten Adaptionsrate führt.

Kategorien
Analysen

Wir leben bereits in einer Multi-Cloud getriebenen Welt

Nicht zuletzt das Disaster um Nirvanix hat gezeigt, dass man sich nicht auf einen einzelnen Cloud-Anbieter verlassen. Aber auch ungeachtet der Risikostreuung ist der Einsatz einer Multi-Cloud Strategie ein empfehlenswerter Ansatz, der bereits von vielen heute schon bewusst oder unbewusst praktiziert wird.

Hybrid oder Multi-Cloud?

Was bedeutet genau Multi-Cloud? Oder was ist der Unterschied zu einer Hybrid Cloud? Nun, eine Hybrid Cloud verbindet von ihrer Definition her eine eigene Private Cloud bzw. eine on-Premise IT-Infrastruktur mit einer Public Cloud, um die lokalen Infrastrukturen bei Bedarf mit weiteren Ressourcen zu versorgen. Bei diesen Ressourcen kann es sich um Rechenleistung, Speicherplatz aber auch Services in Form von Software handeln. Wird ein lokales E-Mail System mit einem SaaS CRM-System integriert, kann durchaus von einer Hybrid Cloud gesprochen werden. Eine Hybrid Cloud gilt also nicht nur für IaaS bzw. PaaS Szenarien.

Ein Multi-Cloud Konzept erweitert den Hybrid Cloud Gedanken um die Anzahl der zu verbindenden Clouds. Genauer gesagt kann es sich dabei um n-Clouds handeln die in irgendeiner Form miteinander integriert sind. Dabei werden bspw. Cloud-Infrastrukturen so miteinander verbunden, dass die Applikationen verschiedene Infrastrukturen oder Services parallel oder je nach Auslastung oder aktuellen Preisen nutzen. Auch das parallele oder verteilte Speichern von Daten über mehrere Clouds ist vorstellbar, um die Verfügbarkeit und Redundanz der Daten sicherzustellen. Aktuell wird sehr intensiv über Multi-Cloud im IaaS-Umfeld diskutiert. Siehe dazu auch Ben Kepes‘ und Paul Miller’s Mapping Session zum Thema Multi-Cloud sowie Paul’s Sector RoadMap: Multicloud management in 2013.

Was oft vergessen wird ist, dass Multi-Cloud insbesondere im SaaS-Umfeld seine Bedeutung hat. Die Anzahl neuer SaaS-Applikationen wächst täglich und damit auch der Bedarf, diese unterschiedlichen Lösungen miteinander zu integrieren und Daten austauschen zu lassen. Aktuell bewegt sich der Cloud-Markt unkontrolliert auf viele kleine Insellösungen zu, die jede für sich zwar einen Mehrwert bieten, in der Summe jedoch zu vielen kleinen Dateninseln führen. Mit solchen Entwicklungen haben in Unternehmen schon in vor Cloud Zeiten zu kämpfen gehabt und das vergebens.

Risiken streuen

Auch wenn das Cloud-Marketing ständig die Verfügbarkeit und Sicherheit der Daten, Systeme und Applikationen verspricht, liegt die Verantwortung dies sicherzustellen in den eigenen Händen (Das bezieht sich auf eine IaaS Public Cloud). Zwar stellen die Cloud-Anbieter hierfür weitestgehend alle Mittel und Wege zur Verfügung, im IaaS-Bereich muss sich der Kunde aber selbst darum kümmern. Ausfälle wie die der Amazon Web Services oder unvorhergesehene Schließungen wie die von Nirvanix sollten zu mehr Sensibilität bei der Nutzung von Cloud-Services führen. Die Risiken müssen bewusst gestreut werden. Dabei sollten sich nicht alle Eier in einem Nest befinden, sondern strategisch über mehrere verteilt werden.

Best-of-Breed

Die Best-of-Breed Strategie ist der meist verbreitetste Ansatz in IT-Unternehmensarchitekturen. Dabei werden mehrere Branchenlösungen für verschiedene Teilbereiche innerhalb des Unternehmens eingesetzt und miteinander integriert. Die Idee hinter Best-of-Breed besteht darin, die jeweils beste Lösung zu nutzen, die eine All-in-one Lösung in der Regel nicht bieten kann. Man stellt sich also die für seinen Zweck besten Services und Applikationen zusammen.

Verfolgt man diesen Ansatz in der Cloud, befindet man sich direkt in einem Multi-Cloud Szenario, was bedeutet, dass schätzungsweise 90% aller Unternehmen die Cloud-Services nutzen, Multi-Cloud Nutzer sind. Ob die eingesetzten Cloud-Services auch miteinander integriert sind bleibt zu bezweifeln. Was auf der einen Seite empfehlenswert ist, lässt sich auf der anderen Seite in vielen Fällen auch nicht vermeiden. Zwar existieren bereits ein paar gute All-in-one Lösungen am Markt. Dennoch sind die meisten Perlen eigenständig implementiert und müssen mit anderen Lösungen kombiniert werden, z.B. E-Mail und Office/ Collaboration mit CRM und ERP. Das hat von der Risikobetrachtung, insbesondere in der Cloud, seinen Vorteil. Fällt ein Anbieter aus, ist auch nur ein Teil-Service nicht erreichbar und nicht direkt die gesamte Produktivitäts-Umgebung.

Insellösungen vermeiden: Schnittstellen und Integration

Solche Best-of-Breed Ansätze versuchen Cloud-Marktplätze zu schaffen, indem sie einzelne Cloud-Lösungen in unterschiedlichen Kategorien zusammenfassen und Unternehmen damit ein umfangreiches Portfolio verschiedener Lösungen bieten, mit der sich eine Cloud-Produktivitäts-Suite zusammenstellen lässt. Dennoch zeigen, obwohl sehr stark kontrollierte und vermeintlich integrierte Marktplätze an einer entscheidenden Stelle massive Probleme mit der Integration. Es existieren viele einzelne SaaS-Applikationen die nicht zusammenspielen. Das bedeutet, dass keine gemeinsame Datenbasis existiert und das z.B. der E-Mail Service nicht auf die Daten im CRM-Service zugreifen kann und umgekehrt. Damit entstehen wieder, wie bereits oben beschrieben, einzelne Datensilos und Insellösungen innerhalb des Marktplatzes.

Dieses Beispiel zeigt auch die größte Problematik mit einem Multi-Cloud Ansatz. Die Integration der vielen verschiedenen und normalerweise voneinander unabhängig agierenden Cloud-Services und deren Schnittstellen zueinander.

Multi-Cloud ist „The New Normal“ in der Cloud

Das Thema Multi-Cloud wird derzeit insbesondere im IaaS-Umfeld stark diskutiert, um das Risiko zu streuen und die Kosten und Leistungen unterschiedlicher Cloud-Infrastrukturen optimal ausnutzen zu können. Aber ebenfalls im SaaS-Umfeld muss das Thema unbedingt eine höhere Bedeutung zugesprochen werden, um Daten- und Insellösungen in Zukunft zu vermeiden, die Integration zu vereinfachen und Unternehmen bei ihrer Adaption ihrer Best-of-Breed Strategie zu unterstützen.

Ungeachtet diesen Erwartungen ist der Multi-Cloud Einsatz bereits Realität, indem Unternehmen mehrere Cloud Lösungen von vielen unterschiedlichen Anbietern einsetzen, auch wenn diese noch nicht (vollständig) miteinander integriert sind.

Kategorien
Analysen

Nirvanix. Die Hölle auf Erden. Warum ein Multi-Cloud Ansatz zwangsläufig notwendig ist.

Der eine oder andere wird bestimmt davon gehört haben. Nirvanix hat sich selbst ins Jenseits befördert. Der Enterprise Cloud Storage Service, der unter anderem eine große Kooperation mit IBM eingegangen war, hatte am 16. September 2013 plötzlich die Schließung angekündigt und seinen bestehenden Kunden zunächst eine Frist von zwei Wochen eingeräumt, ihre Daten zu migrieren. Der Zeitraum wurde mittlerweile auf den 15. Oktober 2013 verlängert, da die Kunden mehr Zeit für die Migration benötigen. Wie ein Nirvanix Kunde berichtet, hat dieser dort 20 Petabyte an Daten gespeichert.

Das Ende von Nirvanix

Wie aus dem nichts hat der Enterprise Cloud Storage Anbieter Nirvanix am 16. September 2013 sein Ende erklärt. Bis heute ist nicht bekanntgegeben worden, wie es dazu gekommen ist. Gerüchte sagen, dass eine weitere Finanzierungsrunde fehlgeschlagen sei. Weitere Gründe liegen scheinbar am fehlerhaften Management. So hatte das Unternehmen seit 2008 bis heute fünf CEOs. Vergessen sollte man allerdings auch nicht den starken Konkurrenzkampf im Cloud Storage Umfeld. Zum einen haben in den vergangenen Jahren viele Anbieter ihr Glück versucht. Zum anderen senken die beiden Platzhirsche Amazon Web Services mit Amazon S3 und Microsoft mit Azure Storage in regelmäßigen Zyklen die Preise für ihre Services, die ebenfalls Enterprise-fähig sind. Auch hat es für Nirvanix nichts genützt von Gartner als einer der Top Cloud Storage Service Anbieter genannt zu werden.

Besonders brisant ist die Tatsache, dass Nirvanix in 2011 einen fünf Jahres Vertrag mit IBM abgeschlossen hat, um IBMs SmartCloud Enterprise Storage Services um Cloud-basierte Speicherkapazitäten zu erweitern. Wie IBM angekündigt hat, sollen auf Nirvanix gespeicherte Daten auf den IBM SoftLayer Object Storage umgezogen werden. Als IBM Kunde würde ich trotzdem vorsichtig anfragen, wie es um meine gespeicherten Daten steht.

Multi-Cloud: Die Eier müssen über mehrere Nester verteilt werden

Zunächst ein Gruß an die Venture Capital Gemeinde. Wenn es stimmt, dass Nirvanix auf Grund einer fehlgeschlagenen Finanzierungsrunde den Dienst einstellen musste, dann sehen wir, was für eine Verantwortung mittlerweile in deren Händen liegt. Mehr braucht man dazu nicht schreiben.

Wie soll man als Cloud-Nutzer mit so einem Horror-Szenario wie dem von Nirvanix umgehen? Nun, wie man sieht scheint eine gute Kundenbasis und Kooperationen mit globalen Playern kein Garant dafür zu sein, dass ein Service langfristig überlebt. Auch Google spielt derzeit seine Cloud-Strategie auf dem Rücken seiner Kunden aus und trifft keine verbindliche Zusage über das langfristige bestehen seiner Services auf der Google Cloud Platform, wie etwa der Google Compute Engine (GCE). Im Gegenteil, es ist davon auszugehen, dass die GCE nicht lange überleben wird wie andere bekannte Google Services auch.

Backup und Multi-Cloud

Auch wenn der Cloud Storage Anbieter für die Verfügbarkeit der Daten zu sorgen hat, trägt man als Kunde eine Sorgfaltspflicht und die muss darin bestehen, dass man über den Zustand seiner Daten informiert ist und – auch in der Cloud – für Redundanzen und Backups sorgt. Mittlerweile sind Funktionen in den gängigsten Cloud Storage Services integriert, um nahtlose Backups der Daten vorzunehmen und mehrfache Kopien zu erstellen.

Zwar befinden wir uns im Zeitalter der Cloud, dennoch gilt weiterhin: Datensicherung! Man sollte daher sicherstellen, dass ständig ein getestetes(!) und zuverlässiges Backup sowie ein Wiederherstellungsplan existieren. Weiterhin muss ausreichend Bandbreite zur Verfügung stehen, um schnellstmöglich die Daten verschieben zu können. Auch das sollte in regelmäßigen Abständen anhand eines Migration-Audit überprüft werden, um im Fall aller Fälle schnell handeln zu können.

20 Petabyte an Daten mal eben so zu verschieben ist keine leichte Aufgabe. Daher muss man sich über andere Ansätze Gedanken machen. Multi-Cloud ist ein Konzept was in Zukunft immer stärker an Bedeutung gewinnen wird. Dabei werden Daten und Applikationen über mehrere Cloud-Plattformen und Anbieter hinweg (parallel) verteilt. Darüber hatten bereits meine Analysten Kollegen und Freunde Paul Miller und Ben Kepes während ihrer Mapping Session auf der GigaOM Structure in San Francisco diskutiert. Paul hatte im Anschluss daran einen interessanten Sector RoadMap Report zum Thema Multicloud Management geschrieben.

Auch wenn neben Scalr, CliQr, Rightscale und Enstratius bereits einige Management Plattformen für Multi-Cloud existieren, befinden wir uns immer noch in einem sehr frühen Stadium was die Nutzung angeht. schnee von morgen webTV von Nikolai Longolius bspw. setzt primär auf die Amazon Web Services und hat als Fallback Szenario eine native Web-Applikation 1:1 für die Google App Engine entwickelt. Das ist kein Multi-Cloud Ansatz, zeigt aber dessen Bedeutung, um weniger Aufwand für eine Anbieterübergreifende Hochverfügbarkeit und Skalierbarkeit zu erreichen. Wie Pauls Sector Roadmap gut zeigt, ist es insbesondere die Kompatibilität der APIs, der eine große Bedeutung zugesprochen werden muss. Unternehmen werden sich in Zukunft nicht mehr nur auf einen Anbieter verlassen können, sondern ihre Daten und Applikationen über mehrere Anbieter verteilen, um eine Best-of-Breed-Strategie zu fahren und das Risiko gezielt zu streuen.

Das sollte auch in Erwägung gezogen werden, wenn man einfach „nur“ Daten in der Cloud speichert. Das goldene Nest ist die Summe aus mehreren verteilten.

Kategorien
News

CloudBerry erweitert sein Portfolio. Amazon Glacier und Multi-Cloud Migration Client

CloudBerry, Anbieter von Tools für das Backup der Daten in der Cloud hat sein Portfolio erneut erweitert und wird demnächst ebenfalls einen Client für Amazon Glacier anbieten. Dabei würde es sich nach FastGlacier um den zweiten Client für das Langzeit-Backup auf den Amazon Web Services handeln. Weitere neue Services von CloudBerry sind u.a. ein Cloud Migrator Service, mit dem sich Daten über mehrere Cloud Storages und einem einzigen Web-Client hinweg übertragen lassen.

CloudBerry erweitert sein Portfolio. Amazon Glacier und Multi-Cloud Migration Client

Neue Services

Amazon Glacier Erweiterung

Derzeit arbeitet CloudBerry noch an der Unterstützung für Amazon Glacier. Es wird dazu keinen separaten Client geben. Stattdessen werden die bestehenden Lösungen CloudBerry Explorer und CloudBerry Backup mit der Glacier Funktionalität erweitert.

CloudBerry Drive

CloudBerry Drive befindet sich derzeit noch in der Entwicklung. Später soll sich der Speicherplatz von Cloud Storage Lösungen damit wie ein lokales Laufwerk in den Windows Explorer integrieren lassen.

CloudBerry Backup for MS SQL Server

CloudBerry Online Backup for SQL Server richtet sich an Nutzer, die ihr Disaster Recovery für den MS SQL Server auf Amazon S3 und Windows Azure Storage auslagern und steuern wollen.

Cloud Migrator

Der CloudBerry Cloud Migrator ist ein Service, mit dem sich die Daten über mehrere Cloud Storage Services und einem einzigen Client übertragen lassen. Dazu ist keine lokale Software notwendig, da der Service auf Amazon EC2 betrieben wird und über eine Weboberfläche genutzt wird.

Produkt Updates

CloudBerry Backup 2.9.1

CloudBerry Backup 2.9.1 unterstützt nun den OpenStack Keystone Identity Service, einem Authentifizierungsservice, der Identity, Token, Katalog und Policy Services integriert. Nutzer des OpenStack Object Storage von Anbietern wie bspw. RackSpace, HP Cloud oder Haylix, welche die Keystone Authentifizierung implementiert haben, können ab sofort CloudBerry Backup nutzen, um eine lokale Datensicherung vorzunehmen.

CloudBerry Explorer 3.5

Der CloudBerry Explorer 3.5 unterstützt ab sofort die 64-bit Version von Windows und kann nun ebenfalls mit dem Eucalyptus 3.0 Cloud Storage genutzt werden.

Explorer for OpenStack and RackSpace 1.3

Wie bereits unter „CloudBerry Backup 2.9.1“ beschrieben, unterstützt auch der Explorer for OpenStack and RackSpace 1.3 nun den OpenStack Keystone Identity Service.