Besonders hervorheben möchte ich dabei folgenden Punkt: Man benötigt eine idiotensicheres Deployment. Denn man kann nicht 10 mal am Tag oder noch öfter deployen wenn man jedesmal danach offline ist. Das ist nicht agil, dass ist besheuert.

Die zwei haben dabei natürlich gut reden. Viele Entwickler und Startups haben kein extra Team für sowas und müssen das ganze nebenher entwickeln und administrieren. Da ist oftmals die Frage neues Feature oder automatisierter Deployprozess und die Antwort fällt fast immer auf das neue Feature. Der Deployprozess mag noch so schön sein, interessiert aber keinen der User auch nur die Bohne.

Wir hoffen, dass wir dieses Problem mit unserer Cloud Hosting Lösung aus der Welt schaffen können. Wir haben den One-Button Deployprozess nämlich Serienmässig.

Genug Eigenwerbung, hier ist das Video:

Ebenfalls interessant in dem Zusammenhang ist ein weiter Artikel auf DataCenterKnowledge. Dort kommen die großen Rechenzentrumsbetreiber zum Schluss, Optimierung ist der Schwierige Teil und das größte Problem ist immernoch menschliches Versagen.

via DataCenterKnowledge

Ein ausführlicher Vergleich der beiden Frameworks Django und Rails aus Entwicklersicht ist jetzt auf dem Blog von James Smith erschienen. Der Vergleich ist lesenswert und bietet die Möglichkeit aus James Erfahrungen zu lernen. Der Titel – A Django Developer’s Views on Rails – macht auch gleich die Perspektive deutlich. Darüber hinaus bieten auch die Kommentare bereits weitere interessante Anmerkungen zum Thema.

via @diefenbach

Auch die Anzahl der AWS Entwickler stieg von 370.000 im April 2008 auf 490.000. Beeindruckende Zahlen.

In der Präsentation geht Henry ausserdem darauf ein, welche Desingprinzipien Amazon S3 zu Grunde liegen. Mehr Hintergründe zur Präsentation und die Folien hat James Hamilton auf seinem Blog gesammelt.

via Data Center Knowledge

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.

Wie sich das für ein Techieblog gehört, beginne ich natürlich bei 0 zu zählen.

Was Programmierer über Caching wissen sollten (Teil 1)

Sky’s the limit (Wortspiel)

Google Axes Mashup Editor to Focus on Cloud Computing Infrastructure (Abgehackt)

Wer weitere Links kennt die hier nicht helfen dürfen ist herzlich eingeladen mich zu kontaktieren.

Für die eigene Arbeit nutzen allerdings weniger als 10% cloud-basierte Dienste. Dagegen sprechen, so die Befragten, Sicherheitsbedenken.

Grundsätzlich finde ich es natürlich gut, wenn Menschen skeptisch und damit vorsichtig sind. Trotzdem hinterlässt es einen faden Beigeschmack. Vor allem kann mir niemand erzählen, dass man gute Webanwendungen entwickeln kann, wenn man selbst keine nutzt.

via ZDNet

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.

Elf Punkte fast Kent Langley, seines Zeichens “Scale Consultant” in seinem Blog treffend zusammen.