Der Grundpreis für den Server beträgt 39,99 Euro im Monat inklusive einem Prozessorkern, ein Gigabyte RAM und 100 Gigabyte Festplattenplatz. Jeder weitere Prozessorkern, zusätzliche Gigabyte Arbeitsspeicher oder 100 GB Plattenplatz kosten jeweils fünf Euro im Monat.

Quelle: http://presse.1und1.de/

Und warum ist dies jetzt kein Cloud Computing?

• Ich binde mich mindestens 1 oder 12 Monate an eine Dienstleistung.
• Prozessorleistung, Arbeitsspeicher und Festplattenplatz können zwar täglich geändert werden,  abgerechnet wird dies aber für den ganzen Monat.
• Meine Bandbreite ist auf 100 Mbps begrenzt, dabei ist diese für Stoßzeiten z. B. für TV-Beiträge besonders wichtig!
• Cloud Computing ist mehr als nur Virtualisierung eines Images, es ist eine neue Sicht- und Denkweise.

Letztendlich bleibt es ein Virtuelle Server mit der Option Ressourcen über einen längeren Zeitraum anzupassen und dies geht schon seit einigen Jahren mit der Lösung von  der vanager GmbH, allerdings auch nur nach oben.

In einer Präsentation von Jeff Dean stellte Google jetzt aber ein System vor in dem sie von 10⁶ bis 10⁷ Server unterstützen wollen.

Mehr Infos zum System und auch ein paar Informationen zu dem Potential das in weltweiten Rechenzentren schlummert hat der Artikel dazu auf DataCenterKnowledge.

Einige Eckdaten:

• ca. 40.000 Server +/- 10.000
• 2 U Dual-Socket wahrscheinlich 8 Kern Server (Rackable S2108)
• 8 x 500GB SATA Festplatten pro Server
• Server verteilt auf 6 Availability-Zones
• 6.700 pro Zone
• 16 Server pro Rack
• 417 Racks pro Zone, 2500 insgesamt
• 200.000 m² Rechenzentren insgesamt

Beeindruckende Zahlen. Wie Randy aber schreibt, sind es teilweise Informationen die er von zuverlässiger Quelle bekommen hat. Selbstverständlich  kann er die Quellen nicht nennen, und man muss ihm deshalb glauben, dass diese zuverlässig sind. Andere Zahlen sind annahmen. Jedoch ist Randy nicht einfach nur irgendwer, sondern hat in seiner Berufslaufbahn und insbesondere als CTO bei GoGrid durchaus genug Erfahrung gesammelt, dass man ihm die zuverlässige Einschätzung zutrauen kann.

Für den Umsatz entscheidend ist aber insbesondere die Größe der Instanz, deren Beliebtheit und die Gesamtauslastung. Seine Annahme hierzu bezeichnet Randy selbst als “wild ass guess”. Demnach macht Amazon mit EC2 alleine, über 220.000.000 US-Dollar Umsatz im Jahr. Auch wenn die Zahlen nicht 100% verlässlich sein werden, sind einige der Zahlen überaus interessant und geben einen guten Einblick in das Geschäftsmodell des IaaS Platzhirsches. Alle Details gibts bei Randy selbst:

Amazon’s EC2 Generating 220M+ Annually

Update: In den Kommentaren wurden einige Korrekturen vorgeschlagen und insbesondere der Kommentar vom Rightscale CTO Thorsten verhilft den Annahmen zu mehr Glaubwürdigkeit.

via Twitter jamesurquhart

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.

Amazon, Rackspace Are Top Cloud Hosts

Auf dem Wolfram|Alpha Blog hingegen wurde ein Artikel veröffentlicht, der die Server beschreibt, die Wolfram|Alpha am Launchtag online halten sollen. Man möchte nicht dem eigenen Buzz erliegen. Cuil irgendjemand?

Hier gehts zum Post mit den Details. Wer auf Videos von Server steht bekommt hier direkt das zweite heute. Im Video handelt es sich vermutlich um die im Blogpost beschriebenen Dell Server.

Im Vergleich dazu benötigt laut Techcrunch Amazon 100.000 Server. Verglichen werden hier zwar Äpfel mit Birnen, da die Salesforce-Infrastruktur zwischen den Kunden geteilt wird, Amazon hingegen als Iaas-Anbieter gerade einzelne Teile der Hardware vermietet. Diese kann dann natürlich nicht mehr geteilt werden.

Trotzdem sind die Zahlen sehr interessant. Noch mehr interessante Zahlen hat der Artikel auf Techcrunch.

Einen etwas faden Beigeschmack hinterlassen allerdings die Aussagen, dass dies Salesforce nur möglich ist, weil man proprietäre Software einsetze. Mit Open Source Komponenten wäre dies nicht möglich, so der Artikel. Dieser Aussage gebenüber bleibe ich aber eher skeptisch und zwar so lange bis mich jemand vom Gegenteil überzeugt indem er mir 1000 Server und 55000 Kunden gibt und es mich ausprobieren lässt.

Bildquelle: Racker Hacker

Meint jedenfalls Major Hayden in seinem Racker Hacker Blog. Natürlich nicht ohne ein Augenzwinkern, aber sein Grundgedanke ist nicht falsch.

Die ersten grundsätzlichen Schritte um einen MySQL Server zu optimieren kann und sollte jeder Serveradministrator kennen und ausführen können. Genau diese Schritte sind im, mit dem Blogbeitrag veröffentlichten, Flussdiagramm zusammengefasst.

Ein Blick kann jedenfalls nicht schaden, und auch als Grundlage für einen eigenen Notfallplan oder als Ersatz in Ermangelung eines eigenen Notfallsplanes kann man sich das Ding ruhig mal an die Wand hängen.

Bildquelle: StudiVZ

Vor ein paar Wochen hab ich zum ersten mal von dem Projekt gehört und fand die Idee an sich relativ gut. Ich persönlich finde es immer sehr interessant wenn kleine und große Unternehmen Einblicke in ihre internen Strukturen gewähren.

Gerade im Bereich Technik wird es natürlich ungemein spannender, umso größer die Platformen sind. StudiVZ gehört dabei sicherlich zu den Größten Internetplattformen hier in Deutschland und deshalb können die StudiVZ Entwickler sicher einiges erzählen.

Ich bin zwar nun wahrlich kein StudiVZ Fan. Wie viele in Deutschland bin ich der Ansicht, dass man mit dem Fokus auf reine Vermarktung ohne große Innovationen und durch verschlafen einiger Trends im Bereich Social Networks (z.B. eine offene Plattform für Drittanbieterapplikationen) sich selbst keinen Gefallen getan hat. Darüber hinaus finde ich auch immernoch die Abmahnwelle gegen jedern der VZ im Namen hatte mehr als unschön.
Aber das sind alles Entscheidungen die auf anderen Ebenen in solchen Unternehmen getroffen werden. Im StudiVZ Developer Blog geht es um andere, um technische Themen. Deshalb verlinke ich an dieser Stelle gerne dorthin und freue mich auf hoffentlich tiefe und spannende technische Einblicke in die Systemadministrations- und Entwicklungsabteilung von StudiVZ. Den Anfang macht auch schon eine Besichtigung der StudiVZ Rechnerfarm im Rechenzentrum von O2/Telefonica in Gütersloh.

Hier sehe ich auch den entscheidenden Faktor, das Blog muss ein wirkliches Entwicklerblog sein. Von Entwicklern für Entwickler. Gespickt mit allerlei technischem Fachwissen, mit Tipps und Tricks und auch mit alltäglichem Klatsch und Tratsch aus der Entwicklungsabteilung. Nur so kann die gewünschte Zielgruppe, andere Entwickler, angesprochen werden.

Ich denke, ein Teil der Motivation ein solches Blog zu starten wird für StudiVZ sicherlich darin bestehen potentielle neue Mitarbeiter anzusprechen. Wenn das Blog aber zu einem reinen Marketingkanal verkommt wird dies nicht gelingen.

Man kann übersichtlich neue Musik der Künstler mit denen man innerhalb des Dienstes verbunden ist hören, man kann eigene Musik an andere senden und Soundcloud bietet zusätzlich noch einen Player um die eigene Musik in andere Seiten einzubinden und dort anhörbar zu machen. Die Versandfunktion will das versenden von großen Dateien erleichtern. Selbst ausprobiert habe ich den Dienst nicht. Bin aber auch wahrlich kein Musiker.

Warum ich jetzt über Soundcloud schreibe ist dieser Blogpost. Bei Soundcloud kam es im Zuge eines zur Behebung von Geschwindigkeitsproblemen ohnehin geplanten Serverumzuges zu einem Fehler mit den Festplatten des Datenbankservers. Dadurch ging die Seite offline und weil man sich gerade im Umzug befand blieb sie dies auch bis der Umzug abgeschlossen war. Für geschlagene zwölf Stunden.

Solche Vorfälle passieren immer wieder. Ob jetzt menschliches Versagen oder einfach Pech die Ursache dafür waren ist eigentlich nebensächlich. Fakt  ist, sowas darf nicht passieren wenn man ein Unternehmen aufbauen will.

Das Problem, die Skalierung der eigenen Plattform mit den Anforderungen ist schon tausendmal gelöst worden. Doch trotzdem muss es jedes Startup für sich selbst neu lösen. Warum? Weil die Hostingunternehmen nicht in der Lage sind funktionierende Lösungen zu schaffen um dieses Problem zu lösen.

Man ruht sich lieber auf seinen Lorbeeren aus und übertrifft sich gegenseitig mit Absenz jeglicher Innovation.