Kategorie: Insights

Kategorien
Insights

Umfrage: Platform-as-a-Service – Zukunft der deutschen Software-Industrie

Seit über fünf Jahren existieren Platform-as-a-Services (PaaS) am Markt, die sich im Laufe der letzten Jahre zu vollständigen Ökosystemen entwickelt haben. In den USA und Skandinavien gehören PaaS bereits zu den Standardwerkzeugen von professionellen Softwareentwicklern. In Deutschland verhalten sich Geschäftsführer und Entwicklungsleiter noch deutlich zurückhaltender. Dabei erhalten nicht nur deutsche Unternehmen, sondern ebenfalls klassische ISVs (Independent Service Provider) mit einem PaaS eine echte Alternative, um damit die unternehmensinternen Entwicklungssysteme und -Prozesse abzulösen und damit auf das Cloud-Zeitalter umzusteigen.

Neue PaaS-Betriebsmodelle verändern den Markt

Neue PaaS-Betriebsmodelle wie ein Hosted PaaS helfen nicht nur dabei Software-Entwicklungsprozesse deutlich effizienter zu gestalten, sondern auch Big Data Analytics intelligent umsetzen.

Ob und wie sich diese Situation bei deutschen ISVs und Softwarehäusern derzeit verändert und entwickelt, untersucht Crisp Research derzeit im Rahmen einer empirischen Studie „Platform-as-a-Service – Zukunft der deutschen Software-Industrie“.

Für weitere Informationen steht unser Projektleiter Max Hille zur Verfügung.

Umfrage: „Platform-as-a-Service – Zukunft der deutschen Software-Industrie“

Kategorien
Insights

arago veröffentlicht die AutoPilot Community Edition und kündigt Knowledge Community TabTab an

Die Frankfurter arago AG hat mit der Autopilot Community Edition erstmalig eine kostenlose Version ihrer wissensbasierten Automatisierungslösung für den IT-Betrieb veröffentlicht. Die Version richtet sich an kleinere Unternehmen und Startups, die den finanziellen Kraftakt nicht stemmen können, um in eine moderne Automatisierungsplattform zu investieren.

Der Autopilot als Community Edition

Die kostenlose Variante des AutoPilot kann in Umgebungen für bis zu fünf Systeme ohne Einschränkungen eingesetzt werden. Mit ihrem wissensbasierten Ansatz setzt die Lösung auf das vorhandene Wissen eines Unternehmens, um den IT-Betrieb damit dynamisch und selbständig zu automatisieren, indem sich der AutoPilot die Eigenschaften der künstlichen Intelligenz, maschinelles Lernen und Data Analytics zu nutzen macht. Die Community Edition unterscheidet sich funktional nicht von der Enterprise Variante. Der AutoPilot muss initial mit dem notwendigen Wissen für die Administration des IT-Betriebs gefüttert werden, welches in sogenannte Wissensbausteine abgelegt wird. Im Anschluss arbeitet die Lösung wie ein autonomer Administrator, indem er das Wissen je nach Situation und Bedarf flexibel zu Handlungsabläufen kombiniert.

Die Knowledge Community TabTab

Neben den fünf Systemen lässt sich die AutoPilot Community Edition auf bis zu 25 administrierte Systeme erweitern. Hierfür muss man sich als IT-Experte an der neuen Knowledge Community TabTab beteiligen, welche Anfang 2014 starten wird und als Plattform für den Austausch von Wissensbausteinen agiert. Nutzer des AutoPilot können hierüber ihre Wissensbausteine mit der Community teilen und im Gegenzug die Wissensbausteine anderer Experten einsetzen, um den Wissenspool ihres AutoPilot zu erweitern.

Wie mir CEO Chris Boos während der GigaOM Structure Europe erzählt hat, sieht er mit der Veröffentlichung der Community Edition und der Knowledge Community eine Win-Win-Situation für alle Seiten. Auf der einen Seite erhalten auch kleine Unternehmen und Startups die Möglichkeit kostenlos eine mächtige Automatisierungslösung einzusetzen. Auf der anderen Seite kann arago somit auf das Feedback der Community setzen, um den AutoPilot effizient weiterzuentwickeln. Zudem sieht Boos insbesondere für IT-Experten einen Vorteil, indem diese ihr Expertenwissen über TabTab der weltweiten IT-Community präsentieren können.

Disruptiv: Crowdsourcing für den IT-Betrieb

Nachdem arago sich mit dem AutoPilot auf einem sehr guten Weg befindet, den IT-Betrieb grundlegend auf den Kopf zu stellen, macht das Unternehmen aus Frankfurt einen weiteren logischen Schritt, um das für den AutoPilot wichtige Wissen zu konservieren. Die Knowledge Community TabTab wird zum einen als Wissensplattform für die AutoPilot Kunden dienen, um ihr Wissen mit anderen Kunden zu teilen und im Gegenzug ihren eigenen Wissenspool zu erweitern. Zum anderen erhält arago damit selbst die Möglichkeit, den globalen AutoPilot Wissenspool maximal zu erweitern, um die Intelligenz des Systems stetig zu erweitern. Das hat für arago insbesondere den Vorteil, immer mehr Kenntnisse über nicht-standardisierte, heterogene Umgebungen und individuelle Applikationen zu bekommen und damit noch besser auf ungeplante Ereignisse sinnvoll zu reagieren.

Kleine Unternehmen und Startups sollten den Einsatz der kostenlosen AutoPilot Community Edition in Erwägung ziehen, um sich ausschließlich auf ihr Kerngeschäft konzentrieren zu können und ihre wichtigen Ressourcen und Mitarbeiter nicht ausschließlich im IT-Betrieb, der in erster Linie zur Instandhaltung der Unternehmens-IT dient, zu binden.

Kategorien
Insights

Aufbau einer Hosted Private Cloud mit der Open-Source Cloud Computing Infrastrukturlösung openQRM

Unternehmen haben die Vorteile der Flexibilisierung der eigenen IT-Infrastruktur erkannt. Dennoch hat die jüngste Vergangenheit die Bedenken bestärkt, den Weg in die Public Cloud aus Gründen des Datenschutzes und der Informationssicherheit zu meiden. Es sind daher Alternativen gefragt. Mit der Private Cloud wäre eine gefunden. Wären dazu nicht hohe Vorabinvestitionen in eigene Hard- und Software notwendig. Ein Mittelweg besteht in der Nutzung einer Hosted Private Cloud. Diese Form der Cloud wird mittlerweile von einigen Providern angeboten. Es besteht aber ebenfalls die Möglichkeit, selbst den Aufbau und den Betrieb zu übernehmen. Dieser INSIGHTS Report zeigt, wie dieses mit der Open-Source Cloud Computing Infrastrukturlösung openQRM möglich ist.

Warum eine Hosted Private Cloud?

Unternehmen sind angehalten ihre IT-Infrastruktur zu flexibilisieren, um ihren Ressourcenbedarf je nach Situation zu skalieren. Der Idealfall stellt hierbei die Nutzung einer Public Cloud dar. Dabei sind keine Vorabinvestitionen in eigene Hard- und Software notwendig. Viele Unternehmen scheuen, aus Gründen des Datenschutzes und der Informationssicherheit, jedoch den Weg in die Public Cloud und schauen sich nach einer Alternative um. Diese nennt sich Private Cloud. Der Hauptvorteil einer Private Cloud besteht dabei in der flexiblen Self-Service Bereitstellung von Ressourcen für Mitarbeiter und Projekte wie in einer Public Cloud, die durch eine reine Virtualisierung der Rechenzentrumsinfrastruktur nicht möglich ist. Jedoch ist für den Aufbau einer Private Cloud zu beachten, dass Investitionen in die eigene IT-Infrastruktur geleistet werden müssen, um den virtuellen Ressourcenbedarf durch einen physikalischen Unterbau zu gewährleisten.

Daher muss ein geeigneter Mittelweg gefunden werden, der einen flexiblen Ressourcenbezug über einen Self-Service ermöglicht, aber zugleich keine hohe Investitionskosten in eigene Infrastrukturkomponenten erwartet und ohne auf ein selbst festgelegtes Datenschutz und -sicherheitsniveau verzichten zu müssen. Dieser Mittelweg besteht im Hosting einer Private Cloud bei einem externen (Web)-Hoster. Die notwendigen physikalischen Server werden über einen Hoster angemietet, der für deren Wartung zuständig ist. Um auch den etwaigen physikalischen Ressourcenbedarf zu sichern, sollten mit dem Hoster entsprechende Absprachen getroffen werden, um die Hardware sehr zeitnah nutzen zu können. Mögliche Alternativen wären Standby-Server oder ähnliche Ansätze.

Auf dieser externen Server-/Storage-Infrastruktur wird anschließend die Cloud-Infrastruktursoftware installiert und zu einer virtuellen gehosteten Private Cloud konfiguriert. Diese erlaubt es Mitarbeitern zum Beispiel je nach Bedarf eigene Server für die Softwareentwicklung zu starten, einzufrieren und nach Beendigung des Projekts wieder zu entfernen. Für die Abrechnung der jeweilig genutzten Ressourcen sorgt die Cloud-Infrastruktursoftware, die über solche Funktionen entsprechend verfügen muss.

openQRM Cloud

Grundsätzlich kann eine openQRM Cloud für den Aufbau einer Public als auch Private Cloud genutzt werden. Diese basiert komplett auf openQRMs Appliance Modell und bietet vollständig automatisierte Deployments die von Cloud Nutzern angefragt werden können. Dazu unterstützt eine openQRM Cloud alle Virtualisierungs- und Speichertechnologien, die auch von openQRM selbst unterstützt werden. Es besteht darüber hinaus die Möglichkeit, physikalische Systeme über die openQRM Cloud bereitzustellen.

Auf Basis der openQRM Enterprise Cloud-Zones lässt sich darüber hinaus eine vollständig verteilte openQRM Cloud Infrastruktur aufbauen. Damit können mehrere voneinander getrennte Rechenzentren in logische Bereiche aufgeteilt oder zum Beispiel die Unternehmenstopologie hierarchisch und logisch sicher voneinander getrennt aufgebaut werden. Zudem integriert openQRM Enterprise Cloud-Zones ein zentrales und mehrsprachiges Cloud-Portal inkl. einer Google Maps Integration, wodurch ein interaktiver Überblick über sämtliche Standorte und Systeme entsteht.

Aufbau der Referenzumgebung

Für den Aufbau unseres Referenz-Setups werden ein physikalischer Server und mehrere öffentliche IP-Adressen benötigt. Für die Installation von openQRM bestehen zwei Möglichkeiten:

  • Empfohlen: Ein privates Class C Subnetz (192.168.x.x/255.255.255.0) konfigurieren in welchem openQRM betrieben wird. openQRM benötigt dann zusätzlich eine öffentliche IP-Adresse für den Zugang von außen.
  • Option: openQRM in einer virtuellen Maschine installieren. Bei dieser Variante steuert openQRM den physikalischen Server und bezieht die virtuellen Maschinen für den späteren Betrieb der Cloud von dem physikalischen Host.

Für die Zuordnung der öffentlichen IP Adressen kann in beiden Szenarien Cloud-NAT eingesetzt werden. Diese openQRM Cloud Funktion übersetzt die IP Adressen des privaten openQRM Class C Netzwerk in öffentliche Adressen. Dies erfordert Post- und Pre-Routing Regeln, die auf dem Gateway/Router mittels IPTables wie folgt konfiguriert werden:

Für die Konfiguration komplexer Netzwerkumgebungen ist das IP-Management Plugin zu empfehlen. Dieses Enterprise Plugin erlaubt es beliebige Netzwerk- und IP-Adress-Konfigurationen für die verwalteten Server vorzunehmen. In der openQRM Cloud bietet es zudem eine Zuordnung von Netzwerken zu Cloud Benutzergruppen und unterstützt darüber hinaus das automatisierte VLAN Management.

Weiterhin werden zwei Bridges benötigt:

  • Eine für die öffentliche Schnittstelle mit einer öffentlichen IP-Adresse.
  • Eine für die private Schnittstelle dpe für die DHCP konfiguriert ist.

Die Daten der Cloud werden später auf dem lokalen Speicher des physikalischen Servers gespeichert. Hierfür bieten sich zwei Varianten:

Empfohlen:

  • KVM-Storage LVM Deployment (LVM Logical Volume Deployment)
  • Benötigt eine oder mehrere dedizierte LVM Volume Group(s) für die virtuellen Maschinen. Für komplexere Setups empfiehlt sich ein zentrales iSCSI Target oder ein SAN zu verwenden.

Option:

  • KVM-Storage BF Deployment (Blockfile Deployment)
  • Erstellen eines Verzeichnis auf dem Linux-Server unter z.B.
    • /var/lib/kvm-storage/storage1
    • /var/lib/kvm-storage/storage2

      • (Die Storage Verzeichnisse lassen sich über die Plugin Konfiguration beliebig einstellen)

  • Für komplexere Setups empfiehlt sich ein zentrales NAS für die konfigurierten Mountpoints zu verwenden.

Am Ende muss IPTables entsprechend der oben genannten Regeln und der gewünschten eigenen Sicherheit konfiguriert werden. Im Anschluss erfolgt die Installation von openQRM. Pakete für die gängigen Linux Distributionen liegen unter http://packages.openqrm.com. Nachdem openQRM installiert und initialisiert wurde folgt dessen Konfiguration.

Basis-Konfiguration von openQRM

Der erste Schritt nach der Initialisierung ist das Editieren der „/usr/share/openqrm/plugins/dns/etc/openqrm-plugin-dns.conf“, indem der Standardwert auf die eigene Domain geändert wird.

Domain für das private Netzwerk konfigurieren:
# please configure your domain name for the openQRM network here!
OPENQRM_SERVER_DOMAIN=“oqnet.org“

Es folgt das Aktivieren und Starten der Plugins über die Weboberfläche des openQRM-Servers. Die folgenden Plugins sind dazu zwingend erforderlich:

DNS Plugin

  • Dient der automatisierten Verwaltung des DNS Service für das openQRM Management-Netzwerk.

DHCPD

  • Verwaltet automatisch die IP-Adressen für das openQRM Management-Netzwerk.

KVM Storage

  • Integriert die KVM Virtualisierungstechnologie für das lokale Deployment.

Cloud-Plugin

  • Ermöglicht den Aufbau einer Private und Public Cloud Computing Umgebung mit openQRM.

Zu den weiteren empfohlenen Plugins gehören:

Collectd

  • Ein Monitoring-System inkl. Langzeitstatistiken und Graphiken.

LCMC

  • Integriert die Linux Cluster Management Console zur Verwaltung der Hochverfügbarkeit einzelner Services.

High-Availability

  • Ermöglicht eine automatische Hochverfügbarkeit der Appliances.

I-do-it (Enterprise Plugin)

  • Bietet eine automatische Systemdokumentation (CMDB).

Local server

  • Integriert bestehende und lokal installierte Server mit openQRM.

Nagios 3

  • Überwacht automatisch Systeme und Services.

NoVNC

  • Bietet eine remote Web-Konsole für den Zugriff auf virtuelle Maschinen und physikalische Systeme.

Puppet

  • Integriert Puppet für ein vollständig automatisiertes Konfigurationsmanagement und Applikationsdeployment in openQRM.

SSHterm

  • Ermöglicht die sichere Anmeldung über eine Web-Shell an den openQRM-Server und integrierte Ressourcen.

Zu den Plugins die mehr Komfort bei der automatischen Installation von virtuellen Maschinen als Cloud Templates bieten gehören:

Cobbler

  • Integriert Cobbler für das automatisierte Bereitstellen von Linux System in openQRM.

FAI

  • Integriert FAI für das automatisierte Bereitstellen von Linux System in openQRM.

LinuxCOE

  • Integriert LinuxCOE für das automatisierte Bereitstellen von Linux System in openQRM.

Opsi

  • Integriert Opsi für das automatisierte Bereitstellen von Windows System in openQRM.

Clonezilla/local-storage

  • Integriert Clonezilla für das automatisierte Bereitstellen von Linux und Windows System in openQRM.

Basis-Konfiguration der Host-Funktion für die virtuellen Maschinen

Fall 1: openQRM ist direkt auf dem physikalischen System installiert

Als Nächstes muss der Host konfiguriert werden, um darüber später die virtuellen Maschinen bereitzustellen. Dazu wird eine Appliance vom Typ KVM Storage Host erstellt. Man geht dazu wie folgt vor:

  • Appliance erstellen
    • Base > Appliance > Create
  • Name: z.B. openQRM
  • Als Ressource den openQRM Server selbst auswählen
  • Typ: KVM Storage Host

Dadurch erhält openQRM die Information, dass auf dieser Maschine ein KVM Storage angelegt werden soll.

Fall 2: openQRM ist in einer VM installiert, die auf dem physikalischen System läuft

Mittels des „local-server“ Plugins wird das physikalische System in openQRM integriert. Dazu wird das „openqrm-local-server“ Integrations-Tool vom openQRM Server auf das zu integrierende System kopiert z.B.

scp /usr/share/openqrm/plugins/local-server/bin/openqrm-local-server [IP-Adresse des physikalischen Systems]:/tmp/

Danach wird es auf dem zu integrierenden System ausgeführt:

ssh [IP-Adresse des physikalischen Systems]: /tmp/openqrm-local-server integrate -u openqrm -p openqrm -q [IP-Adresse des openQRM Server] -i br0 [-s http/https]

(in diesem Beispiel ist „br0“ die Bridge zum openQRM Management Netzwerk)

Die Integration mittels „local-server“ erstellt in openQRM automatisch:

  • eine neue Ressource
  • ein neues Image
  • einen neuen Kernel
  • eine neue Appliance aus den obigen Subkomponenten

Als Nächstes muss die Appliance des gerade integrierten physikalischen Systems konfiguriert werden, um darüber später die virtuellen Maschinen bereitzustellen. Dazu wird die Appliance als Typ KVM Storage Host eingestellt. Man geht dazu wie folgt vor:

  • Appliance editieren
    • Base > Appliance > Edit
  • Typ: KVM Storage Host einstellen

Dadurch erhält openQRM die Information, dass auf dieser Maschine ein KVM Storage angelegt werden soll.

Basis-Konfiguration der Storage-Funktion

Nun folgt die grundsätzliche Konfiguration des Storage. Hierzu wird ein Storage Objekt von einem selbst gewünschten Typ erstellt. Dazu geht man wie folgt vor:

  • Storage erstellen
    • Base > Components > Storage > Create
    Im Fall 1, die Ressource des openQRM Servers auswählen
  • Im Fall 2, die Ressource des integrierten physikalischen Systems auswählen
  • Name: z.B. KVMStorage001
  • Deployment-Typ wählen
    • hängt vom zu Beginn gewählten Typ ab: KVM-Storage LVM Deployment oder Verzeichnis (KVM-Storage BF Deployment)

Vorbereitung eines Images für virtuelle Maschinen

Um später über das Cloud-Portal virtuelle Maschinen (VM) als Teil fertiger Produkte bereitzustellen, muss zunächst ein Image für eine VM vorbereitet werden. Das funktioniert wie folgt:

  • Erstellen einer neuen virtuellen Maschine mit einer neuen virtuellen Festplatte und auf dieser ein ISO installieren.
    • Plugins > Deployment > LinuxCOE > Create Templates
    • Die hier erstellten Images werden automatisch in einem ISO-Pool, der für alle virtuellen Maschinen innerhalb von openQRM verfügbar ist, abgelegt.

Anschließend folgt das Erstellen einer Basis für ein Mastertemplate. Dieses dient als Grundlage, um später den Anwendern ein Produkt über die Cloud anhand eines Bestellvorgangs bereitzustellen.

  • Erstellen einer neuen Appliance
    • Base > Appliance > Create
  • Erstellen einer neuen Ressource
    • KVM-Storage Virtual Machine
      • Neue VM anlegen
      • Einstellungen vornehmen
      • ISO Image auswählen
      • Erstellen
    • Erstellte Ressource auswählen
  • Neues Image erstellen
    • Image als KVM-Storage Volume hinzufügen
    • KVM-Storage auswählen
    • Volume Group auf KVM-Storage auswählen
    • Neues Logical Volume hinzufügen
    • Image für die Appliance auswählen
    • Editieren, um damit ein Passwort zu setzen. (Damit wird das zuvor gewählte Passwort des ISO Image überschrieben.)
  • Kernel auswählen
    • von der lokalen Festplatte
    • (LAN Boot wäre ebenfalls möglich)
  • Appliance starten
    • die automatische Installation kann nun über VNC verfolgt werden.
    • Weitere Anpassungen können nun selbst vorgenommen werden.
    • Und folgendes beachten
      • Misc > Local-Server > Help >Local VMs („Local-Server für Lokale Virtuelle Maschinen“)

Aufräumen

Die erstellte Appliance kann nun gestoppt und anschließend gelöscht werden. Entscheidend hier war, dass wir uns ein Image erstellt haben, das für die Cloud als Mastertemplate genutzt werden kann.

Das über die Appliance erstellte Image enthält das Basis Betriebssystem welches aus dem ISO-Image installiert wurde.

Konfiguration der openQRM Cloud

Wir haben nun alle Vorbereitungen abgeschlossen, um mit der Konfiguration der openQRM Cloud zu beginnen. Die Einstellungen dafür finden wir unter „Plugin > Cloud > Configuration > Main Config“. Sämtliche Parameter, die hier angepasst werden, haben einen direkten Einfluss auf das Verhalten der gesamten Cloud.

Grundsätzlich lässt sich eine openQRM Cloud mit den Standardparametern betreiben. Je nach Bedarf und der eigenen speziellen Situation müssen Anpassungen erfolgen. Hilfreich dazu ist der Bereich „Beschreibungen“ in der rechten Spalte der Tabelle.

Es existieren jedoch einzelne Parameter, die unabhängig von dem eigenen Anwendungsfall in Betracht gezogen werden sollten. Dazu gehören:

Automatische Provisionierung (auto_provision)

  • Legt fest, ob Systeme automatisch durch die Cloud bereitgestellt werden oder ob zunächst eine Freigabe durch den Administrator notwendig ist.

Provisionierung physikalischer Systeme (request_physical_systems)

  • Mit diesem Parameter lässt sich definieren, ob neben virtuellen Maschinen auch physikalische Host über die Cloud bereitgestellt werden sollen.

Klonen der Images (default_clone_on_deploy)

  • Die Cloud rollt standardmäßig Kopien (Klone) eines Images aus.

Hochverfügbarkeit (show_ha_checkbox)

  • Ermöglicht den Betrieb der openQRM Cloud inklusive Hochverfügbarkeit der bereitgestellten Ressourcen.

Abrechnung der genutzten Ressourcen (cloud_billing_enabled)

  • openQRM verfügt über ein umfangreiches Abrechnungssystem, mit dem für sämtliche Ressourcen eigene Preise festgelegt werden können, um einen transparenten Überblick zu den laufenden Kosten zu erhalten.

Cloud Produkt Manager (cloud_selector)

  • Aktiviert den Produkt-Manager, mit dem den Nutzern verschiedene Ressourcen über das Cloud-Portal bereitgestellt werden können.

Währung zur Abrechnung der Ressourcen (cloud_currency)

  • Legt die Landeswährung fest, mit der die Ressourcen abgerechnet werden sollen.

Umrechnungsfaktor für Ressourcen in reale Währung (cloud_1000_ccus)

  • Legt fest, wie viel 1000 CCUS (Cloud Computing Units) in einer zuvor festgelegten realen Währung entsprechen sollen.

Ressourcenzuordnung für Gruppen (resource_pooling)

  • Legt fest, von welchem Host eine bestimmte Benutzergruppe ihre virtuellen Maschinen erhalten darf.

Produkte für openQRM Cloud anlegen

Um unseren Nutzern Cloud Ressourcen über das Cloud-Portal bereitzustellen, müssen vorab Produkte ausgewählt werden, welche über die Konfiguration einer virtuellen Maschine bestimmen. Die Einstellungen dafür nehmen wir unter „Plugin > Cloud > Configuration > Products“ vor.

Unter der „Cloud Produkt Verwaltung“ lassen sich verschiedene Produkte erstellen, die später unter dem Cloud-Portal von dem Nutzer eigenständig zu vollständigen virtuellen Maschinen zusammengebaut werden können. Zu den Produkten die uns dabei zur Verfügung stehen gehören:

  • Anzahl der CPUs
  • Größe der lokalen Festplatte
  • Größe des Arbeitsspeichers
  • Der Typ des Kernel
  • Die Anzahl der der Netzwerkkarten
  • Vorinstallierte Applikationen
  • Typ der Virtualisierung
  • Ob eine virtuelle Maschine hochverfügbar sein soll

Über die Statuszeile können mit +/- die jeweiligen Produkte aktiviert bzw. deaktiviert werden und damit dem Nutzer im Cloud-Portal angezeigt oder vor ihm versteckt werden.

Bitte beachten: Produkte die deaktiviert werden, aber noch innerhalb von virtuellen Maschinen aktiv sind, werden weiterhin abgerechnet.

Um nun ein neues CPU Produkt zu erstellen wählen wir den Reiter „CPU“ und bestimmen in dem Bereich „Hinzufügen eines CPU Produkts“ unsere gewünschten Parameter.

Der erste Parameter bestimmt, wie viele CPUs (Kerne), hier 64, unser Produkt haben soll. Über den zweiten Parameter legen wir fest, welchen Wert dieses Produkt hat und wie viele Kosten entsprechend während seiner Nutzung pro Stunde entstehen. In diesem Beispiel entstehen Kosten von 10 CCUs pro Stunde für 64 CPUs.

Anhand der Pfeiltasten lässt sich die Reihenfolge bestimmen, wie die einzelnen Produkte im Cloud-Portal angezeigt werden. Der Default-Wert ist der an obiger Stelle.

Bitte beachten: Im Cloud-Portal existieren Standard-Profile in den Größen „Small“, „Medium“ und „Big“. Die Profile werden automatisch entsprechend der Reihenfolge unter den jeweiligen Produkten bestimmt. Das bedeutet Small nimmt immer den ersten Wert, Medium den Zweiten und Big den Dritten.

openQRM erlaubt es ebenfalls, die virtuellen Maschinen mit vorkonfigurierten Softwarestacks zu bestellen. Dazu greift openQRM auf Puppet (Plugins > Deployment > Puppet) zurück. Damit ist es möglich zum Beispiel den bekannten LAMP-Stack zu bestellen.

Haben wir unsere Produktpalette fertig konfiguriert, ist der Nutzer an der Reihe, sich seine virtuellen Maschinen zu bestellen. Das erfolgt über das Cloud-Portal.

openQRM Cloud-Portal

Für das Erstellen einer neuen virtuellen Maschine (VM) klicken wir im Reiter auf „Neu“. Es
erscheint die Eingabemaske, in der wir unsere VM anhand der Produkte, die der
Administrator im Admin-Backend festgelegt und freigegeben hat, erstellen können.

Wir entscheiden uns für das Profil „Gross“ und einem LAMP-Server. Unsere virtuelle Maschine besteht damit aus den folgenden Produkten:

  • TYP: KVM-Storage VM
  • RAM: 1 GB
  • CPU: 64 Kerne
  • Festplatte: 8 GB
  • Netzwerkkarte: 1

Darüber hinaus soll diese virtuelle Maschine „Hochverfügbar“ sein. Das bedeutet, wenn diese ausfallen sollte, wird automatisch eine Ersatzmaschine mit exakt derselben Konfiguration hochgefahren, mit der man weiterarbeiten kann.

Für diese Konfiguration werden uns Kosten in Höhe von 35 CCUs pro Stunde entstehen. Das entspricht 0,04Euro pro Stunde bzw. 0,84Euro pro Tag oder 26,04Euro pro Monat.

Wollen wir die virtuelle Maschine bestellen, wählen wir „absenden“.

Unter dem Reiter „Aufträge“ sehen wir alle aktuellen und vergangenen Bestellungen, die wir mit unserem Benutzer getätigt haben. Der Status „active“ in der ersten Spalte zeigt, dass die Maschine bereits hochgefahren ist.

Parallel dazu erhalten wir eine E-Mail mit der IP-Adresse, einem Benutzernamen und Passwort, über die wir uns an der virtuellen Maschine anmelden können.

Der Reiter „Systeme“ bestätigt uns beide Informationen noch einmal und zeigt weitere Informationen zu der virtuellen Maschine. Darüber hinaus haben wir die Möglichkeit, Änderungen an der Systemkonfiguration vorzunehmen, die virtuelle Maschine in den Ruhezustand zu setzen oder neu zu starten. Weiterhin ist der Login über eine Web-Shell möglich.

Die virtuelle Maschine kann, wenn sie nicht mehr benötigt wird pausiert werden. Alternativ besteht die Möglichkeit, dass der Administrator dieses zum Beispiel anhand einer Inaktivität des Systems oder zu einer bestimmten Uhrzeit veranlasst.

Virtuelle Maschine mit dem „Visual Cloud Designer“ erstellen

Neben dem „gewöhnlichen“ zusammenbauen einer virtuellen Maschine, ermöglicht das openQRM Cloud-Portal es dem Benutzer, dieses bequem per Drag-and-Drop zu erledigen. Dabei hilft der „Visual Cloud Designer“, der unter dem Reiter „VCD“ zu finden ist.

Mit dem Schieberegler unter „Cloud Components“ lässt sich zwischen den Produkten auf der linken Seite hin und her scrollen. Mit der Maus lässt sich die „Cloud Appliance“ (virtuelle Maschine) in der Mitte mit den entsprechenden Produkten bestücken.

Unsere virtuelle Maschine „Testosteron“ haben wir in diesem Fall also mit einem KVM-Storage, Ubuntu 12.04, 64 CPUs, 1024 MB Ram, 8 GB Festplatte, einer Netzwerkkarte, Software für einen Webserver und mit der Eigenschaft Hochverfügbarkeit ausgestattet.

Mit einen Klick auf „Check Costs“, sagt uns openQRM, dass wir für diese Konfiguration 0,03 EUR pro Stunde bezahlen würden.

Um den Bestellvorgang für die virtuelle Maschine zu starten klicken wir auf „Request“. Wir erhalten die Meldung, dass openQRM mit dem Ausrollen der Ressource beginnt und wir weitere Informationen im Postfach haben.

Die E-Mail enthält wie bereits oben beschrieben, sämtliche Zugangsdaten, um mit der virtuellen Maschine zu arbeiten.

Im Cloud-Portal unter „Systeme“, sehen wir dann auch bereits die gestartete virtuelle Maschine.

Virtuelle Maschine mit dem „Visual Infrastructure Designer“ erstellen

Neben der Bereitstellung einzelner virtueller Maschinen bietet das openQRM Cloud-Portal zudem die Möglichkeit, vollständige Infrastrukturen, bestehend aus mehreren virtuellen Maschinen und weiteren Komponenten, mit einem Klick bereitzustellen.

Dafür greifen wir auf den „Visual Infrastructure Designer“ zurück. Dieser ist im Cloud-Portal unter dem Reiter „VID“ zu finden.

Über den „VID“ lässt sich per Drag and Drop eine vollständige WYSIWYG Infrastruktur zusammenbauen und direkt ausrollen. Hierzu müssen anhand des „VCD“ oder auf normalem Weg jedoch zunächst fertige Profile mit vorkonfigurierten virtuellen Maschinen z.B. Webserver, Router, oder Gateways erstellt werden, die anschließend provisioniert werden können.

Kategorien
Insights

TecArt-CRM Mobile – Modulare "All-in-One Business Suite" aus der Cloud

Die Wahl einer geeigneten Customer-Relationship-Management (CRM) Lösung ist eine kleine Herausforderung für jedes Unternehmen. Dabei hängt die endgültige Entscheidung von den jeweiligen Anforderungen und speziellen Bedürfnissen ab. In diesem Zusammenhang ist die flexible Nutzung einer Lösung von entscheidender Bedeutung, um nicht in langfristige Verträge und hohe Investitionskosten zu geraten. Dieser INSIGHTS Report gibt einen Überblick über die Cloud-CRM Lösung der TecArt GmbH aus Erfurt, zeigt deren Funktionen und welche Vorteile ein Unternehmen damit erhält.

Einleitung

Die Bedeutung des Customer-Relationship-Management (CRM) nimmt, trotz seiner Historie, in den Unternehmen stetig zu. Ohne dem konsequenten Fokus auf seine Kunden und die bedingungslose Gestaltung der dafür notwendigen Prozesse, ist ein Unternehmen in der heutigen Zeit nicht mehr wettbewerbsfähig. Nur mit einem ganzheitlichen und unternehmensübergreifenden Beziehungsmarketing kann die Zusammenarbeit zwischen einem Unternehmen und seinen Kunden langfristig ausgerichtet und gefestigt werden, was sich ausschlaggebend auf den gegenwärtigen und zukünftigen Erfolg auswirkt. Hierzu müssen die unterschiedlichen Abteilungen, wie das Marketing, der Vertrieb, der Kundenservice und ebenfalls die Bereiche Forschung und Entwicklung in die Prozesse integriert werden.

Die allumfassende Integration dieser Abteilungen ist zum einen organisatorisch nicht immer ganz einfach umzusetzen, zum anderen muss eine geeignete IT-Lösung gefunden werden, welche die Anforderungen des Unternehmens nahezu perfekt erfüllt. Dafür wurde in der Vergangenheit massiv in on-Premise Systeme investiert, was zu langfristigen und unflexiblen Lizenzkosten führte. In Zeiten des Cloud Computing respektive von Software-as-a-Service (SaaS) ist es allerdings nicht mehr notwendig, sich an langfristige Verträge der Anbieter zu binden. Stattdessen wird die Lösung pro Benutzer und im Idealfall pro Monat abgerechnet, wodurch das monatliche bzw. jährliche Kosten-/ Nutzenverhältnis transparenter wird.

An dieser Stelle sei angemerkt, dass der Vorteil der Flexibilität einer SaaS-Lösung nicht darin besteht, die Möglichkeit zu besitzen, jährlich oder gar halbjährlich den Anbieter zu wechseln. Ein Unternehmen plant trotz SaaS langfristig. Die Kosten und der Aufwand ständig einen neuen Anbieter zu evaluieren und anschließend zu migrieren steht in keinem Verhältnis zu dem eigentlichen Vorteil, der sich daraus ergibt. Im Einzelfall kann dies in Erwägung gezogen werden, wenn die Zufriedenheit mit dem Anbieter nachlässt. Der eigentliche Flexibilitätsvorteil einer SaaS-Lösung besteht in deren Skalierbarkeit in Bezug auf die monatliche Nutzung pro Nutzer und Funktionalität. Das bedeutet, dass ein Unternehmen besser auf seine monatlichen Anforderungen reagieren kann, indem es u.a. flexibler auf die Mitarbeiterfluktuation reagiert. So lässt sich besser mit Saisonkräften planen, für die normalerweise im Voraus eine bestimmte Anzahl von Lizenzen für diesen Zeitraum eingekauft wurde, welche nach dem Einsatz als totes Kapital nicht mehr benötigt werden. Bei der Nutzung einer SaaS-Lösung können für einen bestimmten Monat die Anzahl an benötigten Nutzern erhöht und anschließend wieder verringert werden. Damit lässt sich besser für die Zukunft planen.

Dies gilt auch für ein SaaS CRM-System, bei dem es um weit viel mehr geht, als nur eine Datenbank mit Kundeninformationen. Insbesondere der aufstrebende Markt der mobilen Kollaboration ermöglicht es Außendienst-Mitarbeitern vor Ort beim Kunden ständig auf aktuelle Live-Daten zuzugreifen und diese im gleichen Umfang zu bearbeiten. Darüber hinaus sollte die Menge an weiteren Services in Betracht gezogen werden. Das hat den Hintergrund, dass aktuelle SaaS CRM-Lösungen am Markt zwar eine Integration mit weiteren externen SaaS-Angeboten, wie bspw. E-Mail Services versprechen, die Umsetzung jedoch suboptimal gelöst ist. In diesem Zusammenhang ist neben weiteren Aspekten ebenfalls auf die Verfügbarkeit von Schnittstellen zu achten, um eigene bestehende Systeme mit der CRM-Lösung zu verbinden.

Überblick TecArt-CRM

Der Markt für CRM-Systeme aus der Cloud ist in den letzten Jahren stark gewachsen. Angeführt von Salesforce haben sich die Lösungen für das Kundenbeziehungsmanagement von on-Premise Installation hin zu Web-basierten Lösungen aus der Cloud entwickelt. Die unterschiedlichen SaaS-CRMs adressieren dabei je nach Funktionsumfang und Leistung unterschiedliche Zielgruppen. Vom großen Konzern, über den Mittelständler bis hin zum Freiberufler, bietet der Markt eine große Auswahl unterschiedlicher Systeme für das Web-basierte Kundenbeziehungsmanagement.

Die TecArt GmbH aus Erfurt richtet sich mit ihrem TecArt-CRM an mittelständische und größere Unternehmen. Neben einer vollständigen Web-basierten Lösung bietet das Unternehmen seine Software ebenfalls für die on-Premise Installation im eigenen Rechenzentrum an. Den gegenwärtigen Vorteil erreichen Unternehmen jedoch nur mit der Nutzung der Cloud-basierten Lösung TecArt-CRM Mobile, in der es in diesem INSIGHTS Report gehen soll.

Ganzheitliche Module für die flexible Nutzung

TecArt-CRM Mobile wurde für kleine und mittelständische Unternehmen entwickelt, die in der Regel über keine Vollzeit IT-Abteilungen und somit über keine leistungsstarke IT-Infrastruktur verfügen, aber dennoch den Vorteil von mehreren Standorten für sich nutzen möchten.

Sechs Hauptmodule, darunter Services für die Verwaltung von E-Mails, Kontakten, Terminen, Aufgaben und Dokumenten, bilden den Kern der SaaS-Applikation und gehören zum standardisierten Leistungsumfang des CRM-Systems. Für einen festen monatlichen Betrag pro Benutzer gibt es zudem 5 GB Speicherplatz für jeden Nutzer inklusive, der gegen einen Aufpreis bei Bedarf erhöht werden kann. Das Hosting, die Wartung des Systems und das tägliche Backup der Daten, übernimmt die TecArt GmbH.

Eine der großen Stärken von TecArt-CRM Mobile ist die Möglichkeit, das Basissystem je nach Bedarf um weitere Zusatzmodule monatlich zu erweitern und ebenfalls wieder zu kündigen. Unternehmen erhalten damit einen sehr flexiblen Zugriff auf weitere Mehrwert-Services, mit denen sie das CRM-System den eigenen Anforderungen nach anpassen können. Zu diesen nützlichen Services gehören u.a. eine Projektverwaltung, Angebotsverwaltung, Vertragsverwaltung oder die Ressourcenplanung.

Die mobile Cloud ermöglicht den Zugriff von jedem Ort

Neben der Browser-basierten Nutzung ermöglicht TecArt-CRM Mobile ebenfalls den mobilen Zugriff zum Abrufen und Bearbeiten der Daten im CRM-System. Hierzu werden für die mobile Synchronisation die gängigen mobilen Betriebssysteme iOS, Android, Windows Phone und Blackberry, aber ebenso ältere Systeme wie Windows Mobile und Symbian unterstützt.

Für die mobile Synchronisation von Informationen hat die TecArt GmbH den Dienst „TecArt-Push“ entwickelt, der die browserbasierte Cloud-Lösung TecArt-CRM mit einer Push-Funktion erweitert. Dieser ist vergleichbar mit den Lösungen wie man sie von Google Apps oder Apple iCloud kennt. Damit erhalten Unternehmen neben einem CRM-System ebenfalls eine vollwertige mobile Groupware für unterschiedliche Endgeräte für den Zugriff auf E-Mails, Kontakte, Termine und Aufgaben, die automatisch mit dem TecArt-CRM synchronisiert werden.

Auch Außendienst-Mitarbeiter bekommen damit die wertvolle Möglichkeit, von unterwegs auf Informationen zuzugreifen und gleichermaßen Daten wie E-Mails, Termine, Kontakte usw. zu erfassen und zu bearbeiten.

Neben der Synchronisation von Daten ermöglicht die „TecArt-CRM Web-App“, über eine mobile Internetverbindung, zudem den Zugriff auf weitere Daten und Informationen von anderen Services im Backend des CRM-Systems. Das bedeutet, dass somit ebenfalls u.a. auf Dokumente, Tickets, Projekte, Verträge und Angebote zugegriffen werden kann. Anhand eines integrierten Geolocation Service lassen sich darüber hinaus Kontakte in der unmittelbaren Nähe des aktuellen Standorts finden.

Kooperation mit Cloud Marketplaces zur Erhöhung der Reichweite

Cloud Marketplaces gehören zu der Zukunft des Cloud Computing und sind eine logische Entwicklung, um Unternehmen und Entwickler einen guten Überblick sowie einen einfachen Zugriff auf IT-Ressourcen zu ermöglichen.

Darüber hinaus gibt es auch weniger gute Cloud Applikationen auf dem Markt, die entweder keinen echten Mehrwert bieten, nicht gut durchdacht sind oder eine schlechte Architektur besitzen und dadurch ebenfalls sicherheitstechnisch nicht gut implementiert sind. Somit helfen Cloud Marketplaces dabei, potentielle Top-Applikationen von eher unbedeutenden Services zu trennen und bieten Entscheidungshilfen bei der Auswahl. Das wird zum einen durch den Marktplatz Anbieter selbst gewährleistet, zum anderen anhand eines Bewertungssystems, über das die Nutzer Kommentare und Beurteilungen hinterlassen können. Zudem räumen Cloud Marketplaces auf und fassen die unterschiedlichen Cloud Angebote thematisch zusammen. Sie bilden quasi ein unabhängiges Ökosystem von Cloud Services.

Cloud Marketplaces können darüber hinaus jungen Unternehmen helfen, ihren Bekanntheitsgrad und die Reichweite zu erhöhen. Aber auch für etablierte Unternehmen, die mit Cloud Angeboten starten, ergeben sich dadurch Chancen, sich einer breiten Masse zu präsentieren und vor dem bestehenden Mitbewerb transparent zu bewähren.

Dies gehört auch zur Strategie der TecArt GmbH, die für ihr TecArt-CRM Mobile Kooperationen mit zwei Cloud Marketplaces, dem Telekom Business Marketplace und dem Fujitsu Cloud Store, geschlossen hat. Insbesondere die Aufnahmekriterien des Business Marketplace der Deutschen Telekom sind sehr hoch und haben hohe Anforderungen in Bezug auf die Architektur und Sicherheit der Cloud Applikation, die mit Audits überprüft werden. Da die Telekom damit auf Klasse statt Masse setzt, ist die Aufnahme von TecArt-CRM Mobile als äußerst positiv zu bewerten.

Zusätzliche APIs und Software vereinfachen die Integration

Gute Cloud Applikationen zeichnen sich durch ihre Transparenz, Offenheit und den damit verbundenen Schnittstellen (APIs, Application Programming Interface) aus, mit denen die Applikationen selbst erweitert oder mit bereits bestehenden Software-Lösungen integriert werden können.

Das hat auch TecArt verstanden und bietet neben den Kernmodulen und den erweiterten Services ebenfalls zusätzlich weitere Funktionen und Software an, um die TecArt-CRM Produktlinie zu erweitern. So lässt sich u.a. über Zusatzsoftware eine Synchronisation mit Outlook herstellen oder die Integration mit einer Telefonanlage realisieren. Weiterhin ist das Angebot von eigenen Web-Services für Entwickler in Unternehmen sehr interessant, um darüber bestehende Softwarelösungen wie ein Warenwirtschafts-, Zeiterfassungssystem oder einen eigenen Webshop an TecArt-CRM anzubinden.

Preismodell: Pay per use oder on-Premise

TecArt-CRM kann über zwei unterschiedliche Bezugsmodelle genutzt werden. Die klassischen on-Premise Modelle „Company“ und „Enterprise“ richten sich an diejenigen, die sich noch konservativ selbst um das Hosting und den Betrieb ihre Infrastruktur kümmern möchten. Dazu kann das TecArt-CRM zu einem Festpreis eingekauft werden. Hierbei dürfen allerdings die weiteren Kosten für den Betrieb und die Wartung der dafür benötigten IT-Infrastruktur nicht vernachlässigt werden.

Die moderne Art des IT-Bezugs wird über TecArt-CRM Mobile angeboten. Dazu wird für diverse Kernmodule pro Benutzer und Monat ein fester Grundbetrag berechnet. Weitere Module lassen sich flexibel pro Benutzer hinzubuchen und werden dann ebenfalls zusätzlich monatlich abgerechnet. Der Vorteil an dieser Lösungsvariante besteht darin, dass sich TecArt zu 100% um das Hosting, den Betrieb und die Wartung der notwendigen IT-Infrastruktur sowie das TecArt-CRM System kümmert. Ein Kunde konsumiert lediglich die Services bei Bedarf.

Sicherheit und Standortvorteile

Die Themen Datenschutz und Datensicherheit werden im Zusammenhang mit der Cloud weiterhin stark diskutiert. Insbesondere in einem sehr sensiblen Umfeld wie dem Customer-Relationship-Management, bei dem viele personenbezogene aber speziell auch unternehmenskritische Daten verarbeitet werden, darf sich ein Unternehmen nicht für irgendeinen Anbieter entscheiden. Stattdessen muss ein Anbieter gewählt werden, der den unternehmenseigenen Ansprüchen genügt und insbesondere alle datenschutz- und datensicherheitstechnischen Bereiche erfüllt.

Im Bereich der Datensicherheit setzt TecArt auf eine SSL-Verschlüsselung, mit der eine gesicherte Verbindung während der Datenübertragung zwischen dem Server und dem Client hergestellt wird. Darüber hinaus ist der Standort des Rechenzentrums in Deutschland und nach dem ISO Sicherheitsstandard 27001 zertifiziert. TecArt gewährleistet für seine Services eine Erreichbarkeit von 98% im Jahresdurchschnitt. Weiterhin bietet das Unternehmen mit einem Überschreibungsschutz mehr Sicherheit von Dokumenten, indem eine personifizierte Versionsablage und –kontrolle dafür sorgt, dass die Daten immer in einem konsistenten Zustand gehalten werden. Zudem stellt ein Lese- und Schreibschutz auf Nutzerebene sicher, dass nur berechtigte Personen Zugriff auf Module, Objekte und einzelne Dokumente erhalten. Für den Fall der manuellen Löschung durch einen Benutzer steht weiterhin ein persönlicher Papierkorb für den Mitarbeiter zur Verfügung. Sollte dies nicht reichen, werden täglich automatische Backups des Systems vorgenommen, die sieben Tage gespeichert werden.

Neben der Datensicherheit ist der Datenschutz mit sehr viel Sensibilität zu betrachten. Auf Grund des deutschen Firmensitzes unterliegt die TecArt GmbH dem europäischen und deutschen Datenschutzrecht und garantiert, dass keine Daten an US-amerikanische Regierungsbehörden weitergegeben werden. Weiterhin richtet sich TecArt streng nach der Geheimhaltungsstufe „VS-Vertraulich“. Das bedeutet, dass sämtliche Daten und Dokumente die auf den Cloud Services von TecArt gespeichert und verarbeitet werden, die Sicherheitseignung nach den Stufen behördlich, vertraulich und Verschlusssachen (VS-Vertraulich) erfüllen.

Auszeichnungen zeugen von Qualität

Auch wenn Auszeichnungen immer mit der Jury in direkten Zusammenhang stehen, sind sie eine Tendenz für die Qualität einer Lösung. Handelt es sich um mehr als eine Auszeichnung von unterschiedlichen und unabhängig voneinander agierenden Konsortien oder Verbänden, darf ein Unternehmen mit ruhigen Gewissen davon ausgehen, dass die Qualität tatsächlich stimmt.

TecArt kann bereits sechs unabhängige Auszeichnungen vorweisen. Darunter den Hosting & Service Provider Award 2013, das Prädikat BEST OF 2013 in der Kategorie CRM im Rahmen des Innovationspreis-IT 2013 der initiative Mittelstand und den Telekom Innovationspreis 2012.

Empfehlung für das Management

Die Wahl einer geeigneten Customer-Relationship-Management Lösung ist eine kleine Herausforderung für jedes Unternehmen. Dabei hängt die endgültige Entscheidung von den jeweiligen Anforderungen und speziellen Bedürfnissen ab. In diesem Zusammenhang ist die flexible Nutzung einer Lösung von entscheidender Bedeutung, um nicht in langfristige Verträge und hohe Investitionskosten zu geraten. An dieser Stelle setzt TecArt-CRM an und bietet neben wichtigen Kernfunktionen die Möglichkeit, bei Bedarf das System monatlich um weitere Module mit mehr spezifischen Funktionen zu erweitern bzw. wieder zu verkleinern, was den Nutzern in der Summe einen erheblichen Mehrwert verschafft.

Wird das gesamte Portfolio von TecArt-CRM betrachtet, darf hier von keiner reinen CRM-Lösung mehr die Rede sein. Mit vollständig integrierten Funktionen für die Verwaltung von E-Mails, Aufgaben, Terminen, Kontakten, Aufgaben und weiteren Services, bietet TecArt-CRM einem Unternehmen viel mehr als ein gewöhnliches System für das Kundenbeziehungsmanagement. TecArt-CRM konzentriert sich vollständig auf die Standard-Prozesse eines Unternehmens inkl. Synchronisation mobiler Endgeräte und unterstützt somit jedes Unternehmen bei seiner zukünftigen Cloud-Collaboration. Aus diesem Grund handelt es sich bei der Lösung im eigentlichen Sinne um ein kollaboratives CRM, was in diesem Fall auch besser ausgedrückt, als eine All-in-One Business Suite aus der Cloud bezeichnet werden kann.

Unternehmen die sich ebenfalls auf das Thema „Social CRM“ – Die Nutzung moderner Social Networks für die Kundenkommunikation. – konzentrieren möchten, sind bei TecArt-CRM derzeit noch nicht richtig aufgehoben. Dazu haben die Erfurter aktuell keine Funktionalität im Portfolio.

Weiterhin ist TecArt-CRMs große Vielfalt und Modularität gleichzeitig eines seiner Schwachpunkte. Das ist nicht zwangsläufig als großer Negativpunkt zu bewerten. Dennoch sollte ein Kunde für die erste Registrierung viel Zeit für den Auswahlprozess mitbringen. Darüber hinaus kann man bei dem Entscheidungsprozess, welches Modul bereits von Beginn an gewählt werden soll und welches nichts, schnell den Überblick verlieren. An dieser Stelle wird deutlich, dass eine maximale Modularität in diesem Fall nicht immer von Vorteil ist und vorgefertigte Pakete den Entscheidungsprozess vereinfachen.

Unterm Strich ist TecArt-CRM ein empfehlenswertes und gut durchdachtes CRM-System, das viel DNA und Ansätze für eine moderne Cloud Collaboration mitbringt und jedem Unternehmen dabei helfen kann, in Zukunft besser mit seinen Kunden zusammenzuarbeiten.

Kategorien
Insights

Sicherheitsvergleich: TeamDrive vs. ownCloud

Dropbox polarisiert innerhalb der IT-Abteilungen. Vom Vorstand bis hin zum normalen Mitarbeiter greifen viele auf den beliebten Cloud-Storage Service zurück. Das liegt vor allem an der einfachen Nutzung, die von den internen IT-Abteilungen heute nicht so unkompliziert bereitgestellt wird. Hier greifen insbesondere zwei aus Deutschland heraus entwickelte Lösungen an, die es Unternehmen erlauben, eigene Dropbox ähnliche Funktionen innerhalb einer selbstverwalteten IT-Infrastruktur zu implementieren, TeamDrive und ownCloud. TeamDrive vertritt dabei einen vollständig kommerziellen und proprietären, ownCloud hingegen einen vermeintlichen Open-Source Ansatz, dem aber ebenfalls eine kommerzielle Version zu Grunde liegt. Beide beanspruchen für sich den Titel „Dropbox für Unternehmen“. Bewegen wir uns allerdings genau in diesem Umfeld, spielt das Thema Sicherheit eine sehr wichtige Rolle.

Hintergrund zu TeamDrive und ownCloud

TeamDrive und ownCloud verfolgen zwei unterschiedliche Geschäftsmodelle. Wo sich TeamDrive als vollständig kommerzielles Produkt für Unternehmen am Markt positioniert, setzt ownCloud auf die Open-Source Community, um damit Marktanteile zu gewinnen. Mit einer kommerziellen Version adressiert ownCloud allerdings auch den Markt für professionelle Unternehmenslösungen.

Über TeamDrive

TeamDrive ist eine Filesharing und Synchronisations-Lösung für Unternehmen, die ihre sensiblen Daten nicht bei externen Cloud-Services speichern wollen und es ihren Teams zudem ermöglichen möchten, Daten oder Dokumente zu synchronisieren. Dazu überwacht TeamDrive beliebige Ordner auf einem PC oder Notebook, die man mit eingeladenen Anwendern gemeinsam nutzen und bearbeiten kann. Damit stehen Daten jederzeit, auch offline zur Verfügung. Eine automatische Synchronisation, Backups und Versionierung von Dokumenten schützen die Anwender vor Datenverlust. Mit der Möglichkeit die TeamDrive Registration- und Hosting-Server im eigenen Rechenzentrum zu betreiben, lässt sich TeamDrive in vorhandene IT-Infrastrukturen integrieren. Dafür stehen alle notwendigen APIs zur Verfügung.

Über ownCloud

ownCloud ist eine Open-Source Filesync- und –sharing-Lösung für Unternehmen und Organisationen, die ihre Daten weiterhin selbst unter Kontrolle behalten möchten und nicht auf externe Cloud-Storages zurückgreifen wollen. Der Kern der Anwendung besteht aus dem ownCloud Server über welchen sich die Software zusammen mit den ownCloud-Clients nahtlos in die existierende IT-Infrastruktur integriert und die Weiternutzung bereits vorhandener IT-Management-Tools ermöglicht. ownCloud dient als lokales Verzeichnis, bei dem unterschiedliche lokale Speicher gemountet werden. Dadurch stehen die entsprechenden Dateien allen Mitarbeitern auf allen Geräten zur Verfügung. Neben einem lokalen Storage können ebenfalls Verzeichnisse über NFS und CIFS angebunden werden.

TeamDrive und ownCloud: Die Sicherheitsarchitektur

In diesem Vergleich soll es um die Sicherheitsarchitektur hinter TeamDrive und ownCloud gehen. Der sonstige Funktionsumfang der beiden Lösungen wird nicht betrachtet. Es geht also um die Betrachtung der Verschlüsselungsverfahren, Datenhaltung, Datenverarbeitung und der Benutzerautorisierung, soweit Informationen zur Verfügung stehen. Dabei wird davon ausgegangen, dass grundlegende Kenntnisse zum Thema Sicherheit bekannt sind.

TeamDrive: End-to-End Verschlüsselung

TeamDrive ist trotz seines kommerziellen Ansatzes recht auskunftsfreudig und stellt einige Sicherheitsinformationen öffentlich zur Verfügung. Darunter zu dem Thema Verschlüsselung. Zudem wird mit dem Datenschutzsiegel des „Unabhängigen Landeszentrum für Datenschutz Schleswig-Holstein (ULD)“ geworben. Nach einer Anfrage wurden bereitwillig umfangreiche Informationen zur Verfügung gestellt, wobei einige jedoch einem NDA (Non-Disclosure Agreement) unterliegen.

Verschlüsselungsverfahren

TeamDrive setzt auf die folgenden Verschlüsselungsmechanismen:

  • Advanced Encryption Standard – AES 256
    Zur Verschlüsselung der Daten setzt TeamDrive auf das Advanced Encryption Standard (AES) Kryptosystem mit einem 256 Bit Schlüssel und verwendet die C Code Implementation der OpenSSL library.
  • Diffie-Hellman und RSA 3072
    Für den Schlüsselaustausch setzt TeamDrive bei seinen älteren Clients auf den Diffie-Hellman Algorithmus. Neue Clients hingegen verwenden RSA 3072. Die Diffie-Hellman Implementierung basiert dabei auf der C Code Implementation wie sie von der OpenSSL library zur Verfügung gestellt wird.
  • Message Digest 5/6 – MD5/MD6
    Der TeamDrive Hash-Funktionalität liegt der MD5 bzw. MD6 Algorithmus zu Grunde, wobei der Hashwert mit einer zufällig gewählten Zeichenfolge (Salt) gespeichert wird.
  • PrimeBase Privacy Guard – PBPG
    Der PrimeBase Privacy Guard (PBPG) ist ein proprietäres Public/Privat Schlüsselsystem, das auf dem Diffie-Hellman Schlüsselaustausch und der AES Verschlüsselung aufsetzt. Das Verhalten von PBPG für den Anwender gleicht dem bekannten Public/Privat Schlüsselsystemen von PGP oder GnuPG. Die PBPG-Verschlüsselung generiert zufällige Änderungen und verifiziert die Dateien während des Austauschs, damit PBPG erkennen kann, ob eine Nachricht oder ein Schlüssel manipuliert oder anderweitig verändert worden sind. Zwei Nachrichten sind dabei niemals gleich. Dabei wird nicht nur für jeden Benutzer ein Schlüsselpaar erzeugt, sondern ebenfalls für jede Installation. Die PBPG Implementierung ist offen und kann bei Bedarf von Partnern und anderen Interessierten überprüft werden.

Systemarchitektur

Daten werden bei TeamDrive in einem sogenannten Space gespeichert, auf dem eine festgelegte Anzahl von Nutzern Zugriff erhalten kann. Der Austausch findet über ein Space Depot statt, welches auf einem TeamDrive Hosting Server oder WebDAV liegen kann.

Jeder Space verfügt über seinen eigenen 256 Bit AES Schlüssel, der für die Verschlüsselung der Daten in diesem Space genutzt wird, wenn die Daten das Endgerät des Nutzers verlassen. Dabei hat nur die TeamDrive Software, welche auf dem Endgerät der anderen Nutzer eines Spaces installiert ist, Kenntnisse über den Schlüssel.

Jeder Server auf dem ein Space Depot zur Verfügung steht, ist für das Speichern, Weiterleiten und Anpassen von Veränderungen innerhalb des Depots verantwortlich. Damit können die Clients auch dann Daten austauschen, wenn nicht alle zur selben Zeit online sind. Alle Daten, die auf dem Server gespeichert sind, werden mit einem 256 Bit AES Schlüssel des Spaces verschlüsselt.

Benutzerautorisierung

Die Anmeldung eines Nutzers erfolgt über die TeamDrive Client-Software, die ihn gegen den TeamDrive Registrierungsserver überprüft. Das erfolgt grundsätzlich über die Eingabe einer E-Mail Adresse oder eines Benutzernamens und eines Passworts.

Die Autorisierung zwischen dem TeamDrive Client und dem Registrierungsserver erfolgt auf Basis des Public Key des Registrierungsserver. Informationen wie die E-Mail-Adresse und das Registrierungspasswort plus weitere Daten des Benutzers werden unter der Verwendung des Public Key des Registrierungsservers verschlüsselt an den Registrierungsservers übertragen.

Einzig der Aktivierungscode wird unverschlüsselt über eine ebenfalls unverschlüsselte E-Mail an den Nutzer verschickt. Zudem wird eine verschlüsselte Antwort mit der Device ID an den TeamDrive Client gesendet. Nach der Aktivierung durch den Nutzer generiert die Client-Software einen PBPG Key und einen passenden Public Key. Im Anschluss schickt die Client-Software das Registrierungspasswort und den Public Key verschlüsselt, unter Verwendung des Public Keys des Servers, an den Registrierungsserver zurück. Der Aktivierungscode wird verifiziert und der Public Key des Nutzers gespeichert. Alle im Anschluss folgenden Nachrichten, die an den Registrierungsserver geschickt werden, sind mit dem PBPG Public Key des Nutzers verschlüsselt und benötigen die Geräte-ID und das Registrierungspasswort zur Autorisierung.

Datenhaltung und Verarbeitung

Zum Erzeugen eines Space, benötigt der Benutzer ein Space Depot und dessen Passwort. Damit weiß der TeamDrive-Client, mit welchem Server er Kontakt aufnehmen muss, um den Space zu erzeugen. Anschließend fordert die Client-Software den Public Key des TeamDrive Hosting Servers an. Die Client Software sendet die Geräte-ID, die Space Depot ID, Benutzername, Benutzer-ID, den Public Key des Benutzers und den Namen des Spaces als verschlüsselte Nachricht an den TeamDrive Server. Die Nachricht wird mit dem Public Key des Servers verschlüsselt übertragen. Die Space Depot ID und das Passwort werden überprüft. Für die verschlüsselte Übertragung der Antwort wird der Public Key des Benutzers verwendet. Der TeamDrive Server erstellt einen neuen Space auf dem vorgegebenen Space Depot. Ein 128 Bit „Genehmigungscode“ wird zufällig für den neuen Space erzeugt und an den Client zurückgesendet.

Für den Zugriff auf einen Space wird die entsprechende URL, ein Autorisierungscode und ein Space Datenschlüssel benötigt. In der URL ist die Adresse des Servers, über die das Space Depot mit dem Inhalt des Spaces angesprochen wird, sowie die Space ID, enthalten. Veränderungen in dem Space werden auf das Space Depot und in den Space hochgeladen bzw. heruntergeladen. Dabei werden HTTP PUT und POST Methoden verwendet. Bevor eine Datei den Client verlässt, wird diese komprimiert und mit dem 256-Bit AES Schlüssel verschlüsselt.

Um auf einen Space zuzugreifen, öffnet der TeamDrive Client eine Session mit dem Server. Darin wird zunächst die ID des Space, auf den der Zugriff stattfinden soll, übertragen. Der Server erzeugt nach erfolgreicher Prüfung eine neue Session ID mit einer 128-Bit Zufallszahl (RND) und sendet diese an den Client zurück, der hier lokal abgelegt wird. Für das Hochladen und Löschen von Daten verwendet der Client die RND und den Autorisierungscode des Space und verknüpft diese xor inkl. einer MD5 Operation auf dem Ergebnis. Das Ergebnis wird zusammen mit der Session ID und den verschlüsselten Daten an den Server geschickt.

Die Sicherheit eines Space Depot wird dadurch sichergestellt, dass nach jeder Anfrage ein zufälliger RND Wert zurückgesendet wird, die der Client jedes Mal für einen lokalen Wert neu berechnen muss. Zudem garantiert ein MD5 Hash, dass der Autorisierungscode des Space nicht abgeleitet werden kann. Auch dann wenn der RND und der lokale Wert auf der Client-Seite bekannt sind. Damit wird ebenfalls verhindert, dass ein Angreifer in eine Session eindringen kann, um Daten auf den Server hochzuladen.

Zusammenfassung

Die Datensicherheit in einem TeamDrive Space wird durch die Verschlüsselung der Daten mit einem 256-Bit AES Schlüssel sichergestellt. Dabei ist der Schlüssel nur den TeamDrive Clients bekannt die Mitglied eines Space sind. Anbieter von Storage-Services auf Basis von TeamDrive oder Systemadministratoren haben keinen Zugriff auf die Daten. Der Austausch der Space Autorisierungsschlüssel unter TeamDrive Nutzern erfolgt mit einem sicheren Public/Privat-Key Verfahren, welches selbst eine 256-Bit AES Verschlüsselung verwendet. Der Zugriff auf ein Space Depot bzw. einem Space wird mit einem 128-Bit Autorisierungscode geschützt. Mit dem Autorisierungscode wird verhindert, dass der Speicherplatz eines Space Depot bzw. eines Space von unautorisierten Dritten verwendet werden kann.

Neben der verschlüsselten Speicherung der Daten auf den Servern und den Clients, werden die Daten ebenfalls während der Übertragung immer komplett verschlüsselt, wodurch TeamDrive eine vollständige End-to-End Verschlüsselung der Daten gewährleistet.

Weiterhin ist zu erwähnen, dass TeamDrive von dem „Unabhängigen Landeszentrum für Datenschutz in Schleswig Holstein (ULD)“ das Datenschutzgütesiegel erhalten hat. Die Prüfnummer lautet 2-3/2005. Darüber hinaus wurde TeamDrive im Mai 2013 von Gartner zum „Cool Vendor in Privacy“ 2013 benannt.

ownCloud: Serverseitige Verschlüsselung

Bei ownCloud sucht man vergeblich nach öffentlichen Sicherheitsinformationen, die von ownCloud selbst zur Verfügung gestellt werden. Das verwundert ein wenig, da selbst in der ownCloud Community scheinbar viele offene Fragen [1], [2] hinsichtlich der Serverseitigen Verschlüsselung und der Verschlüsselung im Allgemeinen bestehen. Einzig ein Blog-Beitrag ist zu finden, in dem das grundsätzliche Verständnis von ownCloud zum Thema Sicherheit öffentlich dargestellt wird. Auf direkte Nachfrage bei ownCloud wurden jedoch anstandslos Fragen beantwortet und weitere Informationen zur Verfügung gestellt.

Verschlüsselungsverfahren

Für die Verschlüsselung der Daten setzt ownCloud 5.0 auf den Advanced Encryption Standard (AES) mit einem 256 Bit Schlüssel.

Der Sicherheitsblogger Pascal Junod hatte sich Anfang 2012 mit der Verschlüsselung von ownCloud 4.0 auseinandergesetzt. Die notwendigen Informationen sind in der OC_Crypt class zu finden. Junod hat in diesem Zusammenhang diese PHP Datei analysiert und entsprechende Informationen veröffentlicht. Demnach wird der Schlüssel in der mt_rand() PHP Routine generiert. Die den Mersenne Twister, einen Pseudozufallszahlengenerator, implementiert. Junod kommentiert, das es sich dabei nicht um eine kryptographisch gute Qualität handelt. Der generierte Schlüssel wird mit dem Benutzerpasswort in Verbindung mit dem symmetrischen Blockverschlüsselungsalgorithmus Blowfish im ECB Mode verschlüsselt und anschließend in der encryption.key gespeichert. Junod kommt zu der Schlussfolgerung, dass ein Angreifer im Besitz dieser Datei über die Brute-Force-Methode an das Passwort gelangen könnte. Er macht zudem darauf aufmerksam, dass dieser Schlüssel für die Verschlüsselung sämtlicher Daten eines Nutzers verwendet wird und dass die Daten serverseitig verschlüsselt werden. Er beschreibt weitere Möglichkeiten, um die encryption.key zu stehlen. So wird das Passwort, welches für die Verschlüsselung der Datei zuständig ist, in Klartext (einfaches HTTP) vom Client an den Server übertragen. Wird die Verbindung nicht mit HTTPS gesichert, ist jeder in der Lage die Kommunikation abzuhören und das Passwort zu stehlen und könnte somit auf den ownCloud Account und sämtliche Daten zugreifen. Weiterhin wird die encryption.key im Klartext in den Sitzungsdaten auf der Serverseite gespeichert. Die meiste Zeit im /tmp Verzeichnis. Das bedeutet, dass ein böswilliger ownCloud Serveradministrator in der Lage wäre, die Daten zu entschlüsseln. Zudem weißt Junod darauf hin, dass die Verschlüsselung serverseitig vorgenommen wird, wodurch ein Systemadministrator mutwillig die ownCloud Installation manipulieren könnte. Er empfiehlt daher ownCloud 4.0 niemals einzusetzen, um vertrauliche Informationen zu speichern.

ownCloud bestätigt in der Anfrage, dass ownCloud 5.0 selbst keine vollständig integrierte End-to-End Verschlüsselung in der Software implementiert hat. Dies kann jedoch mit Tools von Drittanbietern realisiert werden. Weiterhin wird Verschlüsselung „at rest“ betrieben. Das bedeutet, dass die Daten physikalisch in verschlüsselter Form gespeichert werden. Die Verbindung zwischen den Endgeräten und dem Server wird mit SSL gesichert. Der Schlüsselaustausch erfolgt autorisiert über die Provisioning API. Ein umfangreiches Schlüsselmanagement soll in Zukunft folgen.

Systemarchitektur

ownCloud verfügt über ein Plugin für die serverseitige Verschlüsselung, mit der Administratoren die Daten verschlüsselt auf dem Server ablegen können. Nutzer erhalten Zugriff auf die Daten und können diese teilen, als seien sie unverschlüsselt. Das neue Plugin in ownCloud 5.0 ersetzt dabei die Sicherheitslücke in ownCloud 4.0, bei der ein böswilliger Systemadministrator die Sicherheitsarchitektur umgehen konnte, indem er Anpassungen am ownCloud Quellcode vornehmen konnte, um eine Backdoor oder einen Passwort Sniffer zu integrieren. Für die Verschlüsselung der Daten während der Übertragung vom Server zum Endgerät wird SSL verwendet. Das Passwort kann von einem Nutzer jederzeit geändert werden. Sämtliche Dateien werden anschließend mit dem neuen Passwort verschlüsselt.

Für eine serverseitige Sicherheit muss der Administrator die Verschlüsselungs-App in ownCloud der ownCloud Managementkonsole aktivieren und den Hacken „Verschlüsselung“ in der Admin-Oberfläche setzen. Anschließend wird ein Schlüsselpaar (Public/ Private) für alle Nutzer erstellt. Hierzu wird das Nutzerpasswort verwendet, um den privaten Schlüssel zu schützen. Darüber hinaus wird, für jede auf den Server hochgeladene Datei, ein symmetrisches Schlüsselpaar erstellt. Die von dem Nutzer hochgeladenen Daten werden mit dem symmetrischen Schlüssel verschlüsselt und gespeichert. Als Algorithmus wird der Advanced Encryption Standard (AES 256) verwendet. Der symmetrische Schlüssel wird mit dem privaten Schlüssel des Nutzers verschlüsselt und auf dem Server abgelegt. Werden die Daten von dem Server abgerufen, werden sie zunächst entschlüsselt und anschließend über eine SSL-Verbindung an den Client gesendet. Die Verschlüsselungsroutine verhält sich mit anderen, an ownCloud angebundenen Applikationen, wie der Web-Oberfläche, der Versionierung und dem Algorithmus für die Synchronisierung, exakt gleich. Ändert ein Nutzer sein Passwort, wird sein privater Schlüssel mit dem alten Passwort entschlüsselt und mit dem neuen Passwort erneut verschlüsselt.

Für den Nutzer gleicht eine auf den ownCloud Server hochgeladene und anschließend verschlüsselte Datei wie eine nicht verschlüsselte Datei. Die Verschlüsselung ist für ihn vollständig transparent. Wird eine Datei mit einem anderen Nutzer geteilt, werden die öffentlichen Schlüssel von jedem dieser Nutzer in der verschlüsselten Datei hinterlegt. Diese Nutzer können damit auf die Datei zugreifen und Änderungen an ihr vornehmen, als handelt es sich um eine unverschlüsselte Datei. Genauso verhält es sich mit einem Ordner. Nutzer können keine Dateien öffnen, die nicht für sie bestimmt sind. Sollte ein böswilliger Nutzer versuchen, Zugriff auf das Speicher-Backend zu nehmen, werden die Dateien und Schlüssel darin unlesbar.

Ist das entsprechende Plug-In aktiviert, ist ein Systemadministrator in der Lage, über die Kommandozeile, alle Dateien zu sehen, die auf ownCloud gespeichert sind. Allerdings sind die Inhalte der Dateien verschlüsselt. Es können weiterhin normale Backups vorgenommen werden, jedoch bleiben alle Dateien verschlüsselt. Selbst dann, wenn die Daten nach außerhalb des Systems kopiert werden. Ein Administrator kann zudem weitere Einstellungen vornehmen, um bestimmte Dateigrößen und -formate von der Verschlüsselung auszuschließen.

Zusammenfassung

Mit der Version 5.0 bietet ownCloud nun auch serverseitige Verschlüsselung der Daten an. Jedoch muss von einem Administrator dazu explizit ein Plug-In aktiviert werden, um Dateien mit AES 256 zu verschlüsseln. Verlässt eine Datei den ownCloud Server wird sie zunächst entschlüsselt und über eine SSL-Verbindung an den ownCloud-Client übertragen. Das bedeutet, dass eine vollständige End-to-End Verschlüsselung derzeit mit einfachen Bordmittel nicht zur Verfügung steht, was ownCloud selbst bestätigt.

Das ownCloud Encryption-Module wurde für den Einsatz innerhalb eines Unternehmens-Rechenzentrum, auf unternehmenseigenen Servern und unter der Verwaltung von vertrauensvollen Administratoren, entwickelt.

Empfehlung für das Management: TeamDrive vs. ownCloud

Der Vergleich von TeamDrive mit ownCloud stellt gewissermaßen auch einen kommerziellen einem Open-Source Ansatz gegenüber. Was hier jedoch ein wenig irritiert ist die Offenheit des kommerziellen Anbieters TeamDrive gegenüber ownCloud. Kommerzielle Anbieter werden oftmals kritisiert, wenig über ihre Sicherheitsarchitektur zu sprechen. In diesem Fall sehen wir genau das Gegenteil. Das mag bei ownCloud möglicherweise daran liegen, dass bisher nicht viel Sicherheit respektive Verschlüsselung implementiert war, über die man sprechen konnte. Erst mit der ownCloud Version 5.0 wurde ein Modul für die serverseitige Verschlüsselung implementiert. Dass allerdings Informations- aber insbesondere Sicherheitsbedarf besteht, zeigen die Fragen aus der ownCloud Community. Hier ist die ownCloud Community auch weiterhin gefordert, mehr öffentliche Informationen und Sicherheit einzufordern.

In diesem Zusammenhang macht der Inhalt des oben angesprochenen Blog-Artikels von ownCloud Sinn, der die grundlegende Sicherheitsphilosophie von ownCloud widerspiegelt. ownCloud sieht das Thema Verschlüsselung zwar als einen wichtigen Punkt an. Der Fokus sollte aber eher auf der Kontrolle der Daten liegen.

Sicherheit vs. Flexibilität

TeamDrive setzt auf einen vollständig integrierten Ansatz und bietet zudem eine End-to-End Verschlüsselung aller Daten, die vom Server zum Client des jeweiligen Endgeräts übertragen werden. Damit ermöglicht es TeamDrive trotz eines sehr hohen Anspruchs an das unbequeme Thema Sicherheit, die bequeme Nutzung eines Cloud-Storage Service. ownCloud entschlüsselt die Daten erst wenn diese vom Server geladen werden und überträgt sie in einer SSL-Verbindung. Die fehlenden Bordmittel zur End-to-End Verschlüsselung lassen sich mit externen Lösungen von Drittanbietern erreichen. Hier sollte jedoch bedacht werden, dass die Integration damit aufwändiger wird und ob ein Open-Source Ansatz speziell in diesem Fall noch Kostenvorteile bietet.

Verschwiegen werden darf nicht, dass ownCloud auf Grund seines Open-Source Ansatzes mehr Flexibilität bietet als TeamDrive und damit vollständig den eigenen Bedürfnissen nach an die eigene IT-Infrastruktur angepasst werden kann, wenn das erforderlich ist. Hinsichtlich der Sicherheit besteht bei ownCloud allerdings noch Nachholbedarf. Das hat zur Folge, dass die Lösung per se nicht den aktuellen Sicherheitsansprüchen von Unternehmen entspricht und daher nur bedingt zu empfehlen ist.

Am Ende muss die Entscheidung getroffen werden, ob ein Unternehmen einen kommerziellen und integrierten Ansatz inklusive Sicherheitsmechanismen anhand von Bordmittel erwartet oder eine Open-Source Software, für die weitere externe Sicherheitslösungen benötigt werden, die selbst zu integrieren sind. Wer eine All-in-One Lösung inklusive vollständiger End-to-End Verschlüsselung und damit gleichzeitig mehr Sicherheit sucht, sollte sich für TeamDrive entscheiden.

Kategorien
Insights

INSIGHTS: expressFlow – Automatisierte Prozessabläufe in der Cloud

Als Prototyp während einer Doktorarbeit an der TU Wien zum automatisierten modellieren vollständiger Workflows entwickelt, konzentriert sich das österreichische Startup expressFlow nun auf die Verarbeitung von Dateien. Dabei geht es nicht nur um das einfache Speichern und wieder Aufrufen, sondern ebenfalls um den Lebenszyklus einer Datei und ihrem Beitrag innerhalb eines Gesamtprozesses.

INSIGHTS: expressFlow - Automatisierte Prozessabläufe in der Cloud

Die expressFlow Umgebung

expressFlow existiert in seiner Form bereits seit 2009 und entwickelt sich gebootstrapped stetig voran. Dazu setzt das Unternehmen vollständig auf das Google Ökosystem und lässt die expressFlow Umgebung auf Googles Platform-as-a-Service Google App Engine laufen. Zielgruppe sind affine Cloud-Nutzer beziehungsweise ungefähr 20 Prozent der Dropbox-Nutzer.

Das Automatisierungstool wird schrittweise entwickelt und befindet sich derzeit in der ersten Entwicklungsstufe. Damit lassen sich Dateien über eine auf HTML-5 basierende Webseite hochladen. Im Anschluß erfolgt eine automatische AES-Verschlüsselung der Daten und Dokumente. Danach wird der Speicherort der Daten ausgewählt. Da expressFlow auf die Google Infrastruktur setzt, ist der primär unterstützte Speicher Google Drive. Ebenso kann aber auch Dropbox gewählt werden. expressFlow lässt sich am besten als eine Middleware für die Verwaltung und Bearbeitung von Dateien verstehen. So speichert die Plattform keine Daten permanent, sondern nur temporär, wenn an den Dokumenten gearbeitet wird. expressFlow verschlüsselt die Daten und transferiert diese auf den selbst ausgewählten Cloud Storage. Wird eine Datei geöffnet, wird sie temporär auf expressFlow zwischengespeichert, entschlüsselt und kann anschließend weiterverarbeitet werden.

In der zweiten Entwicklungsstufe soll es möglich sein, Dokumente aus einem Cloud Storage direkt zu starten. Dies soll mit einer App aus dem Google Chrome Webstore erfolgen.

INSIGHTS


In seinen ersten Ausbaustufen hilft expressFlow beim Hochladen und automatischen Verschlüsseln von Dateien zu einem selbst ausgewählten Cloud Storage Service. Der Weg zu einem automatisierten Workflow-Tool ist noch weit. Jedoch steckt in expressFlow viel Potential, wenn man bedenkt welche Möglichkeiten mit dem plattformunabhängigen Service abgebildet werden können.

So könnten sich vollständige Arbeits- und Prozessabläufe innerhalb von expressFlow abbilden lassen, indem ein Mitarbeiter A eine Datei hochlädt, Freigaben für Kollegen erteilt und Mitarbeiter B informiert beziehungsweise automatisch informieren lässt, dass dieser daran weiterarbeiten soll. Ein weiteres Szenario könnte darin bestehen, Daten über expressFlow in die Amazon Cloud hochzuladen und automatisch per MapReduce verarbeiten zu lassen.

Ein ebenfalls interessanter Ansatz, der sich in Richtung Hochverfügbarkeit beziehungsweise Multi-Vendor-Strategie bewegt, ist, die Daten anhand von expressFlow über mehrere Cloud Storage Services hinweg verteilen zu lassen. Damit würde derselbe Datenbestand synchron über mehrere voneinander unabhängige Infrastrukturen repliziert. Kann eine Datei aus Cloud Storage A nicht aufgerufen werden, da der Anbieter gerade ein Problem hat, wird diese Datei dann von dem Cloud Storage B geladen.

Download

Der INSIGHTS Bericht kann ebenfalls unter „expressFlow: Automatisierte Prozessabläufe in der Cloud“ betrachtet und als PDF heruntergeladen werden.

INSIGHTS analysiert und kommentiert aktuelle Meldungen und Ereignisse von Anbietern. Sie sind auch an der Publikation von INSIGHTS Berichten interessiert, dann finden Sie hier weitere Informationen.

Kategorien
Insights

INSIGHTS: fortrabbit veröffentlicht PaaS für PHP-Profis

Mit fortrabbit startet der zweite Platform-as-a-Service (PaaS) aus Deutschland, genauer aus Berlin. Die drei Gründer kommen aus der PHP Szene und konzentrieren sich mit ihrem Angebot auf professionelle beziehungsweise fortgeschrittene PHP Entwickler. Auf Grund der eigenen Expertise ermöglichen sie Profi PHP-Entwicklern mehr Freiheiten im Umgang mit der Programmiersprache. Zu erwähnen ist, dass fortrabbit vollständig mit privaten Mitteln (bootstrapped) geründet wurde, ohne die Hilfe von Venture Capital.

INSIGHTS: cloudControl wird zum multi-language Platform-as-a-Service

Die fortrabbit Plattform

fortrabbit selbst gibt es schon seit ein paar Jahren. Eine erste Version des selbst entwickelten PaaS lief in einer ersten Version auf eigenen Servern in einem Berliner Rechenzentrum. Um das Angebot für die Masse zu skalieren, erfolgte der Wechsel auf die Infrastruktur der Amazon Web Services (AWS), genauer in die Region Irland. Wobei die benötigten Instanzen und der Storage auf zwei Availibilty Zones verteilt ist. Für den Wechsel auf AWS wurde die PaaS-Software vollständig neu geschrieben und den Bedingungen auf der Amazon Infrastruktur angepasst.

Zielkunden von fortrabbit sind in erster Linie fortgeschrittene PHP-Entwickler, die sich bereits gut auskennen und mehr Freiheiten beim Umgang mit der Programmiersprache benötigen. Als Zielmarkt wurde zunächst Europa festgelegt, wobei eine Expansion, genau wie ein eigenes Partnernetzwerk nicht ausgeschlossen sind.

PHP Renaissance

Die eigene PHP-Expertise, aber auch die eigenen Anforderungen an einen Profi-PHP PaaS, haben fortrabbit dazu bewegt, den Entwicklern mehr Freiheiten auf ihrer Plattform zu geben. Dazu bietet der auf PHP 5.4 und LAMP basierende PaaS eine tiefere Unterstützung, die andere PaaS-Angebote in dieser Form nicht ermöglichen. Dazu gehören Funktionen wie einen beschreibbaren Speicher (native writeable storage), SFTP, Domain-Routing, SSL, SSH-Zugriff (keine Root-Rechte aber u.a. wget und Zugriff auf Error Logs) und Monitoring-Funktionen (Status der Applikation, PHP-Requests, Cache Hits, Miss, inkl. graphischer Darstellung). Hinzu kommt mit dem Composer ein Package Management für PHP, das dafür sorgt, das sämtliche Abhängigkeiten (Dependency Manager) serverseitig erfüllt werden.

INSIGHTS


Im ersten Moment ist die Frage gerechtfertigt ob der Markt noch einen weiteren PaaS benötigt. Mit der Google App Engine, AppFog, Cloud Foundry, Heroku, Engine Yard, OpenShift, Stackato, Windows Azure oder auch cloudControl existieren bereits viele, mittlerweile etablierte PaaS. Dennoch müssen hier zwei Dinge beachtet werden. PaaS hat das schnellste Wachstum von allen Services in der Cloud. Alleine für den Bereich der reinen Anwendungsentwicklung, in dem sich fortrabbit bewegt, sind jährliche Wachstumsraten von 22% zu erwarten. Darüber hinaus hat fortrabbit ein sehr spezielles Angebot, was sich auf eine bestimmte Zielgruppe fokussiert. Wo andere PaaS-Anbieter sich zu einem Polyglot entwickeln, also mehrere Programmiersprachen parallel unterstützen, konzentriert sich fortrabbit auf seine eigenen Stärken und diese liegen im Bereich PHP.

Der Service adressiert fortgeschrittene beziehungsweise professionelle PHP-Entwickler, die mehr Freiheiten bei der Konfiguration ihrer Umgebung benötigen. Hier wird die eigene PHP-Erfahrung fortrabbit einen Vorteil gegenüber anderen PaaS bieten, um den Service mit weiteren Mehrwerten auszubauen.

Download

Der INSIGHTS Bericht kann ebenfalls unter „fortrabbit veröffentlicht PaaS für PHP-Profis“ betrachtet und als PDF heruntergeladen werden.

INSIGHTS analysiert und kommentiert aktuelle Meldungen und Ereignisse von Anbietern. Sie sind auch an der Publikation von INSIGHTS Berichten interessiert, dann finden Sie hier weitere Informationen.

Kategorien
Insights

INSIGHTS: cloudControl wird zum multi-language Platform-as-a-Service

Das Berliner Platform-as-a-Service (PaaS) Startup cloudControl hat damit begonnen seine Entwicklungsplattform für PHP Applikationen um weitere Sprachen wie Java, Python und Ruby zu erweitern. Mit ihrem neuen „Pinky Stack“, der sich derzeit noch im Betastatus befindet, will das Unternehmen seinen Nutzern die Freiheit geben, sowohl Public als auch Private PaaS ohne Vendor lock-in zu nutzen.

INSIGHTS: cloudControl wird zum multi-language Platform-as-a-Service

Der Pinky Stack

Mit dem Pinky Stack bietet cloudControl Entwicklern nun ein breiteres Portfolio an Programmiersprachen und entwickelt sich damit zu einer Polyglot Plattform. Auf Basis von Buildpacks stehen nun Sprachen wie Java, PHP, Python und Ruby zur Verfügung, wobei das Startup seine Plattform in Zukunft um weitere Sprachen erweitern will.

Die Buildpack API

Der PaaS Markt ist stark fragmentiert, was dazu führt, dass eine Vielzahl an offen APIs existieren. Dabei unterstützt ein Anbieter in der Regel auch nur eine einzige Schnittstelle. Die Folge ist ein zunehmendes Vendor lock-in Risiko im PaaS Bereich. Eine Lösung sind die sogenannten Buildpack APIs. Diese wurden ursprünglich von Heroku entwickelt und als Open-Source veröffentlicht. Bei Buildpacks handelt es sich um eine offene API, die beschreibt, wie man verschiedene Sprachen und Frameworks für das Deployment vorbereitet. cloudControl hat sich als erster PaaS Anbieter aus Europa dafür entschieden, den Buildpack Standard zu unterstützen. Unternehmen und Entwickler erhalten dadurch die Möglichkeit ihre Anwendungen sowohl auf Public PaaS wie Heroku oder cloudControl als auch auf Stackato basierten Private PaaS Platformen zu betreiben.

INSIGHTS


cloudControl entwickelt sich mit dem Release des Pinky Stacks von einem reinen PHP Platform-as-a-Service zu einem Polyglot PaaS mit einer attraktiven Sprachunterstützung. Insbesondere die Adaption von Java ist ein richtiger Schritt in Richtung Enterprise-PaaS. Wo sich Web-Entwickler verstärkt auf PHP, Ruby oder Python konzentrieren, haben Unternehmensentwickler andere Anforderungen. Zudem ist Java weiterhin die bevorzugte Sprache im Unternehmensumfeld.

Die Unterstützung der Buildpack API ist ein sehr gut Schritt in Richtung eines offenen Platform-as-a-Service. Unternehmen und Entwickler bekommen damit die Freiheit ihren Programmcode dort zu hosten, wo es notwendig ist, beziehungsweise wo es die Regularien und Unternehmensrichtlinien es erlauben.

Download

Der INSIGHTS Bericht kann ebenfalls unter „cloudControl wird zum multi-language Platform-as-a-Service“ betrachtet und als PDF heruntergeladen werden.

INSIGHTS analysiert und kommentiert aktuelle Meldungen und Ereignisse von Anbietern. Sie sind auch an der Publikation von INSIGHTS Berichten interessiert, dann finden Sie hier weitere Informationen.