• Ab wann ist eine Anwendung als SaaS zu klassifizieren?  und
• Wo grenze ich SaaS von normaler Software und normalen Webseiten ab?

Manchmal ist es nicht direkt ersichtlich, welche Anwendung wirklich SaaS ist und welche nicht. Zweifellos kann man Gmail als SaaS bezeichnen. Aber sind Twitter und Spiegel Online auch SaaS Anwendungen? Immerhin liefern sie eine Informationsdienstleistung und bestehen aus Code…

Wir wollen hier mal ein paar Punkte darlegen, nach welchen wir SaaS abgrenzen. Wichtig ist zu beachten, dass man sowohl gegenüber normaler Desktop Software als auch gegenüber sonstigen Webseiten abgrenzen kann.

1. Die Software muss web-basiert laufen können

Eins der eindeutigsten und unbestritensten Merkmale von SaaS ist, dass die Software nicht mehr auf dem Heimrechner installiert werden muss. Das bedeutet, dass sie unabhängig von Browser und Betriebssystem laufen muss und über das Internet von überall erreichbar sein sollte. Addons oder Tools die installiert werden können, um die Nutzung zu erleichtern, dürfen durchaus vorhanden sein (z.B. Gmail + Gmail Notifier)

2. Der Softwareanteil der Anwendung muss überwiegen

Um “normale” Webseiten von SaaS Lösungen zu unterscheiden, muss man vor allem beachten, worauf der Schwerpunkt der Webanwendung liegt. Ist der Inhalt der Schwerpunkt (wie bei Twitter.com), tendiert es zu nicht-SaaS. Ist jedoch die Software der Schwerpunkt (wie bei CoTweet durch nützliche Sonderfunktionen) ist die Software eher als SaaS zu klassifizieren. Hierzu kann man sich vortrefflich streiten. Die Grundfrage sollte jedoch immer sein “Nutze ich es wegen dem Inhalt oder den Funktionen der Software?”

3. Mieten und Abrechnung nach dem tatsächlichen Verbrauch anstatt Kauf

SaaS Software sollte mietfähig und nach dem tatsächlichen Verbrauch abrechenbar sein. Der Service-Grundgedanke ist hier der Kern der Diskussion. Anschaffungskosten sollten vermieden werden.

4. Skalierbarkeit und on-demand Erweiterbarkeit

Eine gute SaaS Anwendung sollte skalierbar sein. Dies verbindet die Punkte 1 und 3. Da sich Unternehmen nicht mehr selbst um die Infrastruktur und den Kauf der Software kümmern müssen sollte der Anbieter eine stufenlose Skalierbarkeit ermöglichen, um jedem Unternehmen die benötigte Flexibilität einzuräumen.

5. Datenspeicherung, Datensicherheit und Online-collaboration

SaaS Anbieter sollten dafür Sorgen, dass deren Nutzer sich nicht selbst um die Datensicherung der Anwendungen kümmern müssen. Diese sollten vom SaaS Anbieter sicher und redundant gespeichert werden. Damit einhergehend sollte die Software optimalerweise auch regeln, dass Mitarbeiter gemeinsam an Dateien arbeiten können – am Besten sogar in Realtime und an einem Dokument (z.B. Google Docs).

Bildnachweiss: cc by sa paul_houle

Bis auf die Sache mit der Ressourcenplanung bin ich auch ganz seiner Meinung. Die Ressourcenplanung würde ich aber – wer hätte das gedacht – meinem Cloud Anbieter überlassen. Was aber natürlich nichts an der Tatsache ändert, dass ich trotzdem meine Applikation kennen muss um dementsprechend zu entscheiden ob und wie ich die Ressourcen aus der Cloud nutzen kann.

Denn eines darf man nicht vergessen, Cloud Computing ist nicht automatisch verlässlicher. Ganz im Gegenteil. Die Stärke spielt die Cloud aber dann aus, wenn man darauf vorbereitet ist. Denn wer damit rechnet, dass Instanazen ausfallen hat durch die Cloud die Möglichkeit in sehr kurzer Zeit Ersatz zu “besorgen”.

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.

Hier seine Punkte in der Übersicht, den gesamten Artikel gibts bei Wille.

• Die Datenbank entlasten.
• Was ein Cache wirklich ausmacht.
• Objekte grob Cachen.
• Flüchtigen Status nicht dauerhaft speichern.
• Die Daten möglichst nah an dem Ort speichern wo sie abgerufen werden.
• Den Zugriff auf beschränkte Ressourcen limitieren.
• Einzelne Abläufe asynchron abarbeiten.
• Zugriffe übers Netwerk minimieren.

Im Beitrag beschreibt Nati welche Hürden bei einer Anwendung wie Twitter zu bewältigen sind, welche potentiellen Lösungen es gibt und welche Lösung welche Vor- und Nachteile hat.

Dabei geht es natürlich nicht nur darum einen Twitterklon zuschreiben. Die Problematik lässt sich ohne weiteres auch auf andere Social Media Konzepte übertragen und die Lösungsansätze sind dann zumindest ähnlich. Wer also vor hat das nächste große Ding zu programmieren wird die Lesezeitinvestition für den Artikel sicher nicht bereuen.

• Schnell und klein anfangen und die richtigen Dinge messen.
• Horizontale- oder vertikale Skalierbarkeit.
• Jedes Problem hat seine eigene Lösung.
• Fazit.

Mit der Frage, wie lösen die Großen diese Probleme. Insgesamt ist der Artikel eine gute Zusammenfassung der üblichen Techniken. Für erfahrene Entwickler wird womöglich wenig neues dabei sein, trotzdem kann es nicht schaden, sich die ein oder andere Idee nochmal durch den Kopf gehen zu lassen. Oft kommt man so auf ganz neue Ideen für die eigene Software.

via Highscalability

• Cloud Storage Could Mean Fat Pipes For All
• Inside A Google Data Center
• Art of scalability (1) – Scalability principles
• HP Forgot to Put the ‘Cloud’ in MagCloud