Desktop as a Service für IT-Startup (Kosten, Aufwand, Erfahrungsberichte)

overflow

OpenBSD Enthusiast
Einige von euch kennen vermutlich Shadow https://shadow.tech/de/.

Genau das gleiche Konzept möchte ich für mein Startup umsetzen, aber auf eigenen Servern.
Mitarbeiter sollen über einen Client sich mit dem Desktop in der Cloud verbinden und von da aus arbeiten.

Als Desktop-Cloud-PC werden wir vermutlich BSD einsetzen.
Zum Großteil wird auf den Systemen programmiert.
Erwähnenswert wäre noch der Einsatz von Nextcloud für die Datenablage, Videotelefonie etc.

Und nein, Github und Konsorten oder Clickup fü das Projektmanagement komme nicht in Frage.
Wir möchten die volle Kontrolle der Daten haben und das System auf dem entwickelt wird überwachen.
Endgeräte wie Laptops bereitzustellen ist keine Option :)

Aktuell planen wir für 10 Mitarbeiter aber das Fundament sollte für 50 gesetzt sein.

Ich frage mich wie ich herausfinden kann, wie viel Leistung ich benötige...

Sollte ich auf 10, 20, 40Gbps oder doch lieber auf 100Gbps Ethernet Karten setzen?... Wie viel RAM und CPU benötigt mein Server?...
All das sind einige Fragen die mir Kopfschmerzen bereiten und noch natürlich viele Dinge die mir heute noch nicht einfallen.

Eine große Nummer die wir vorhaben. Vielleicht hat hier jemand ja Erfahrungen.

Vielleicht kriege ich mein vorhaben mit Parsec einfach realisiert. Muss hier noch weiter recherchieren...
 
Zuletzt bearbeitet:
hi

im kern scheinst du ja mehr in Richtung VDI zu denken.

Wenn also die Mitarbeiter keine eigenen PC als Arbeitspatz haben sollen,
und es mehr Richtung Terminal gehen soll , was spricht das gegen ein
Xserver / Teminal Thema.

Jedoch wirst du mittelfristig nicht ohne Windows auskommen da es z.b.
in der Buchaltung ziemlich Windows lastig zu geht.

Netzwerk seitig kannst du zum Start auch über Multiple LACP nachdenken ,
es Erhöht zwar nicht den Transfer einer einzelen Datei vom Client zum Server ,
jedoch bleibt die Speed , bei zunehmender anzahl der Clients , konstant .

Die Kosten für ein hochbandiges Netz kann man auch nachgelagert sich an den Hals
hängen.

Ein durchdachtes Netz Layout wird das problemlos Inriegrieren.

Was ist mit WLAN , Backup , Sicherheit , alles Fragen die du vorab bedenken solltest.

Es gibt so einiges als Startup zu beachten , alles dinge die mirbekannt sind aus
meiner Zeit bei 2 Startups , von dem eines am Ende eine Nr 2 Gobal in seinem Bereich war.

Holger
 
Aktuell planen wir für 10 Mitarbeiter aber das Fundament sollte für 50 gesetzt sein.
im kern scheinst du ja mehr in Richtung VDI zu denken.
Ich würde hier einen weiteren Layer dazwischen setzten. Ich denke da an Proxmox [1] oder OpenNebula [2]. Damit kannst du deine Server problemlos erweitern und weitere Kapazitäten zur Verfügung stellen. Die VMs kann man dann für die Mitarbeiter dynamisch erstellen. Für den Zugriff würde ich Guacamole [3] versuchen. VPN etc. ist natürlich auch noch eine Variante.

Sollte ich auf 10, 20, 40Gbps oder doch lieber auf 100Gbps Ethernet Karten setzen?... Wie viel RAM und CPU benötigt mein Server?...
Reden wir hier vom Backend Netzwerk? Wenn ja dann mind. 10GBit/s. Wenn die Server alle SSD's haben dann kann es nicht schnell genug sein. Wegen CPU und RAM, dass kannst du dir ausrechnen: 30 VM's mit 16GB RAM macht: 480GB RAM.

[1] https://www.proxmox.com/de
[2] https://opennebula.io
[3] https://guacamole.apache.org
 
Als Desktop-Cloud-PC werden wir vermutlich BSD einsetzen.
Verstehe ich es richtig, dass die Nutzer auf einem BSD mit irgendeiner Desktopumgebung arbeiten werden? Da stellt sich das potentielle Problem, dass Remote Desktops unter allen freien Desktop-Systemen immer nur zweite Klasse waren und sind. Etwas mit der Eleganz und vor allem Effizient des in Windows integrierten RDP-Servers gibt es einfach nicht. Man kann es direkt machen, also mit einem Server innerhalb des Remotesystem. Dann läuft es de facto auf VNC mit all seinen Nachteilen - entweder direkt oder indirekt mit xrdp als Wrapper auf RDP - hinaus oder man nimmt eine proprietäre Lösung wie Anydesk mit den jeweiligen Nachteilen. Oder man kann es indirekt durch einen Hypervisor machen, wodurch man z.B. SPICE nutzen kann. Das ist zwar recht effizient und flexibel, bei den endnutzerfreundlichen Clients sieht es aber eher mau aus.

Das Problem ist definitiv lösbar, zur Not muss man halt selbst in die hauen und was bauen, aber man sollte es halt auf dem Zettel haben.
 
Genau das gleiche Konzept möchte ich für mein Startup umsetzen, aber auf eigenen Servern.

Was möchtest du denn als Produkt oder Dienstleistung mit deinem Startup anbieten? :cool:

Ich frage deswegen, weil sehr viele Startups daran pleite gehen, bei der Entscheidung build or buy nicht einfach eine existierende Lösung einzukaufen.

Genau das gleiche Konzept möchte ich für mein Startup umsetzen, aber auf eigenen Servern.

Welchen geschäftlichen Mehrwert hat das für dein Startup? Du wirst viel Geld und Arbeitszeit für etwas aufwenden, was selbst nach Monaten und Jahren schlechter laufen wird als deutlich günstigere existierende Lösungen.

Und nein, Github und Konsorten oder Clickup fü das Projektmanagement komme nicht in Frage.

Also auch kein GitLab, das du selber hosten kannst - sogar auf BSD?

Wir möchten die volle Kontrolle der Daten haben und das System auf dem entwickelt wird überwachen.

Ist dein Startup in einer regulierten Branche, die eine entsprechende Überwachung zwingend erfordert? Ansonsten kannst und willst du dir als Startup Micromanagement nicht leisten. :o

Endgeräte wie Laptops bereitzustellen ist keine Option :)

Gibt es dafür einen nachvollziehbaren Grund, den du im Interesse der Diskussion mit uns teilen möchtest? :confused:

Aktuell planen wir für 10 Mitarbeiter aber das Fundament sollte für 50 gesetzt sein.

Nachdem ich selber Softwareentwickler bin kann ich dir sagen, dass du mit diesem Setup arge Probleme bei der Mitarbeitergewinnung und -bindung haben wirst. Du bietest Softwareentwicklung auf Remote-Hardware in einer unerprobten sowie erst in Entwicklung befindlichen Umgebung unter BSD, auf dem viele als selbstverständlich betrachtete Entwickler-Tools mäßig bis überhaupt nicht funktionieren?

Bei den Rahmenbedingungen kriegst du entweder nur Grünschnäbel, die noch keine Ahnung haben, oder musst Veteranen für extrem viel Geld einkaufen. Bei letzteren konkurrierst du dann aber u.a. mit dem Finanzdienstleistungssektor, der solchen Leuten problemlos sechsstellige Jahresgehälter zahlen kann. Spitzenleute wirst du mit damit überhaupt keine bekommen.

Oder umgekehrt gefragt: warum sollte ein Entwickler in dein Startup kommen, wenn er unzählige andere Optionen hat?

Eine große Nummer die wir vorhaben. Vielleicht hat hier jemand ja Erfahrungen.

Wie sieht denn euer MVP aus? Die meisten Startups scheitern daran, dass sie eine große Nummer vorhaben und dabei vergessen, dass der Weg dorthin mit vielen kleinen Nummern gepflastert ist. :ugly:

Eine große Nummer die wir vorhaben.

Das haben alle vor - trotzdem gehen 9 von 10 Pleite. :o

Vielleicht hat hier jemand ja Erfahrungen.

Aus Erfahrung kann ich dir sagen, dass schon mit üppiger Finanzierung ausgestattete Startups mit solchen Plänen Pleite gegangen sind. Der Aufbau eigener IT-Infrastruktur ist einer der Kardinalsfehler schlechthin. Das bindet enorm Kapital und Arbeitskraft und macht dich völlig unflexibel. Du musst bei deiner IT-Infrastruktur damit umgehen können, dass du in Rekordzeit von 5 auf 50 auf 500 auf 50 Leute skalierst.

Während du mit deiner IT-Infrastruktur kämpfst, buttert die Konkurrenz alles in ihr Produkt und fegt dich vom Markt. :(

Ich habe vor kurzem das hier gesehen [1]. Dort läuft ein Manjaro Linux komplett im Browser. Keine Ahnung, was da an Technologie verwendet wird.

Das ist ein UI-Fake, da läuft kein echtes Manjaro dahinter.
 
Vielen Dank für die zahlreichen Antworten.

Ich versuche mal allen zu antworten :)

Wenn also die Mitarbeiter keine eigenen PC als Arbeitspatz haben sollen,
und es mehr Richtung Terminal gehen soll , was spricht das gegen ein
Xserver / Teminal Thema.

Guter Frage, darüber habe ich nicht nachgedacht...

Jedoch wirst du mittelfristig nicht ohne Windows auskommen da es z.b.
in der Buchaltung ziemlich Windows lastig zu geht.

Eine Non-Windows-Variante wird es schon geben. Lexoffice Online würde auch unsere Anforderungen zum Großteil abdecken, aber man muss schon schauen, da hast du recht.
Was ist mit WLAN , Backup , Sicherheit , alles Fragen die du vorab bedenken solltest.

WLAN wollen wir nicht. Zu viele Strahlungen sind nicht gut :) Und ist auch ziemlich unsicher. Security hat einen hohen Stellenwert im Konzept.
Ich würde hier einen weiteren Layer dazwischen setzten. Ich denke da an Proxmox [1] oder OpenNebula [2]. Damit kannst du deine Server problemlos erweitern und weitere Kapazitäten zur Verfügung stellen. Die VMs kann man dann für die Mitarbeiter dynamisch erstellen. Für den Zugriff würde ich Guacamole [3] versuchen. VPN etc. ist natürlich auch noch eine Variante.


Reden wir hier vom Backend Netzwerk? Wenn ja dann mind. 10GBit/s. Wenn die Server alle SSD's haben dann kann es nicht schnell genug sein. Wegen CPU und RAM, dass kannst du dir ausrechnen: 30 VM's mit 16GB RAM macht: 480GB RAM.

[1] https://www.proxmox.com/de
[2] https://opennebula.io
[3] https://guacamole.apache.org

Danke, ja wir reden hier vom Backend Netzwerk
Verstehe ich es richtig, dass die Nutzer auf einem BSD mit irgendeiner Desktopumgebung arbeiten werden? Da stellt sich das potentielle Problem, dass Remote Desktops unter allen freien Desktop-Systemen immer nur zweite Klasse waren und sind. Etwas mit der Eleganz und vor allem Effizient des in Windows integrierten RDP-Servers gibt es einfach nicht. Man kann es direkt machen, also mit einem Server innerhalb des Remotesystem. Dann läuft es de facto auf VNC mit all seinen Nachteilen - entweder direkt oder indirekt mit xrdp als Wrapper auf RDP - hinaus oder man nimmt eine proprietäre Lösung wie Anydesk mit den jeweiligen Nachteilen. Oder man kann es indirekt durch einen Hypervisor machen, wodurch man z.B. SPICE nutzen kann. Das ist zwar recht effizient und flexibel, bei den endnutzerfreundlichen Clients sieht es aber eher mau aus.

Das Problem ist definitiv lösbar, zur Not muss man halt selbst in die hauen und was bauen, aber man sollte es halt auf dem Zettel haben.

Es muss am Ende des Tages nicht BSD werden. Es läuft aber auf ein unixoides System hinaus. Eine andere Alternative haben wir ja nicht. Wir wollen mit dem Projekt auf Open Source setzen und wollen weg von den gierigen Datenkraken. Das sehe ich persönlich auch einfach zu realisieren. Es gibt schließlich genug Freie Software.
Was möchtest du denn als Produkt oder Dienstleistung mit deinem Startup anbieten? :cool:

Ich frage deswegen, weil sehr viele Startups daran pleite gehen, bei der Entscheidung build or buy nicht einfach eine existierende Lösung einzukaufen.

Es wird ein Blockchain - Projekt, welches Services für B2B, B2C und Regierungen bereitstellt.
Welchen geschäftlichen Mehrwert hat das für dein Startup? Du wirst viel Geld und Arbeitszeit für etwas aufwenden, was selbst nach Monaten und Jahren schlechter laufen wird als deutlich günstigere existierende Lösungen.

Das sehe ich ehrlich gesagt nicht so. Selbstverständlich kann sich nun ein Startup nicht mit Google und Konsorten vergleichen. Aber Google zeigt mit Stadia das Cloud Gaming sehr gut funktioniert. Auf der anderen Seite benötigen wir keine Latenzen wie im Gaming und habe eine überschaubare Teilnehmeranzahl.

Wenn wir den Mitarbeiter Laptops bereitstellen, dann werden diese pro User 2.000,- EUR kosten + Wartungskosten, Ersatzteile und Verschleiss. Wenn der Mitarbeiter dann im tiefsten Dschungel in Thailand sitzt, müssten wir Laptops mit hochsensiblen Daten durch die Welt versenden. Das ist ein No-Go. Klar gibt es auch hochsichere und überteuerte Versandmethoden.

Vielleicht etwas zu kurz gedacht aber bevor wir 20.000 € für Laptops + zzgl. Ersatzteile etc. für Hardware ausgegeben, die vermutlich in einigen Jahren verranzt sind - vermutlich auch defekt sind - investieren wir das Kapital lieber in performantere Server.
Also auch kein GitLab, das du selber hosten kannst - sogar auf BSD?

Bei GitLab bin ich dabei ...
Nachdem ich selber Softwareentwickler bin kann ich dir sagen, dass du mit diesem Setup arge Probleme bei der Mitarbeitergewinnung und -bindung haben wirst. Du bietest Softwareentwicklung auf Remote-Hardware in einer unerprobten sowie erst in Entwicklung befindlichen Umgebung unter BSD, auf dem viele als selbstverständlich betrachtete Entwickler-Tools mäßig bis überhaupt nicht funktionieren?

Bei den Rahmenbedingungen kriegst du entweder nur Grünschnäbel, die noch keine Ahnung haben, oder musst Veteranen für extrem viel Geld einkaufen. Bei letzteren konkurrierst du dann aber u.a. mit dem Finanzdienstleistungssektor, der solchen Leuten problemlos sechsstellige Jahresgehälter zahlen kann. Spitzenleute wirst du mit damit überhaupt keine bekommen.

Die Grünschnäbel kommen uns nicht ins Haus. In 'nem Blockchain Projekt werden wir vermutlich auch niemanden unter 100k kriegen. Daher rechnen wir schon mit 6 stelligen Jahresgehältern.
Das haben alle vor - trotzdem gehen 9 von 10 Pleite. :o

Mit einer guten Planung wird das schon. Aber ich weiß was du meinst... Wir sind vorsichtig.
Aus Erfahrung kann ich dir sagen, dass schon mit üppiger Finanzierung ausgestattete Startups mit solchen Plänen Pleite gegangen sind. Der Aufbau eigener IT-Infrastruktur ist einer der Kardinalsfehler schlechthin. Das bindet enorm Kapital und Arbeitskraft und macht dich völlig unflexibel. Du musst bei deiner IT-Infrastruktur damit umgehen können, dass du in Rekordzeit von 5 auf 50 auf 500 auf 50 Leute skalierst.

Während du mit deiner IT-Infrastruktur kämpfst, buttert die Konkurrenz alles in ihr Produkt und fegt dich vom Markt. :(

Sehe ich nicht so. Anfang nächstes Jahr fangen wir "so richtig" an und fangen an Mitarbeiter einzustellen. Bis dahin wird die gesamte Infrastruktur konzipiert und implementiert und ggf. ein paar Mitarbeiter an Land gezogen um die Infrastruktur zu perfektionieren. In der Zwischenzeit wird auch das "Produkt" genauer spezifiziert.

Und wenn die Server einmal gekauft sind, haben wir wesentlich geringere Kosten als wenn wir alles Mieten und Leasen würden.

Sklalierbarkeit ist für uns auch sehr wichtig und genau deshalb wollen wir alles in eigenen Händen halten.
 
Das sehe ich ehrlich gesagt nicht so. Selbstverständlich kann sich nun ein Startup nicht mit Google und Konsorten vergleichen. Aber Google zeigt mit Stadia das Cloud Gaming sehr gut funktioniert. Auf der anderen Seite benötigen wir keine Latenzen wie im Gaming und habe eine überschaubare Teilnehmeranzahl.

Google hat Stadia de-facto fallen gelassen weil es eben nicht wirklich funktioniert hat.

Es wird ein Blockchain - Projekt, welches Services für B2B, B2C und Regierungen bereitstellt.

Ich würde gerne in einem Jahr einen Statusbericht zu dem Projekt lesen. Und das meine ich aufrichtig.
 
Ich hab Jahrelang ein Linux-Terminalserversystem betreut mit "Igel" Thin-Clients und ne ganze menge des damals verfügbaren zeugs durchprobiert.

Die beste Chance war der xrdp server, aber meine Erfahrung vor einigen Jahren, der wird nach schon wenigen usern nach rel. kurzer zeit instabil, und videos ließen sich auch mit damals recht potenter Hardware z.B. nicht schauen. Audio ist auch ne ziemlich komplexe sache.

Zumal man pro user, wenn man die Performance / RAM eines 2K Notebooks haben möchte auch ordentlich in Server-Hardware investieren muss.

Dann kommt natürlich noch die Anbindung der Clients hinzu, wenn das "Lokal" laufen soll natürlich nicht so spannend, aber wie schauts mit Homeoffice, Mobile user e.t.c. aus. Hast du z.B. 2x 4K Bildschirme wird da auch "nen büsschen" über die Leitung gezogen.

Meine Erfahrungen mit einigen hundert usern: Das Konzept Terminalserver ist toter als tot, und das nochmal "ontop" mit Linux o.ä.
Und der Mehrwehrt oft sehr sehr viel kleiner als man glaubt.

Wenn ihr sowas bauen wollt, hut ab, aber vermutlich werdet ihr da genauso viel entwicklung reinstecken wie in das Produkt selbst, villeicht wollt ihr das System dann auch verkaufen?

Viele die in dem Bereich mal aktiv waren (z.B. Nomachine), auch mit einigen dutzend MA exclusiv dafür, sind lange pleite oder haben den Geschäftsbereich aufgegeben.
 
Und wenn die Server einmal gekauft sind, haben wir wesentlich geringere Kosten als wenn wir alles Mieten und Leasen würden.
Sie mir nicht böse, aber wenn ich dir einen Rat geben darf: Wenn du es noch nicht hast, bezahle einen fähigen Kaufmann zum Ausarbeiten eines belastbaren Geschäfts- und Investitionsplans. Dieser Satz zeigt, dass du keine Ahnung vom kaufmännischen Teil einer Unternehmensführung hast. Das ist nicht weiter schlimm und muss einem auch nicht peinlich sein. Die wenigstens ITler sind gute Kaufleute und umgeehrt sind die wenigsten Kaufleute gute ITler. Dafür gibt es schließlich unterschiedliche Berufsfelder. Nur sollte die eine Gruppe nicht so vermessen sein, die Tätigkeiten der anderen Gruppe nach ein paar Wochenendseminaren nebenbei mitmachen zu können. Das geht in totsicher eher früher als später die Hose!
 
Sie mir nicht böse, aber wenn ich dir einen Rat geben darf: Wenn du es noch nicht hast, bezahle einen fähigen Kaufmann zum Ausarbeiten eines belastbaren Geschäfts- und Investitionsplans. Dieser Satz zeigt, dass du keine Ahnung vom kaufmännischen Teil einer Unternehmensführung hast. Das ist nicht weiter schlimm und muss einem auch nicht peinlich sein. Die wenigstens ITler sind gute Kaufleute und umgeehrt sind die wenigsten Kaufleute gute ITler. Dafür gibt es schließlich unterschiedliche Berufsfelder. Nur sollte die eine Gruppe nicht so vermessen sein, die Tätigkeiten der anderen Gruppe nach ein paar Wochenendseminaren nebenbei mitmachen zu können. Das geht in totsicher eher früher als später die Hose!

Nein, bin über jeden Ratschlag dankbar. Die Diskussion habe ich genau aus dem Grund angestoßen. Andere Meinungen zu hören und vor allem auch die Tipps anzunehmen.

In der Tat ist der kaufmännische Teil nicht mein Part - Gott sei Dank - und es wird gerade auch Unterstützung in dem Bereich gesucht. Ansonsten wären wir wohl zum Scheitern verurteilt...
 
hi

also , eine eigene infrastruktur ist nie verkehrt , grade wenn sicherheit und datenschutz eine rolle spielt.
cloud loesungen sind , auf dauer , teuerer als eigene hardware.

man muss ja nicht den , bei den meisten firmen vorhanden , ansatz der monokultur windows fahren, es gibt
fuer viele it infrastruktur themen gute lösungen im opensource bereich.

und das terminal thema ist mm. nicht tot citrix und vmware sind mit ihren VDI lösungen
gut im geschäft , und es schliesst ja eigene pc fuer mitarbeiter nicht aus .




holger
 
Und wenn die Server einmal gekauft sind, haben wir wesentlich geringere Kosten als wenn wir alles Mieten und Leasen würden.
Sie mir nicht böse, aber wenn ich dir einen Rat geben darf: Wenn du es noch nicht hast, bezahle einen fähigen Kaufmann zum Ausarbeiten eines belastbaren Geschäfts- und Investitionsplans. Dieser Satz zeigt, dass du keine Ahnung vom kaufmännischen Teil einer Unternehmensführung hast. Das ist nicht weiter schlimm und muss einem auch nicht peinlich sein. Die wenigstens ITler sind gute Kaufleute und umgeehrt sind die wenigsten Kaufleute gute ITler. Dafür gibt es schließlich unterschiedliche Berufsfelder. Nur sollte die eine Gruppe nicht so vermessen sein, die Tätigkeiten der anderen Gruppe nach ein paar Wochenendseminaren nebenbei mitmachen zu können. Das geht in totsicher eher früher als später die Hose!
Ich wollte hier noch nachhaken. Obwohl ich keine Ahnung von der Materie habe ist schon einiges an Betriebskosten zu erkennen:

Du musst die Hardware über den Nutzungszeitraum abschreiben, die Hardware sollte sich aus offensichtlichen Gründen schneller amortisieren als Du sie abschreibst. Ausfallsicherheit bedeutet Redundanz, das heißt Extra-Kosten die nichts zum Profit beitragen. Zumindest Backup/Restore kann man dem Kunden aber verkaufen. In Zeiten von Crypto-Malware ist kein Backup russisches Roulette.

Am Ende des Abschreibungszeitraums musst Du wohl neue Hardware anschaffen, da der Betrieb in der Regel nicht mehr wirtschaftlich ist, die Leistung/Watt ist nicht mehr konkurrenzfähig, Wartungsaufwand steigt, Ersatzteile werden knapp und damit teurer etc.. Hardware muss überwacht und gewartet werden.

Die Hardware mag sich amortisiert haben aber dann musst Du ja neue kaufen und die ursprüngliche Investition willst Du ja auch irgendwann mal raus holen. Am Ende bleibt die Frage ob der Betrieb von Hardware eine Kernkompetenz ist und ob die Unternehmung groß genug ist um die Skaleneffekte mitzunehmen damit der Eigenbetrieb tatsächlich günstiger ist als der Cloud Dienstleister. Der macht ja auch Profit, das spielt dem Eigenbetrieb natürlich in die Hände.
 
Aus eigener Erfahrung muss ich auch sagen: Was den Kernbereich des Business angeht, kann es Sinn machen, auf selbst-gestrickte Lösungen zu setzen. Da kennt man sich aus, da haben die Mitarbeiter:innen vermutlich viel Know-how und hiermit will man sich ja von den Wettbewerbern absetzen. Bei allem anderen muss man aber sehen, dass man nicht zu viel Zeit/Kraft reinsteckt. Ich würde hier nicht mehr zu weit vom Standard abweichen, zumindest für alles, was nicht leicht gegen Alternativen austauschbar ist.

Ich bin da durchaus ein gebranntes Kind: Wir wollten in unserer kleinen Firma mal ein CRM einführen und hatten auf die Community-Version von SugarCRM gesetzt. Die wurde dann aber ca. 2 Jahre später eingeschläfert. Die neueren Versionen waren nur noch proprietär zu haben. Dann haben wir doch auf eine SaaS-Lösung gesetzt.

Enigmail: Wir haben jahrelang alle Mails unter uns verschlüsselt. Dann wurde Enigmail kürzlich eingestellt und Thunderbird's eigene PGP-Implementierung war (ist?) bei weitem noch nicht da, wo Enigmail vorher war. Hier war es leicht: Wir lassen das verschlüsseln vorerst. Zumal eh zunehmend Mitarbeiter:innen per iOS zugreifen wollten und Apple für sein Mail-Client kein PGP anbietet. Andere iOS-Clients habe ich mir angeschaut und war auch nicht gerade begeistert. Auch hier: Jede Abweichung vom Standard (Nutzung von GnuPG) erhöht letztlich den Aufwand, schränkt Technologiewahlen ein, und stellt ein höheres Risiko für die Zukunft dar.

Derzeit sind wir auf Suche nach einer für uns praktikablen Lösung für ein E-Mail-Ticketing System. Früher war da OTRS der Platzhirsch unter den Opensource-Angeboten. Aber auch hier wurde die Community-Version vor einiger Zeit eingeschläfert. Es gibt Nachfolge-Projekte, aber keines davon sieht mir groß/kräftig genug aus, dass ich mich darauf verlassen wollen würde. Daher schauen wir jetzt nach einer Standard-SaaS-Lösung. Ist nicht mein Wunsch, aber die Hoffnung auf längerfristigen Support sowie die gute Benutzbarkeit sind uns dann doch wichtiger.

In Sachen Buchhaltung haben wir von Beginn an auf eine kommerzielle Lösung, MonkeyOffice, gesetzt. Läuft allerdings nur unter Winows oder macOS. Das war lange Zeit kein Problem; der Kollege hat das in einer VirtualBox auf seinem Ubuntu-Laptop laufen. Da musste er normal 2-3 Mal im Monat dran, um die Rechnung einzugeben bzw. zu erstellen. Mittlerweile muss er aber so häufig dran, dass es lästig wird, immer die virtuelle Maschine zu starten... daher gucken wir nun nach einer Alternative - Windows-Hosting mit Zugriff per RDP oder auch andere Buchhaltungs-Software. Auch hier kostet uns die Nutzung von Linux/BSD extra Zeit/Kraft, weil wir nicht die Standard (Windows)-Lösung verwenden können/wollen. Der Kollege überlegt jetzt sogar, nach ca. 20 Jahren Linux auf dem Laptop aufzugeben und auf ein Apple-Gerät/macOS umzusteigen...

Ich würde daher Vorsicht walten lassen, wenn es um Software/Infrastruktur geht, die nicht der Kernbereich des Geschäfts betrifft. Wir zumindest haben nicht die Kapazität, ein Opensource-Projekt eigenständig fortzuführen, wenn wir eine Software weiter nutzen wollen, die plötzlich nicht mehr weiterentwickelt wird. Aber wir fördern regelmäßig Projekte, deren Software wir direkt oder indirekt nutzen, z.B. Matomo, eine freie und Privacy-freundliche Alternative zu Google Analytics.
 
Wenn wir den Mitarbeiter Laptops bereitstellen, dann werden diese pro User 2.000,- EUR kosten + Wartungskosten, Ersatzteile und Verschleiss.

2.000€ ist ~1 Arbeitswoche eines Entwicklers - also Peanuts im Vergleich zu den restlichen Kosten. Zumal dich deine VDI-Lösung auf jeden Fall mehr kosten wird.

Wenn der Mitarbeiter dann im tiefsten Dschungel in Thailand sitzt, müssten wir Laptops mit hochsensiblen Daten durch die Welt versenden. Das ist ein No-Go.

Datenträgerverschlüsselung existiert und wird von so ziemlich jeder SSD und jedem Betriebssystem out of the box unterstützt.

Klar gibt es auch hochsichere und überteuerte Versandmethoden.

Mit DHL wären es 88€ (46€ Versand plus 42€ für 3.000€ Höherversicherung).

Vielleicht etwas zu kurz gedacht aber bevor wir 20.000 € für Laptops + zzgl. Ersatzteile etc. für Hardware ausgegeben, die vermutlich in einigen Jahren verranzt sind - vermutlich auch defekt sind - investieren wir das Kapital lieber in performantere Server.

Eure Mitarbeiter brauchen ja dann trotzdem Laptops oder setzt du auf BYOD?

Welche Vorteile versprichst du dir denn sonst von der VDI-Lösung? Bis jetzt sehe ich ausschließlich Nachteile (mehr Kosten, mehr Aufwand, schlechtere Usability).

Mit einer guten Planung wird das schon. Aber ich weiß was du meinst... Wir sind vorsichtig.

Als Selbständiger kann ich den Hang und Drang zur Selbständigkeit bestens verstehen (ich würde Stand heute nicht mehr in eine Festanstellung zurückgehen). Aus meiner Erfahrung kann ich dir aber nur nahelegen, dir (einen) Mitgründer mit solidem betriebswirtschaftlichen Know-How zu suchen.

Sehe ich nicht so. Anfang nächstes Jahr fangen wir "so richtig" an und fangen an Mitarbeiter einzustellen. Bis dahin wird die gesamte Infrastruktur konzipiert und implementiert und ggf. ein paar Mitarbeiter an Land gezogen um die Infrastruktur zu perfektionieren.

Verstehe ich das richtig? Du (plus dein(e) Mitgründer) wollen sehr viel Zeit und Geld für Infrastruktur - was nicht euer Geschäft ist - verwenden, anstatt voll an eurem Produkt zu arbeiten? :eek:

Und wenn die Server einmal gekauft sind, haben wir wesentlich geringere Kosten als wenn wir alles Mieten und Leasen würden.

Die Rechnung geht in den meisten Fällen schon nicht auf, bevor man die Opportunitätskosten berücksichtigt (siehe das Beispiel im nächsten Absatz).

Skalierbarkeit ist für uns auch sehr wichtig und genau deshalb wollen wir alles in eigenen Händen halten.

Gerade Skalierbarkeit ist doch das Argument schlechthin gegen Self-Hosting.

Spielen wir mal ein Szenario für ein Startup an einem Freitag durch:

Dev: "Hey, wir haben in unserem Blockchain-Produkt ein obskures Problem, das nur sporadisch unter hoher Last auftritt. Der Kunde ist schon etwas genervt, weil wir schon eine Weile daran sitzen. Ich bräuchte übers Wochenende mal etwas CPU-Power, damit ich das Verhalten nachvollziehen kann."
Ops: "Kein Problem - reichen dir 100 Cores?"
Dev: "Ich bräuchte eher so 10.000 Cores."
Wie läuft das jetzt in Folge ab?

Firma A bei einem Cloud-Provider:

Firma A bei einem Cloud-Provider startet unmittelbar seinen vorhandenen Lasttest-Job mit mit veränderten Parametern, Kostenpunkt ~3.000€ für 10.000 CPU-Cores für 48h. Das Kundenproblem kann zeitnah gelöst werden.​

Firma B als Self-Hoster:

Firma B als Self-Hoster kann den Lasttest mangels Kapazität nicht durchführen, d.h. wichtige Erkenntnisse zur Problembehebung fehlen.

Firma B hat jetzt zwei Möglichkeiten.

Eine davon ist den Kunden zu verlieren, was für das Überleben der Firma jetzt nicht so prickelnd ist.

Die andere ist die Beschaffung neuer Hardware, was je nach Lieferbarkeit einige Wochen (aktuell gern auch länger) dauert und einen sechstelligen Betrag nur für die Anschaffung kostet. Jeden Monat verursacht sie laufende Kosten durch Hosting/Strom/Kühlung. Es sind durch die Administration auch Mitarbeiter gebunden, die eigentlich an der Weiterentwicklung des Produkts der Firma arbeiten sollten. Der Kunde ist angepisst, weil man ihn auf einen Zeitpunkt weit in der Zukunft vertrösten muss.
Welche der beiden Lösungen skaliert noch gleich besser?

Interessant wird die Rechnung dann bei Folge 2 mit der Erkenntnis des Entwicklers, dass das Problem ganz wo anders herkommt, man den enormen Lasttest eigentlich gar nicht gebraucht hätte und ein völlig anderes Test-Setup benötigt...

also , eine eigene infrastruktur ist nie verkehrt , grade wenn sicherheit und datenschutz eine rolle spielt.

Wenn man nicht gerade den billigsten Anbieter nimmt, machen die meisten Hoster und Cloud-Anbieter einen deutlich besseren Job als man als KMU jemals könnte. Man braucht schon eine beträchtliche Größe, Kapital und Know-How, um dort gleichziehen zu können.

cloud loesungen sind , auf dauer , teuerer als eigene hardware.

Das hängt vom Anwendungsfall ab.

Allein die 24/7-Besetzung eines IT-Leitstands plus Bereitschaftsdienste der 2nd-Level-Ansprechpartner kostet dich Summen, von denen du verdammt viele Cloud-Setups bezahlen kannst. Von den Kosten für die eigenen Rechenzentren (du brauchst ja mindestens 2) wollen wir gar nicht anfangen...
 
sorry , wir reden hier von einem startup , bei dem vieles seber gemacht werden soll /kann.

man kann das system so aufsetzen das man einen hybriden ansatz ( on permise in neu deutsch )
fährt.

ich habe kein problem mit der cloud wenn sie die DsGVO einhält und Transparent ist.

nur ob ich am am start meines buisness mich komplett abhängig machen wuerde ich mir 3x
ueberlegen,von daher eher einen hybriden ansatz.

was nicht beutet das ich z.b. nicht ein vlan und samt darin laufen server bei netcup mieten
wuerde.

die mischung zum produkt / buisness ziel ist da auschlaggebend.

amazon/azue/apple/google sind wirklich nur zum scalieren gut und nicht fuer permanent hosten.

das wird jeder der schon ausfälle mit genannten cloud anbieter mitgemacht hat bestätigen.

bei aws war mein längster ausfall knapp 24 std in dem das produkt , welches dort gehostet war ,
nicht produktiv arbeiten konnte.

von daher bin ich auch ein gebranntes kind , wenn ich die datenschutz brille gar nicht erst anziehe.

die verwendung einer vdi umgebung schliesst ja nicht aus das das terminal auf einem notebook
laeuft auf dem der entwickler seine software schreibt.

holger
 
Mitarbeiter sollen über einen Client sich mit dem Desktop in der Cloud verbinden und von da aus arbeiten.
...

Endgeräte wie Laptops bereitzustellen ist keine Option :)
Dh die Leute müssen ihren eigenen Kram mitbringen, können darauf aber nicht das laufen lassen, was sie wollen sondern nutzen ihre eigene Hardware nur für den Remote Zugriff?
Wer macht denn sowas mit?

Ein Server für Nextcloud, Gitlab usw kostet bei Hetzner keine 100 Euro im Monat. Das Ding kann man auch Vollverschlüsseln wenn man will. Dann bekommt jeder ein MBP 13" für 1200 Euro oder ein Thinkpad für den gleichen Preis und die Bude kann losrocken. Versteh jetzt das Problem nicht.
 
Ich habe eine VDI Umgebung (Citrix) für über 1.000 Mitarbeiter aufgebaut und anschließend jahrelang auch betreut. Aus meiner Sicht sind noch einige Punkte unklar bzw. habe ich Sie überlesen.
  • Was sind die Anforderungen die für eine VDI Lösung und gegen die Entwicklung, Datenablage, etc. auf lokalen Clients sprechen? Ist es Schutz der entwickelten Lösung (IP, Stichwort Data Loss Prevention)? Falls ja, wie wird im VDI Setup der Abfluss der Daten/entwickelten Lösung verhindert?
  • Was sind die Gründe für BSD bzw. gegen Linux, Windows, OSX? Wer gibt Dir Support, falls Du Probleme mit BSD bekommst?
  • Was soll entwickelt werden? Ist es Ressourcenlastig (CPU, RAM, Storage)? Braucht ggf. jeder Entwickler seinen eigenen Server?
  • Wie erfolgt das Backup und der Restore der Daten (Nextcloud, git Repo, E-Mail, etc.)? Ggf. ist das Thema rechtssichere Archivierung relevant (u.a. für E-Mails).
  • Wie wird intern und nach extern kommuniziert? Teams, Slack, E-Mail, ... Wo wird diese Kommunikationsplattform gehostet (beim Hoster der Domäne)?
  • Wie erfolgt das Onboarding der Mitarbeiter (Account, Homedrive, Passwortübergabe, Endgeräte, ...).
  • Wer betreut die Infrastruktur? Wie sehen die Verfügbarkeitsanforderungen an die Infrastruktur aus (SLA, RPO, RTO). Bei 50 MA betreut man das ganze nicht mehr nebenbei.
  • Gibt es ein einheitliches Entwicklertoolset oder soll/kann sich jeder seine Tools selber installieren? Wir wird hier sichergestellt, dass die Versionen zueinander kompatibel sind (git/NetCloud Client und Server, ...)

Das Thema Bandbreite und Latenz ist aus meiner Erfahrung das geringste Problem. Für professionelle Lösungen (u.a. Citrix) gibt es einen Bandbreitenrechner, der Dir je nach Nutzung (mit/ohne Print, mit/ohne Audio-/Videostream, etc.) die benötigte Bandbreite ausrechnet. Aus meiner Erfahrung sind die Ressourcen der VDI Umgebung (CPU, RAM, Storage, ggf. GFX) das größere Problem.
 
Guten Abend,
@overflow : aus eigener Erfahrung und mit dem, was ich in Deinem Beitrag gelesen habe, kann ich dir nur eins empfehlen: Sucht Euch einen sehr guten IT-Kaufmann, der mit euch zusammen mal alles durchkalkuliert. Denke immer daran - das haben wir anfangs auch unterschätzt, bis unser Berater uns das mal klar gemacht hat - Kleinvieh macht immer viel Mist. Ich meine Miete und Nebenkosten, Energiekosten, Versicherungen, Rücklagen, guter(!) Steuerberater, Kreditkosten usw. Sicherlich kann man einiges davon steuerlich geltend machen, aber bevor es soweit ist, muss erstmal bezahlt werden...

Nur mal so meine Gedanken dazu
 
Fast ein Jahr ist ins Land gezogen. Ich hatte am Wochenende mit Freunden eine Diskussion, in der es auch um das Thema Unix-VDI ging. Dabei musste ich an diesen Thread denken.

Sehe ich nicht so. Anfang nächstes Jahr fangen wir "so richtig" an und fangen an Mitarbeiter einzustellen. Bis dahin wird die gesamte Infrastruktur konzipiert und implementiert und ggf. ein paar Mitarbeiter an Land gezogen um die Infrastruktur zu perfektionieren. In der Zwischenzeit wird auch das "Produkt" genauer spezifiziert.

Wie sieht es ein Jahr später aus? :)
 
Firma A bei einem Cloud-Provider startet unmittelbar seinen vorhandenen Lasttest-Job mit mit veränderten Parametern, Kostenpunkt ~3.000€ für 10.000 CPU-Cores für 48h. Das Kundenproblem kann zeitnah gelöst werden.
Hast du das schonmal probiert? Ich glaube nicht, denn das geht auch bei Amazon, Google und Co. nicht zwangsweise in 48 Stunden. Auch nicht wenn du gegenüber anderen Kunden schonmal eine leichte Besserstellung erarbeitet hast. Durfte das mal miterleben und im konkreten Fall wäre so ziemlich jeder größere Anbieter von dedicated Servern und wohl auch selber hosten schneller skaliert gewesen. Details sind hinter einem NDA, aber ich sag mal das war bei einem von den ganz großen Cloud-Providern und weniger als 10k CPU-Cores. Wenn der NDA mal weg ist schreib ich gern mal mehr darüber, aber ist noch nicht so lange her, aber immerhin schon lange genug, dass Supply Chains kein großes Thema waren.

Ich will deiner grundsätzlichen Aussage nicht widersprechen, nur dass das Thema Skalierung mit einer Cloud definitiv nicht gegessen ist, auch wenn gern mal so getan wird. Da stehen große Unternehmen dahinter, die kosten optimieren wollen. Man muss bedenken, dass Cloud-Lösungen eben auch für Anbieter große Vorteile bieten. Die müssen auch nicht immer riesige Mengen an Ressourcen bereithalten. Klar, geht das auf's Image, aber gerade wenn man ein größerer Anbieter ist kann man sich sowas auch leisten. Ich meine welchem großen Unternehmen schaden die ständigen Negativschlagzeilen wirklich?

EDIT: Ups, gerade gesehen, dass das Mai letztes Jahr war. Wohl Zeit für's Bett. ;)
 
Hast du das schonmal probiert? Ich glaube nicht, denn das geht auch bei Amazon, Google und Co. nicht zwangsweise in 48 Stunden. Auch nicht wenn du gegenüber anderen Kunden schonmal eine leichte Besserstellung erarbeitet hast. Durfte das mal miterleben und im konkreten Fall wäre so ziemlich jeder größere Anbieter von dedicated Servern und wohl auch selber hosten schneller skaliert gewesen. Details sind hinter einem NDA, aber ich sag mal das war bei einem von den ganz großen Cloud-Providern und weniger als 10k CPU-Cores. Wenn der NDA mal weg ist schreib ich gern mal mehr darüber, aber ist noch nicht so lange her, aber immerhin schon lange genug, dass Supply Chains kein großes Thema waren.
Wir tun das tatsächlich in einem Projekt, wo wir zum Training manchmal auf bis zu 8.000 Cores Skalieren und zwar On-Demand. Allerdings sollte ich dazu sagen dass wir das nicht in einer einzigen Region tun sondern über mehrere Regionen verteilen. Wenn GPUs benötigt werden ist das meiner Erfahrung nach aber tatsächlich nicht so einfach.
 
Hast du das schonmal probiert? Ich glaube nicht, denn das geht auch bei Amazon, Google und Co. nicht zwangsweise in 48 Stunden.

Ich kann aus eigener Erfahrung berichten, dass noch viel größere Setups bei AWS, Azure und GCP problemlos provisionierbar sind. Man läuft höchstens in die vorkonfigurierten soft limits, die man aber jederzeit erweitern kann.

Auch nicht wenn du gegenüber anderen Kunden schonmal eine leichte Besserstellung erarbeitet hast.

Das brauchst du nicht. 10000 Cores sind ja auch nicht mal 100 Server, Rauschen in der Statistik eines Public-Cloud-Providers.

Durfte das mal miterleben und im konkreten Fall wäre so ziemlich jeder größere Anbieter von dedicated Servern und wohl auch selber hosten schneller skaliert gewesen.

Dann müsste man die Rahmenbedingungen kennen, um beurteilen zu können, wo das Problem lag. Jeden Tag skalieren zahllose Unternehmen weit jenseits des erwähnten Beispiels.

Details sind hinter einem NDA, aber ich sag mal das war bei einem von den ganz großen Cloud-Providern und weniger als 10k CPU-Cores. Wenn der NDA mal weg ist schreib ich gern mal mehr darüber, aber ist noch nicht so lange her, aber immerhin schon lange genug, dass Supply Chains kein großes Thema waren.

Das würde mich sehr freuen und interessieren. :)

Wir tun das tatsächlich in einem Projekt, wo wir zum Training manchmal auf bis zu 8.000 Cores Skalieren und zwar On-Demand. Allerdings sollte ich dazu sagen dass wir das nicht in einer einzigen Region tun sondern über mehrere Regionen verteilen. Wenn GPUs benötigt werden ist das meiner Erfahrung nach aber tatsächlich nicht so einfach.

Das deckt sich mit meiner Erfahrung. Abseits des GPU-Engpasses (der dank Bitcoin-Boom und GPU-Mangel auch die Cloud-Provider betroffen hat) und des Beginns der Pandemie (Azure war regional am Limit) bin ich persönlich bei der großen 3 Cloud-Providern noch nie auf Hardware-bedingte Begrenzungen gestoßen.
 
Hier sind meine 1000 Cores ;-) hihi
 

Anhänge

  • kirschen.webp
    kirschen.webp
    40,6 KB · Aufrufe: 168
Zurück
Oben