App-Umgebung : Was unsere Rails-Entwickler jetzt bevorzugen

by Elixir Consultant

• 0
• 3.7K
• Uncategorized

App-Umgebung : Was unsere Rails-Entwickler jetzt bevorzugen

Schienenentwickler – Umweltdiskussionen

Rails Developer wollen immer Dinge mit Stil machen. Es war schon immer eine klassische Frage, was gut für Ruby on Rails Entwickler ist: AWS oder Heroku. Die gleiche Diskussion findet in unserem Unternehmen statt, seit einiger Zeit unter den Rails Developers, und ich könnte sagen, dass dies eine endlose Debatte ist. Aber bei der Arbeit mit verschiedenen Ruby on Rails-Entwicklern mit unterschiedlichem Hintergrund und Erfahrung konnte ich einige Muster von Punkten sehen, die in Diskussionen ausgetauscht wurden. Ich versuche, diese gemeinsamen Punkte in diesem Blogbeitrag zu konsolidieren.

Schienenentwickler – AWS VS HEROKU

Erstens lässt sich die Tatsache verstehen, dass der Vergleich von AWS und Heroku kein Apfel-zu-Apfel-Vergleich ist. AWS ist IaaS (Infrastructure as a Service) und Heroku ist PaaS (Platform as a Service). Worin besteht der Unterschied? IaaS bietet eine Reihe von Komponenten, die ein Entwickler benötigt, um eine Anwendung darauf aufzubauen. PaaS bietet eine einsatzbereite Umgebung, in der der Entwickler den Code zusammen mit minimalen Konfigurationsänderungen verschieben muss, damit die Anwendung funktioniert. IaaS erfordert mehr Geschicklichkeit beim Einsatz, aber PaaS ermöglicht es dem Entwickler, sich mehr auf den Code zu konzentrieren.
AWS haben tatsächlich ein PaaS-Angebot: “Elastic Beanstalk”, das Ruby, Node.js, PHP, Python, .NET und Java unterstützt, aber der Großteil der Menge springt ansonsten, so dass AWS PaaS vorerst aus der Diskussion/dem Vergleich heraus bleibt.

Umgebungskomponenten – Rails Developer View:

Aus Sicht des Entwicklers von Ruby on Rails verwenden sie hauptsächlich die folgenden Komponenten.
Bei AWS geht es um EC2-Instanzen, S3, Load Balancer, Cache Layer, Apache, Passenger, Ruby, Rails, PostgreSql… was auch immer, was nicht, was auch immer ein Ruby on Rails-Entwickler für die Entwicklung/Deployment benötigt, individuell konfiguriert werden muss. Schließlich muss Ruby on Rails Entwickler ein Bereitstellungssystem wie Capistrano und mehr über das Logging-System implementieren.
Heroku, es geht nicht darum, einzelne Komponenten einzurichten. Rails Developers muss einige Zeilen Codeänderung in der Anwendung vornehmen, notwendige Add-ons machen, einen Git-Push durchführen, das ist alles.

Sicherheitshorizont – Rails Developer View:

In AWS geht es vor allem um Sicherheitsupdates und das Patchen, bei dem es darum geht, es manuell von Rails Developers zu erledigen, wann und wo immer es erforderlich ist. Es besteht eine gute Chance, dass diese Aktivität schlecht verwaltet wird und die Produktionsserver weit hinter den Sicherheitsupdates zurückbleiben. Mit Heroku sind Sicherheitsupdates im Besitz der Plattform, nicht aber der Rails Developers. Es gibt gemischte Meinungen darüber, dass Heroku die Verantwortung trägt, und es gibt Fälle, in denen die Aktivität gegen den bereitgestellten Code verstößt, aber das nimmt den Rails-Entwicklern sicherlich viele Kopfschmerzen.

Skalierungsanwendung – Rails Developer View:

Ich habe erklärt, wie allgemein ein Ruby on Rails-Entwickler die Umgebung in seinem obigen IaaS vs. PaaS-Vergleich implementiert. Ungefähr hat die Anwendung eine Procfile, die Zeilen der Form dyno_type: command_to_run hat, so zum Beispiel (siehe http://devcenter.heroku.com/articles/process-model):
web: bundle exec rails server worker: bundle exec rake jobs:work
Das, mit einem:
heroku scale web:4 arbeiter:15
wird dazu führen, dass Sie 4 Web-Dynos und 15 Arbeiter-Dynos laufen haben. Beachten Sie, dass Web ein spezieller Dyno-Typ ist, der Zugang zur Außenwelt hat und sich hinter seinem netten Web-Traffic-Multiplexer befindet, der den Traffic entsprechend weiterleitet.

Kostenfaktor:

Auch hier ist es nicht richtig, die AWS und Heroku auf den Kostenfaktor zu vergleichen. Obwohl die Kosten für die Nutzung der Heroku-Umgebung 100% teurer sind als bei AWS, ist der Aufwand für EC2 für Dyno wichtiger. Es ist wahrscheinlich nicht allzu unangemessen, einen Dyno als eine Art EC2-Mikroinstanz zu betrachten. Aber der Aufwand, den der Ruby on Rails-Entwickler aufwenden muss, um eine Umgebung auf einem IaaS-Angebot aufzubauen, um es auf PaaS-Standard zu bringen, ist definitiv nicht billig und einfach. Lassen Sie uns auch die Kosten für die Arbeitskräfte vereinbaren, die für die Einrichtung und Instandhaltung einer Umwelt erforderlich sind.

Fazit:

Sowohl Heroku als auch AWS sind ausgezeichnete Plattformen. Ruby on Rails-Entwickler wollen sich jetzt mehr auf den “Code” als auf die Umgebung konzentrieren, so dass die meisten von ihnen es vorziehen, an Heroku für die Entwicklung, das Testen, die Bereitstellung und die Produktion der Anwendung zu arbeiten. Aber für sehr “Serious Production Deployment” mit mehreren zahlenden Kunden mit komplexem Anwendungs-Setup, mit einem zu wartenden SLA, mit engagierter Zeit für Dev-Ops etc. kann Rails Developers nicht ganz dazu bringen, so viel Kontrolle an Heroku abzuladen, und dann wäre AWS die Wahl. Die Gewinnerplattform kann AWS oder Heroku sein, je nachdem, was den Rails-Entwicklern am meisten hilft, die Ziele zu erreichen, sie glücklich und produktiv macht und gleichzeitig bezahlbar genug bleibt, um nachhaltig zu sein. Rails Developers – Happy Coding !!!!!!!!!