In eigener Sache
Artikel merken

Wie wird t3n.de gehostet?

Reichte 2005 noch ein Massenhoster, braucht t3n.de heute eine passende Hosting-Infrastruktur. In diesem Artikel geben wir einige Einblicke hinter die Kulissen: Wie wurde t3n.de die letzten Jahre gehostet? Welche Lösungen kamen zum Einsatz? Wann und warum wurde das System geändert?

Von Martin Brüggemann
11 Min. Lesezeit

Die Anfänge beim Massenhoster

Als wir 2005 zu dritt mit t3n.de losgestartet sind, lag unsere Webpräsenz mit vielen anderen Webprojekten auf einem Debian-Rootserver bei einem großen Hosting-Provider in Süddeutschland. Damals lieferte noch der Apache-Webserver unsere Website aus und unser MySQL-Server auf der gleichen Maschine lief mit den Debian-Default-Einstellungen. Wir hielten das für eine schöne Lösung. Zumindest eine Zeit lang. Genauer gesagt: Bis irgendjemand auf die Idee kam, dass man unser tolles Printmagazin für eine begrenzte Zeit kostenlos in unserem Shop bestellbar machen könnte. Was folgte, war der erste „Totaleinschlag“ in unserer Webhosting-Geschichte: Schon nach wenigen Minuten war unser Shop nicht mehr erreichbar.

In solch einem Moment überlegt man sich natürlich, was man an der MySQL-Einstellung hätte verbessern können, ob der Apache Webserver richtig konfiguriert ist, welche Möglichkeiten es evtl. noch gegeben hätte, besser zu cachen oder einen PHP-Bytecache einzusetzen,… Einen Tag später hatten wir einen dedizierten neuen Rootserver – den größten, den unser Massenhoster damals im Programm hatte (aber immer noch eine selbst zusammengebaute Kiste mit Desktop-Gehäuse). Dennoch blieb ein Problem: Trotz neuem Server war ich immer noch der Alleinverantwortliche für den Betrieb unserer Website und musste mir überlegen, wie unsere Zukunft aussehen sollte.

Gleiches Hosting, neuer Server – auch keine Lösung

Nun hatten wir also diesen neuen, tollen Server mit AMD-Prozessor und unglaublichen 2 GB RAM – über den wir uns heute schlapp lachen würden. Da liefen zwar immer noch alle Services auf einer Maschine, aber immerhin keine anderen Webhosting-Projekte. Mit der Zeit kamen bei t3n.de dann immer mehr interne Ideen dazu. Wir starteten neue Portale wie z.B. das Portal „socialnews“ (damals noch unter dem Namen hype!) und andere Verzeichnisse wie unser Job-Portal, einen Marktplatz für Dienstleister, ein Open-Source-Verzeichnis und ein Startup-Verzeichnis. Auf einmal brauchten wir Funktionen wie Single Sign On, interne APIs, Newslettermöglichkeiten, generierte XML-Sitemaps… Wir veröffentlichten mehr Inhalte, wurden besser verlinkt und auch besser von den großen Suchmaschinen indexiert. Kurz: Alles wurde komplexer, unser Traffic stieg stetig und gleichzeitig waren wir mit unserem Rootserver immer unzufriedener. Die reine Hardware-Performance war nicht das Problem. Vielmehr machte uns das in unseren Anfängen als „toll“ befundene Billig-Konzept des Hosting-Anbieters und die damit einhergehende schlechte Gesamtverfügbarkeit zu schaffen – „schlechte Verfügbarkeit“ stand dummerweise bei der Bestellung auch nicht in der Produktbeschreibung ;-)

Als unser Server zwei Tage komplett nicht erreichbar war, weil es im Rechenzentrum einen weitreichenden Kabelbrand gab und alle Leitungen ausgetauscht werden mussten, hielten wir es für einen guten Zeitpunkt, unsere Hosting-Strategie ein wenig zu überdenken.

Zu viel eigene Hardware erhöht die Komplexität und verschlechtert die Ausfallsicherheit.

Die naive Zeit des eigenen Serverschranks im eigenen Serverraum

Zufälligerweise fiel unser Wechselbedürfnis in dieselbe Phase wie unser Umzug in ein neues Büro. Dort gab es einen „Serverraum“, wo man zumindest schonmal einen 19′-Schrank reinstellen konnte und die Anbindung war mit 35 Mbit auch ziemlich luxuriös. Hinzu kam, dass eine Webagentur im selben Gebäude ebenfalls Hosting betrieb und wir inzwischen einen Systemadministrator-Azubi in unserem Team hatten, so dass unser Hosting-Wechsel vom Billigprovider hin zum eigenen Serverraum nach einer runden Sache aussah. War es eine Zeit lang auch: Wir konnten uns eigene Server zusammenstellen, waren gleichzeitig auch schlau genug, an die grundlegendsten Redundanz-Features wie Festplatten im Raid-1 und Fallback-Netzteil (zumindest schonmal im Schrank) zu denken.

Trotz allen Aufwands, den wir mit der Zusammenstellung der Schrank-Lösung, den Servern, der ausfallsicheren Stromlösung usw. hatten, blieb am Ende die Erkenntnis, dass wir selbst bei einigermaßen guten Rahmenbedingungen und einem inzwischen auf zwei Mann gewachsenen Team (inklusive mir), niemals die mit jedem Mehrtraffic immer höher werdenden Anforderungen stemmen konnten.

Wir hatten keinen Einfluss darauf, dass ein Baustellen-Bagger fünf Kilometer weiter ausgerechnet die für uns zuständige Glasfaserleitung kappte und wir für fünf Stunden offline waren. Wir hatten keinen Einfluss darauf, dass die Klimaanlage beim Bau des Gebäudes für einen Serverraum völlig unterdimensiniert wurde und es hätte auch keinen Sinn gemacht, für uns eine eigene Lösung zu implementieren. Hinzu kam, dass unser Vermieter irgendwann auch noch auf die Idee kam, dass es sinnvoll sein könnte, den Serverstellplatz nicht mehr wie anfänglich pauschal, sondern zuzüglich des verbrauchten Stroms zu berechnen. Der nachträglich eingeführte Stromzähler machte dann auch die noch so optimistische Effizienz-Schätzung zunichte. Wir mussten uns mal wieder etwas Neues überlegen. Hinzu kam, dass wir täglich an Traffic zulegten und merkten, dass wir von dedizierten Servern auf eine Virtualisierungstechnik wechseln mussten, da uns Flexibilität fehlte, unsere vorhandenen Hardware-Ressourcen optimal zu nutzen.

So kann das aussehen, wenn man zum Neustarten des Servers erstmal einen Monitor anschließen muss und der leider nur auf dem Kopf in den Schrank passt. Kabelmanagement auf die rustikale Art.

Eigene Hardware im Rechenzentrum um die Ecke

Noch bevor das überhaupt richtig bei unseren Lesern ankam, war uns klar, dass wir virtualisieren müssen, um mit unserem Hosting flexibler zu werden. Wir wollten einfach nur noch für einen physikalischen Server zuständig sein und darauf alle Projekte virtualisieren. Also haben wir uns den größten Dual-Xeon-Server besorgt, den wir damals kurzfristig auftreiben konnten und auf Basis des Virtualisierungssystems Xen ein Hostsystem aufgesetzt. Wir waren so richtig begeistert von unserer Virtualisierungsidee, dass wir ziemlich viel virtualisiert haben. Im Nachhinein wahrscheinlich etwas zu viel.

Mit dem Wechsel auf Virtualisierung und ein Rack im professionellen Rechenzentrum (RZ), hatten wir schonmal einen wichtigen Schritt getan. Ausfallsicherheit und Anbindung, sowie das Preis/Leistungsverhältnis waren einfach spitzenmäßig. Zudem waren wir in guter Nachbarschaft (ja, es gibt noch RZs, in denen die Server mit Klarnamen beschriftet werden) und das Rechenzentrum war auch nur 3 km von unserem damaligen Büro entfernt, so dass man im Notfall auch schnell da war.

Wir betrieben also diese wunderbare virtuelle Serverwelt und waren damit auch wirklich gut zufrieden. Bis der Tag kam, an dem wir uns fragten, wie wir denn eigentlich das Hostsystem, also den Xen-Server am Besten im laufenden Betrieb updaten, ohne Gefahr zu laufen, dass danach alles down ist. Jeder, der mal einen Webserver betrieben hat, weiß, dass es keine gute Idee ist, im Livebetrieb umfangreichere Upgrades durchzuführen und durch die strikte Virtualisierung waren wir schon bei der kleinsten Änderung am Xen-Server dazu gezwungen, alle virtuellen Maschinen vorher auszuschalten und konnten dann nur beten, dass sie wieder hochfahren bzw. der Xen-Server nach einem Upgrade überhaupt noch funktionstüchtig war.

Kurz: Auch diese Hosting-Lösung war langfristig zum Scheitern verurteilt. Zudem verursachte unser selbst aufgesetzter Xen-Server unter Debian immer mehr merkwürdige Kernelprobleme und wir hatten kein adäquates Testsystem, um Änderungen sicher zu testen. Man hätte nun einen baugleichen zweiten Server kaufen können und diesen neben dem Live-Server platzieren können. Dummerweise hatten wir beim Kauf des Servers nicht darauf geachtet, dass das verbaute Mainboard nur bis 8 GB Speicher aufrüstbar ist und wir mit unserem ganzen Virtualisierungsideen und neuen Projekten plus stetig wachsendem Traffic damit vorne und hinten nicht hinkamen.

Profis ins Boot holen?

Uns wurde also klar, dass wir eine Lösung für das Management unseres Xen-Servers brauchten. Von der Technik waren wir nach wie vor voll überzeugt und obwohl wir mit unserer inzwischen gesammelten Erfahrung natürlich einiges anders machen wollten, brauchten wir am Ende einfach einen stabilen Xen-Hostserver als Basis. Also waren wir mal wieder am Suchen. Der Billighoster von damals hatte neue Server im Programm (immer noch Desktop-Hardware), doch der Kabelbrand von damals saß uns noch fest im Kopf. Bei anderen Hostern gab es inzwischen sogar Angebote gemanagter Virtualisierungslösungen. Nach näherer Betrachtung gab es aber bei allen fertigen Paketen immer irgendeinen Haken. Nach wochenlanger Recherche und einigen Tests, waren wir auf einmal auf der Suche nach einem Individualhoster, einem Spezialisten für unsere Anforderungen.

Das Team von unbelievable machine. Seit 2009 zuständig für die Hardware und den Xen-Server hinter t3n.de.

Von den Raketenforschern unter den Hostern

Über das Sun Startup Essentials Programm sind wir dann auf unbelievable machine (kurz *um) aufmerksam geworden – eine kleine Hosting-Schmiede aus Berlin. So richtig habe ich am Anfang nicht begriffen, was die eigentlich machen und irgendwie schien mir eine Individuallösung anfänglich auch als viel zu unkalkulierbar. Nach den ersten Gesprächen mit den *um-Jungs kristallisierte sich aber relativ schnell heraus, dass wir uns mit unbelievable machine einen Partner ins Boot holen könnten, der uns das ganze Management der Hardware-Lösung und auch die Verwaltung unseres Xen-Servers komplett abnehmen würde.

Jetzt sind wir inzwischen etwas über ein Jahr dort Kunde. Ich nenne Sie gerne die „Raketenforscher unter den Hostern“, weil sie als Hosting-Dienstleister von der Hardware über das RZ bis hin zur Anbindung einfach extrem anspruchsvoll sind und sich da eine Truppe an Experten gefunden hat, die es schafft, State-Of-The-Art-Hosting-Technologie so auf praxistaugliche Lösungen runterzubrechen, dass das Ganze für kleine Kunden wie uns am Ende dennoch bezahlbar ist.

Wir haben zum Beispiel ein Sun-Blade in einem der von *um betriebenen Bladecenter mit ausreichend Leistung durch Dual-Intel-Nehalem-Prozessor, SAS-RAID und 24 GB Arbeitsspeicher, auf dem *um für uns einen Citrix Xen-Server betreibt. Das Rechenzentrum in Berlin, in dem *um seine Hosting-Lösungen betreibt, ist das professionellste RZ, das ich je betreten habe und alles ist so extrem redundant ausgelegt, dass ich es für unsere Anforderungen für fast gnadenlos überdimensioniert halte – aber schaden kann die zusätzliche Professionalität ja auch nicht. Zumindest so lange das Preis/Leisungsverhältnis stimmt. Das Thema Xen-Server-Hostsystem haben wir inkl. Backups komplett an *um ausgelagert. Wir kümmern uns nur noch um unsere virtuellen Maschinen. Als weitere Pakete nutzen wir aktuell noch die Shared-Firewall-Lösung und den 24/7-Restart/Reset-Service.

Gerade der Restart/Reset-Service hat mir schon so manchen Ärger erspart. Ab einem gewissen Punkt tut es einfach richtig weh, wenn man mit einer groß gewachsenen Website auf einmal offline und dummerweise als technischer Ansprechpartner alleinverantwortlich für alles ist.

Langfristig ist es einfach eine Illusion, als Einzelperson immer voll verfügbar zu sein und im Notfall jedes Serverproblem zeitnah lösen zu können. Ich hatte dieses Jahr die Situation, dass ich mit meinem zu diesem Zeitpunkt 15 Monate alten Sohn an der Supermarktkasse stand, den Wocheneinkauf einpacken/bezahlen sollte, er schon unruhig wurde, weil er endlich was zu Essen auf dem Tisch haben wollte und in diesem wundervollen Moment der Erwartungen mich dieses schlimmste aller Monitoring-SMS erreichte: „t3n.de not reachable“. Natürlich hätte ich laut schreien, meinen Sohn schnappen und aus dem Supermarkt zum nächsten Internetanschluss rennen können, aber stattdessen habe ich einfach nichts dergleichen getan und auf meine Hosting-Lösung vertraut.

Natürlich schau ich mir auch heute trotzdem noch zeitnah an, wo der Fehler lag, aber falls ich im Notfall nicht reagieren kann, versucht der *um-Bereitschaftsdienst den Fehler selbständig zu beheben. 24 Stunden am Tag, 7 Tage die Woche. Wir haben am Anfang gemeinsam eine Dokumentation unserer Hosting-Architektur erarbeitet, so dass die grundlegendsten Fehlerquellen von jedem *um-Mitarbeiter eigenständig behoben werden können. Dafür bezahlen wir eine monatliche Pauschale und den Aufwand für jeden Notfalleinsatz – auch abhängig vom Tag und der Uhrzeit. Bisher eine absolute faire Lösung, die ich auf keinen Fall mehr missen möchte. Für mich ist das ein absolutes Plus an Lebensqualität.

Mindestens einmal im Jahr setzen wir uns übrigens zusammen und besprechen unsere Hosting-Entwicklung, Probleme und Verbesserungsideen. Da der Traffic ständig wächst und neue Projekte dazukommen, ist das für mich ein unglaublich wichtiger Termin, der natürlich durch zahlreiche Besprechungen über das Jahr hinweg ergänzt wird.

Was die Zukunft bringt

Auch wenn heutzutage jeder „Cloudhosting“ schreit und ich ebenfalls ein großer Cloud-Fan bin, sehe ich uns mit unserer Hosting-Infrastruktur noch weit von der Cloud entfernt. Wir haben umfangreiche Tests mit den Amazon AWS Services gemacht, betreiben heute parallel zu unserer t3n.de-Hosting-Infrastruktur mehrere Jiffyboxen für interne Projekte, die wir nicht mit unserem Live-Betrieb von t3n.de auf einem Server betreiben wollen und ich habe mir auch schon cloudcontrol, heroku und alternative Virtualisierungslösungen zum Citrix Xen-Server wie z.B. KVM, OpenStack usw. angeschaut. Das sind alles tolle Entwicklung und ich bin mir sicher, dass wir mit t3n.de auch hier demnächst vorne mit dabei sein werden, aber solange wir dann immer noch für den Betrieb unserer Kernkomponenten (Webserver,MySQL-Server,MessageQueue,…) selbst verantwortlich sind, werde ich erstmal nichts ändern, sondern meine Zeit lieber in die Optimierung unserer Software-Lösungen stecken.

Meine Meinung ist, dass sich die Sicht von professionellen Webhosting-Kunden verändern wird. Wir werden endlich den lang prophezeiten Wandel vom Server- zum Application-Hosting sehen. Wo der Kunde früher zufrieden war, dass er sich nicht mehr um das Management seiner Serverhardware kümmern musste, wird er sich in Zukunft fragen, warum er sich um die Konfiguration eines MySQL-Servers kümmern sollte, wo doch 2.000 andere Kunden beim gleichen Provider ähnliche Anforderungen haben und man einfach einen zentral vom Provider verwalteten MySQL-Cluster per MySQL-Proxy nutzen könnte.

Wir werden einen Wandel sehen vom monatlichen Fixpreis-Hosting hin zu nutzungsbasierter Abrechnung, wo man neben einer niedrigen Grundpauschale nur das zahlt, was man wirklich an Ressourcen in Anspruch nimmt. Es werden sich Standards etablieren, die den relativ einfachen Wechsel von einem Application-Provider zum anderen ermöglichen und sei es, dass einfach beide Provider technisch ähnliche Lösungen bereitstellen.

Die nötige technologische Basis für all diese Dinge steht in Form von immer besser werdenden Open-Source-Lösungen schon lange in den Startlöchern. Themen wie Skalierbarkeit, Hochverfügbarkeit und realistisches Kosten/Nutzen-Verhältnis werden als gegeben vorausgesetzt. Gleichzeitig machen wir uns aber auch wieder etwas abhängiger von anonymen Lösungen von Riesenkonzernen ohne Telefonnummer und globalen Spezialanbietern.

Bei aller Euphorie sollte man am Ende nie vergessen, dass auch das Thema Hosting am Ende mit Menschen zu tun hat. Bei Amazon AWS kann ich nicht anrufen und fragen, was die zu dem Aufbau meiner virtuellen Maschinen sagen. Wenn ich zu cloudcontrol wechseln wollen würde, könnte ich zur Zeit keine MessageQueue, keinen Solr-Server und keine Cronjobs betreiben. Außerdem stehen die Server hinter cloudcontrol wieder im Amazon AWS Rechenzentrum in Irland. Für eine Microsite sicher gut, aber die tolle Responsetime und Kalkulierbarkeit unseres im RZ in Berlin stehenden Servers ist auch nicht nachteilig. Jiffybox finde ich für kleine Projekte toll, ist aber auch nur eine halbe Cloud-Lösung, da man sich selbst um Kernfragen wie Skalierbarkeit und Performance kümmern muss, indem man zum Beispiel mehrere Jiffyboxen zu Cluster-Systemen kombiniert und sich um die nachhaltige Konfiguration/Überwachung wie bei echten Servern selbst kümmern muss.

Jede Hosting-Lösung ist nur so gut, wie die Menschen die dahinter stehen. Egal ob Cloud, eigener Serverraum oder managed Xen-Server. Egal wie gut man ist, welche tollen Technologien man einsetzt oder wie zuverlässig die Hosting-Lösung ist – wer schonmal einen Webserver betrieben hat weiß:

Es brennt immer etwas an. Sei bereit.

29 Kommentare
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Kai Thrun

Schön geschrieben. Etwas lang für den Lesesnack zwischendurch aber es sei dir die Chance gegönnt sich auch mal in den Redaktionsteil zu schleichen ;)

Antworten
Martin Brüggemann

Danke Kai! Das mit der Länge ist so eine Sache. Bin eigentlich auch Fan von knackigen Artikeln, aber wann schreibt man schonmal einen Artikel über 5 Jahre Hosting-Geschichte.. das musste ich natürlich ausnutzen ;)

Antworten
Bit

[…]Wir konnten uns eigene Server zusammenstellen, waren gleichzeitig auch schlau genug, an die grundlegendsten Redundanz-Features wie Festplatten im Raid-0 und Fallback-Netzteil (zumindest schonmal im Schrank) zu denken.[…]

Raid-0 bietet keine Redundanz. Fällt eine Platte aus, ist alles weg… Ihr habt vermtl. Raid-1 verwendet…

Antworten
Martin Brüggemann

@Bit Hättest du uns das doch damals erzählt!! ;) Nee. Raid-1 stimmt. War ein Tippfehler. Hab ich korrigiert. Danke.

Antworten
Dirk Deimeke

Sehr schöner Artikel. Vielen Dank!

Antworten
Thomas Weise

Vielen Dank für die ehrlichen Einblicke in Deinen/Euren „Leidensweg“ zum Hosting. Das war sehr interessant.
Ich selbst lege den größten Wert auf die Erreichbarkeit des Hosters, wie schnell wird geholfen. Da schneiden die „kleinen“ Hoster fast durchweg besser ab.

Antworten
Andreas Lenz

@kai: sind dir zuwenig bilder gelle!? ;)

Antworten
Markus Möller

Sehr interessant. Danke!

Antworten
Andy

„Außerdem stehen die Server hinter cloudcontrol wieder im Amazon AWS Rechenzentrum in Irland. Für eine Microsite sicher gut, aber die tolle Responsetime und Kalkulierbarkeit unseres im RZ in Berlin stehenden Servers ist auch nicht nachteilig. “

Wenn Amazon, dann willst du sicherlich S3 und CloudFront einsetzen. Dann stehen die EdgeLocations an sehr viel mehr Standorten (Europa :Amsterdam, Dublin, Frankfurt, London) und nur die Quelle ist Irland. Finde das bringts auch nur für Zeugs, was eben ins CDN gehört, *.css, *.js, manche png/jpeg Files, etc.

Antworten
schoysi

Danke für den Artikel! Hat wirklich Spass gemacht diesen durchzulesen. Und irgendwie erinnert mich das auch ein wenig an unsere ersten Projekte ;)

Antworten
Stephan Schwenk

Toller Artikel und interessant geschrieben. Ich betreibe mit meinem Unternehmen selber einen Root-Server in einem RZ und weiß genau, wovon Du sprichst: „…komisch, habe seit 15 Minuten keine E-Mail mehr erhalten…“ und schon steht das Telefon nicht mehr still, weil das mittlerweile auch die Kunden gemerkt haben. Und das nur, weil irgendeine Sicherung in irgendeiner UV sich verabschiedet hat und das gesamte Rack lahmgelegt wurde.

Ich glaube, ich muss die *um-Jungs mal kontaktieren ;-)

Antworten
Sven

Ein schöner Artikel, vor allem weil es sich bei uns in den Jahren ziemlich ähnlich entwickelt hat. Wahrscheinlich ist das fast überall so. Wir sind nun auch wieder weg von der eigenen Hardware im Rechenzentrum, da die Hardware im Fall eines Defekts sehr große Sorgen machen kann. Vor allem wenn wie bei uns zu Weihnachten ein Teil ausfällt …

Antworten
richin

Perfekter Artikel um den Trend „Cloud“ zu erklären. *Daumen Hoch* ;)

Antworten
Minho Park

Sehr aufschlussreicher Artikel mit dem Fazit: Wir sind nicht allein mit dem Thema :)
Danke für den Erfahrungsaustausch!

Antworten
fixi

Sehr schöner Artikel. Aus der Realität…
Ich habe in den letzten 15 Jahren viel Projekte geleitet und auch eine Zeit selbst gehostet….
Ihr habt sicher alle schon Erfahrungen mit 1+1 und Co. Kundenservice gemacht.
Ich zahle lieber mehr für ein Qualitätsprovider, bei dem ich die Personen mit Namen kenne.

Antworten
atomiccocktail

Das hinter dem Hostingangebot auch Menschen stehen müssen, kann man gar nicht oft genug unterstreichen. Wenn es denkbar wäre, das wichtigsten Betriebsmittel einer Website ohne persönliches Engagement einfach auszulagern, kann was nicht stimmen. Das sagt einem schon der Hausverstand.

Antworten
oli

Danke. Toller Artikel.

Antworten
Andy

Sehr interessanter Artikel – Danke für den tollen Erfahrungsbericht!

Bitte (wieder) mehr davon auf/in T3N … :-)

Antworten
alex x

Mich würde interessieren, ob ihr ein eigenes CMS System benutzt oder auf ein bestehendes zurückgreift? Und falls auf ein bestehendes: Auf welches? :-)

Antworten
Martin Brüggemann

@alex x Wir verwenden für den Newsbereich WordPress, Shop/SingleSignOn basiert auf TYPO3, Howto und Fragen ist Symfony/Doctrine, Startups/Jobs/Marktplatz/Socialnews sind Eigenentwicklungen mit PHP. Das ganze läuft auf lighttpd/php-fcgi/apc hinter nginx als ReverseProxy. Wir setzen außerdem Apache Solr für die globale Suche, Beanstalkd als MessageQueue und MySQL als DBMS ein. Als Versionsverwaltung und Deployment setzen wir github.com ein. Mehr fällt mir gerade nicht ein, aber ich schreib bei Gelegenheit mal einen Artikel nur zu unserer Software-Architektur, wenn Interesse besteht.

Antworten
Marcus

Danke für diesen Artikel. Mir hat besonders das herausstellen der „menschlichen Komponente“ gefallen.

Antworten
alex x

Vielen Dank für die detailreiche Antwort. Ihr habt ja ein ganz schönes Sammelsurium an verschiedener Software. Mich würde auf jeden Fall ein Artikel über die Software im Hintergrund interessieren, v.a. wie spielen die einzelnen Komponenten zusammen. Weitere Fragen für den Artikel wären z.B.:
Wieso keine komplette Eigenentwicklung? Wäre eine an eure Bedürfnisse angepasste Lösung nicht effezienter? Könnte man dadurch nicht Resourcen sparen(Server)? Damit könnte man auch einen Zusammenhang zu diesem Artikel schaffen :-)
Müsst ihr in jedem einzelnen Softwareprodukt Templates pflegen oder vereint im Hintergrund Typo3 die gesamte Softwaresammlung.

Jedenfalls vielen Dank für den Artikel und das Kommentar. Ist wirklich sehr interessant, was in einem Unternehmen im Hintergrund alles werkelt.

Antworten
Michael Nordmeyer

Ich denke nicht, das man beim Application Hosting zwangsläufig abhängiger vom Hoster wird, als wenn man seine eigenen Lösung betreibt. Solange die App nicht mit der speziellen Infrastruktur des Hosters verzahnt ist, ist es sogar leichter zu wechseln. Beispiel: Heroku. Es ist immer vom Einzelfall abhängig, ob man sich mit einer großen und etablierten Infrastrukturlösung abhängig macht. Klar, 1und1 ist nicht die erste Wahl ;)

Antworten
marius

Hallo,
@Martin und Alex
IMHO finde eure Software-Architektur unglaublich interessant.
Alleine das SingleSignOn klingt schon nach einem gutem Thema…
Ich freue mich auf einem Artikel im neuem Jahr. Thumbs Up!
=)
Mit besten Grüßen
Marius M – mariusmüller.de

Antworten
BastianBBux

Netter Einblick. Nur stellt sich mir die Frage wie das mit der Virtualisierung läuft. Meiner Erfahrung nach ist bei ein bisschen mehr Traffic mit TYPO3 und Virtualisierung der HDD-I/O recht schnell hoffnungslos überfordert.
Daher setze ich auf dedizierte Rootserver bei einem großen und professionellen Hoster.
Natürlich kenne ich daher auch die Situation an der Supermarktkasse. Aber ist bei mir halb so wild dank Android, außerdem sind wir DINKs (mit Betonung auf NK). ;)

Antworten
Andreas Jonderko

Hallo Martin,
toller Artikel, bildet den Alltag eines Software-Entwicklers, der sich zwagsweise mit einer super Performance – Problematik befassen muss, ab. Das Supermarktproblem kennt wohl auch jeder verantwortliche, wo einem dann kurz das Herz stehen bleibt und man sich für wenige Sekunden in der „Matrix“ befindet :D
Wollte nur noch dazu sagen, dass es meistens so läuft, da man in der Startphase einfach nicht die nötigen finanziellen Mittel hat, um gleich bei einem professionellem Hoster zu landen. Der Spagat zwischen „Startup“ und „etabliertem Unternehmen“ ist einfach der harte Weg.
Da wir ebenfalls nicht die Mittel für die professionelle Serverbetreung haben, haben wir uns entschieden vorerst die Hardware anzumieten (bei Hetzner) und nur noch die virtualisierung zu übernehmen. Mittlerweile gibt es auch eine sehr schöne Lösung über „OpenNebula“, die einem viel Arbeit beim deployen und verwalten der Images / Netzwerke etc. übernimmt.

Antworten
Timo

Danke!
Hab vor ein paar Tagen die Seite von UM Entdeckt und war noch am überlegen.
Zufällig entdeckte ich diesen Artikel. Nun weiss ich wo ich morgen hingehe (Sprichwörtlich da mein Büro nur ein paar Ecken weiter ist)

=)

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.