Kuby-core: Welche Art von Apps sollten wir (nicht) mit Kuby bereitstellen?

Hey @hovancik. Sie haben völlig Recht, in der Dokumentation steht nicht viel über die verschiedenen Cloud-Anbieter und wie viel sie kosten. Ich habe darüber nachgedacht, den Dokumenten eine Preismatrix hinzuzufügen, aber die Bereitstellungslösung hat wirklich nichts mit dem Cloud-Anbieter zu tun. Stellen Sie sich zum Beispiel vor, Sie stellen dieselbe Frage an Capistrano :)

Kuby wurde entwickelt, um Ihre App in jedem Kubernetes-Cluster bereitzustellen, unabhängig vom Cloud-Anbieter und wie viel es kostet. Sie als Entwickler sollten frei wählen können, welcher Cloud-Anbieter Ihren Anforderungen am besten gerecht wird. Zum Beispiel würde ich EKS oder Azure nicht für ein Hobby oder ein persönliches Projekt wählen – es ist viel zu teuer. Für EKS gelten die von Ihnen erwähnten 72 $/Monat buchstäblich nur für die Kubernetes-Steuerungsebene und beinhalten nicht die Kosten für Rechenressourcen, Blockspeicher usw. Stattdessen würde ich zu DigitalOcean oder Linode greifen, die weitaus teurer sind -effektiv (ca. 20 $/Monat für eine Instanz mit 4 GB RAM und 2 CPUs) und geben Ihnen die Steuerungsebene kostenlos. Wenn Sie Teil eines Unternehmens sind, das einige der anderen zahlreichen AWS- oder Azure-Dienste nutzen möchte, ist EKS vielleicht die richtige Lösung für Sie. Der Punkt ist, dass Sie wählen können. Kuby ist das egal – es wurde entwickelt, um überall zu funktionieren.

Wäre es jedoch hilfreich, eine Preismatrix in der Dokumentation zu sehen? Ich zögere, einen hinzuzufügen, weil 1) die oben aufgeführten Gründe, 2) sich die Preise häufig ändern und 3) ich nicht in das Geschäft einsteigen möchte, Cloud-Anbieter zu empfehlen oder als bevorzugt wahrgenommen zu werden.

Die Gedanken?

Hallo @camertron , ja, die Preismatrix ist eine schlechte Idee.

Wie der Titel schon sagt, versuche ich zu fragen: Welche Art von Apps sollten wir (nicht) mit Kuby bereitstellen? In gewissem Sinne: Beschreiben Sie das Tool im Begriff der Arbeit :)

Ich habe mit hobby vs professional (=Geld) angefangen, weil es einfach ist, aber ich würde gerne mehr darüber erfahren, welche Art von Apps Sie anstreben. Ist das Overkill für eine einfache servergerenderte Rails-App mit db? Oder ist das der perfekte Kandidat? Oder je komplizierter die App, desto besser ist dieses Tool für Entwickler?

Vielleicht verstehe ich das falsch und das ist für alle Arten von Apps gedacht? Weißt du, die Art von Seiten, auf denen use this tool if und don't use this tool if stehen, ist das, wonach ich suche, wenn ich sie überprüfe :)

Ah ok ich verstehe was du meinst. Ich würde sagen, Kuby ist für alle Arten von Apps gedacht, aber es gibt sicherlich einige Arten, die mehr davon profitieren als andere. Sie sind wahrscheinlich besser dran, einen kostenlosen Heroku-Dyno für eine superkleine App zu verwenden, die nicht viel Verkehr sieht und die nur ein paar hundert (oder weniger) Datenbankzeilen verwaltet. Die Sache ist die, dass Kuby keine schlechte Wahl für diese Art von Apps ist, es ist nur so, dass Sie wahrscheinlich weniger Geld und weniger Intelligenz ausgeben werden, um Heroku einzurichten. Es ist ziemlich schwer, sie an Einfachheit zu schlagen. Heroku wird jedoch teurer, wenn Sie mehr Ressourcen benötigen, und ich habe festgestellt, dass ein verwalteter Kubernetes-Cluster mit einem einzelnen Knoten, der mit Kuby bereitgestellt wird, im Allgemeinen kostengünstiger ist als das entsprechende Heroku-Setup. Ja, die Konfiguration von Kuby erfordert mehr Intelligenz (auch hier ist es ziemlich schwer, git push heroku master zu schlagen), aber die Flexibilität, die Sie dadurch erhalten, ist es meiner Meinung nach wert.

Kuby ist möglicherweise auch nicht die richtige Wahl für sehr große, stark angepasste Apps, die erheblich von den Rails-Konventionen abweichen. Ich bin sicher, Sie könnten Kuby dazu bringen, für solche Apps zu arbeiten, aber es würde wahrscheinlich bedeuten, Kuby in hohem Maße anzupassen. Dazu müssten Sie wahrscheinlich ein tieferes Verständnis dafür haben, wie Docker, Kubernetes und Kuby funktionieren. Ich denke, es läuft darauf hinaus, wie bereit Sie sind, Zeit in das Erlernen der Technologien zu investieren.

Vielleicht ist der beste Weg, es zu sagen, dass Kuby entwickelt wurde, um das gleiche Publikum wie Rails selbst zu bedienen, und sollte als auf der gleichen Ebene wie Active Record, Active Storage usw. angesehen werden. Man könnte vernünftigerweise sagen, dass ein ORM zu viel des Guten ist eine sehr kleine App, und Sie könnten auch sagen, dass es Ihnen in einer großen, maßgeschneiderten App im Weg steht. Active Record wurde entwickelt, um die Komplexität der Datenbankkommunikation zu abstrahieren, und Kuby wurde entwickelt, um dasselbe für die Bereitstellung zu tun. Beide werden, wie DHH gerne sagt, mit Batterien geliefert.

Danke! Irgendeine Form davon sollte wahrscheinlich irgendwo im Internet sein :)

Einverstanden, danke, dass du das angesprochen hast @hovancik :)