Sie befin­den sich hier:Start­sei­te/Blog/Eli­xir: Zau­ber­trank für Digitalisierung?

Elixir: Zaubertrank für Digitalisierung?

Lese­zeit: 12 Minu­ten
elixir logo socialshare

Wer Lösun­gen für digi­ta­le Ser­vices (Mobi­li­ty, eHe­alth u.ä.) und/oder das Inter­net of Things (IoT) ent­wi­ckelt, muss sehr genau über­le­gen, wel­che Tech­no­lo­gie dafür dau­er­haft trag­fä­hig genug ist. Das ist kei­ne ein­fa­che Wahl, denn neben den spe­zi­fi­schen Anfor­de­run­gen der Lösung wird sie in der Regel fol­gen­de Qua­li­täts­an­for­de­run­gen erfül­len müs­sen: skalierbar/elastisch, neben­läu­fig, ver­teilt, reak­tiv, robust, sicher, inte­grier­bar, kon­nek­tier­bar. Nur mit der Kom­bi­na­ti­on die­ser Eigen­schaf­ten las­sen sich fürs Inter­net Lösun­gen ent­wi­ckeln, die auch bei stei­gen­der Benut­zer­zahl eine gute UX (Uxer Expe­ri­ence) bie­ten. All das soll mit her­vor­ra­gen­der Wart­bar­keit und Pro­duk­ti­vi­tät ein­her­ge­hen, da die „time-to-mar­ket“ über die Ver­tei­lung die­ser Zukunfts­märk­te ent­schei­det. Die Stan­dard­tech­no­lo­gien, die in deut­schen Unter­neh­men für „Enter­pri­se-Anwen­dun­gen“ ver­wen­det wer­den (vor allem .NET, JEE, Spring), sind die­sen Her­aus­for­de­run­gen nur bedingt gewach­sen. Auf die­se Stacks zu set­zen, nur weil man Per­so­nal dafür hat, wäre sehr kurz­sich­tig. Zumal auch Ihr Per­so­nal irgend­wann mal auf moder­ne Umge­bun­gen wech­seln will.

Ich möch­te Ihnen in die­sem Bei­trag eine Tech­no­lo­gie vor­stel­len, die m.E. für Digi­ta­li­sie­rung und IoT ein Stan­dard wer­den kann, wie es Java/JEE im Enter­pri­se-Umfeld war: Eli­xir.
Eli­xir ist eine Pro­gram­mier­um­ge­bung, die fol­gen­de Vor­tei­le auf sich vereint:

  • Eine leicht­ge­wich­ti­ge, schnell erlern­ba­re, aber denoch sehr mäch­ti­ge, funk­tio­na­le Pro­gram­mier­spra­che
  • Ein sehr gute erwei­ter­ba­re Ent­wick­lungs- und Build-Umgebung
  • Eine sehr akti­ve Community
  • Her­vor­ra­gen­de Unter­stüt­zung für ver­schie­dens­te Ziel­platt­for­men vom Web bis Embed­ded Devices
  • Basiert auf der sta­bils­ten Soft­ware-Platt­form der Welt

Wegen der Kom­bi­na­ti­on die­ser Vor­tei­le kann Eli­xir trotz sei­ner Jugend (erst 2012 ver­öf­fent­licht) eine beein­dru­cken­de Ent­wick­lung auf­wei­sen und hat gute Chan­cen, eine der Stan­dard-SW-Tech­no­lo­gien der nächs­ten Jahr­zehn­te zu werden.

Die stabilste Plattform der Welt: Erlang/BEAM

Für die Wahl einer Ent­wick­lungs­tech­no­lo­gie ist vor allem ent­schei­dend, dass sie das Errei­chen der Qua­li­täts­an­for­de­run­gen über­haupt ermög­licht, bes­ser aber pro­ak­tiv unter­stützt. Ein Nega­tiv­bei­spiel ist Ruby (on Rails). Die­se bei Ent­wick­lern sehr belieb­te Tech­no­lo­gie ist letzt­end­lich dar­an geschei­tert, dass sie in der betrieb­li­chen Pra­xis nicht leis­tungs­stark genug war. Übri­gens wird sie bei vie­len Inter­net­fir­men, die mit Ruby on Rails auf zuneh­men­de Ska­lie­rungs­pro­ble­me stie­ßen, gera­de durch Eli­xir ersetzt (des­sen Sprach- und Tool­de­sign sich u.a. an der Leicht­ge­wich­tig­keit von Ruby ori­en­tiert hat).

Eli­xir ist in Hin­blick auf Betriebs­taug­lich­keit her­vor­ra­gend auf­ge­stellt (und übri­gens viel bes­ser als z.B. JVM-basie­ren­de Lösun­gen), weil es qua­si auf den Schul­tern eines kampf­erprob­ten Gigan­ten steht: OTP. Auch wenn Sie die­ses Kür­zel noch nie bewußt wahr genom­men haben, besteht zumin­dest eine sehr hohe Wahr­schein­lich­keit, dass Sie sich täg­lich mehr­fach auf sei­ne Sta­bi­li­tät ver­las­sen (kön­nen).

OTP steht für Open Telecom­mu­ni­ca­ti­on Plat­form, ist die Basis für Steue­rungs­soft­ware in Ver­mitt­lungs­ein­hei­ten, soge­nann­ten Swit­ches und gilt als die sta­bils­te Soft­ware-Platt­form der Welt. Sie schul­tert ein rie­si­ges Daten- und Kom­mu­ni­ka­ti­ons­vo­lu­men, näm­lich schät­zungs­wei­se 50% des welt­wei­ten Mobil­funk-Ver­kehrs! Das heißt natür­lich, dass es sich um eine mas­siv ver­teil­te und neben­läu­fi­ge Platt­form han­delt. In Infor­ma­ti­ker- und Inge­nieurs­krei­sen ist OTP aber vor allem für eines legen­där: Ihre unfass­ba­re Sta­bi­li­tät bzw. Feh­ler­to­le­ranz. Als Beleg dafür wird ger­ne eine gemes­se­ne Ver­füg­bar­keit von 99,9999999% kol­por­tiert – umge­rech­net bedeu­tet das eine „Aus­fall­zeit“ von ca. 3 Sekun­den (pro Jahr!). Wohl­ge­merkt für ein­zel­ne Sys­te­me, nicht erst durch Red­un­danz im Gesamt­sys­tem erzielt. Von kei­ner ande­ren SW-Platt­fom sind auch nur annä­hernd so gute Zah­len für Ein­zel­sys­te­me bekannt. Die wer­den i.d.R. schon durch zwei Din­ge unmög­lich gemacht: Abstür­ze und „War­tungs­fens­ter“.

Mög­lich ist eine sol­che Sta­bi­li­tät nur, weil sie von Anfang an das trei­ben­de Ent­wurfs­ziel war. Als die Ver­mitt­lungs­tech­no­lo­gie in den 1980ern zuneh­mend von mecha­ni­scher (die guten alten „Heb­dreh­wäh­ler“) auf digi­ta­le Steue­rung umge­stellt wur­de, über­leg­te der schwe­di­sche Tele­kom-Anbie­ter Erics­son, wie man die für ein Tele­fon­netz nöti­ge Sta­bi­li­tät und Ver­füg­bar­keit gewähr­leis­ten könn­te, wäh­rend gleich­zei­tig Soft­ware ab einem gewis­sen Kom­ple­xi­täts­grad als imma­nent feh­ler­haft galt und auch häu­fig aktua­li­siert wer­den muss­te. Und das alles soll­te auch noch auf Basis der sehr ein­ge­schränk­ten (Embedded-)Hardware-Möglichkeiten der 1980er Jah­re mög­lich sein.

Aus den Ver­su­chen mit den dama­li­gen Platt­for­men wur­de sehr schnell deut­lich, dass eine völ­lig neue Art von Soft­ware-Platt­form und Soft­ware-Design nötig sein wür­de. Schließ­lich führ­te das zu einem bis heu­te unge­schla­ge­nem Power-Team: Die akto­ren-/mes­sa­ge-basier­te Pro­gram­mier­spra­che Erlang (Erics­son Lan­guage) und die dazu­ge­hö­ri­ge vir­tu­el­le Maschi­ne BEAM.

1200px erlang logo svg 300x263 1

„Let it crash!“ – Aktorsysteme und ihre Supervision Trees

Der ent­schei­den­de Gedan­ke beim Ent­wurf von Erlang war fol­gen­der: Da man Soft­ware bekannt­lich nicht garan­tiert feh­ler­frei erstel­len kann, muss man Soft­ware­sys­te­me feh­ler­to­le­rant machen, um sie ver­füg­bar zu hal­ten. Das heißt, man muss ein­zel­ne Soft­ware­tei­le so gut wie mög­lich iso­lie­ren, damit Feh­ler sich nicht aus­brei­ten kön­nen, und über­wa­chen, um auf Abstür­ze kon­trol­liert zu reagieren.

oanaf

Die­se Idee hat­te Carl Hewitt bereits 1973 in sei­nem Akto­ren­mo­dell vor­ge­stellt: Soft­ware wird in klei­ne eigen­stän­di­ge Ein­hei­ten, sog. Akto­ren, auf­ge­teilt. Die­se sind voll­stän­dig von­ein­an­der getrennt und kom­mu­ni­zie­ren nur über den Aus­tausch von Nach­rich­ten mit­ein­an­der. Um die Seman­tik von Sys­te­men abzu­bil­den, wer­den Akto­ren in Super­vi­son Trees ange­ord­net, die Akto­ren mit­ein­an­der bekannt machen und auf den Tod von Akto­ren z. B. durch Excep­ti­ons, die übli­cher­wei­se nicht abge­fan­gen wer­den) geord­net reagie­ren. Akto­ren haben auch im Design einen Vor­teil: Dadurch dass sie rela­tiv klein und kom­plett von­ein­an­der getrennt sind, ist es viel ein­fa­cher, die in ihnen abge­bil­de­te Logik kon­sis­tent zu beschrei­ben und zu testen.

Joe Arm­strong, der Vater von Erlang adap­tier­te die­ses Modell in sei­ne Spra­che und schuf mit BEAM eine vir­tu­el­le Maschi­ne, die die Akto­ren nativ unter­stützt. Denn für Akto­ren (in Erlang hei­ßen sie Pro­zes­se) sind fol­gen­de Din­ge wich­tig: Sie müs­sen extrem leicht­ge­wich­tig sein, einen abso­lut abge­schlos­se­nen Adress­raum besit­zen und bedin­gungs­lo­sem pre­emp­ti­vem Mul­ti­tas­king unter­lie­gen. Die­se Kri­te­ri­en zusam­men ermög­li­chen auf der BEAM eine mas­si­ve Neben­läu­fig­keit in Qua­si-Echt­zeit. Weil die BEAM nicht als gene­ri­sche Betriebs­sys­tem-Vir­tua­li­sie­rung (wie die JVM), son­dern auf Basis des Akto­ren­mo­dells ent­wor­fen wur­de, gilt sie bis heu­te als des­sen bes­te Imple­men­tie­rung und ist ande­ren Aktor-Imple­men­tie­run­gen (z.B. AKKA auf der JVM) über­le­gen, weil die­se sich letzt­end­lich immer wie­der auf ten­den­zi­ell unge­eig­ne­te Betriebs­sys­tem-Mit­tel wie Threads stüt­zen müs­sen. Auf der BEAM ist es unpro­ble­ma­tisch mög­lich, Sys­te­me mit Hun­dert­tau­sen­den Akto­ren zu betrei­ben, weil sowohl Start­up-Zeit als auch Foot­print eines Aktors mini­mal sind. Kor­rekt ent­wor­fe­ne Aktor­sys­te­me (mit guten Super­vi­si­on Trees) sind auf die­ser Basis – wis­sen­schaft­lich aus­ge­drückt – sau­schnell und qua­si „unka­putt­bar“.

Neben sei­ner Haus­do­mä­ne Tele­kom­mu­ni­ka­ti­on ist Erlang/BEAM nicht von unge­fähr die tech­ni­sche Basis bekann­ter sehr leis­tungs­fä­hi­ger Sys­te­me wie CouchDB, Rab­bitMQ, Riak, ejab­berd (XMPP Ser­ver, den z.B. Face­books Chat benutzt) und dem Mes­sen­ger-Ser­vice von WhatsApp.

Das Aktor­mo­dell war auch die Grund­la­ge für eine ande­re Ent­wurfs­an­for­de­rung an die OTP, Hot Code Repla­ce­ment. Dadurch dass das Sys­tem nur aus lau­ter über Nach­rich­ten kom­mu­ni­zie­ren­de Akto­ren besteht, deren Ersatz ohne­hin im Ent­wurf vor­ge­se­hen ist, ist es natür­lich auch mög­lich, bei einem sol­chen Ersatz auch eine neue Soft­ware­ver­si­on ein­zu­spie­len, ohne dass das Sys­tem dazu her­un­ter­ge­fah­ren wer­den müss­te. Wie gut das funk­tio­niert, zeigt Eli­xirs Erwei­te­rung Sub­pro­jekt Ner­ves für die Pro­gram­mie­rung von Embed­ded-Sys­te­men: Nach­dem man ein­mal ein Eli­xir-Pro­jekt auf die Ziel­hard­ware geflasht hat, kann man wei­te­re Soft­ware­ver­sio­nen über das Netz dar­auf spie­len (und über das Netzt übri­gens auch das ein­ge­bet­tet lau­fen­de Sys­tem remo­te moni­to­ren). Eli­xir hält so gar jeweils zwei Images vor. Dadurch kann bei Feh­lern der neu­en Ver­si­on schnell wie­der auf die alte zurück­ge­schal­tet werden.

Einfach, sicher, produktiv: Elixir als funktionale Programmiersprache

In der Zeit des zuneh­men­den Fach­kräf­te­man­gels ist es wich­tig, Ent­wick­lern eine Tech­no­lo­gie an die Hand zu geben, die sie schnell erler­nen und beherr­schen kön­nen, die siche­ren und aus­drucks­star­ken Code för­dert und for­dert und die durch Syn­tax und Too­ling Spaß, Akzep­tanz und Pro­duk­ti­vi­tät der Ent­wick­ler fördert.

Eine sol­che Umge­bung bringt nicht sel­ten eine um Fak­tor 5 bis 10 höhe­re Pro­duk­ti­vi­tät ggü. eta­blier­ten Tech­no­lo­gien her­vor, was das Argu­ment des Aus­bil­dungs­be­darfs recht schnell ad absur­dum füh­ren kann. Ein wei­te­rer Aspekt ist hier­bei nicht zu über­se­hen: Im „war for talents“ hat man grö­ße­re­re Aus­sicht auf jun­ge Talen­te, wenn man ihnen die Mög­lich­keit gibt, in sol­chen moder­nen Umge­bun­gen zu abrei­ten, in denen sie (auch für sich selbst) die Zukunft sehen. Kein guter Berufs­an­fän­ger will sich heu­te noch ernst­haft mit Java u.ä. Spra­chen her­um­schla­gen (so wie bei uns in den 80er Jah­ren das eta­blier­te COBOL nicht die ers­te Wahl war).

Eli­xir hat es geschafft, über die sta­bi­le Platt­form Erlang/BEAM eine moder­ne, funk­tio­na­le, dyna­mi­sche Pro­gram­mier­spra­che mit ent­spre­chen­dem Too­ling zu legen. Ich habe schon zig Pro­gram­mier­spra­chen in mei­ner Kar­rie­re erlernt, aber ich war sel­ten schon nach kür­zes­ter Zeit so nach­hal­tig von einer über­zeugt wie von Elixir.

Wer die Vor­tei­le der funk­tio­na­len Pro­gram­mie­rung anhand von kon­kre­ten Eli­xir-Code­bei­spie­len ken­nen ler­nen möch­te, sei auf mei­ne Blog­se­rie hin­ge­wie­sen: Ein­fach, sicher, pro­duk­tiv: Funk­tio­na­le Programmierung

Welche Zielplattform darf es sein?

Ange­sichts der Basis Erlang/BEAM, die auf allen gän­gi­gen Platt­for­men läuft, ver­wun­dert es nicht, dass es auch für Eli­xir schon Sub­pro­jek­te gibt, die die­se Platt­form­viel­falt nutzen.

Stan­da­lo­ne: Erlang/Beam ist für die übli­chen Ser­ver­/­Desk­top-Betriebs­sys­te­me ver­füg­bar (ähn­lich wie die JVM), eig­net sich somit her­vor­ra­gend für die Ent­wick­lung von Stan­da­lo­ne-Anwen­dun­gen und Utitilies

Web: Der Stan­dard für moder­ne Anwen­dun­gen / Ser­vices ist natür­lich das Web. Eli­xir bie­tet hier mit dem Ser­ver Phoe­nix eine sehr gut ent­wor­fe­ne, und auf der Basis von Pipes&Filters extrem gut erwei­ter­ba­re Lösung an, die nicht nur für HTTP(s) mit den ver­schie­de­nen Mime-Types geeig­net ist, son­dern auch mit den soge­nann­ten Chan­nels eine sehr leis­tungs­fä­hi­ge Webso­cket-Imp­l­eme­tie­rung bie­tet. Ver­blüf­fend ist vor allem die Geschin­dig­keit: Wer das ers­te mal mit Phoe­nix rum expe­ri­men­tiert, wun­dert sich nicht sel­ten über Ant­wort­zei­ten im Bereich von Mikro-(statt Milli-)sekunden. Und vor kur­zem wur­de demons­triert, dass Phoe­nix auf einem ein­zel­nen Ser­ver 2 Mio. akti­ve Webso­ckets par­al­lel bedie­nen kann – bei vol­ler Neben­läu­fig­keit und ohne Performance-Einbußen.

Embed­ded: In Hin­blick auf kom­men­de immer kom­ple­xe­re IoT-Sze­na­ri­en ist es beson­ders erfreu­lich, dass man jetzt auf Embed­ded-Devices end­lich eine Alter­na­ti­ve hat, die ermög­licht mit dem glei­chen neben­läu­fi­gen funk­tio­na­len Soft­ware-Design zu arbei­ten. Da Erlang/BEAM ja für die­sen Bereich ent­wor­fen wur­de, ist das auch nahe­lie­gend. Mit Ner­ves gibt es ein Sub­pro­jekt, mit dem sich sehr schnell Pro­jek­te für gän­gi­ge Embed­ded-Ziel­um­ge­bun­gen gene­rie­ren las­sen, die oft auch schon gute APIs für Aktua­to­ren, Sen­so­ren, Dis­plays und ähn­li­che Peri­phe­rie mitbringen

Loca­ti­on-Trans­pa­ren­cy: Zum The­ma Ziel­platt­for­men sei ein wei­te­rer Vor­teil der Aktor­i­m­ple­men­tie­rung von Erlang genannt, die natür­lich auch in Eli­xir ver­füg­bar ist. Ein Aktor­sys­tem kann über vie­le Nodes / Devices ver­teilt sein. Solan­ge die­se in einem TCP-Netz ver­bun­den sind, kön­nen sie unter­ein­an­der direkt kom­mu­ni­zie­ren, als wenn sie im sel­ben Adress­raum lägen. Das ermög­licht die Art von neben­läu­fi­gen, lose gekop­pel­ten Peer-to-Peer-Netz­wer­ken, wie wir sie in der IoT-Zukunft immer stär­ker wer­den imple­men­tie­ren müssen

Fazit

Ich habe dar­zu­le­gen ver­sucht, wel­che Vor­tei­le Eli­xir in sich ver­eint. M.E. ist es damit einer der hei­ßes­ten Kan­di­da­ten, wenn es um die Fra­ge geht, mit wel­cher Tech­no­lo­gie sich Digi­ta­li­sie­rung und IoT am ehes­ten erschlie­ßen lassen.

Ich kann sowohl als IT-Stra­te­ge/-Archi­tekt als auch als Ent­wick­ler, der ich im Her­zen immer geblie­ben bin, sehr gut nach­voll­zie­hen, war­um Eli­xir in den letz­ten Jah­ren soviel Furo­re macht, eine Kon­fe­renz nach der ande­ren aus dem Boden schießt und man vor allem wirk­lich beein­dru­cken­de Suc­cess Sto­ries hört. Nicht ein­mal Goo­g­les Go kann da mithalten.

JEE, .NET und Spring sind Tech­no­lo­gien, die uns im Umfeld der Enter­pri­se-IT vor­an­ge­bracht haben. Dort waren sie gut und den Anfor­de­run­gen ange­mes­sen. Die Zukunft von Digitalisierung/IoT gehört die­sen Tech­no­lo­gien nicht, weil Ihr Ent­wurf den dor­ti­gen Anfor­de­run­gen nicht aus­rei­chend genügt. Wenn Sie sich des­halb aber ohne­hin nach einer neu­en Tech­no­lo­gie für Ihre Digi­ta­li­sie­rungs­pro­jek­te umse­hen müs­sen, zie­hen Sie Eli­xir ernst­haft in Betracht. Ich sehe weit und breit kei­ne ande­re Tech­no­lo­gie, die gleich­zei­tig so reif und so modern ist.

Kommentare und Feedback gerne via Social Media:

Blei­ben Sie auf dem Lau­fen­den – mit dem monat­li­chen sepp.med Newsletter: