Tools, Ruby und ob man das alles braucht

TL;DR

Immer häufiger findet man diese Abkürzung.

Sie entwickelt sich so langsam zu einer Abkürzungen, die ich immer weniger leiden mag. Denn sie beschreibt mein Problem: “Too long; didn’t read”.
Immer wieder entdecke ich bei meinem wöchentlichen “Zug durch die Gemeinde” neue, absolut faszinierende Blog-Einträge, Produktbeschreibungen oder -besprechungen. Dann mache ich mir Bookmarks und die Liste mit den Dingen, die ich noch lesen möchte wird immer länger und länger. Allmählich gilt auch hier “TL;DR”.

Die Zusammenhänge in der IT werden immer komplexer und die Frequenz, mit der neue oder mit einem Thema zusammenhängende Informationen auftauchen, scheint immer weiter zu steigen und auch ihr Umfang scheint immer größer zu werden.

“Zug durch die Gemeinde”

Was heißt das? – Einmal in der Woche habe ich in meinen “Pomodories” einen “Zug durch die Gemeinde” eingeplant. Da suche ich mir ein Thema aus und folge für zwei “Pomodori Einheiten” den Links, die ich auf den Seiten finde oder suche nach Erklärungen für Begriffe, die ich entdecke und verstehen möchte.
Ich lasse mich vom Zufall leiten und durch das Internet treiben. Nichts wirklich suchen, aber immer bereit Neues zu finden und zu Unbekanntes zu entdecken. Ein sehr kreativer, belebender und ungemein spannender Prozess.

So bin ich vor einiger Zeit auf Docker gestoßen und habe vor zwei Jahren OpenStack für mich entdeckt. Auf CloudStack bin ich gestoßen, weil jemand ein “Shoot-out” zwischen den beiden Cloud-Plattformen beschrieben hat.

Für mich sind solche Streifzüge sehr inspirierend und anregend. Sie bieten mir die Möglichkeit, mein Wissen zu vergrößern und meine Neugier zu befriedigen. Die IT ist eine Industrie, in der kaum etwas so wertlos ist, wie das Wissen von gestern. Und man kann täglich so viel Neues lernen.

Was man so findet und wenn man darüber nachdenkt

Es versteht sich von selbst, daß man nicht immer Dinge entdeckt, die allgemein als “the bleeding edge” gelten. Doch für mich sind sie das, zum Teil.

So entdeckte ich Ruby für mich.

Ruby ist …

“[…] eine dynamische, freie Programmiersprache, die sich einfach anwenden und produktiv einsetzen lässt. Sie hat eine elegante Syntax, die man leicht lesen und schreiben kann […]”

Na toll! Und was kann man damit so machen? Braucht man das in der Praxis und wenn ja wofür? Lohnt der Aufwand es zu lernen?

Bei einem meiner letzten Vorstellungstermine bei einem großen Kunden der MT AG, waren Ruby-Kenntnisse ein entscheidendes Kriterium. Im Rahmen der Vorbereitung dieses Termins hatte ich mir Ruby angesehen, aber das reichte bei Weitem nicht, um die Anforderungen zu erfüllen. Gerade wenn man die Projekt-Angebote auf den einschlägigen Portalen liest, dann entdeckt man Ruby immer häufiger. Oder ist das nur eine Folge meiner “selektiven Wahrnehmung“?

Doch warum findet man immer häufiger Ruby in den Anforderungen und gerade dann, wenn es um das Thema “Automatisierung” im weiteren Sinne geht? Was ist an Ruby so “sexy”, daß man es nicht mit Python, Perl oder einem Shell-Skript machen könnte? Ich habe darauf keine erschöpfende Antwort und bin für neue Erkenntnisse offen.

Bei dem Kunden ging es darum, daß er damit das Provisionieren von Web-Applikations-Server automatisieren und dann standartisiert aufsetzen will. Gut, daß kann man auch mit Python oder Perl. Warum er Ruby gewählt hat? Es habe sich so ergeben, war die Antwort, weil der eine Kollege ein echtes Ass in Ruby ist. That’s why!

Schlussfolgerungen

Wenn also immer mehr Kunden auf Ruby setzen, sollte man dann nicht auch Ruby lernen?

Ich denke, daß es bei der MT AG bereits ein paar KollegInnen gibt, die Ruby beherrschen oder zumindest damit zurecht kommen. Für mich ist das zwar interessant, aber einfach zu viel zu lernen.

Denn eigentlich möchte ich erst noch meine Kenntnisse in Python vertiefen. Nicht zuletzt, weil im OpenStack / CloudStack Umfeld eigentlich alle Automatissmen in Python implementiert sind und weil WLST (WebLogic Scripting Tool) ein “Dialekt” von Python bzw. Jython ist. Und ist es wirklich so, daß man gewisse Aufgaben “nur” mit Ruby erledigen kann, die man mit den anderen Sprachen nicht kann? Worin zeigen sich denn die Unterschiede und sind sie wirklich so signifikant, wenn man die “Glaubensfragen” außen vor läßt?

Das ist wie mit Ansible, Puppet, Chef und SaltStack. Alles sind es ausgereifte Konfigurations-Management-Werkzeuge für Server (gemeint sind VIELE Server), um damit Aufgaben und Informationen aus dem Bereich der Konfiguration und Administration zu verteilen und zu automatisieren. Doch dann hören die Gemeinsamkeiten auch schon bald auf.
Ansible geht wohl demnächst zu RedHat, Puppet ist schon eine eigene Firma und Chef … weiß ich nicht. Ich bevorzuge SaltStack. Das gibt es auch mit professionellem Support, ist aber grundsätzlich Open Source.
Da Infrastruktur mein Thema ist, sollte ich mindestens eins dieser Tools beherrschen und die anderen zumindest rudimentär kennen, oder? Doch habt Ihr Euch schon mal angesehen, wie unterschiedlich sie sind?

Für Puppet und Chef gilt es eine jeweils eigene DSL zu lernen und kompatibel zueinander sind sie auch nicht. Auch wenn Puppet und/oder Chef die “Platzhirsche” sind, so finde ich so doch sehr klobig und nicht elegant. Aber es gibt eine Menge Leute, die diese beiden Tools sehr erfolgreich einsetzen.

Bei Ansible kann man alles in Textdateien konfigurieren, die dann zur Konfiguration genutzt werden und bei SaltStack stehen diese Informationen in YAML-Dateien. Die Synthax ist weniger klobig und die beiden Tools nutzen modernere Techniken, um die Informationen zu verteilen, bei SaltStack kann man sogar sehr leicht die bisherigen Skripte sehr leicht einbinden und einfach weiterhin einsetzen.

Dann haben die Tools alle noch APIs und man kann sie von außen “fernsteuern”, sei es mit Ruby, Python, Shell-Skripte …

Hmmm, es scheint also, als würde Ruby es immer unausweichlicher sich damit zu beschäftigen. Genau so auch mit Ruby on Rails, wie auch mit Groovy, Jython und Python, dann vielleicht noch Rust und ….

… am Ende des Tages wird es darauf hinauslaufen, daß sich von den “jungen Wilden”  jeweils eine(r) ein Thema greift und sich darin fortbildet. Das Wissen braucht die MT AG sicherlich in zunehmenden Maße.

Aber nicht alles in einem Kopf. Ist ja eh nicht gut.

Ach ja! Ruby!

Stimmt! Ruby. Da war ja noch etwas.

Braucht man es nun oder etwa doch nicht? Typische Antwort eines Beraters: Es hängt vom konkreten Fall ab!

Ruby ist eine recht moderne und innovative Sprache, mit einer aktiven Community. Durch das populäre Framework “Rails” ist es möglich schnell und recht einfach komplexe Web-Anwendungen zu entwickeln, die sich am MVC-Paradigma orientieren. Man verwendet den zum Ruby-Paket gehörenden Webserver WEBrick als Applikationserver, um Anwendungen während der Entwicklungsphase zu testen.

In Produktion werden die Pakete dann auf einem Webserver der FastCGI unterstützt betrieben; also eigentlich alle modernen Webserver. Entweder funktioniert das schon mit “Bordmitteln” oder durch den Einsatz von entsprechenden Plug-Ins. Viele Anwender setzen den in Ruby geschriebenen Webserver “Mongrel” besonders gerne in Produktion ein.

Mich würde ein “Shoot-out” zwischen Apache, NGINX, Lighttpd und eben Mongrel interessieren. Vielleicht kennt ja jemand eine Site, wo sich dem entsprechende Informationen finden? Ich würde mich über zahlreiches Feedback sehr freuen.
Und vielleicht weiß jemand etwas Entscheidendes zum Thema “mod_ruby vs Phusion Passenger (aka mod_rails)” zu sagen. Angeblich soll das Apache Modul “mod_ruby” ja nicht so ganz rund laufen.

In Anbetracht der vielen Dinge, die man über Ruby wissen kann und wie viele man davon auch wissen sollte, entscheide ich für mich, daß ich Ruby auf die “Warteliste” schreibe und es mir bei entsprechender Priorität noch einmal intensiver anschaue.

Es sei denn mir nennt jemand mindestens zwei Gründe, warum ich das auf jeden Fall ändern sollte.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Bitte füllen Sie dieses Feld aus
Bitte füllen Sie dieses Feld aus
Bitte gib eine gültige E-Mail-Adresse ein.

Menü