Szeret vásárolni? A nők zöme e kérdésre vélhetőleg igennel felel, a férfiak esetében talán árnyaltabb a válasz. Az azonban bizonyos: az online shoppingolás lehetősége mindkét nem számára megkönnyíti az életet. A hétköznapokon is, ám a karácsony közeledtével főleg. Jószerével nincs olyan ajándékötlet, amelyet pár kattintással ne lehetne valóra váltani.

Ám elgondolkodtak már azon, milyen mértékű professzionalitást és kapacitást kíván meg mindez informatikai szempontból? Az, hogy a webshopok akciók ideje alatt vagy más, turbulens időszakokban zavartalanul üzemeljenek, ma már természetes elvárásunk, ám jó pár éve még korántsem volt magától értetődő, hogy egy félnapos netes kuponakció okozta roham nyomán nem fagy le az egész weboldal.

Mára ez a kérdés viszonylag egyszerűen megoldhatóvá vált.

A szakemberek ugyanis választ találtak arra a kérdésre, miképpen lehet számítógépes rendszerek teljesítményét minél kevesebb emberi interakcióval, terheléshez alkalmazkodóan, dinamikussá tenni. Régen szakítottak már azzal a koncepcióval, amely egy óriási, erős computer építésével igyekezett nagy teljesítményt elérni – ezt vertikális skálázásnak nevezzük –, hiszen egy idő után azt már nem lehetett tovább erősíteni, kapacitása korlátozott volt, gazdaságilag nem érte meg. Ehelyett az erőforrások optimális kihasználása érdekében sok hétköznapi számítógép teljesítményét adják össze. Utóbbi megoldás – a horizontális skálázás – olcsóbb és rugalmasabb megoldást biztosít.

E módszer a konténerizáció technológia révén is kihasználható.

Ez azt jelenti, hogy a különböző alkalmazások egységes módon, „csomagban” kezelhetők. Azokat konténerben szállítják, magukat a konténereket pedig egy erre kitalált platform futtatja. A fejlesztő az elkészített programot beteszi tehát egy konténerbe: a sok kis gépből összeállított klasztert – ezt a „végtelenül” skálázható erőforráshalmazt – csupán arra kell fölkészíteni, hogy konténereket tudjon futtatni.

Miért forradalmi a konténerizáció megjelenése? Mert míg a hagyományos virtualizáció alatt hosszú percekig tart, míg egy virtuális gép elindul, a konténerizáció révén mindez milliszekundumok kérdése. Képzeljük el, hogy mondjuk egy karácsonyi akció indulásakor, amikor plusz 100 ezer felhasználó özönlik a webshopba és kezd el vásárolni, mekkora mértékben ugrik meg a teljesítményigény. A hagyományos, régi eszközök korában ilyenkor a rendszergazda kapott egy piros lámpát, majd elkezdte bekapcsolgatni az új gépeket. Várni kellett. A látogatók meg gutaütést kaptak a hibaüzenetektől. A konténerizáció jóvoltából a vásárlók mindebből ma már semmit nem érzékelnek: automatizált az egész folyamat. Szenzor figyeli a leterheltséget, és a küszöbérték elérésekor újabb erőforrásokat von be. Emberi beavatkozás nélkül adaptálódik a rendszer a teljesítményigényekhez.

A konténerizáció és a horizontális skálázás egyik lehetséges támogató eszközét a Google pár éve nyílt forrású szoftverré tette. Fejlesztéséhez programozók ezrei szabadidejükben, non-profit módon járulnak hozzá.

A neve: Kubernetes.

A görög szó – amelyből egyébként a kibernetika is származik – kormányost jelent. Az ókorban a tengerészeknek merészségre, leleményre volt szükségük: térkép és navigációs eszközök nélkül hajózva folyamatosan önálló gondolkodásra kényszerültek. Vélhetően így tettek kései örököseik, azok az informatikusok is, akik a Google-nél néhány éve megalkották ezt a fejlesztés gyorsítására és a műveletek egyszerűsítésre használható konténermenedzsment-eszközt. Használata révén a szoftverfejlesztőknek kevesebbet kell az infrastruktúra menedzselésével bíbelődniük, több idő marad az alkalmazások fejlesztésére.

Erre szükség is van.

Ma már egyre több webshop hirdet meg pár órás akciókat, amikor brutálisan alacsony áron lehet a termékeikhez jutni. Ilyenkor néhány órára a korábbi sokszorosára duzzad a forgalom. Nem lehet tudni, hogy a technológiai háttér elérhetősége indukálta e kampányokat, vagy az igény nyomán lendültek bele a fejlesztők a munkába, de tény, hogy manapság nem jelent gondot a technológiai háttér biztosítása az efféle „rohamok” idejére.

A háttérben pedig az történik, hogy a fejlesztő jelzi a Kubernetes felé, hogy egy bizonyos alkalmazásból fusson – mondjuk – minimum három, maximum tíz, a forgalom alakulásától függően. A rendszer pedig automatikusan eldönti, hogy a száz gépből álló pool-ból melyik gépen futnak majd az alkalmazások.

A fejlesztők pedig mindeközben levegőhöz jutnak. Ezt ki is használják.

Sokan éppen arra, hogy az ilyen jellegű eszközöket tovább fejlesszék.

Kipattan egy jó üzleti ötlet. Jönnek a társak, s a latolgatás: versenyképes lesz-e az elgondolás. A potenciális befektetőnek azonban pár mutatós dia a jövőképről, stratégiáról nem elég. És itt jön a dilemma: hogyan lehetne a lehető legszínvonalasabban bemutatni a prototípust?

„Mi e ponton jövünk a képbe, azaz akkor, ha a színes-szagos, már meglévő honlap nem elég: működő technológiai megoldásra, alkalmazásra van szükség – hangsúlyozza Wolf András, a BlackBelt Technology értékesítési igazgatója.

Céljuk, hogy egy kezdő vállalkozást már a legelején a legmegfelelőbb technológiával indítsanak el. Ne kelljen hajmeresztő összegeket kidobnia akkor, ha történetesen egy kockázati tőkésnek vagy üzleti angyalnak kell bemutatnia termékének, szolgáltatásának egy már működő prototípusát. „Már akkor elkezdjük a munkát, amikor egy startupnak még csak pár ügyfele van, és együtt megyünk velük egészen a többezres kliensszámig. Egy kezdő cég nem tudná magától így felskálázni a kapacitásait, márpedig ez egy rejtett műszaki kockázatot jelent. Szolgáltatásunk tehát afféle biztosítás a kisvállalkozások és befektetőik számára is.”

Sokan „okosban” próbálják ezt megoldani: gyorsan fejlesztenek valamit a prezentációra, ám minthogy menet közben a startup és az ötlet is módosul, kikristályosodik, e kezdeti rendszerek általában a kukában landolnak. „Mi ellenben egy stabil műszaki környezetet alkotunk, amely alkalmas a módosításra, modellezésre, akár új prototípus létrehozására”.

Szerverparkok helyett

Nagyon lényeges elem, hogy ezek nem a startup cégek saját szerverén futnak, hanem egy webes központi rendszeren keresztül, amely felhő alapú, s azokra jellemzően weboldalon keresztül lehet regisztrálni. A felhő megoldást azért preferálják a BlackBeltnél, mert skálázható, azaz a szolgáltató által nyújtott szint szabadon alakítható a cég ügyfeleinek számától, kihasználtságtól függően. Minthogy utóbbi folyamatosan változik, szerencsés – és ami talán a legfontosabb: költséghatékony – ha ehhez egy technológiai megoldás képes folyamatosan alkalmazkodni. „A lokális hardverrel rengeteg probléma van: ha egy cég megvásárolja akár a legnagyobb szervert is, az néhány év múlva elavul, így lehet mellé venni egy újat. Pillanatok alatt hatalmas és méregdrága szerverpark épül így ki, amely csak viszi az áramot. Szakembereink ezzel szemben felhőbe költöztetik az alkalmazást, és azt méretben folyamatosan optimalizálják, menedzselik. Egyszerűen hangzik, de nem az. Ez egy szakma, amelyhez csapatunk remekül ért. A különbség pedig havonta komoly összegekben mérhető.”

A BlackBelt koncepciójának lényege tehát, hogy mindent a felhőben tárolnak, működtetnek. Távoli eléréssel dolgoznak; a legprofesszionálisabb hazai és nemzetközi felhőszolgáltatókkal állnak kapcsolatban, velük működnek együtt, őket ajánlják ügyfeleiknek. Segítenek az időtálló és megfizethető technológia kiválasztásában.

Ügyfeleiknek saját fejlesztésű JUDO platformjuk mellé konzultációt is biztosítanak, amellyel felhőbe tudják költöztetni technológiai megoldásaikat. Emellé szolgáltatót is javasolnak. Együtt gondolkoznak klienseikkel, fejlesztéseik a termékfejlesztés életciklusát is követik, vezérlik.

Problémák helyett rendszerek

Szakmai rutin, és jelentős megtakarítás – e kettőt garantálja a BlackBelt. Mindehhez nincs szükség nehézkes tárgyalásokra, találkozókra. „Szükség esetén videokonferenciákon egyeztetünk, ha pedig azt kéri az ügyfél, akkor a teljes megoldást üzemeltetéssel átadjuk számára. Be tud jelentkezni azokba a szerverekbe, ahol fut az alkalmazása. Ha ellenben úgy dönt, hogy ránk bízza az üzemeltetést, azt is vállaljuk. A lényeg: problémákkal keresnek meg bennünket, az együttműködésünk végén pedig létrejön egy új rendszer”.

Számos szektorban dolgoztak már a telekomtól a pénzügyin, kiskereskedelmin át a logisztikáig és az orvos technológiáig. Nemcsak magyar, de nyugati piacokra is fejlesztenek.
„Azáltal, hogy sok iparágban működünk, változatos üzleti problémákkal találkozunk. Mi ezeknek vagyunk a specialistái. Olyan helyzetekre keresünk megoldást, amelyeket korábban még senki nem orvosolt.”

A BlackBelt a fiókban lapuló üzleti ötletek megvalósításában is segít. Melyik cég ne ismerné a problémát, ami abból fakad, hogy a menet közben felmerülő innovációk idő és erőforrás hiányában évekig kallódnak, és sok esetben aztán végleg el is felejtődnek? Minthogy a fő tevékenység hozza a bevételt, onnan nem lehet forrásokat átcsoportosítani. Wolf András csapata azonban vállalja, hogy e terveket valóra váltja. Közben pedig – minthogy ők hangsúlyozottan csak a technológiai oldalt ismerik és képviselik professzionálisan – az üzleti ötlet is biztonságban van.

 

Látott ön már rögbi meccset? Akkor biztosan megvan a jelenet, amikor a támadók egymással szemben, összekapaszkodva, előrenyomással igyekeznek megszerezni az oldalról bedobott labdát. Ez a tolongás vagy viaskodás, angolul scrum.

Az agilis metódus egyik, talán legnépszerűbb módszertana is ezt a nevet kapta, vélhetően arra utalva, hogy a (fejlesztő) csapat tagjai egymással itt is szoros együttműködésben küzdenek a sikerért. Mindenkinek mindenkivel össze kell dolgoznia – ebből adódnak a scrum előnyei: a folyamatos egyeztetések, iterációk, melynek révén az ügyfelek néhány hetente rálátnak a projektre, és azt módosítani, pontosítani tudják. Az eredménnyel nem a projekt végén találkoznak, hanem már menet közben.

A módszer nyilvánvaló előnyei dacára azonban sok cégnél még mindig tartanak az egyeztetések következtében menet közben módosuló büdzsétől.

Pedig a költségek kontrollálhatóak.

Mégpedig a következőképpen: adott egy specifikáció – ezt az agilis metódusban backlognak (BL) nevezzük –, amelyet részfeladatok, un. sztorik alkotnak. Fontos, hogy a sztorik rövidek és lényegre törőek legyenek, ezáltal a megvalósítás nagyfokú szabadságát meghagyják a fejlesztőknek. A sztorikhoz tartozó időigényt az 5-8 tagú team tagjai megbecsülik, ezek alapján sztori pontokat rendelnek a részfeladatokhoz. Ezek is jelenthetik a költségbecslés alapját.

Nézzünk egy példát! Egy webshop esetében például úgy szól a BL, hogy a honlapnak tartalmaznia kell az összes funkciót, amit az ügyfél szeretne. Legyen egy adminisztratív felület, ahova feltölti a termékeit, legyen ügyfélfelülete, tudjon fizetni a vevő, és be lehessen állítani, hogyan jut majd a termékhez. Ebben az esetben a regisztráció az első sztori, a bejelentkezés a második, a vásárlás a harmadik és így tovább. A csapat megbecsüli – a részletesen szabályozott backlog refinement nevű meeting keretében –, hogy az egyes funkciók összesen hány sztori pontot érnek, majd pontonként kikalkulálnak egy összeget. A regisztráció viszonylag egyszerű, jellemzően két pontot ér. A pontonkénti árnak tehát a kétszeresébe kerül, mondjuk kétszázezer forintba. Elképzelhető, hogy az ügyfél ennél olcsóbb megoldást szeretne – erre, a Vízesés modellel szemben, itt van mód. Dönthet úgy például, hogy webshopjában regisztráció nélkül is lehessen vásárolni, de úgy is, hogy egyáltalán nincs szükség regisztrációra. Ilyenkor újra megbecsüli a csapat a sztori pontok számát – ezáltal a költségeket is.

Az ügyfél pedig máris megspórolt egy felesleges funkciót – és akár egy jelentősebb összeget.

A scrum módszertanban minden, így a szerepek is pontosan definiáltak. A Product owner (PO) írja a sztorikat az ügyféllel együtt, ő a BL „gazdája”. Összekötő a csapat és a megrendelő között. Ám nem ő, hanem a team dönti el, hogy a következő néhány hetes etapban mennyi feladatot tudnak bevállalni. A projekt szemlélet az elkötelezettségen, a felelősségvállaláson alapul.

A Scram master részletesen ismeri a módszertant. Ő az, aki a folyamatok, vállalások betartásáért felel. Projektmenedzseri feladatokat is ellát: felelős a csapat összetartásáért, a felmerülő problémák elhárításáért. Ő vezeti a Scrum guide-ban részletesen szabályozott, maximum 15 perces, daily standup meetingeket, ahol a csapattagok beszámolnak egymásnak arról, mit végeztek előző nap, milyen feladatok várnak rájuk aznap, felmerült-e bármilyen, a munkát akadályozó tényező. E három témáról kell nyilatkozniuk a teamtagoknak tehát minden reggel.

A guide kötelezővé teszi továbbá a retrospektív megbeszéléseket is: a kétheti összejöveteleken a fejlesztők visszatekintve értékelik az elmúlt iterációban elvégzett munkákat, levonják a tanulságokat, illetve kijelölik a további fejlődési irányokat.

Az ügyfélnek pedig nincs más dolga, mint néhány hetente beülni egy terembe, megnézni – kipróbálni –, hol tart a számára készülő fejlesztés, és ha szükséges, beavatkozni.

Ez régen elképzelhetetlen lett volna.

Tapasztalatom szerint az ügyfelek mind inkább igénylik a transzparenciát, és szeretnek élni beleszólási jogukkal is. Az agilis szerződésben szerepel az egységnyi költség, a fejlesztő csapat pedig biztosítja, hogy mindig azt készíti el, ami fontos a megbízó számára. A kétheti megbeszéléseken nyomon tudja követni, hol tart a munka, sőt az is előfordul, hogy találkozik a fejlesztőkkel – erre korábban csak közvetetten, a projekt menedzseren keresztül nyílt mód.

A scrum oktatására ma már iparág is épül: tréningeken, workshopokon lehet tanulni e módszer gyakorlati alkalmazását. A lényeg azonban három szóban összefoglalható: rugalmasság, elkötelezettség és valódi, összedolgozó csapat.

Mint a rögbi meccseken.

Képzeljünk el egy nagy, komplex projektet. Másfél évig dolgozik a fejlesztő csapat, szóról szóra követik a szerződésben foglaltakat. Határidőre le is szállítják a szoftvert, és meggyőződésük: mindenben az ügyfél kívánságai szerint jártak el.

Csakhogy a várt ováció elmarad. Nem arat sikert a regisztrációs felület. QR kódot kell használni azonosításra, holott a megbízó – bár ezt nem nevesítette a szerződésben – vonalkódra gondolt.  Meg sem fordult az ügyfél részéről aláírók fejében, hogy más megoldás is létezhet. A projekt elkészült a megcélzott határidőre, de mindkét fél csalódott. A rengeteg energia nem a várt eredményt hozta.

Ismerős a sztori? A szoftverfejlesztés világában dolgozó szakemberek nagy része átélt már effélét. Sokan tudják is, mi áll a háttérben.

A visszatérő problémát ugyanis a Vízesés modell (Waterfall) alkalmazása jelenti.

winston royce waterfall

A tradicionális módszertanok közül máig legjelentősebb megközelítést az amerikai Winston W. Royce írta le egy tanulmányában. A végcél hosszas egyeztetése után induló projekt, pontos határidővel és büdzsével; állandó tagokból álló teamek; a fejlesztés ideje alatt minimális interakció az ügyfél és IT team között – röviden és sommásan ez jellemzi a Vízesés modellt. És noha Royce már a hetvenes években felhívta a figyelmet a metódus hiányosságaira, nem hittek neki. A hosszas előkészítés és a méretes dokumentáció azt a csalfa érzést keltette, hogy mindent nagyon jól előkészítettünk, mindent tudunk és ismerünk, pontosan látjuk az előttünk álló feladatokat. Bár valójában csak egy délibábban gyönyörködtünk.

Vannak persze olyan iparágak, ahol nem nagyon van mód más logika és projektmenedzsment módszer alapján dolgozni. Tipikusan ilyen az állami cégek és közbeszerzések világa vagy a banki szektor. Itt nincs mese: „pontosan” meg kell mondani, hogy a fejlesztők mit, mikorra szállítanak, és persze mennyiért. A hierarchikus szervezetek és a pályáztatás logikája miatt szorosra van kötve minden érintett keze – és ez nemcsak a hazai viszonyok közt igaz.

Az üzleti életben, a saját termék fejlesztésben, a „laposabb”, decentralizáltabb szervezetekben azonban rendkívül kevés feladat olyan, ami indokolja a Vízesés modell alkalmazását, ha létezik másik lehetőség is.

Márpedig létezik.

1986-ban két japán szervezeti kutatással foglalkozó szakember a modell hátrányait kiküszöbölendő javaslatot tettek néhány újításra: önszerveződő, rugalmas csapatok felállítását szorgalmazták, és a folyamatos tanulás fontosságát hangsúlyozták a szervezeteken belül.

A ’90-es évek második felére aztán ezeket a javaslatokat több szoftverfejlesztési úttörő már a gyakorlatban is sikeresen használta, mint Kent Beck az Extreme Programming megálmodója. Sőt: Jeff Sutherland és Ken Schwaber arra vállalkoztak, hogy az addigra már megjelent gyakorlati elemeket rendszerbe foglalják – amiből megszületett a Scrum. Rugalmasan kell válaszolni az ügyféligényekre! – vallották. Ennek nyomán született meg 2001-ben 17 szoftverfejlesztési guru egyetértésével az Agilis Kiáltvány (Agile Manifesto).

AgileManifesto

A legritkább esetben fordul elő, hogy egy ilyen akció mögött nem történelmi-politikai okok, hanem üzleti, szakmai indíttatás rejlik.

Az Agile Manifesto e szempontból is kivétel.

Legfontosabb ajánlásai a megrendelővel történő szoros együttműködésre, hatékony kommunikációra és a változás iránti nyitottságra vonatkoznak. Az agilis módszertan szoftverfejlesztési problémákból nőtt ki, ezért kulcseleme a rugalmasság: a fejlesztés egymásra épülő fázisokra osztva zajlik, minden etapot az ügyféllel történő egyeztetés előz meg, követ és sző át. Az alapokat itt is részletes átbeszélés során fektetik le, ám menet közben – az 1-3 hetes fázisok során – van mód a változtatásra, módosításra, finomhangolásra. Nem ritka, hogy maga az ügyfél kéri eredeti koncepciója megváltoztatását. Fontos elem még a fejlesztési fázisok végi retrospektív, azaz a folyamat áttekintése annak fényében, mit lehetne legközelebb másként, jobban csinálni.

Volt cég, amely korán felismerte az agilitás erejét, mások az elmúlt években fokozatosan térnek, tértek át a modellre. Vannak persze, akik számára máig idegen ez a megközelítés.

Az averzió mögött pedig jellemzően két ok húzódik meg. Egyfelől a tény, hogy nem lehet a projektekhez kőbe vésett végső határidőt és kapcsolódó forrásigényt sem rendelni, sokak számára nehezen kezelhető. Másrészről pedig visszatartó erő lehet a felismerés: a folyamatos egyeztetések a megrendelő cég erőforrásaira is igényt tartanak. Azaz az ügyfélnek időről időre foglalkoznia kell az éppen futó informatikai projekttel, jóvá kell hagynia, vagy éppen meg kell változtatnia annak menetét. Ez figyelmet, energiát kíván. Ráadásul nemcsak a fejlesztésnek, de az abban részt vevő szervezeteknek is agilisaknak kell lenniük, amely lényege: rugalmas vállalat, gyors döntéshozatal, hatékony kommunikáció. Ez megint csak nem mindenütt adottság.

Ezzel szemben áll a mérleg másik serpenyője.

Ebben hajszálpontos végeredmény szerepel: olyan informatikai megoldás, amelyet a megbízó megálmodott. A hibalehetőségek minimálisak, az ügyfél pontosan azt kapja, amit várt. Nincs fölöslegesen kidobott pénz. Ha valahol, itt száz százalékig megáll a „Jó munkához idő kell” igazsága.

Összességében úgy vélem, azok a szervezetek, amelyek már „megégették magukat”, azaz ahol megérett a helyzet a változtatásra – előállt a „sense of urgency” – nagy eséllyel soha többé nem szeretnének visszatérni a Vízesés korszakába. Nem véletlen, hogy tőlünk nyugatabbra az agilis módszertan elterjedtsége sokszorosa az itthoninak.

Jóllehet az átállás sosem fájdalommentes, tapasztalatom szerint a befektetett munka minden esetben meghozza a gyümölcsét.

És a megérdemelt ovációt is.

Az ügyfélportál elkészülte csak a jéghegy csúcsa volt. Ennél fontosabb, hogy a BlackBelttel közösen megvalósított projekt során korszerűsítették, majd összekötötték egymással az informatikai rendszereiket, és megtisztították az adatokat. Ahogyan az ügyfélszolgálati vezető fogalmaz: áteveztek egy új világba.

2015-ben kezdődött. Az Invitel akkori vezetése ekkorra ismerte fel: ahhoz, hogy a versenyképességet jelentősen növeljék, vonzóbbá kell válni. A modernizálás igénye számos program elindulásában öltött testet, ezek egyike az ügyfélportál fejlesztése volt. „Nem volt olyan online felületünk, amelynek révén ügyfeleink önkiszolgáló módon és a nap 24 órájában el tudták volna intézni az ügyeiket, vagy megtekinthették volna azt, hogy mi mit tudunk róluk. A technológiák eközben ekkortájt kezdtek megérni arra, egy kényelmesebb önkiszolgáló rendszert lehessen fejleszteni, ahol az ügyfél nem azt érzi, hogy dolgozik, hanem hogy halad. Ez fontos szempont volt” – emlékszik vissza Ilosvay Csaba vállalati ügyfélszolgálati vezető.

Egyfajta katarzis

Az ügyfélportál kapcsán kiírt tenderre tíz cég jelentkezett, közülük nyert a BlackBelt. „Mindegyiküknek adtunk egy próbafeladatot. A BlackBelt az átadott adatbázis elemekből visszafejtette a működésünket, sőt, még egy működő prototípust is hozott a legegyszerűbb funkciókra. Az adatforgalom struktúrából összerakták az adatbázis hierarchiát és lemodellezték az üzleti folyamataink egy részét. Meglepődtünk, hogy ennyi információból ezt képesek voltak megcsinálni. Tették ezt olyan professzionális módon, hogy akkor nekünk magunknak sem volt ilyen komoly dokumentációnk az adatkapcsolatainkról. Azonnal látszott, hogy pillanatok alatt reagálnak, ha kell, és az is, hogy fejlesztési keretrendszerük, a Judo, megfelelő paraméterezés mellett rendkívül gyorsan tud produktumot előállítani.”

A Judo, azaz a BlackBelt által készített fejlesztői környezet jóvoltából egy-egy kérés felmerülésekor nem kódolni kellett elkezdeni, hanem csupán kiválasztani és cégre szabni a modulokat. Mindemellett Ilosvay Csaba hangsúlyozza: kezdetben rengeteg egyeztetésre volt szükség. Nekik, mint ügyfélnek sok esetben markáns elképzelésük volt a megvalósítás menetéről, ám a BlackBelt szakemberei tapasztalataik alapján ezt – építő jelleggel – nem egyszer megkérdőjelezték.  A két cég folyamatos együttgondolkodása kellett ahhoz, hogy a létező legjobb eredmény születhessen meg. „Erős kézzel vezettek minket végig az úton, nem hagytak beesni a szakadékba. Partnerként álltak hozzánk, gondos gazdaként, mintha a saját portáljuk készülne. Eközben nekünk is fel kellett nőni a feladathoz: a portálfejlesztés csapatmunka, s ehhez a saját háttérrendszerünket is fejlesztenünk kellett. Megdolgoztunk egymásért. Elakadáskor elvonultunk, mindenki gondolkodott egy kicsit, majd utána jött a kreatív, közös ötletelés, melynek nyomán egyfajta katarzis élményt éltünk át. Ily módon számos felesleges költségelemtől megmentettek minket és az egész projektet egyaránt, így összességében nagyon hatékony projekt volt.”

Isten hozott a jelenben, irány a jövő!  

A szakember szerint az ügyfélportál voltaképpen egy kívánatos eleme volt egy olyan hosszú folyamatnak, melynek során rendet tettek: korszerűsítették, majd összekötötték egymással informatikai rendszereiket, és megtisztították az adatokat. Ügyfeleikre partnerként gondolnak: a portál használata során így ők ugyanazokat az adatokat látják, mint az ügyfélszolgálatos kollégák. Ily módon az ügyfélszolgálati munka a közös megoldásra való törekvést jelenti. A felületet – a vizuális megjelenítést, a belső folyamatokat és megoldásokat – folyamatosan fejlesztik, azt ma már több száz ügyfelük használja.

Nem mellesleg a projekt révén új korszak kezdődött az ügyfélszolgálat életében is. A call centeres kollégák számára az integrált rendszerek által és a biztonságos informatikai csatornák megnyitásával egyszerűvé vált a távmunka, hetente több alkalommal is élhetnek ezzel a lehetőséggel – amely az új, potenciális belépők számára is vonzóvá teszi a céget. A projekt tehát nemcsak ügyfeleik, de a kollégák igényeit is kiszolgálja. Ez pedig munkaadóként megfizethetetlen.

„A pályázatok elbírálásakor annak idején szempont volt, hogy a projektnek milyen társadalmi és emberi haszna van. A közös munka egyfajta spirált indított el itt a cégnél, amelynek eredményeképpen ma már elmondhatjuk: az Invitech a jelen legjobb technológiáival felvértezte magát, így immár a jövőbe tudunk tekinteni.”

 

Több mint húsz év telt el azóta, hogy a Netscape Communications kijött a JavaScript (JS)-tel. Kezdetben, a statikus weboldalak idején még csak amolyan „mórickás” volt: jelentéktelen kiegészítő eszköznek tartották, amely olyan kaliberű feladatokat oldott meg, mint a háttér színének megváltoztatása vagy egy-egy ablak „felugratása”. Később, a fogyasztói igények növekedésével aztán megérkeztek a felhasználói élményt (user experience – UX) növelő megoldások, amelyek révén a weboldalak letisztultabbak, funkcionalitás tekintetében pedig szofisztikáltabbak lettek. Ekkoriban értékelődött fel a JS szerepe. Mind nagyobb komplexitású alkalmazásokat kezdtek el vele építeni. Ma pedig már ott tartunk, hogy a webes oldalak jelentős része ezzel fut – a kis webshopoktól a legnagyobb közösségi hálókon át a tudomány sok területéig.

Ennek nyomán persze megnőttek a kódok méretei is – és itt álljunk is meg egy pillanatra.

Képzeljünk el egy szótárat, amely egy nyelv szavait tartalmazza. A könnyebb eligazodás kedvéért az igéket vastagon szedi, a főneveket pedig aláhúzza – azaz szófajonként használ valamilyen megkülönböztető jelölést. Könnyű benne megtalálni egy-egy kifejezést? Nos, nem igazán. Az eltérő betűtípus segít egy picit, de minthogy kizárólag fekete betűket tartalmaz, egy pillanat alatt átfutva egy oldalpárt, aligha talál oda automatikusan a szem a keresett szóra.

A JS nyelv szókincse, azaz a kódbázis némiképp hasonló logika szerint tagolódik. Van egy kis segítség a szófajok – típusok – beazonosításában, de érdemi támogatást nem kapnak a fejlesztők. Erre mondjuk, hogy a gyengén típusos nyelvek közé tartozik.

Amikor tehát a JS alkalmazási területe – és ezáltal a használt kódbázis – szélesedett, ez a gyenge típusosság időigényesebbé tette a fejlesztők munkáját. Amikor ugyanis sok, akár több tízezer soros, bonyolult alkalmazások kódjának szövegezésében nem jelennek meg a típusok, a fejlesztő csak egy rendkívül absztrakt, semmitmondó adatokból álló „szöveget” lát. Márpedig ebből nehéz dolgoznia. Minél nagyobb a kódbázis, annál problémásabb a hibátlan értelmezés. Két választása lehet: vagy tudja fejből értelmezni – ez komplexebb alkalmazásoknál persze nem jellemző – vagy dokumentációt csinál magának (és társainak) róla. Utóbbi megint csak időigényes, és bár sok esetben szükséges, de fejlesztés közben nem a leghatékonyabb módszer.

Nincs más megoldás?  De igen! Az egyik lehetőség erre a TypeScript (TS).

Ez a nyelv szuperszettje a JS-nek: más programnyelvekből behoz már ismert típusokat és alkalmazható módszertanokat. Programozás közben pontosan tudja, hogy a kódnak melyik pontjával dolgozik éppen, nem kell találgatnia, próbálkoznia, dokumentációt olvasnia hozzá. A szótáras metaforánál maradva, most már nem vastagítás és aláhúzás segít, hanem színes szövegkiemelők: ha sárga, akkor ige, ha piros, akkor számnév. A TS egyszerűbb esetekben is alkalmazható, de igazán a problémásabb kódbázisok okán született. Olyan projektek esetén segítség igazán, amelyeken több ember dolgozik egyszerre, gyakori konzultációt igénylő feladatok megoldásán.

Minthogy kódolás közben folyamatosan meg kell adni a típusokat – használni kell a „szövegkiemelőt” – a munka némiképp lassabb, mintha gyengén típusos programnyelvet használnának. Ám később a befektetett idő megtérül: kevesebb hibalehetőséget rejt a kész program, fenntarthatóbb, tartósabb, használata problémamentesebb lesz. Mint ahogyan ezer szót megtanulni egy idegen nyelven tovább tart, mint húszat, ám mennyivel könnyebben boldogul aztán az ember a megszerzett tudásával!

TS-t ma még kevesebben használnak, mint JS-t. Ám mi itt a BlackBeltnél nagyon fontosnak tartjuk az új kollégák támogatását, segítségünkkel hamar elsajátítható e programnyelv használata.

Meggyőződésünk, hogy megéri.

Egyfelől mert a Microsoft áll mögötte, ez szakmai garanciát, folyamatos fejlesztést és bővülő eszköztámogatottságot jelent. Olyan eszközökét, amelyek meggyorsítják a programozást és redukálják a hibalehetőségeket. A JS-hez kapcsolódó eszközök messze nem ilyen hatékonyak.

S hogy mit jelent mindez az ügyfél szempontjából?

Ahogy azt már említettem, a TS révén stabilabb alappal, biztosabb működéssel kell számolni. A program segítségével kisebb a valószínűsége annak, hogy hibát ejtenek a fejlesztők. Ha mégis becsúszna, később azokat gyorsabban és könnyebben lehet korrigálni.

A TS kód egyébként, amit a fejlesztők használnak, egy fordítási eljárással átalakul JS-be. Azaz: magyarul írom a könyvem, mert ezen a nyelven tudom magam igazán szabatosan kifejezni, de angol a célközönségem, ezért lefordíttatom. Mivel a fordító a TypeScript forráskódból JavaScript kódot generál, a program bármely JavaScript futtatására alkalmas böngészőben vagy akár a szerver oldalon is működni fog. Nincs szükség külső programra vagy plugin telepítésére.
Mindezeket figyelemben véve tapasztalataink szerint nagyobb vagy bonyolultabb projektek esetén a TS a kézenfekvő megoldás.

S nemcsak mi gondoljuk így: az alábbi grafikon a TS iránti megnövekedett érdeklődést mutatja:

Móricka nagykorú lett.

Nehéz? Olyan, mint egy vizsga? Sajnálom, én így interjúztatok! – hangoztatja Privitzky Gábor, a BlackBelt Technology műszaki-technológiai igazgatója, aki kezdetektől ragaszkodik a komoly szakmai felvételihez. A céghez csak a legjobbak kerülnek be, ám ők aztán jellemzően úgy érzik: végre egy munkahely, ahol nap mint nap tovább lehet fejlődni. És még a csapat is remek!

Developers„Előfordult, hogy miután az ügyfelünk is meghallgatott néhányat a hozzá delegálandó embereink közül, egy idő után azt mondta: a többieknek most már csak a neveit diktáljátok le, őket már nem hallgatjuk meg. Egészen biztosan jók lesznek!” – meséli büszkén Privitzky Gábor. Mint mondja, a cégnél általa meghonosított szigorú szakmai szűrő, noha erőforrásigényes, hosszú távon mindenképpen megéri: bizalmat épít partnereik körében, szorosabb üzleti kapcsolat alakul ki köztük. „Ha ügyfeleink, akik tanácsadó szolgáltatást vásárolnak tőlünk, azt látják, hogy közös projektjeinkhez mindig felkészült, jó szakembereket küldünk, máskor is bennünket hívnak majd.”

 

Kicsit, mint a Vágó-vetélkedőben

Privitzky Gábor

Az igazgató hosszú évek tapasztalatai alapján már a BlackBelt alapításakor ragaszkodott ahhoz, hogy komolyan vegyék a szakmai felvételiztetést. Korábbi munkahelyein vele is gyakran előfordult, hogy szakmailag nem értett szót egyik-másik kollégával, ez pedig nyilvánvalóan gátja a hatékonyságnak. „Léteznek olyan vállalatok, ahol csupán önéletrajz alapján döntenek. Értesz a C++-hoz? És még Linuxot is láttál? Szuper! Fel vagy véve! Csakhogy ezzel a szűrőt áttolom az ügyfélhez. Ez így nem fair. A kiválasztást nekünk kell megejtenünk.”

Persze nemcsak a szűken vett lexikai tudást, hanem a szakmai rátermettséget és hozzáállást is nézik: mennyire szeretne itt dolgozni a jelentkező, milyen a szakmai érdeklődési köre. Az igazgató hangsúlyozza: azt mérik fel, hogy az egyetemen mennyire figyeltek oda a jelentkezők. „Mondják is azok, akiknek nem sikerült az interjú: ez olyan volt, mint egy egyetemi vizsga. Nos, igen! Én így interjúztatok. A jelöltek gyakran kapnak algoritmizáló jellegű feladatot. Sokszor nem is a konkrét megoldás, hanem az érdekel, hogyan gondolkodik a felvételiző. Tudja-e, hogy mekkora a szóban forgó algoritmus időbeli bonyolultsága? Rájön-e, hogy ez egy exponenciális, polinomiális, négyzetes, esetleg lineáris probléma? Ha már találkozott az egyetemen hasonlóval, vagy gondolkodott valaha ilyesmin, akkor jó választ fog adni. Persze volt már olyan, hogy nemcsak a gondolatmenetet, de a konkrét megoldást is megmondta valaki. Az illető most is nálunk dolgozik.”

Eközben számít az is, hogy a jelentkező egy esetleg számára túl nehéznek bizonyuló feladatot miképpen kezel. Nem jó, ha magabiztosan mellébeszél, de az sem, ha feladja. Ilyenkor célszerű, ha inkább elkezd hangosan gondolkodni, honnan közelítene a megoldás felé. „Kicsit olyan ez, mint annak idején a Legyen Ön is milliomos!-ban. Körbe lehet járni a témát, szabad segítséget kérni” – jegyzi meg Privitzky Gábor.

 

Tudni illik

Így tett a gyakornokként két hónapja itt dolgozó Stasz Balázs is az interjún kapott feladat kapcsán. Noha megoldása nem volt tökéletes, a jó megközelítéssel állt a feladathoz. „A felvételit általánosságban nem éreztem túlságosan nehéznek. Úgy gondolom, a feltett kérdésekre adott válaszok jó részét minden fejlesztőnek illik tudnia” – véli a Budapesti Műszaki és Gazdaságtudományi Egyetemen januárban diplomázó hallgató, aki jelenleg JAVA fejlesztőként bővíthet ismereteit a BlackBeltnél.

A felsőoktatással kapcsolatos tapasztalatok alapján Privitzky Gábor úgy látja: azok a jó képzések, ahol a hallgatókat a megszerzett tudás felhasználására készítik fel, és gondolkodni tanítják meg ahelyett – sajnos néhány intézménynél ez sem ritka –, hogy az aktuálisan fontosnak gondolt technológiák részleteit magoltatnák be.

Mindemellett a nyelvtudást is muszáj még felmérni, ez rendkívül fontos, ha valaki nálunk szeretne dolgozni – fűzi hozzá az igazgató.

 

Szédítő tempó

Van persze olyan is, hogy nem ő interjúztat, de a szakmai szűrőn akkor is át kell esniük a delikvenseknek. Mocsányi Ákos senior fejlesztő nemrégiben például DevOps Engineer (azaz fejlesztő és egyben üzemeltető) munkakörhöz választotta ki a legjobb jelöltet. „A személyiségre voltam kíváncsi, az üzemeltetési tapasztalatra, és arra, mennyire magabiztos a jelentkező. Fontos volt, hogy ne szeppenjen meg, amikor az interjú egy pontján megkérem: írjon egy programot, én pedig nézem közben. A feladat egyébként nem volt túl nehéz. Az érdekelt, hogyan kezel egy ismeretlen gépet, eszközöket. Mégis voltak páran, akik ettől leblokkoltak.”

Nem így László Levente, aki a megmérettetés során a legjobbnak bizonyult, és néhány hete meg is kezdte a munkát a cégnél. „Nem volt nagyon izzasztó – tízes skálán mondjuk úgy ötös nehézségű lehetett a feladat –, de azért kicsit esetlenné tett a helyzet, ki is zökkentett. Kezdetben zavart lesz az ember, hiszen új a környezet, de aztán átállítottam pár dolgot, és megoldottam. A légkör egyébként kellemes volt, tapasztalataimról, ügyfélkezelésről és az érdeklődési körömről egyaránt beszélgettünk”.

Ez persze nem véletlen. Az öt évvel korábban megszerzett ismeretek már-már elavultnak számítanak, fontos tehát az erős szakmai érdeklődés. „Aki lemarad, néhány éven belül képtelen lesz betölteni a munkakörét” – állítja Mocsányi Ákos. Ezért is lényeges feltérképezni, hogy a jelentkező mennyire nyitott és kíváncsi a legfrissebb technológiai trendekre, képes-e befogadni az újdonságokat. Szédítő tempóban változik a szakma – lépést tartani csak a legjobbak tudnak.

A fekete övesek.

Hogy kicsoda Satoshi Nakamoto? Máig nem tudjuk. Személyt vagy társaságot egyaránt takarhat a név, annyi azonban bizonyos: a múlt évtized végén egy olyan decentralizált rendszer részleteit publikálta, melyben a klasszikus pénzügyi szereplők (bank, clearing house) mellőzésével lehet értéket vagy pénzt tárolni és mozgatni meghamisíthatatlan és utólag módosíthatatlan módon –  digitális aláírások és hash láncok alkalmazásának köszönhetően. Ehhez kidolgozta a blockchain nevű adatstruktúrát, valamint az új tranzakciók hozzáfűzésének protokollját. Ezek révén lehetővé vált, hogy harmadik fél bevonása nélkül tudjunk elektronikusan pénzt kezelni.

Képtalálat a következőre: „blockchain”

A blockchain blokkok láncolatát jelenti, blokk alatt pedig ebben az esetben egy olyan csomagot értünk, amely akár több száz, a Föld bármely pontján lezajló pénzügyi tranzakciót tartalmaz. Ezek rákerülnek a blockchain hálózat tranzakciós listájára, amikor pedig összegyűlt belőlük körülbelül 350 (eredetileg 1 megabájtnyi, de ez blockchainenként változó), azokat egy blokkban a lánchoz kell fűzni. A blokkok úgy vannak összekapcsolva, hogy nem lehet kivenni egyet és betenni a helyére egy másikat, vagy egyszerűen csak összekötni azokat, amelyek a “kimetszés” után egymás szomszédjai lennének. A lánc tehát utólag nem módosítható, és a blokkok egymáshoz fűzése csak egy költséges műveletsor elvégzése árán történhet meg.

Blokkot létrehozni és a lánchoz fűzni csak egy bonyolult feladvány megfejtésével lehet.

És itt kerülnek a képbe a blokkbányászok.

A bányászok nagy teljesítményű számítógépeket állítanak munkába annak érdekében, hogy az említett rejtvényt megfejtsék. Hogy néz ki a feladvány? Nos, ehhez előbb meg kell értenünk a hash fogalmát.

Ez egy karaktersorozat, melyet a hashfüggvény állít elő – utóbbi lényege, hogy bármekkora adattömegből egy lényegesen rövidebb (fix méretű) karaktersorozatot (hasht) készít. A „bányagép” először kiszámítja a blokk hashét. A feladvány pedig így szól: találd meg azt a számot (nonce), amit ha hozzáhashelünk a blokk hashéhez, akkor az új hash bizonyos jellemzőknek megfelel – például négy 0-val fog kezdődni.  Ezt megtalálni persze elég nehéz. Amint azonban a világ blockchain-bányái érzékelik, hogy összegyűlt egy blokknyi tranzakció, versenyezni kezdenek az aktuális feladvány megoldásáért.

Világszintű verseny veszi kezdetét. S hogy mi a cél? A jutalom!

Ez pedig egy kriptodeviza-adag, ami a leggyorsabban megoldást szállító bányászt illeti. A kriptodevizának (Bitcoin, Ether stb.) pedig dollárban, euróban stb. rögzített aktuális árfolyama van.

A Bitcoin tehát blockhain alapú digitális pénz, protokollja, szoftvere révén a számítógépek hálózata egy megosztott könyvelést működtet a világhálón keresztül. Jóllehet a Bitcoin piaci kapitalizációja a legnagyobb, ma már több száz kriptodeviza létezik. E rendszereket világszintű decentralizáltságuk révén nem lehet leállítani, megszüntetni. Nincs olyan geopolitikai helyzet, vagy titkosszolgálat, amely a működésüket leállíthatná. A blockchaint nem lehet kikapcsolni.

Képtalálat a következőre: „bitcoin”

S hogy kik állnak a bányagépek mögött?

Bárki, aki össze tud rakni egy hozzávetőleg két-háromezer dollárt érő célgépet.

A nagyobb bányák viszont óriási géptermek, hangárok, melyekben több tízezer gép csap elég nagy zajt. Cégek, magánszemélyek, államok a tulajdonosok, akik olcsó és megbízható energiához férnek hozzá a bányák folyamatos és óriási energiaszükségletének kielégítésére. Ehhez, jelenleg úgy tűnik, Kínában a legmegfelelőbbek a feltételek, de hírek szerint Oroszországban már állami szinten készülnek kriptodevizát bányászni. Ott áramszolgáltató cégek igyekeznek bányászokkal szövetkezni, számukra olcsóbb áramot biztosítva. Az utóbbi hetekben Észak-Korea is nagyszabású bányászakcióba kezdett. A szomszédunkban, Ausztriában pedig egy lány testvérpár néhány éve HydroMiner néven alapított céget: a bányászathoz vízierőművekben előállított olcsóbb és környezetbarát áramot használnak.

De mennyire jó üzlet ez?

Az évtized elején még könnyű volt Bitcoint bányászni, és sokan kíváncsiságból kezdtek bele. Városi legendák szerint egy egykori pesti informatikushallgató egyetemi évei alatt bányászott bitcoinjai idén nyár elején több mint 300 millió forintot értek, és azt tervezi, ha felszalad az áruk egymilliárd forintig, nyugdíjba megy.

Bitcoint bányászni ma már nehéz, más valutákat – például Ethert – lényegesen könnyebb. A piacon azonban hozzá lehet jutni a kriptodevizához, és annak árfolyamát kizárólag a kereslet-kínálat alakítja, központi szereplő jegybanki eszközökkel nem befolyásolja. Ennek persze megvannak a hátulütői is. Jelenleg például az árfolyam rendkívül volatilis: egyetlen nap alatt harminc százalékot is képes mozogni egyik irányba, majd húszat a másikba. A kriptodeviza piac most a spekulánsok játszótere, ám jelenleg az össznépi játékban csak a Föld népességének kevesebb, mint egy százaléka vesz részt.

Ez az arány azonban egészen biztosan emelkedni fog.

Előrejelzések szerint a Bitcoin árfolyama is óriásit robban majd az elkövetkező tíz évben, egyes becslések szerint akkorra 50 ezer dollárra rúghat. Jelenleg azonban ettől még messze vagyunk. És bár ma még jellemzően befektetési eszközként tekintünk rá, fizetni egyre több helyen lehet majd vele.

Japánban már most sok helyen elfogadják a Bitcoint. A kasszagép egy QR-kódban megjeleníti a tranzakció adatait (összeg, Bitcoin cím, tranzakció-azonosító), a telefonon levő pénztárca pedig leolvassa azt, és indítja a fizetést. A tranzakció pedig – ahogyan arról már szó volt – egy blokkba íródik. A bankszámlát ebben a kontextusban címnek nevezik, arra és arról könyvelődnek az összegek. A telefonról elküldött összeg pedig a bolt címére kerül.

De hogy jön ide a tulipánmánia?

A címben említett virághagymákat Törökországból a bécsi udvar isztambuli nagykövete hozta be Európába, majd egy holland botanikus terjesztette tovább Hollandiában az 1500-as évek végén. Az emberek megőrültek értük, a tulipánmániának tízezrek köszönhették meggazdagodásukat. Aztán egy árverésről egyszer csak elmaradoztak a vevők. Noha a háttérben a bubópestis állt, a lufi pillanatok alatt kipukkadt, a tulipántőzsdézésnek befellegzett. Sokan idézik a sztorit a Bitcoin kapcsán is.

 

Ám az eddigi fejlemények azt mutatják: a kriptodevizák kora előtt állunk.

A Kubernetes technológiáról korábbi cikkünkben már részletesen írtunk. Akkor a horizontális skálázással kapcsolatban emeltük ki a megoldás előnyeit. Léteznek azonban más helyzetek is, amelyekben áttörést hozott e technológia.

Tekintsük ehhez a szoftverkészítés tevékenységét a korszerű, agilis megközelítésben. Ez egy részfeladatok rendszeres ismétlésére épülő folyamat, mely magába foglalja szoftverfejlesztési életciklus minden elemét. Úgymint: tervezés, elemzés, programozás, futtatható formátumra hozás, egység tesztelés, átvételi tesztelés.

A programozási fázis utáni feladatok nagyban automatizálhatók, amire szükség is van ahhoz, hogy a tesztelés ne vonjon el emberi erőforrást a csapattól, valamint, hogy minél gyorsabb visszacsatolás érkezzen a fejlesztőkhöz a legutóbbi változtatások helyességéről. Ezek az automatikus lépések gyakorlatilag folyamatosan integrálják a fejlesztők által eszközölt forráskód módosításokat az alkalmazásba. Innen a fázis neve: Continuous Integration. Könnyen belátható, hogy ez a módszertan a hagyományos, vízesés jellegű metódusokhoz képest – ahol a visszacsatolásokra sokszor hónapokat kellett várni – sokkal rugalmasabb, alacsonyabb kockázatú, az üzleti környezet folyamatos változásaihoz sokkal könnyebben alkalmazkodni képes projekteket eredményez.

A Continuous Integration továbbgondolása a Continuous Delivery és a Continuous Deployment. A Continuous Delivery az újonnan a programba épített funkció elérhetővé tételét jelenti. Ennek keretében kitelepítik egy tesztszerverre – ez még nem az ügyfélé –, megint csak automatizáltan. Ez egy közbülső rendszer, ahol már a potenciális felhasználók is meg tudják nézni. Itt egyfajta minőségbiztosítási eljáráson esik át a funkció.

A Continuous Deployment pedig az utolsó fázis, amikor mindez – automatizmus útján – kikerül az éles rendszerre.

A cél az egész folyamat során az, hogy idejekorán és automatikusan minél pontosabban leteszteljük a programot. A rengeteg teszt lefuttatása azonban nagyon sok időt vesz igénybe, és nagymértékben leterheli a rendszert. Ehhez erőforrások kellenek.

És itt juthat ismét szerephez a Kubernetes.

Minthogy bizonyos folyamatok több erőforrást igényelnek, mások kevesebbet – a tesztek számától és jellegétől, a tesztelt rendszerelemek szükségleteitől, az automatizmusok párhuzamosítottságának mértékétől függően – dinamikusan kell a végrehajtásba bevont erőforrásokat skálázni. Ennek egyik lehetséges technológiája a konténerizáció, annak pedig egy jól működő, nyílt forrású támogató platformja a Kubernetes.

A feladat ugyanakkor csupán messziről tekintve tűnhet egyszerűnek, ahogy közelebb ér az ember, kiderül, hogy rendkívül komplex. Mint a repülés: jól néz ki, hogy csak felszállunk a gépre és az elrepít nyaralni, de közben a pilótafülke gombok százaiból áll. Itt is ez a helyzet. Könnyű elkezdeni a Kubernetes-szel dolgozni, de a hatékony használathoz már nagyon kell hozzá érteni.

A világ ugyanakkor erre tart.

A fejlesztői társadalom ugyanis valósággal „rácuppant”, hiszen ezzel a megoldással nagyon sok hasznos dolgot el lehet érni, amire eddig nem nyílt lehetőség. A kapcsolódó eszközök fejlődési üteme szédítő: havonta számos újdonság lát napvilágot a közösség jóvoltából, tovább könnyítve a használatát. Folyamatos tanulásban vagyunk.

Az ügyfelek pedig igazán elégedettek lehetnek.

A CI/CD koncepció gyakorlati alkalmazása ugyanis nagyban hozzájárul az erőforrások hatékonyabb kihasználásához, így profibb, kevesebb hibalehetőséget tartalmazó programot kap a megrendelő, kedvezőbb áron.  Hiszen, mint említettem, minden változtatás azonnal tesztelésen esik át, nem veszítünk tehát időt, villámgyorsan zajlik a visszacsatolás. Míg korábban ahhoz is idő kellett, hogy az üzemeltető csapat kitegye a programot az éles rendszerre, itt ez most fel sem merül. A felhasználói élmény (user experience) is azonnal rendelkezésre áll.

Mindennek persze előfeltétele az agilitás. A korábbi, Vízesés modell még a hagyományos, hatvanas évekbeli mérnöki szemléletből – a felhőkarcolók, hidak, látványos beruházások idejéből – ered. A szoftveriparban azonban óriás pazarlás volt ezt alkalmazni, megérett hát az idő a paradigmaváltásra. Hiszen az ügyfél nem ér rá.

Mostantól nem is kell várnia.