Amikre nem számítottam

A következő írás talán hasznos lehet a következő szituációkban:

Szituáció 1: felszolgáló vagy egy elit étteremben, személyesen az Elnökúr jön a babájával vacsorázni. Kis pánik tür ki a management körében amikor az elnök úr panaszkodik a terítő tisztaságára (ő ette le), újrateríteni macerás, rövid ötletelés után úgy döntötök, hogy gyorsan kirántjátok a terítőt a lecsóspacalpörkölt alól és ugyanazzal a mozdulattal gyorsan be is csűritek a tisztát.
Én a saját szememmel láttam ilyet a tévében.

Szituáció 2: heggesztőmunkás vagy egy pénzügyi cégnél. A JEE halott, a cég kidobja a szemétbe 20 évi befektetését és áttelepül spring boot-ra. Ja... és microservices.
Aki dolgozott már ilyen helyen, az tudja milyen csillagászati összegek forognak kockán ha valamit elrontunk. Ahogy a BBC dokumentumfilmek unalomig ismételt konklúziója is megfogalmazza: failure is not an option.

Volt pár dolog, amire persze a legelején számítottam:

• Minden EJB cókmóknak búcsút kell mondanunk örökre - jajjdesajnálom
  
• A library függőségek portolása fáj.
  A spring boot sajnos ugyanolyan mint a webklotyi meg a többi JEE kövület abból a szempontból, hogy van egy sor támogatott library amit ad, az ember használhat saját librarykat, de ha valami ütközésbe kerül a JEE szerver vagy a spring boot által adott librarykkal, akkor elég nehéz feloldani a konfliktust.
  Ez nyilván szubjektív, de nekem úgy tűnik, a webklotyiban mégiscsak könnyebben volt lehetséges. Sebaj. Webkoltyi, becstelen halált halsz.
  
• Nehéz átállni spring fejlesztésre olyan fejlesztőkkel, akik elötte egész életükben JEE platformra fejlesztettek.
  

...és amikre NEM számítottam:

Header limit

Látszólag a webklotyi nem alkalmazott megszorításokat a header-ek méretén, 128 KB-ig próbáltam, mindent bevett.
A tomcat viszont default-ból 8 KB korlátot használ. Ez is a teszt rendszeren derült ki, sok consumer minden kéréséhez a jóhiszeműség bizonyítékaként egy headerben elküldi a Biblia teljes szövegét.
A megoldás egyszerű: felhúztam minden spring boot appban a korlátot egy tisztességesen magas korlátra.
Kis magyarázat: sok szoftver, ami a szoftverünknek küld REST hívásokat nem rendelkezik állandó fejlesztőcsapattal, valamint nagyon sok is van belőlük, viszont "failure is not an option", azaz nem csinálhatok olyan változtatást, amitől hanyattesnek egyes furcsa kliensek, ezek is fontosak valakinek.

Gzip

Miután sikerült az agytranszplantáció és felbootolt a rendszer, minden úgy tűnt, hogy működik, bedobtuk az új alkalmazást tesztelésre és mindenkit nagyon szépen megkértem, hogy vagy futtassa a tesztjeit, vagy manuálisan teszteljen. Pont a legeslegfontosabb consumer csapat jelzett vissza, hogy időnként nem működik. Időnként... az mi?
Néztem a logokat és úgy tűnt, részünkről minden oké, HTTP 200, sehol egy hiba mi lehet a baj?
Sok "egyeztetés" (pöcsölés) után végül úgy döntöttem, legegyszerűbb, ha magam próbálom ki a consumer appot. És akkor kiderült, hogy az alkalmazás mindig is küldött egy Accept-Encoding: gzip headert, ezt a webklotyi app és container folyamatosan figyelmen kívül hagyta (korrekt).
A spring boot setupban viszont a zuul konfigurációban volt egy gzip opció engedélyezve, és ha kb 60 KB felett volt a válasz, akkor bekapcsolt. A consumer app viszont hiába kapta meg, hogy "Encoding: gzip" a tömörített tartalmat próbálta json deserializálni.
Megoldás: kikapcsoltam a gzip opciót, mivel nincs lehetőségem minden consumer appot debugolni.

Szemaforok, timeoutok

Az első terhelési tesztek után figyeltem fel arra, hogy egyes http kérések fentakadtak a zuul szemaforain. Megbeszéltük a kollégákkal és felhúztuk a szemaforok számát annyira, amennyi az éles rendszer terhelése alapján értelmesnek tűnt, illetve megszoroztuk kettővel a biztonság kedvéért.
A teszt rendszeren ezután a terhelési teszt szépen átment, semmi probléma.
Aztán az első éles üzem napon azonnal beütött a szemafor probléma. Felemeltem megint duplájára és igazán reméltem, hogy többet soha az életben nem látom ezt a hibát, és egy pár hétig tényleg béke volt, aztán megint beütött.
Egy újjabb emelés következett, most már hónapok óta nem jött a hiba.

Oktatás

A teljes csapatot JEE fejlesztőből spring fejlesztővé konvertálni... mivel a tét csillagászati, a legeslegelején megkértem mindenkit, hogy kérjen időt és eszközt átképzésre. Ezek az emberek mind különböző outsourcing cégek alkalmazottai, mint ahogy én is. A cég, ahol valójában évek óta dolgozunk, minden ilyen kérést azzal hárít, hogy a képzést az alkalmazó cégeknek kell állniuk.
Így történt, hogy egyáltalán senki sem kapott támogatást a munkaadójától. Se idő, se training. Ezek az outsourcing cégek büdös lófaszt nem érnek.

Egyébként a fejlesztők oldaláról pozitív meglepetés volt, hogy a saját idejükből igazán sokat rászántak, pedig gyakran hallottam videóhívások közben, hogy gyerek sír mellettük.

Tanulságok

1. Legyen teljesítmény teszted. De ne csak hogy legyen teljesítmény-teszted, hanem olyan legyen, amit a fejlesztők tarthatnak karban és használhatnak a saját környezetükön. Sőt, fusson rendszeresen, és frekventáltan is, ha kell ha nem. Gatling vagy akár a rühes JMeter.
2. Az jó, ha vannak integrációs tesztek a REST API-ra, de nem elég. Az sokkal fontosabb, hogy a felhasználó alkalmazásokra is legyenek integrációs tesztek.
   
3. Széllel szembe pisilés:
1. Évek óta próbálok változtatni azon a teszt-mentalításon, hogy ha egyszer működött a rendszer, akkor oké. Szerintem ha egyszer nem működött, akkor nem oké, álljunk meg és derítsük ki a hiba okát.
2. Még mindig nem értem miért pazarolja bárki is a pénzét outsourcingra.
   

full stack

Kétféleképpen voltam full stack developer eddig...

A: Az egyetlen ember a projekten

A nyilvánvaló eset. Amikor nincs rá más ember, én is szivesen megcsinálom a felhasználói felületet. Soha nem kaptam rá szépségdíjat, de nagyobb panaszokat se. Kis-project vagy utolsó túlélő, egyre megy: egy-emberes projekteken igazán kivállóan működik a full stack developer, legalább addig amíg az az ember ugyanaz, lehet néha még utánna is.

B: Fallback opció

Voltunk úgy 100-an a projekten, sok-sok komponens, volt közöttünk linux buherátor, python hívő (mind 2-, és 4-space python) volt nyilván DBA-jellegű ember és sok sok java fejlesztő, köztük én...
De mindig amikor valamelyik modul komponens csapatával együtt kellett működni, pl a python-os program fejlesztőivel, akkor rettenetes háború volt munkára bírni az embereket illetve találni bárkit is aki elvégezte volna a munka rájuk eső részét. Volt, hogy a távoli munkatársamat úgy 3 hétig próbáltam elérni emailben, IRC-en, telefonon... és már azt hittem hogy súlyos beteg vagy lepattant, amikor valaki említette hogy éppen az elöbb találkozott vele a konyhában (alig párezer kilóméterrel arrébb lévő konyhában). Oh mondom, hát él? Megpróbáltam a manageremet kérni, hogy a másik csapattól kérjen olyan embert aki tud és akar foglalkozni a kérésünkkel, de csak ez az ember volt... Heteket csúsztunk, utánna amolyan válságmeetingnek nevezhető megbeszélés következett hogy ezt hogyan tudjuk így folytatni és igazán barátságtalan, amolyan adok-kapok hangulatban fejeződött be.
Ez nem csak egy eset, hanem minden eset ilyen volt.

Erről persze több mint eleget beszéltünk a managerekkel, ők is képben voltak a helyzettel, elő is álltak a megoldással. Ez volt a nagy ötlet: Jó, ha a csapatok együttműködése nem egy sikertörténet, akkor rendezzük át és az új csapatok egy-egy feature-ért vagy funkcionális területért lesznek felelősek, minden komponensen / modulon keresztül ez az egy csapat felelős azért az egy feature-ért. Tehát: 100 ember egy reggel full-stack fejlesztőként ébredt fel, legalábbis a munkabeosztásuk és/vagy business title szerint.

Na és ez talán értelmes ötletnek tűnik annak, aki nem próbálta még, de nekem az volt a tapasztalatom, hogy ha az emberek nem tudtak (és őszintén szólva nem is akartak) együtműködni addig, amíg mindenki a saját szakterületével foglalkozott, akkor már igazán reménytelen próbálkozás az, hogy mindenki belenyúlkál mindenbe.

Minőségi változáshoz nem vezetett a transzformáció, de gyorsabb se lett a fejlesztés.