Welche PaaS für EDA?

[ioe]

Hallo Forum

Ich habe eine kleines Event getriebenes System Entwickelt und würde das gerne in der Cloud hosten.
Die Anwendung läuft in einem Docker Stack, sprich sowohl die proprietären als auch die unterstützenden Applikationen sind Container.
Die Performance ist nicht so wichtig, wichtiger ist der 24/7 Betrieb (daher will ich auch keinen VPS mit Docker etc).
Die Applikation benötigt auch nicht viele Ressourcen (die CPU Zeit ist gering)

Ich habe mir bereits ein paar Cloudanbieter wie AWS ECS, Google Run usw. angesehen. Aber bin noch unschlüssig.
Die einzigen Anforderungen sind ein Serverstandort in AT oder DE und dass CI/CD unterstützt wird. Schön wäre noch wenn man die Docker Volumes supported werden.

Selber einen Kubernetes Cluster aufsetzen will ich vermeiden.

Die Applikation verwendet MongoDB, Influx, Redis und Kafka und benötigt einen Proxy.

Was würdet ihr an meiner Stelle unternehmen?

vg

 

[snaxilian]

Die einzigen Anforderungen sind ein Serverstandort in AT oder DE

Geht es dir hier um Latenz oder rechtliche Sicherheit? Bei letzterem ist der Serverstandort irrelevant wenn dein Vertragspartner eine US-Firma ist, unterliegt diese den US-Gesetzen.
Wenn du einem Hoster misstraust oder am Ende ggf. personenbezogene Daten verarbeiten willst, dann kümmere dich um Verschlüsselung der Daten und zwar so, dass nur du Zugriff auf die Keys hast.

Ein mehr oder weniger lokaler Anbieter ist z.B. Netways, die bieten auch managed Kubernetes an: https://nws.netways.de/de/managed-kubernetes/
Wichtig bei egal welchem Anbieter: In der Regel stellen diese nur die Plattform, um so Dinge wie Redundanzen, Backups, etc. musst du dich weiterhin selbst kümmern.

Am Ende wird das Featurelevel bei allen Anbietern annähernd ähnlich sein. Also überlege dir ob und welchen Support du ggf. benötigst und vergleiche anhand der Preise.
Im Zweifel teste die Anbieter der Reihe nach. Wenn du nur PaaS nutzen willst, ist die Gefahr eines VendorLock ja gering.

 

[ioe]

Primär gehts um die Latenz. Deshalb kommt auch AWS in frage.
Die Daten sind eigentlich nicht kritisch, da wir keine Zahlungsinformationen o.ä. speichern.

Klar die Backups machen wir selber. Es geht wie gesagt nur um einen gesicherten 24/7 betrieb.
Wir verwenden nur OCI Konforme Container um eben einen zu (größeren) lockin zu verhindern.

Danke für den Tipp. Das sehe ich mir gleich an

 

[Skysnake]

Wenn du Kubernetes nicht selbst aufsetzen willst, dann nimm halt eine gemanagete Lösung.

Wenn du Docker Stack schreibst, meinst du wirklich Stack, also ein Compose für Docker Swarm?

Wenn ja, schau das du auf Kubernetes gehst. Swarm tut zwar, aber es wir einfach kaum weiterentwickelt. Das Projekt ist meiner Meinung nach quasi tot.

Du musst auch mal definieren, was 24/7 für dich bedeutet. Wie viele 9er dürfen es denn sein?

 

[ioe]

Das sehe ich jetzt auch so. Entweder die Zeit investieren und selber einen K8 Cluster aufsetzen oder eine fertige Lösung. Ich verwende docker compose für die App.

Gut, dann streiche ich Docker Swarm..

Wichtig ist, dass ich die darunterliegende Infrastruktur updaten kann, ohne den Service unterbrechen zu müssen. Nur beim Load Balancer update kommt es ja unweigerlich zu einem Ausfall?

Ich kenne mich da leider zu wenig aus, darum frag ich hier ja. Aber 99,99% sollten schon drin sein.

 

[konkretor]

Schau dir doch mal scaleway an

 

[Skysnake]

Ich kenne mich da leider zu wenig aus, darum frag ich hier ja. Aber 99,99% sollten schon drin sein.

Dir ist schon klar, dass das <60 Minuten downtime im JAHR sind.

Da wirst du um Georeplikation etc nicht rum kommen.

Die Frage für mich ist wirklich, warum du das in Containern machen willst. Wenn du eh keine Leistung brauchst wäre es wahrscheinlich einfacher nen normales HA Setup mit zwei VMs zumachen.

Aber egal was du auch machst, wenn du nur 99% Verfügbarkeit brauchst ist das nichts was du "mal eben" machst.

Du musst auch immer berücksichtigen, dass du regelmäßig Updates machen musst.

 

[untot]

Aber 99,99% sollten schon drin sein.

Das ist ziemlich unrealistisch, wenn du das vom Anbieter für die Infrastruktur garantiert haben willst.
Google garantiert bspw. 99,95 für die GKE, wenn der Cluster regional ist, also über die Zonen einer Region verteilt.
Das wird ohne Multi-Region oder sogar Multi-Cloud nichts, was dir ein Anbieter vertraglich zusichert.
Ansonsten gibt es wenig Argumente, die dafür sprechen, K8s selbst zu betreiben.

 

[snaxilian]

Ich verwende docker compose für die App.

Du kannst nicht einfach dein docker-compose.yaml nehmen und damit ein Deployment auf k8s starten.

Wichtig ist, dass ich die darunterliegende Infrastruktur updaten kann, ohne den Service unterbrechen zu müssen.

Ich habe das Gefühl, dass du PaaS nicht verstanden hast. Du wirst keinerlei Zugriff auf die darunter liegende Infrastruktur haben bei PaaS. Weder kannst noch musst du da Updates machen.
Redundanzen bekommst du bei k8s ja mit einem ReplicaSets von >1, vorausgesetzt deine Anwendung ist entsprechend skalierbar.

Aber auch dann bist du abhängig von der Verfügbarkeit des k8s Clusters an sich. Du kannst die Verfügbarkeit erhöhen durch Nutzung mehr als einer AZ/Region oder mehr als einem Anbieter aber du hast dann folgende Probleme:

• Höhere Kosten
• Du musst deine persistenten Daten irgendwie replizieren. Ist machbar aber nicht in Echtzeit oder nur mit sehr hoher write latency.

Du solltest eher gucken wie du eine möglichst kurze time to recover hinbekommst, sollte ein kompletter k8s Cluster in einer AZ/Region ausfallen. Ist deutlich einfacher umzusetzen als Multi-Region oder Multi-Cloud.

Nur beim Load Balancer update kommt es ja unweigerlich zu einem Ausfall?

Nö bzw. lässt sich das nicht so pauschal beantworten aber auch Loadbalancer lassen sich hochverfügbar betreiben, ist kein Hexenwerk.

Die Frage für mich ist wirklich, warum du das in Containern machen willst. Wenn du eh keine Leistung brauchst wäre es wahrscheinlich einfacher nen normales HA Setup mit zwei VMs zumachen.

1. Overengineering weil man glaubt so etwas zu brauchen.
2. K8s ist en vogue und jeder macht es angeblich.
3. Container haben ihre Vorteile durch das deklarative Setup. Wenn es beim Dev auf dem Laptop mit lokalem k8s/k3s läuft, dann läuft es auch bei jedem Kunden der k8s verwendet.
4. Viele wissen nicht wie man mit zwei Systemen (zzgl. Quorum/Watchdog/Stonith) ein normales HA Setup aufsetzt bzw. wollen sich nicht da einarbeiten was ich verstehen und nachvollziehen kann.

 

[Skysnake]

Also "normales" HA mit Pacemaker und Corosync ist da ja durchaus auch nicht ganz ohne. Aber mit DRBD 9 ist das für die Data Replication deutlich entspannter geworden.

Ich finde Linstor schon ganz gut. Man hat halt das Split Brain Problem nicht mehr.

Aber klar, HA muss man sich drum kümmern und richtig designen. Aber dann sehe ich es als unproblematischer an als K8ns oder docker.

Oder man macht nen Proxmoxx HACluster für VMs. Das tut unterm Strich halt besser, weil im Allgemeinen die Leute einfach nicht so weit hoch skalieren müssen/können das K8ns oder Swarm seine Stärken ausspielen könnten.

Ich brauch halt mindestens 3 Server, hab da aber noch nichts gewonnen.

Den Nutzen den ich sehe ist, das man gezwungen wird die persitenten Daten sauber zu separieren.

Aber K8ns und docker an sich haben so viele Bugs und Limitierungen und bewegen sich noch immer so schnell weiter, das man da eigentlich nicht Schritthalten kann mit kleinen Teams. Da geht dann Security usw unter weil man überlastet ist.

Ich würde sagen mit nem Team kleiner als 5 Leute sollte man von den Dingen tunlichst die Finger lassen. Das Zeug ist einfach zu komplex. Und das sage ich jetzt als jemand der seit 5 Jahren mit Docker Swarm täglich arbeitet.

 

[nemix]

Das mit komplex und Security kann ich nur unterschreiben. Das holt mich aber bei VMs/eigener Infrastruktur für HA Betrieb ja noch mehr rein. OS Patching, HA muss laufen usw.
Da ist für eine OneManshow managed Kubernetes meistens einfacher. Nächster Schritt wäre dann evtl. Serverless per Functions.

 

[M-X]

Ich würde zu AWS greifen.

 

[ioe]

Danke für den vielen Input!

Mittlerweile haben wir (also mein Team und ich) uns auf 3 V-Server und Docker Swarm geeinigt, da k8 zu aufwendig ist für die ersten HA 'Gehversuche'. Die Volumes sind mit GlusterFS repliziert.

Zu den 99.99%: Der V-Server Betreiber den wir verwenden gibt 99.996% Verfügbarkeit an, und ist auch geo redundant. Da die Infrastruktur so betrieben wird, dass laufend Updates eingespielt werden können ohne längere Unterbrechungen (nicht mehr als ein paar Sekunden), denke ich, dass die 99.99 zumindest theoretisch möglich sind.

Wenn dieses Setup gut funktioniert, werden wir Applikationen da drauf migrieren. Daher haben wir uns auch gegen einen fertige Lösung entschieden, da wir hier mehr Kontrolle, Flexibilität und den geringsten Vendor Lock-In haben

Ich denke, dass das für den Anfang ein guter Kompromiss ist.

 

[M-X]

Mit V-Server hast du halt den ganzen overhead mit OS Mangement, Absicherung, Patching, Monitorring etc, aber gut jeder wie er meint. 99.996% sind halt auch nur 20 Minuten Downtime im Jahr, das lassen die sich sicherlich fürstlich bezahlen. Mit Swam setzt ihr gleichzeitig noch auf ein totes Pferd, da Wäre k8 schlauer gewesen.

 

[Skysnake]

Jup, jetzt ein neues Projekt mit Swarm zu beginnen ist in meinen Augen sträflich. Schaut euch doch mal Rancher an.

Und wenn ich GlusterFS höre, dann sollte euch klar sein, dass die serielle Performance bei Metadaten also kleinem io ziemlich kacke ist.

BENCHMARKT das FS BEVOR ihr weiter macht. Am Ende ist es fast unmöglich die Performance da zu steigern....

 

[ioe]

Mit Linux Servern kennen wir uns aus, das ist kein Problem. Die V-Server sind ca. Faktor 10 billiger als eine AWS Lösung.

Danke für den Hinweis.

Ja es mag bessere Lösungen geben, aber wie immer ist die Zeit und Budget knapp.

 

[Skysnake]

Das ist euer Fundament auf dem Ihr Sachen aufbaut....

Wenn ihr euch da tot spart, dann lasst es bitte sein. Da artet schneller in den Workaround des Workaround des Workarounds aus als du den Namen deines Produktes sagen kannst.

Gerade wenn ihr auf Container setzt, muss das Fundament sauber stehen, wenn wenn du da nochmals ran musst, bist du schnell bei ner komplett neuen Architektur und fängst von vorne an.

Vor allem fixt du da auch unendlich Geld teils keine Probleme mehr sondern wirfst das in die Tonne und musst es neu machen....

Wie gesagt, ich habe diese Fehler jetzt mehrere Jahre vom Management miterleben dürfen....

Aber macht wie ihr denkt.

 

[snaxilian]

GlusterFS macht echt keinen Spaß, v.a. wenn ich mir nochmal ansehe, worauf eure Anwendungen so alles basiert. Also naja es macht schon Spaß aber nicht für den Anwendungsfall...
Prüft ggf. ob euer Hoster euch nicht einen NFS Share o.ä. bereit stellen kann.

Anstatt Swarm würde ich auch euch zu einer k8s basierten Lösung/Appliance raten. Das nimmt auf der einen Seite die Komplexität und auf der anderen Seite seid ihr so für die Zukunft flexibler wenn ihr doch auf eine komplett fremd verwaltete k8s Umgebung wechseln wollt oder müsst.
Für den Anfang oder zum damit warm werden kann man oft auch problemlos mit 1x Master und 2x Worker Nodes anfangen oder verwendet auf allen drei Servern die Master und die Worker Rolle. Ist zwar nicht gerade best practices aber so etwas lässt sich später gut anpassen.

Der V-Server Betreiber den wir verwenden gibt 99.996% Verfügbarkeit an, und ist auch geo redundant. Da die Infrastruktur so betrieben wird, dass laufend Updates eingespielt werden können ohne längere Unterbrechungen (nicht mehr als ein paar Sekunden)

Rein aus Interesse: Magst du uns den Anbieter verraten?

Gelten die 99,996% über die gesamte Infrastruktur des Hosters oder für jede Teilprodukte?
Nur weil der Hoster ggf. geo-redundant ist, bedeutet dies nicht zwingend, dass es auch eure vServer sind. AWS ist auch geo-redundant aber wenn ich dann eine EC2 Instanz nur in einer einzelnen AZ betreibe und diese fällt aus, dann startet die EC2 Instanz nicht magisch in einer anderen AZ.
OVH hat ja auch weltweit Rechenzentren und doch war eine ganze Menge plötzlich offline als ein Teil des RZs in Straßbourg im April 2021 brannte...

Die V-Server sind ca. Faktor 10 billiger als eine AWS Lösung.

Du hast aber hoffentlich nicht Äpfel mit Birnen verglichen, oder? Also die idR üblichen Preise eines Hosters mit 12 Monaten Laufzeit vs. die onDemand Preise von AWS für EC2? Korrekter Vergleich wären hier die Reserved Instances gewesen, da sind die Preise dann direkt um knapp über 1/3 niedriger bei einem Jahr Laufzeit. Bei drei Jahren ist der Rabatt knapp über 50% wobei ich jeweils nur für EU/Frankfurt und Nano/Micro EC2 Instanzen geschaut habe.

 

[konkretor]

Ohje wenn ich glusterfs höre fühl ich mich 10 Jahre zurück versetzt und höre mich fluchen.
Das hat einfach zuviele Nachteile. Ich würde das nicht mehr nutzen in Projekten in 2022.

 

[Skysnake]

Jetzt rein interessehalber was für einen Schmerz hast du mit Glusterfs? Das wird immerhin direkt von RedHat supported. Da hätte ich im Betrieb nicht mit sonderlichen Schmerzen gerechnet. Das Ding sollte ja gut angegangen sein. Sprich halt another parallel network Filesystem sein und das wars.

Ansonsten bin ich gestern in der Ct? Über folgende Grqfik gestolpert