Alles was wir wollten war eine Webanwendung entwickeln. Doch unzählige Stunden verloren wir an notwendige Übel wie Sicherheitsupdates, Backups und dergleichen. Und wer kennt das nicht. Das Testsystem zerschiesst man sich hin und wieder, was zeitaufwendige Neuinstallationen nach sich zieht.

Sicher gibt es managed Server, oder die Möglichkeit einen Systemadministrator zu bezahlen. Aber selbst hier muss ich mich um das Deployment meiner Anwendung noch selbst kümmern. Trotzdem kostet der unzureichende Service viel Geld. Wer nicht gerade damit beschäftigt ist Risikokapital zu verbrennen um endlich an die Börse gehen zu können tendiert oftmals dazu in den sauren Apfel zu beissen und die Systemadministration selbst zu übernehmen. Was von der eigentlichen Arbeit abhält und damit wieder bares Geld kostet. Ein Teufelskreis.

Aber als sei das nicht schon genug muss man sich dann auch noch mit Ausfallsicherheit und Skalierbarkeit beschäftigen. Die doppelte Anzahl an Servern zwecks Ausfallsicherheit und wenn dann mal eine Lastspitze kommt reicht die Leistung vielleicht doch nicht.

• Doppelte Kosten obwohl selbst ein Server bei weitem gereicht hätte?
• Kommt doch mal die erhoffte Lastspitze ist trotzdem unsicher ob man sie überlebt?
• Flexibel skalieren?

Alles Fehlanzeige. Die langen Mindestvertragslaufzeiten und der hohe Administrationsaufwand neue Server bereitzustellen macht Skalierung zu einem tage- bzw. wochenlangen Prozess.

Wie man sieht ist das alles nicht das gelbe vom Ei. Deshalb beschlossen wir eine Lösung zu entwickeln, die hochverfügbar ist, lastabhängig skaliert und jeglichen Administrationsaufwand abnimmt, so dass man sich voll auf die zu entwickelnde Software konzentrieren kann. Ganz nebenbei soll das ganze natürlich auch bezahlbar sein.

Herausgekommen ist die cloudControl web – application – platform. Mit wenigen einfachen API Befehlen kann man die eigenen Anwendungen direkt aus jeder beliebigen IDE in das integrierte Versionskontrollsystem hochladen und dann parallel an verschiedenen Versionen arbeiten und gleichzeitig eine Liveversion laufen lassen. Die Anwendungen werden dabei auf einer Vielzahl an Nodes verteilt, was Ausfallsicherheit und Skalierbarkeit gewährleistet und trotzdem muss man nur zahlen was man tatsächlich verbraucht hat.

Wer jetzt wissen möchte was die Plattform genau bietet hat Glück. Just seit wenigen Minuten ist die cloudControl Webseite online und hält eine umfangreiche Liste der gebotenen Vorteile bereit.

Momentan (15.09.2009) stehen wir kurz vor dem Alphatest. Soweit dieser erfolgreich verläuft werden wir dann den Testerkreis erweitern und das ganze dann Betatest nennen. Wer Interesse an einem Account hat sollte das cloudControl Blog oder den Twitter Account im Auge behalten.

Über Feedback zu unserer Lösung freue ich mich in den Kommentaren hier oder auch gerne im cloudControl Blog.

Zusätzlich gibt es das ganze gegen Geld aber auch als Hosted Service. Dieser hat gerade die Beta Phase beendet. Mit Scalr kann man Serverfarmen bestehend aus EC2 Instanzen vordefinieren, bei Ausfall einer der Instanzen oder bei steigendem Ressourcenbedarf startet Scalr dann automatisch neue Instanzen.

Die für das jeweilige Projekt benötigten Instanzen kann man aus einer Liste von vorgefertigen AMIs auswählen. Diese werden dann zu einer Farm zusammengefasst und können über das Interface verwaltet werden.

Obwohl Scalr auf den ersten Blick einen starken Fokus auf das Hosting von Webapplikationen legt, wird einem leider hier nicht unter die Arme gegriffen. Die Konfiguration der Webserver Vhosts etc. müssen weiterhin von Hand übernommen werden. Ähnlich verhält es sich auch im Bezug auf die Datenbank. Im Hinblick auf Sicherheitsupdates sollte allerdings zumindest nach einem Neustart einer Instanz alles in Butter sein. Im laufenden Betrieb muss man sich hierum allerdings auch selbst kümmern.

Scalr nimmt einem damit den Mehraufwand ab, der dadurch entsteht Amazon Instanzen anstelle “gewöhnlicher” Server zu verwenden. Alles weitere bleibt, ganz wie bei dedizierten Servern weiterhin Sache des eigenen Systemadministrators.

Ein Screencast schafft einen schönen Überblick über die Funktionen und die Oberfläche.

Aus diesem Grund habe ich beschlossen hier mal meine Gedanken zu einer Cloud Hosting Plattform aufzuschreiben. Also was muss die Plattform bieten um in meinen Augen Cloud Hosting zu sein. Aber Achtung, selbstverständlich handelt es sich hierbei um meine Meinung, die man teilen kann oder nicht. Ich freue mich immer über Kommentare zum Thema.

Was ist Cloud Hosting?

Eine Hostinglösung muss meiner Meinung nach drei Grundvorraussetzungen erfüllen um sich Cloud Hosting nennen zu dürfen.

1. Sie muss Ausfallsicher sein.
2. Sie muss die Möglichkeit bieten lastabhängig zu skalieren. Sowohl nach oben, als auch nach unten.
3. Sie muss Abrechnung nach tatsächlich verbrauchter Rechenleistung bieten.

Unter Ausfallsicher verstehe ich dabei zumindest, dass es keinen single point of failure gibt. Die Lösung muss so ausgelegt sein, dass ein Ausfall einzelner Komponenten meine Erreichbarkeit nicht beeinflusst. Gleichzeitig muss sie mir die Möglichkeit bieten immer genug Ressourcen zur Verfügung zu haben um auch unerwartete Lastspitzen abzufangen. Gleichzeitig aber ohne, dass ich dauerhaft für das Vorhalten dieser Leistungsreserven zahlen muss.

Das ist aber noch nicht alles. Nach diesen drei Punkten wären auch Angebote wie Amazon EC2 Cloud Hosting. Sind sie aber in meinen Augen nicht. Cloud Hosting muss mir darüber hinaus auch jegliche Administration abnehmen. Das ist bei Amazon EC2 nicht der Fall. Ich möchte als Cloud Hosting Kunde lediglich meine Anwendung hochladen müssen und dann online sein.

Cloud Hosting ist also grundsätzlich vergleichbar mit shared- und managed Hosting. Nur eben plus Ausfallsicherheit und Skalierbarkeit und ohne die unbezwingbaren Administrationsinterfaces und dem steinzeitlichen FTP-Upload. Versionskontrolle, nur Änderungen übertragen und automatischer Rollback? Fehlanzeige bei aktuellen Hostinglösungen. Auch hier muss ein Anbieter sich ins Zeug legen, wenn er sich Cloud Hoster nennen will. Jedenfalls nach meinen Maßstäben.

Mal ehrlich, Lastspitzen sind doch total unwahrscheinlich.

Und wenn man sie hat, hat man auch das Geld sich “richtiges” Hosting zu kaufen. Diese Einstellung hört man hin und wieder und ich kann nur mit aller Entschiedenheit widersprechen.

Durch Seiten wie den Facebook Newsfeed, Friendfeed oder Twitter können sich auch kleine Blogs großen Trafficspitzen ausgesetzt sehen. Durch die Vernetzung innerhalb der sozialen Netzwerke und z.B. der Retweet-Funktion auf Twitter kann sich ein einzelner Link exponentiell verbreiten. Waren bisher nur Seiten wie Heise, Slashdot oder Techcrunch berüchtigt kleine Seiten innerhalb weniger Minuten durch eine einfache Verlinkung offline zu nehmen, so ist die Gefahr, dass dies geschieht durch die Veränderung wie sich Nachrichten im Internet verbreiten radikal gestiegen.

Je nachdem wie ambitioniert man sein Projekt oder Blog betreibt hat man dann einerseits zein Ziel, die Aufmerksamkeit Vieler, erreicht und gleichzeitig aber auch direkt wieder verloren. Offline nützen einem die schönsten Informationen, Angebote und Dienste rein garnichts.

Man mag natürlich für sich selbst entscheiden, so wichtig ist mir das nicht. Aber, zumindest ich für meinen Teil, lege Wert darauf wenn sich jemand für meine Meinung interessiert, dass diese dann auch für ihn erreichbar ist. Sonst bräuchte ich mir die Mühe diese hier aufzuschreiben nicht machen. Deshalb halte ich Lastspitzen und Ausfallsicherheit, die ja in dieser Hinsicht gewissermaßen Hand in Hand gehen, auch für Blogs und private Projekte für unverzichtbar.

Wir brauchen Cloud Hosting!

Bildquelle: cc by sa Rob Shenk

Ganz anders als San Francisco. Dort im Silicon Valley sitzt bekanntlich fast alles was Rang und Namen hat. Wo so viele Technologieunternehmen auf einem Haufen sind muss es natürlich auch Rechenzentren geben. Problem dabei nur, die Region ist eine der erdbebengefährdetsten der Welt. Es wirkt sich natürlich äusserst negativ auf die Ausfallsicherheit aus, wenn einem das ganze Rechenzentrum im Erdboben versinkt. Was also tut man?

Der Artikel auf DataCenterKnowledge fällt ein bisschen in die Kategorie, was es nicht alles gibt. Wie macht man ein komplettes Rechenzentrum Erdbebensicher? Ich jedenfalls finde soetwas immer wieder sehr beeindruckend.

Etwas anders geht Lance Ulanoff an die Sache ran. Unter dem Titel Google’s Cloud: 8 Key Questions, stellt er dabei völlig berechtigte Fragen.

Insbesondere folgende Fragen sollte sich dabei jeder, bevor er seine Daten einem Anbieter anvertraut, stellen:

• Wo sind meine Daten gespeichert?
• Was mache ich, wenn ich nicht auf meine Daten zugreifen kann?
• Wie sicher sind meine Daten?
• Sollte ich lokale Backups meiner Daten machen? (Ja immer!)
• Was passiert wenn der Anbieter den Betrieb einstellt?
• Was passiert wenn ich vergesse zu zahlen?

Interessant wäre natürlich jetzt auch gewesen, den Support der bereits am Markt agierenden Dienste zu testen und diese Fragen zu klären.

Grundsätzlich bezweifel ich aber, dass Onlinespeicher alleine die Lösung ist. Jedenfalls nicht kurzfristig, dafür wären mir die momentanen Bandbreiten der üblichen Internetverbindungen noch zu schwach auf der Brust. Vor allem im Hinblick auf den Upload. Ich persönlich sehe es eher als zusätzliche Option. Am besten mit automatischer Synchronisation auf PC, Notebook, Netbook, Smartphone, Stereoanlage und was ich sonst noch so für Geräte mit meinen Daten füttern will.

Das ganze im Optimalfall noch steuerbar, abhängig von der Art der Daten, so dass auf meiner Stereoanlage nur die Musik landet und auf dem Smartphone auch Videos, Bilder und Dokumente. Zusätzlich sollte die Software selbstständig dafür sorgen, dass immer der schnellste Syncronisationsweg genutzt wird. Also, dass die Daten direkt vom PC aufs Smartphone synchronisiert werden sobald sich diese zwei Geräte im selben Netzwerk befinden.

Das jegliche Daten während der Übertragung und der Speicherung verschlüsselt sein sollten versteht sich ebenfalls von selbst.

Synchronisation zwischen PC und Onlinespeicher gibt es ja schon. Ein Komplettpaket für alle meine Geräte und alle meine Daten ist mir aber noch nicht bekannt.

photo credit: pfala

Bildquelle: salesforce.com

Eigentlich wollte ich ja garnichts zum Salesforce.com Ausfall am 6. Januar 2009 schreiben. Durch einen Fehler bei der Speicherzuordnung fielen Server inklusive der Failoverserver aus. Das Problem wurde manuell behoben, die Salesforce.com Wolke war 38 Minuten offline.

Das Thema ist in den Medien breit getreten worden. Es gab einen Aufschrei und es wurde Salesforce.com und wo man schon dabei war Software as a service und Cloud Computing als Konzept insgesamt für gescheitert eklärt. Zum Glück gibt es auch vernünftige Stimmen, die gegen die panische Herde ankämpfen. Denn völlig vergessen hat diese dabei mal wieder, dass ein solcher Ausfall jeden der Salesforce.com Nutzer, wäre er inhouse passiert wahrscheinlich wesentlich länger als 38 Minuten beeinträchtigt hätte.

Die Milchmädchenrechnung aus dieser Formel? Das System ist offensichtlich nicht perfekt. Es muss natürlich weiter verbessert werden. Aber vielleicht ist es trotzdem schon besser als die Alternativen.

Auf den ersten Blick scheint die Rechnung natürlich aufzugehen. Aber auf den zweiten Blick muss man sich dann fragen, wer soll die ganze Hardware denn administrieren. Denn Serveradministration ist sehr zeitaufwendig. In den meisten Startups bleibt diese Administrationsarbeit dann aber an genau den Entwicklern hängen, deren Zeit eben als zu teuer bewertet wurde. Was hat man also gewonnen? Genau, nichts!

Echte Systemadministratoren, und vor allem auch gute, einzustellen ist aber ebenfalls teuer. Oftmals fällt die Entscheidung dann zumindest in den Anfangsphasen doch lieber auf noch nen Entwickler und die Systemadministration muss nebenher laufen. Wie riskant es ist Sicherheitsupdates und Backups zu vernachlässigen muss ich hier hoffentlich niemandem erzählen.

Mit mehr Hardware steigen aber auch die Probleme die zu bewältigen sind. Web- und Cachingservern sagt man eine fast lineare Skalierung nach. Bei Datenbankservern sieht das ganz anders aus. Sharding verkompliziert Backup und Redundanzanforderungen und Replikation erhöht die Applikationskomplexität enorm.

Hardware an sich ist wirklich nicht teuer. Die Administration derselben aber zeitaufwendig und damit alles andere als günstig. Für jeden dessen Fokus nicht primär die Systemadministration ist, sondern das eigene Produkt oder Projekt kann ein Dienstleister die bessere Wahl sein. Ganz nebenbei kann geteilte Rechenleistung wie ich sie im vorherigen Post beschrieben habe nochmals die Kosten senken. Die Leistungsreserven moderner Hardware reizt man oft nicht aus. Ausfallsicherheitsanforderungen erhöhren das Problem noch und es steht noch mehr Hardware ungenutzt in der Gegend rum und muss bezahlt werden.

Dabei zeigt sich recht deutlich, dass der Administrationsaufwand noch viel mehr als die Kosten gerade für Startups ein Problem darstellen. Hier können Cloud Computing Dienste die Lösung sein. Allerdings muss dabei sichergestellt sein, dass erstens die Anwendung nicht speziell für den einen Dienst entwickelt werden muss, damit jederzeit der Wechsel zu einem anderen Anbieter oder auf eigene Infrastruktur möglich ist und zweitens neben der Qualität des Dienstes vor allem auch die Sicherheit stimmen muss.

Morgen gehts dann vielleicht noch mal speziell um Cloud Computing. Das wird sicher spannend und ich werde natürlich dabei sein und dann selbstverständlich auch an dieser Stelle davon berichten.