Reitet die Welle – Software-Einsatz und Upgrade-Strategien


03.02.2020 von 2020-04-08

https://www.iteratec.de/fileadmin/Bilder/News/iteratec_logo.png
iteratec GmbH
Reitet die Welle – Software-Einsatz und Upgrade-Strategien

Im Westen nichts Neues?

Damals, in der guten alten Zeit, im letz­ten Jahr­tau­send, da war Soft­ware noch für die Ewig­keit. Und Pro­gram­mier­spra­chen und Lauf­zeit­um­ge­bungen hielten min­destens dop­pelt so lange. Das hatte seine Vor­teile, weil wir die In­ves­ti­tion in etwas Ge­lerntes nicht ver­loren haben, son­dern lange da­von zehren konnten. Auch die Pro­jekte waren darauf zu­ge­schnitten. Ein Pro­jekt­team hat Soft­ware er­stellt und sich dann für einen längeren Zeit­raum der nächsten Auf­gaben­stel­lung zu­ge­wen­det. Kon­ti­nui­tät und Stabi­li­tät sind Werte, die in einigen Bereichen durch­aus ge­schätzt wurden und werden.

Das hat sich ge­ändert – zu­min­dest in einem Teil der Welt. Wenn wir uns in den Ge­filden der Inter­net-Tech­no­lo­gien be­wegen, dann poppen neue Soft­ware, Bib­lio­the­ken, Frame­works und Pro­gram­mier­pa­ra­dig­men in zu­neh­mender Ge­schwin­dig­keit hoch. Da bekommt man manch­mal den Ein­druck, sich auf einer un­be­rechen­baren Welle zu befinden.

Die Versions-Rallye an einigen Beispielen

Um den Effekt der zu­nehmen­den Ge­schwin­dig­keit von Soft­ware-Ände­rungen greif­bar zu machen, sehen wir uns einige Bei­spiele aus dem Bereich der Web-App­li­ka­ti­onen an. Im fol­gen­den Bild sind Frame­works aus diesem Be­reich mit ihren Releases auf­ge­listet. Die Daten wurden den je­weiligen Change-Logs entnommen.

Am Anfang gab es in der Java-Welt die Servlets. Damit konnten Seiten aus­ge­liefert werden. Dies wurde mit der Ein­führung von JavaServer Pages (JSP) stan­dar­di­siert. Der Stan­dard wurde je­weils über Jahre hinweg un­ver­ändert ge­lassen. Damit konnte man sich längere Zeit da­rauf ein­stellen, was die Im­ple­men­tie­rung in den App­li­ca­tion-Ser­vern zu leisten, in der Lage war.

Neuen Schwung brachten Java­Server Faces (JSF). Diese wurden schon etwas häufiger aktua­li­siert. Er­gänzend zum Standard gibt es noch Kom­po­nenten­biblio­the­ken wie bei­spiels­weise PrimeFaces und ICEfaces, die die Ge­staltung von Web-Ober­flächen ver­einfacht haben. Hier be­wegen wir uns immer noch in dem Be­reich von Jahren, bevor eine Aktua­li­sie­rung der eigenen Soft­ware wirk­lich er­forder­lich wurde.

Bisher haben wir es mit server­seitiger Er­zeu­gung von Web-Seiten zu tun. Diese wurden an den Browser aus­ge­liefert und dort dar­ge­stellt. Für jede Inter­aktion muss man einen Re­quest zum Server schicken, um die nächste Seite zu er­halten. Dieses Para­dig­ma wurde mit der zu­nehmen­den Mächtig­keit von Java­Script im Browser immer mehr in Frage gestellt. Plötz­lich war der Browser in der Lage, einen Teil der Front­end-Logik selbst­ständig auszuführen.

Ein Problem, das zu der Zeit existiert hat, waren die unter­schied­lichen Imple­men­tie­rungen von Java­Script in den diversen Browsern. Dieses Defizit wurde damals bei­spiels­weise von JQuery ge­schlos­sen. Hier­mit war eine Java­Script-Biblio­thek ver­füg­bar, die eine ein­heit­liche Be­hand­lung der ver­schie­den­en Browser er­möglichte. Mit JQueryUI gibt es er­gänzend dazu eine Bib­lio­thek mit Ober­flächen­komponenten.

Wie man an der obigen Ab­bildung er­kennt, ist im Laufe der Zeit der Ab­stand zwischen den Re­leases weiter ge­schrumpft. Viele haben sich dem zu­neh­menden Druck da­durch ge­stellt, dass sie lange Zeit bei der Version 1 von JQuery ge­blieben sind und ein Up­grade ein­fach ver­schoben haben.

Ein weiterer Schritt in die Richtung der Ent­wick­lung von Client-basier­ten Web-App­li­ka­tio­nen wurde mit AngularJS ge­macht. Dieses wurde 2012 erst­mals pub­li­ziert. Mit dem Versions­sprung von 1 nach 2 ging auch eine Ver­kürzung des Namens auf Angular einher. Mit dieser Ent­wick­lung gab es auch viele in­kompa­tible Ände­rungen, die das Up­grade schwierig ge­macht haben. Seit­her gibt es zwar sehr viele Re­leases, diese sind aller­dings in ihren Ver­ände­rungen deut­lich harm­loser als der große Versions­sprung.

2013 erschien der Konkurrent React auf dem Plan. Dieser legt noch ein­mal etwas zu, was die An­zahl der pub­li­zier­ten Ver­si­onen betrifft.

Schließlich gibt es seit 2015 Vue.js mit der Er­weite­rung Nuxt.js. Beide geben sich nicht viel, wenn es um das Thema Release-Zyklen geht.

Hier will ich nicht be­werten, wie sich diese Frame­works gegen­ein­ander ab­grenzen und ob es abso­lut not­wendig ist, auf das je­weils neueste Pferd zu setzen. Hier geht es mir vor­nehmlich um den Um­gang mit der immer weiter zu­nehmen­den Ge­schwin­dig­keit, mit der neue Re­lea­ses heraus­kommen.

Lade dir das Internet herunter

In dem bisher ge­zeichneten Bild sind nur die Frame­works selbst dar­ge­stellt. Wie wir uns in der Ent­wicklung von Individual­soft­ware auf diese Frame­works abstützen, um Ge­schwindig­keit zu ge­winnen, ge­schieht es auch bei den Frame­works selbst. Ins­beson­dere die neueren Ent­wicklungen in Angular, React und Vue verwenden ihrer­seits eine große Zahl von Libraries. Wenn beim initialen Auf­setzen eines solchen Programms mehrere Hundert Biblio­theken und Hilfs­pro­gramme her­unter­geladen werden, so ist dies keine Ausnahme.

Dadurch verschärft sich die Situation noch weiter. Immer schon war das Auf­treten eines Fehlers ein Grund, auf eine neuere Version up­zu­graden. Da­neben stand am An­fang auch noch der Wunsch, mehr und neue Features ein­setzen zu können. Dies hat sich zu­nehmend ge­wan­delt. Der Aspekt Sicher­heit spielt eine immer größere Rolle.

Die Angreifer auf unsere Web-App­li­ka­ti­o­nen – ins­beson­dere, wenn sie im Inter­net ex­po­niert sind – haben auch heim­lich auf­ge­rüstet. Sicher­heits­lücken werden immer schneller auf­ge­deckt und aus­ge­nutzt. Des­halb ist es zunehmend wichtiger ge­worden, die ein­ge­setzten Frame­works und Bib­lio­theken auf einem aktuellen Stand zu halten, um die bekannten Sicher­heits­lücken zu minimieren.

Wie können wir mit dem Release-Gap umgehen?

Die sich weiter ent­wickelnde Soft­ware hilft uns da­bei, die Er­war­tungen an immer kürzere Ent­wick­lungs­zyklen und noch mehr hippe Funk­ti­o­na­li­tät zu er­füllen. Doch was passiert weiter mit dieser schnell er­stellten Soft­ware? Was machen wir, wenn es darum geht, in ein be­stehen­des Sys­tem neue Funk­ti­onen zu inte­grieren? Seit der letzten Ver­ände­rung kann die Soft­ware schon wieder „ver­altet“ sein.

Die initiale Beschleunigung kann dann ins Gegen­teil um­schlagen, wenn wir Soft­ware in immer kürzeren Ab­ständen ersatz­beschaf­fen müssen, weil die zu­grunde lie­gende Tech­no­lo­gie schon wieder ein­mal ver­altet ist – schließ­lich wollen wir doch nicht von unseren Kollegen oder Kon­kurrenz­unter­nehmen über­holt und zu­rück­ge­lassen werden.

Da müssen wir uns schon der Frage stel­len, wie wir mit dieser Si­tu­a­tion um­gehen sollen und zu wel­chem Typ wir ge­hören – oder ge­hören wollen. Und diese Frage stellt sich nicht nur den einzelnen Entwickler*innen, son­dern auch ganzen Unter­nehmen.

Software für neue Projekte

Wenn wir in der Situation sind, neue Soft­ware zu er­stellen, dann haben wir es mit der klassi­schen Pro­dukt­aus­wahl­frage zu tun. Wir müssen unter den zur Ver­fügung stehenden Halb­fertig­produkten den am besten ge­eigne­ten Mix aus­wählen. Dabei haben wir nicht nur die be­kannten funk­ti­o­nalen und nicht-funk­ti­o­nalen An­for­de­run­gen und deren Prio­ri­täten zu be­rück­sichtigen, sondern sollten auch die Welle der neuen Soft­ware-Pro­dukte und deren Re­leases einfließen lassen.

Es gibt ver­schie­dene Stra­te­gien, wie man mit neuen Tech­no­lo­gien und Vor­gehens­weisen um­gehen kann. Diese wollen wir uns ein­mal an­sehen. Als Me­ta­pher haben wir dazu die Welle ge­wählt, mit der ein Surfer um­gehen muss. Das führt zu in­te­res­san­ten Einsichten.

Early Adopter

Der Typ „Early Adopter“ stürzt sich sofort auf jede neue Tech­no­lo­gie oder jeden Trend und bringt diese zum Ein­satz. Der Vor­teil liegt darin, dass die­jenigen, die die Nase vorn haben, am ehesten von den Neuig­keiten profitieren.

Auf der ande­ren Sei­te sind aber auch die Ri­si­ken ent­sprech­end höher. Brand­heiße und neue Soft­ware oder Para­digmen haben so ihre Tücken und Kinder­krank­heiten. Als Early Adopter muss man das wissen und auch ein­kal­ku­lie­ren, dass man davon ein­mal selbst er­wischt wird.

Für Soft­ware am „Bleeding Edge“ ist es häufig auch nicht ein­fach, ent­sprech­ende In­for­ma­tio­nen zu be­kommen. Ich kann mir nicht ein­fach in der On­line-Buch­handlung meines Ver­trau­ens einen Meter Fach­bücher dazu be­stellen. Auch die Kol­legen, die schon ein­mal Er­fahrungen da­mit ge­macht haben und die man des­halb fragen kann, sind prak­tisch nicht vorhanden.

Man befindet sich so­zu­sagen vor der großen Welle und muss erst ein­mal selbst kräf­tig rudern. Viel­leicht schafft man es dann, auf die Welle auf­zu­stei­gen, oder die Welle ver­ebbt, bevor sie an­kommt, oder man wird von ihr er­wischt und geht unter.

Mainstream Surfer

Der Typ „Mainstream Surfer“ ver­wendet Soft­ware, die einen ge­wis­sen Reife­pro­zess hin­ter sich hat. Da­mit haben an­de­re die schlimm­sten Kin­der­krank­hei­ten ge­heilt. Da­durch, dass die Soft­ware eta­bliert ist, gibt es auch ent­sprechen­de Li­te­ra­tur und Ex­per­tise, auf die man im Zweifels­fall zurück­greifen kann.

Die Soft­ware hat aller­dings schon etwas von dem Nim­bus des Allein­stel­lungs­merk­mals ver­loren. Auch andere kön­nen mit dem gleichen Er­folg solche „Main­stream-Soft­ware“ ein­setzen. Aber we­nig­stens hat man sich er­spart, sich mit den kurz­lebi­gen Pro­duk­ten aus­ein­an­der­setzen zu müs­sen, weil die schon längst wieder ver­schwun­den sind, bevor der Mainstream Surfer sie als inte­res­sant ins Auge fas­sen würde.

Dadurch, dass man leicht vor dem Hoch der Welle her­surft, wird man von ihr ge­tragen, ohne selbst mehr Ener­gie ein­setzen zu müs­sen. Inte­res­sant an dieser Meta­pher ist, dass man sich vor­an be­wegen muss. Wenn man ver­sucht ste­hen­zu­blei­ben, wird man von der Welle erwischt.

Late Follower

Der Typ „Late Follower“ setzt prin­zi­piell nur auf die ab­so­lut so­li­deste und er­prob­te Tech­no­lo­gie. Da­mit kann man ziem­lich sicher sein, dass man so gut wie zu jedem Pro­blem auch eine Lö­sung findet, weil an­dere sicher das gleiche Pro­blem auch schon hatten und sich um eine Lö­sung ge­küm­mert haben.

Von einem Allein­stel­lungs­merk­mal kann hier na­tür­lich nicht mehr die Rede sein. Eher wurde man von der Welle zurückgelassen und ist ein­fach nur ge­zwun­gen, hinter­her­zu­rudern, um nicht gänz­lich vom Rest der Welt ab­ge­hängt zu werden.

Ein tech­no­lo­gi­sches Ri­si­ko, das man damit ein­geht, ist natür­lich, dass man an das Lebens­ende der ein­ge­setz­ten Soft­ware stößt. An­dauernd werden Ver­si­o­nen der Soft­ware ab­ge­kün­digt, ob­wohl man die doch ge­rade eben in Pro­duk­tion ge­bracht hat. Und vielleicht steht sogar das ganze Soft­ware-Pro­dukt auf der Ab­schuss­liste des Her­stel­lers, weil längst ein Nach­folge­pro­dukt ver­fügbar ist und der Fo­kus jetzt da­rauf ge­legt werden soll.

Upgrade oder Migration?

Über eine Ab­lösung von Soft­ware wird meist dann nach­ge­dacht, wenn die Situa­tion schon bei­nahe un­halt­bar ge­worden ist. Das Be­har­rungs­vermögen for­ciert eine Weiter­ver­wendung der ein­ge­setzten Techno­lo­gien aus schein­bar wirt­schaft­lichen Grün­den. Wieviel aber eine ver­passte Business-Chance oder die nicht durch­ge­führ­ten Up­grades wirklich kosten, wird meist ver­nach­lässigt.

Wenn wir uns in der Wartungs- und Weiter­entwick­lungs­phase im Lebens­zyklus von Soft­ware be­finden, sollten wir uns immer der Frage stellen, ob wir noch auf dem richtigen Pfad sind und wann es Zeit wird, auf die nächste Welle aufzusteigen.

Major-Releases, Minor-Releases, Bug-Fixes, Security-Updates

Neben der initialen Ent­scheidung für den Ein­satz von Soft­ware in einem Projekt gibt es auch noch das weitere Leben der Software. Wenn man be­reits in der eigenen System­land­schaft Soft­ware ein­setzt, so kann man sehen, dass in mehr oder weniger regel­mäßigen Zeit­abstän­den für die Soft­ware neue Releases oder Bug-Fixes heraus­kommen.

Als Firma steht man vor der Frage, wie man mit einer fort­schrei­ten­den Ent­wick­lung in der Welt der Soft­ware um­gehen soll. Ein Update von Soft­ware immer auch mit Kosten und Risiken ver­bunden ist. Aus diesem Grund will es gut über­legt sein, wie man mit Software-Updates umgeht.

Meistens ist es so, dass der Um­gang mit den Up­dates davon ab­hängig ist, um welche Art des Updates es sich handelt. Dabei werden oft die folgenden Kategorien unter­schieden:

  • Major-Releases sind normaler­weise neue Ver­si­o­nen der Soft­ware, die in­kompatible Än­de­run­gen ge­gen­über der Vor­gänger­ver­sion haben.

  • Minor-Releases sind normaler­weise neue Ver­si­o­nen der Soft­ware, die rück­wärts­kompa­ti­bel zu der Vor­gänger­version sind, aber neue Features, Bug-Fixes und Security-Updates ent­halten können.

  • Bug-Fixes sind kleinere Aktua­li­sie­rungen der Soft­ware, die aus­schließ­lich zur Aus­merzung von Pro­grammier­fehlern dienen, ohne funktionale Ver­ände­rungen ein­zu­führen.

  • Security-Updates sind das Pendant zu Bug-Fixes, die da­zu dienen sollen, Sicher­heits­lücken zu schließen. Diese kom­men wie auch die Bug-Fixes meistens ungeplant.

Wissen ist Macht

Bevor man sich Gedanken darüber machen kann, wie man in einem Unter­nehmen mit den Releases, Fixes und Updates von ein­ge­setzter Soft­ware um­gehen will, steht die Frage, wie denn der aktuelle Stand eigent­lich ist. Welches Release-Gap ist denn vorhanden?

Gerade die Viel­zahl der Kompo­nen­ten, die heute zum Ein­satz kommen, lässt einen schnell den Über­blick ver­lieren. Die Ent­wicklung oder ein Dienst­leister ver­baut eine weitere Biblio­thek. Diese kann aber eine Viel­zahl von Ab­hängig­keiten mit sich bringen, sodass man plötz­lich dutzende von Kompo­nen­ten mit einem eigenen Re­lease-Zyklus im Haus hat.

Eine sinnvolle Maß­nahme kann es sein, den Über­blick über die ver­schie­den­en Release-Stände mit dem Lizenz­manage­ment zu ver­knüpfen. Beim Lizenz­manage­ment muss man auch wissen, welche Soft­ware im Ein­satz ist und welche Lizenz­bedingungen damit ver­bun­den sind. Als Infor­ma­tion wird hier­zu in der Regel die ent­sprech­ende Ver­sion schon miterfasst.

Da dies kein exotisches Szena­rio ist, gibt es hier­für be­reits Soft­ware­unter­stützung. Für die Build-Sys­teme, wie bei­spiels­weise Gradle, Maven oder npm, gibt es Plug­ins, um die Ab­hängig­keiten aus­zu­werten und einen ent­sprechen­den Re­port ein­schließ­lich der mit den Kom­po­nen­ten ver­bun­den­en Li­zen­zen zu erstellen.

Die Lücke, die hierbei noch zu schließen ist, besteht da­rin, neben den ein­ge­setzten Ver­si­onen auch die schon von den Her­stellern ver­öffent­lichten Ver­sionen im Blick zu haben, welche im Unter­nehmen oder der App­li­ka­tion noch nicht ein­ge­setzt werden. Hierfür muss es einen Pro­zess und die ent­sprechen­den Ver­ant­wort­lichen geben. Dies kann je nach Anzahl der ein­ge­setzten Kom­po­nen­ten schon zu ernst­haftem Auf­wand führen, der dauer­haft er­bracht werden muss.

Bei diesem Vor­gehen muss man beim Quell­code ansetzen. Es werden nicht bereits laufende Appli­ka­ti­onen oder fertiger Binär-Code unter­sucht. Das hat aber auch den Vor­teil, dass eine ent­sprechende In­for­ma­ti­on vor der Pro­duktiv­setzung vor­liegt und über­prüft werden kann, ob dies der Firmen­strate­gie genügt. Der Nach­teil da­ran ist, dass der Quell­code oder zumindest die Build-Strecke vor­liegen müssen. Im Zeit­alter der zu­nehmenden Be­deutung von Open-Source-Soft­ware sollte das aber das kleinste Pro­blem darstellen.

Unternehmen müssen eine Update-Strategie für sich entwickeln

Als Unternehmen sollte man bewusst mit den ver­schie­den­en Arten von Re­leases, Fixes und Updates um­zu­gehen. In manchen Branchen, wie bei Banken, gibt es Vor­gaben einer Auf­sichts­behörde, die dies sogar erzwingen.

Am Ende läuft es auf eine Risiko- und Kosten­abwägung und eine darauf aufbauende strate­gische Ent­schei­dung hinaus. Können und wollen wir es uns leisten, die Soft­ware „ver­alten“ zu lassen? Können und wollen wir es uns leisten, den brand­heißesten Re­leases „hinter­her­zu­laufen“?

Die folgenden Fragen können uns dabei helfen, uns dieser Entscheidung zu nähern.

  • Sind in dem neuen Release Sicher­heits­löcher behoben worden?
    • Können diese Sicher­heits­löcher bei uns aus­ge­nutzt werden?
    • Wie wahr­schein­lich ist es, dass diese Sicher­heits­löcher von einem An­greifer genutzt werden?
    • Welchen Schaden würde durch die Aus­nutzung dieser Sicher­heits­löcher entstehen?
  • Sind in dem neuen Release Bugs behoben worden?
    • Können diese Bugs bei uns auf­treten?
    • Wie wahr­schein­lich ist es, dass diese Bugs auftreten?
    • Welchen Schaden würde durch dies Bugs entstehen?
  • Gibt es in dem neuen Release neue Features?
    • Wollen oder müssen wir diese Features (jetzt) einsetzen?
    • Welche Folgen hätte ein Verzicht auf diese Featues?
  • Mit welchem Aufwand ist die Aktua­li­sie­rung verbunden?
    • Welche Kosten ent­stehen, wenn die Aktua­li­sie­rung jetzt durch­ge­führt wird?
    • Welche Kosten ent­stehen, wenn die Aktua­li­sie­rung später durch­ge­führt wird (technische Schulden)?
      • Welchen Ein­sparungs­effekt hat eine ge­mein­same Ein­führung mehrerer Releases?
      • Wie stark wird die Weiter­ent­wick­lung durch die Nicht-Ein­führung behindert?

Diese und ähnliche Über­legungen müssen an­ge­stellt werden, um zu einer validen Kosten-Nutzen-Ab­schätzung kommen zu können. Oft­mals muss dies nicht individuell für jedes einzelne Release ge­schehen, sondern kann über­greifend für eine App­li­ka­tion oder eine Bibli­o­thek erledigt werden. In diesem Fall kann man bei­spiels­weise Regeln defi­nie­ren, welche eine Aktua­li­sie­rung er­zwingen oder verbieten.

Produktstrategien vs. Agilität

Manchmal wird ver­sucht, dem Problem mit ri­go­ro­sen Archi­tek­tur­vor­gaben zu be­geg­nen. Das kann dann bei­spiels­weise fol­gen­der­maßen aussehen:

„Es darf nur Software aus der White-List produktiv eingesetzt werden.“

Wie soll man in diesem Fall mit den Soft­ware-Aktuali­sie­rungen um­gehen? Sind diese dann erst einmal ver­boten, bis jemand die White-List aktua­li­siert? Sind diese erst einmal er­laubt, bis jemand fest­stellt, dass ein Release un­er­wünschte Eigen­schaften aufweist? Und muss dann die Soft­ware zu­rück­ge­zogen und rück­ge­baut werden?

Das Problem damit ist, dass solche Vor­gaben meist den aktuellen Ent­wicklungen hinter­her laufen. Im besten Fall sind solche Archi­tek­tur­vorgaben schwer­fällig und ver­hindern, dass der Vor­teil, schnell neue Features der Soft­ware zum eigenen Nutzen zu ver­wenden, aus­ge­bremst oder gar ganz ver­hindert werden.

Das Bewusst­sein dieser Proble­matik und die recht­zeitige Aus­einander­setzung da­mit bietet eine erste Grund­lage für einen an­ge­messenen Um­gang. Wir müssen mit der Welle der Ent­wick­lung mit­reiten, um nicht am Ende von ihr ge­trieben und über­rollt zu werden.

Dranbleiben!

Und was können wir dem allem lernen? Soft­ware ist nie fertig. Wir müssen bei unserer Soft­ware be­ständig am Ball bleiben. Es muss klar ge­regelt werden, auf welche Weise die Soft­ware am Leben er­halten wird und wann eine Rund­er­neue­rung oppor­tun ist. Die Zeiten können sich ändern und aus einem Sommer ein Winter werden. Dann surfen wir nicht mehr im Wasser, sondern auf Schnee und müssen die Lawine fürchten, die uns über­rollen kann.

Software, die nicht kontinuier­lich ge­wartet und weiter ent­wickelt wird, ist tot. Wenn wir nur träge auf dem Meer dahin­treiben oder den Wellen hinter­her rudern macht das Surf-Board keinen Spaß. Wir sollten schon sehen, dass wir eine Ge­schwin­dig­keit und eine Welle finden, die uns zügig voran bringt, uns aber nicht über­rollt und er­tränkt. Und selbst der Wechsel des Aggregatzustands könnte als neue Heraus­forde­rung ge­sehen werden, der wir uns gerne stellen.

Diesen Artikel bewerten
 
 
 
 
 
 
 
0 Bewertungen (0 %)
Bewerten
 
 
 
 
 
 
1
5
0