Nachteile eines Hostings auf dem Fremdserver

Oftmals werden wir gefragt ob es Sinn macht, das Hosting von tricoma extern zu vergeben oder im eigenen Haus zu machen. Dies hat extrem viele Nachteile und wird viele nachgelagerte und versteckte Kosten verursachen. Aus der Erfahrung heraus, wird man pro Jahr einen 4-stelligen Betrag zu den Serverkosten haben, wenn man das Hosting nicht bei tricoma hat.
Hier möchten wir auf die Nachteile im Detail eingehen:

1. Updates dauern mind. 3 x so lange = garantierte Ausfallzeiten in Ihrem Betrieb

Update sind ein notwendiges Übel. Es geht dabei um neue Funktionen, aber auch um die Sicherheit Ihres Systems und der Kundendaten.

Wenn wir ein Update auf einem tricoma Server einspielen, dann wird das Update von einem Depotserver geladen, welcher im gleichen Rechenzentrum steht und mit 3-facher Geschwindigkeit die Daten überträgt. Wir arbeiten hier mit so vielen gleichzeitigen Verbindungen, welche bei externen Servern nicht möglich sind, da dies im Regelfall als ein Angriff gewertet wird. Das Update würde dann einfach unterbrochen werden und sie hätten ein "halb aktualisiertes System".
Also wird das Update "gedrosselt", was bedeutet das Sie mind. 3 mal so lange warten müssen, bis dieses fertig ist. In dieser Zeit müssen Sie dann ggf. sogar die Arbeit im kompletten Unternehmen unterbrechen.

2. Für das Update entstehen weitere Kosten mit erhöhtem Stundensatz

Grundsätzlich fallen bei einem Update auf einem Fremdserver immer weitere Kosten zu den Updategebühren mit erhöhten Stundensatz. Der erhöhte Stundensatz ist deswegen nötig, da bei Problemen bei Updates immer ein Techniker auf Abruf bereit sein muss, da diese Probleme teilweise nur von Coreentwicklern (höchste Entwickler im Haus) gelöst werden können. Mehr Details hierzu: Servicegebühr für externes Hosting von tricoma

3. Keine automatischen Sicherheitsupdates von tricoma

Wenn das System bei uns gehostet ist, werden kritische Updates automatisch von uns eingespielt. Dies können wir allerdings bei Fremdservern niemals machen, da wir nicht wissen welche Konfiguration auf dem Server vorhanden ist. Im schlimmsten Fall würden wir dann das tricoma System komplett lahm legen.

4. Kein Monitoring bei Verbindungsfehlern z. B. amazon, ebay, Shopsystem

Dieser Punkt ist eigentlich der allerwichtigste: Wir überwachen minütlich Ihre Prozesse im tricoma System. Sobald etwas auffällig ist, prüfen wir dies und beheben ganz häufig das Problem im Hintergrund. Wenn wir es nicht lösen können, z. B. weil Zugangsdaten abgelaufen sind, nehmen wir direkt Kontakt mit Ihnen auf.
Gerade dies verhindert das Dinge passieren wie:

• Emails an Ihre Kunden gehen nicht raus
• Ebay Käufe werden nicht abgeholt
• Der Lagerbestandsabgleich zu Verkaufsplattformen klappt nicht und Sie haben Überverkäufe
• Es gibt technische Probleme mit der Datenbank
• uvm.

In der Regel werden wir pro Kunde im Jahr ca. 90 mal aktiv. Das bedeutet, dass wir ca. jeden 3. Tag im Jahr uns um etwas kümmern, um Ihr tricoma stabil oder sogar verfügbar zu halten.

Ohne Monitoring würde es beispielsweise erst gemerkt werden, wenn eine Schnittstelle nicht funktioniert, falls jemand in Ihrer Firma sich fragt, warum heute so wenige Lieferungen oder Aufträge da waren. Fällt nur eine kleine Schnittstelle wie z. B. Raktuen oder Hood aus, kann dies auch komplett untergehen. Dies kann für Sie bedeuten, dass Sie Ihren Status auf der jeweiligen Plattform verlieren.

5. Kein Monitoring spezifischer PHP oder Linux Erweiterungen

Wir wissen genau was tricoma an Erweiterungen benötigt. Entsprechend beobachten wir automatisch alle relevanten Nachrichtenportale und PHP Sicherheitswebseiten automatisch. Sobald eine Erweiterung durch eine Sicherheitslücke betroffen ist, schlägt unser Monitoring an und wir können umgehend reagieren.
z. B. indem wir eine Änderung in tricoma vornehmen oder den Server entsprechend umkonfigurieren.

Bei einem kleinen Hoster oder bei einem Hosting im Haus, wird dies höchstwahrscheinlich nicht passieren.
Bei einem großen Hostinganbieter wird sicherlich auch eine Monitoring statt finden, aber auf allgemeine Software wie Wordpress oder bezüglich allgemeiner Serversicherheitslücken. Dieser kann nicht so individual auf die tricoma Software eingehen, da das Wissen hierzu fehlen würden.

Beispiel: Wir benötigen die php7.0-mcrypt Erweiterung. Diese ist standardmäßig bei Ihrem Hoster nicht installiert und im Zuge der tricoma Installation wird diese extra für Sie installiert. Zu 99% wird diese Erweiterung nie speziell vom Hoster bezüglich Sicherheitsthemen überwacht werden, da diese eben nur auf Ihrem Server installiert wurde.
Zur Info: Wir arbeiten mit ca. 30 Erweiterungen speziell für tricoma.

6. Kein Performance Monitoring von tricoma Prozessen

Bei einem mittleren tricoma System werden täglich Millionen von Datenbankabfragen gestartet. Jedes tricoma wird in einer anderen Konstellation und anderen Mitarbeiterzahlen etc. verwendet. Daher ist auch jedes System immer individuell was die Performance angeht.

Beispiel:

• Ein Händler hat 50.000 Kunden
• Ein Händler hat 100.000 Produkte
• Ein Händler hat 80 Mitarbeiter
• Ein Händler hat täglich 10.000 Verkäufe
• Ein Händler hat 20 Shopware Shops angebunden
• etc.

Man merkt hier schnell: Die Auslastung ist hier immer unterschiedlich gelagert und das System muss überwacht werden um zu allen Zeiten eine gute Performance zu haben.

Bei einem externen Hosting fehlt dieses tricoma Monitoring komplett. Es ist uns daher nicht möglich bei Performanceproblemen sauber zu unterstützen. Auch hier würden wieder Kosten auf Sie zukommen, wenn Ihr System langsam ist, da wir nur mit enormen Aufwand die Performanceprobleme analysieren können.

7. Keine 100%ige saubere Konfiguration

Eine optimierte Serverkonfiguration für tricoma bringt Ihnen einen enormen Performancevorteil. Gerade was Speicher- und Cacheinstellungen angehen kann man hier viel verbessern. Diese Konfigurationen wurden mithilfe der Erfahrung hunderter Installation auf unseren Servern entwickelt. Daher holen Sie bei uns das Beste aus Ihrem tricoma heraus. Diese ganze Konfigurationen werden auf einem Fremdserver nicht vorhanden sein, da diese immer im Abstimmung mit der entsprechenden Hardware erfolgen.

Ihr System wird daher auf dem Fremdserver nicht so performant sein, und das auch oft nicht wenn Sie eine bessere Hardware nutzen.

8. Keine tricoma spezifischen Backups

Wir haben ein mehrstufiges Backupsystem und machen mehrere Backups auf verschiedene Arten von Ihrem tricoma.

Wir bekommen häufig Anforderungen von Händlern bestimmte Daten wie z. B. gelöschte Produkte wieder herzustellen.

Genau darauf sind unsere Backups optimiert und wir können daher auf viele einzelne Daten wie Produktbilder, Templates, Lagerwerte oder Kundendaten zugreifen. Bei Hostern wird im Regelfall einfach alles gesichert um bei einem Totalausfall wieder alles einspielen zu können. Möchte man nur etwas ganz bestimmtes, muss das Backup erst einmal an einem anderen Ort komplett eingespielt und aus diesem dann der Datensatz extrahiert werden.
Dies bedeutet für Sie: Mehr Kosten und eine erheblich höhere Ausfallzeit. Aus der Erfahrung heraus wissen wir, das Wartezeiten in solchen Fällen von 3 Tagen und mehr vorkommen kann.

9. Höhere Kosten bei individuellen Erweiterungen

Wenn Sie eine individuelle Erweiterung von Ihrem tricoma System wünschen, so wird diese auf einem fremden Server in den meisten Fällen mit höheren Kosten verbunden sein. Der Hintergrund ist hier, dass wir nicht wissen wie der Server konfiguriert ist und ob auch alle entsprechenden Serverprogramme installiert sind.

10. Gefahr des Unternehmensstillstand aufgrund von Inkompatibilität bei Serverupdates / tricoma Updates

Diese Gefahr wird mit einer sehr hohen Wahrscheinlichkeit zur Wirklichkeit werden: Ihr Server und tricoma arbeiten nicht mehr richtig zusammen.

Beispiel: Ihr Hoster macht ein Update

Wie am Beispiel von vorhin angemerkt kann ein Hoster bei einem Serverupdate nicht auf die installierte Software im Detail eingehen. Im Regelfall wird von Händlerseite zudem auch einfach ein Standard "managed Server" für günstiges Geld gewählt.
Dieser Hoster macht daher Updates der Server automatisiert (meist Nachts) und wird danach NICHT prüfen ob danach bestimmte Teile von tricoma funktionieren. Mal davon abgesehen das dieser in der Regel nicht den Zugang in Ihr Backend hat.
Daher ist dieses Problem das häufigste Problem was auftreten wird, da der Hoster eben auch verpflichtet ist auf Sicherheitslücken zu reagieren (DSGVO). Sie kommen dann morgens auf die Arbeit und Ihr Unternehmen steht.
Sie werden nun viel Geld investieren müssen um wieder ein lauffähiges System zu haben.

Beispiel: Wir machen ein Update

Grundsätzlich wird immer versucht tricoma so weiter zu entwickeln, das es mit den neusten PHP und Datenbankversionen funktioniert. Aber ein gutes Beispiel war die Entwicklung auf PHP7. PHP7 ist im Jahr 2015 veröffentlicht worden. tricoma war erst Anfang 2017 damit kompatibel, da erst dann PHP7 in Debian (unser verwendetes Betriebssystem) als "stable" vorhanden war. Stable bedeutet hier: Es gibt von Betriebssystemseite eine Kompatibilität und auf Sicherheitsfehler wird reagiert. Im Jahr 2018 wurde es Standard und zur Pflicht bei tricoma.
Jetzt setzt der Hoster aber noch eine alte PHP Version ein --> Ihr tricoma wird nicht mehr funktionieren nach dem Update und Sie müssen auf die schnelle jemand beim Hoster erreichen, welcher Ihnen den Server patcht. Nun kommen wir aber wieder zum oben angemerkten Punkt: Der Hoster möchte möglichst auf allen Servern die identische Konfiguration um die Updates automatisieren zu können. Es kann daher sein, das beim nächsten Serverkomplettupdate die individuellen Dinge überschrieben werden.
Alternativ hätte der Hoster im Jahr 2016 ein PHP7 installiert, dann hätte tricoma auch nicht mehr funktioniert, da sich grundlegende Funktionen geändert haben.

Beispiel: Ihr Hoster macht ein Upgrade auf eine neue Betriebssystemversion

Auch bei diesem Thema kann man ganz stark davon ausgehen, das Sie mit einer Nichterreichbarkeit von vielen Stunden rechnen müssen. Denn macht man ein Upgrade auf eine komplett neue Betriebssystemversion, so ändern sich auch die Konfigurationsdateien.
Als wir seiner Zeit von Debian Wheezy (7) auf Debian Jessie (8) gewechselt haben, hatten wir einen Aufwand von sicherlich einem Arbeitstag um alle Konfigurationen wieder richtig zu bekommen, so das tricoma wieder perfekt wie vorher läuft. Hat nun Ihr Hoster Suse oder eine andere Debianversion: Tja, keine Ahnung. Denn keine Ahnung bedeutet in diesem Fall das wir eventuell nicht mal helfen können, da wir keinen root Zugriff auf dem Server haben. Wir können dann Unterstützung geben, welche ab sehr langwierig wird, was für Sie bedeutet das Ihr Unternehmen steht. Wir haben einen Tag gebraucht als tricoma Entwickler. Ihr Serveranbieter ist aber kein tricoma Entwickler.

Es gibt daher in allen 3 Fällen schon fast die Garantie, das Ihr System mehrfach nicht mehr erreichbar sein wird.

11. In der Regel schlechtere SLA (Verfügbarkeits/Ausfallsgarantien)

Wir haben ein 24/7 Monitoring für jeden Server und auch für tricoma. Wenn Nachts ein Server oder auch einzelne tricoma Dienste nicht funktionieren, so bekommen wir eine Benachrichtigung und reagieren sofort.
Aber genau hier geht das Problem los:
Vor einem Serverausfall gibt es häufig Auffälligkeiten wie z. B. Performanceprobleme oder tricoma Dienste welche sporatisch nicht funktioneren. Dieses Monitoring von tricoma Prozessen hat der Hoster nicht und kann daher gar nicht präventiv auf bestimmte Problemfälle eingehen. Es wird daher bei tricoma spezifischen Dingen zu einem Ausfall kommen, welcher vorher hätte verhindert werden können.

Auch sollte man immer die SLA des Hosters prüfen. Oft wird hier angegeben das der Server binnen von 24 Stunden getauscht wird. Im schlimmsten Fall können Sie 24 Stunden nicht arbeiten.

Beispiel:
Ihr Server fällt am Montag um 13 Uhr aus. Sie bekommen den Ersatzserver am Dienstag um 12 Uhr. Ihre Verkäuferstatistik bei ebay und amazon wird drastisch nach unten gehen.

12. Keine spezifisches auf tricoma zugeschnittenes Firewallsystem

Die Firewall von unseren Servern wurde speziell für tricoma entwickelt. Es werden also die Anfragen ausgewertet, nach dem Schema, was für tricoma schädlich sein könnte. Auch wird erkannt welcher Benutzer aktuell im tricoma eingeloggt ist, um gesonderte Regeln zu erlauben.

Beispiel:
Ein externer Hoster hat sicherlich auch ein Firewallsystem, aber dieses ist für die Allgemeinheit. Hierbei wird keine Rücksicht auf tricoma Sitzungen oder Benutzer genommen, sondern es läuft "pauschal" für tausende mögliche Anwendungen.

13. Fehlerfindung bedeutet oft unnötiger kompletter Hardwareaustausch

Viele große Anbietern können alleine schon wegen dem Pricing nicht auf individuelle Fehlerfindung eingehen. Die Erfahrung hat gezeigt, das bei Problemen (Verbindung, Performance, Ausfalle...) oftmals die komplette Hardware vom Hoster (in den meisten Fällen während deren vorgegebener Zeit) getauscht wird. Hierbei wird in der Regel keine Rücksicht darauf genommen, das zu bestimmten Zeiten Ihre Hauptpackphase im Lager ist.

Was nun noch ärgerlich ist: In einigen Fällen liegt das Problem nicht an der Serverhardware, was einen komplett unnötigen Unternehmensausfall bedeutet hat. Es geht nun die Fehlersuche los, welche wieder aufgrund fehlender tricoma Monitorings und fehlendem Logfilezugriff extrem aufwändig und teuer wird.

14. Kein Zugriff auf die Fehlerlogs

Eines der größten Probleme bei Fremdservern ist für uns in der Entwicklung, dass wir keinerlei Zugriff auf Fehlerlogs des Servers haben. Viele Dinge können wir daher nicht sehen und wissen auch nicht, wenn etwas nicht klappt. Dies hat zur Folge, dass Fehlerbehebungen erheblich schwerer werden.

Beispiel:
Wir hatten bereits Kunden mit Fremdservern auf welche jegliche Fehlerausgabe unterdrückt wurden und wir immer wieder die Logfiledatei beim Hoster manuell anfragen mussten. Letztlich war es ein vom Händler falsch eingebundenes Bild in den PDFs.
Kosten für den Händler: einige hundert Euro

15. Serveranbieter kann bei einer Muttergesellschaft außerhalb der EU nur bedingt DSGVO konform arbeiten

Dies ist unserer Ansicht nach ein großes rechtliches Problem, denn gemäß der DSGVO muss man die Daten entsprechend verarbeiten und auch eine Vereinbarung mit dem Diensteanbieter schliessen. Wenn man nun aber bei einem großen Serveranbieter mit einer Muttergesellschaft z. B. in Amerika einen Vertrag schließt, läuft man Gefahr gegen die DSGVO zu verstossen.

Beispiel:
Es gibt beim deutschen Standort massive Probleme im Rechenzentrum. Natürlich werden auch Techniker aus Amerika auf Server und Dienste wie Backups etc. zugreifen. Der Techniker in Amerika unterliegt aber einem ganz anderen Gesetz, welches nicht mit dem Europäischen vereinbar ist. Nun ist eben die Frage: Ist das nun DSGVO konform?

16. Voraussetzungen für die Updateinstallation auf einem Fremdserver

Diese finden Sie hier: Voraussetzungen für die Updateinstallation/Support auf einem Fremdserver