Az IBM terméke generatív AI segítségével konvertálja a COBOL kódot Java kóddá

IBM, Lenovo

Mivel csillió sornyi régi COBOL kód lehet még termelésben, az IBM úgy döntött, hogy lenne piaca egy megoldásnak, ami generatív mesterséges intelligencia segítségével konvertál COBOL kódot Java kóddá. A watsonx Code Assistant for Z termék 2023 negyedik negyedévében válhat elérhetővé. Részletek itt.

( _ventura_ v | 2023. 08. 23., sze – 13:59 )

Akkor a cobol programozók munkáját (akiket hirtelen képeztek ki nemrég), átveszi az AI :D

Fedora 41, Thinkpad x280

( asm v | 2023. 08. 23., sze – 14:17 )

Aztan nehogy az ugyfelek elmigraljak az appjaikat Z-rol.

Azt nem tudom, de amelyik COBOL kódot most fogják konvertálni, az nyilván évtizedek óta működik az adott környezetben, tehát kísérleti bizonyíték van a helyességére.

A bemenetről tehát tudják, hogy helyes, ami meg lesz beőle, arról legfeljebb hiszik.

Science for fun...

Ez műszakilag nyilván nem helyes viszont a rizikót elég jól csökkenti ami a menedzsereknek általában elég (sajnos).

Ebből a hozzáállásból van aztán az, hogy jön egy hekkercsávó és nagyon csúnyán lenyúlja a céget egy csomó pénzre...

zászló, zászló, szív

Kódból fordított (byte)code amit a Java appok futtatnak. A hardveren futó x86 vagy AMD64 kódot is belső opcode-okra fordítja át a CPU, ráadásul másra az AMD és másra az Intel, még a generációk között is van különbség. Rég elmúltak már azok az idők amikor az igaz férfiak gépi kódban írták a cpu által végrehajtott valódi kódot. 

Ez bármelyik régi nyelvre igaz lenne, ha a környezetet (egész platform, vagy csak az interpreter/compiler) emulálod alá, akkor megy ma is akárhol. Nem a COBOL sajátja, az annál régebbi Fortran, Lisp is tudja, de a 3 évre rá megjelent C is a 51. évét tapossa, és ugyanez mondható el rajta.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( DirtY_iCE | 2023. 08. 23., sze – 14:20 )

Az AI 5 perc alatt atirja a cobol kodot java-ra, majd utana a java fejlesztok akiknek fogalmuk sincs a cobol-rol, kereshetik meg javithatjak 5 even at az atiras soran behozott bugokat. Jo.

I hate myself, because I'm not open-source.

Azt gondolom, hogy nincs is más elképzelés erre, mint hogy a heavyliftinget megcsinálja ez az eszköz(gyűjtemény), aztán egy nagyon hosszú, manuális, de már beláthatóbb idejű javítás és tesztelés következik. Az 5 év még valószínű még kevés is, a realítás ennél több lehet, de leaglább már nem arról beszélünk, hogy képtelenség. Izgalmas terület, és kézenfekvő is a Java. 

Illetve, elő-elő kerül a Python is.

( sz332 v | 2023. 08. 23., sze – 16:44 )

Érdemes megnézni a videót, hatalmas csodát egyébként nem csinál, de kezdetnek jó lesz. Megjegyzem, 2023-ban miért akar valaki direkt SQL query-ket írni java kódba? 

Tehát a végén sem időt, sem pénzt nem takarítottink meg. Remek dolog ez az AI. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Az OTP MobilBank használata során olyan tevékenységet észleltünk, amely veszélyezteti az Ön adatait. Ezért ezzel az eszközzel nem engedélyezett az OTP MobilBank teljes körű használata.

Az észlelt tevékenység az elrejtett Magisk app (az is egy kérdés, hogy miért kell az OTP-nek vagy úgy bármilyen banki appnak hozzáférés a mobilon található appok listájához :)). Arról nem beszélve, hogy belépés után dobja fel akkor meg már úgyis mindegy. :P

Igazából nem tudom megmondani, de nagyjából annyi biztos, hogy a java-s csapatok stabilan tudnak szálltani, illetve van medior/senior/lead szintű ember bőven a piacon akit egyáltalán el lehet hozni, és abban a környezetben ami alapvetően alvállalkozó team-ek rakják össze a rendszereket, ez egy tök nagy előny. Van egy nyelv, azt tudják frankón üzemeltetni, teljesítményben jó, stabilitásban jó, és a fejlesztő csapatoknak is van bőven banki tudásuk.

( n.balazs v | 2023. 08. 23., sze – 17:50 )

A francba. Pedig már régóta gondolkodom, hogy átnyergelek Cobol fejlesztővé. Aztán a nyugdíjig ellavírozok a 2-3-4m+-os fizetésből. Kell találnom valami jobb melót. (félig vicc, félig komoly)

( Raynes v | 2023. 08. 23., sze – 18:17 )

Ez a COBOL kb. a világ 3. legbalfékebb szintaxisú nyelve (az Agda és Brainfuck után), ha a funkcionális nyelveket nem nézem. Néhányszor nekifutottam a tanulgatásának, de tényleg nem lehet ezt szebben mondani, agyf*** az egész. Egyszerűen rosszul van megtervezve, mindenben kb. ellentéte egy jól átgondolt C-nek. Csak azért maradt életben, mert sok lusta cég meg kormányszerv spúr volt időben átíratni ilyen muzeális mainframe kódokat. Tényleg viccnek is olyan durva, hogy max. az ellenségemnek kívánom, nem is csoda, hogy ehhez normális fejlesztők csak csillagászati pénzért hajlandóak akár bottal piszkálva hozzányúlni.

Az AI meg nem lesz sose megbízható egyrészt, másrészt átírják Java-ba, hát kösz, de azt is inkább ne, szutyok nyelv, csöbörből vödörbe.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Miért ne Java legyen? Folyamatosan fejlődik, visszafele kompatibilis, jó a teljesítménye, ismertek a nyűgök, de megoldja a problémákat lassan 30 éve. Lehet hozzá felvenni senior (valódi senior) embereket, akár tömegesen is, és nem úgy néz ki hogy kihalna, ami miatt le kellene cserélni. Van hozzá kiváló ide, tooling, statikus kód analizátor, minden ami kellhet, és egy rakás nagyon kiforrott, stabil, open source framework és könyvtár. Gyakorlatilag nincs egy olyan nyelv amely összességében ennyire erős értéket tudna szállítani a jelen dátumot tekintve. 

A lambda kifejezések és a "null pointer dereference" kivédése is megjelent benne már jóideje, amikért sírtak sokat és az aszinkron programozás és a virtuális szálak is kezdenek csorogni mellék és főágakon. Ugyanúgy a vektor műveletek is megjelentek a 19-ben.

De aki utálja, az meg körbe Skálázhatja vagy Kotlinolhatja :D

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Sok banki rendszer van, ami nem ügyfélnek szól, hanem ügyintőzők és üzletkötők, behajtáskezelők használják. Plusz van sokféle riportálási kötelezettség, azokhoz is vannak külön rendszerek (Basel III, IFRS9 például). 

Ezek meg gyakran oracle adatbázist és oracle alkalmazásszerverét használják (WebLogic), néha JBoss/WildFly-t vagy WebSphere-t. 

Amikor még elkezdték fejleszteni 10-20 éve őket, akkor a JEE volt olyan, ami skálázódást ígért és amire hosszú támogatási idő és hotfix biztosítás garantált. Újraírni több év lenne és hatalmas költség, ami az ő szemszögükből ugyanazt tudja (viszont rengeteg tesztelés, hibajavítás) egy csomó felesleges kiadásért cserében.

Azoknak sem vagyok nagy rajongója, de igazad van, azok jobb alternatívák azért a Javánál.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Csab | 2023. 08. 23., sze – 19:57 )

Szerkesztve: 2023. 08. 23., sze – 19:58

Baromság. Egy programnyelvet simán konvertálni lehet egy másikra. Írtam már ilyet tesztek esetén. Egyszerű syntax transzformáció, egy dedós megírja AI nélkül. Egy szaros GCC is tud C++-ról assembly-re fordítani.

A nehézséget a libek jelentik, azokat lehet, hogy szótárazni kell, hogy mit mire konvertáljunk.

A következő hír az lesz, hogy AI segítségével el tudunk tízig számolni? Vagy mi?

Csak syntax transzformáció. A QT például legenerálja a signal kezelés kódját C++-ra, ahogy a Java RMI is tette egykoron. Nem ma találták fel a kódgenerálást egyik nyelvről egy másikra.

Mi a büdös fene köze van az AI-nek az egészhez?

- kedves AI, futtasd már le a syntax transzformációt!

- csinálom...

Gondolom az, hogy felismerje a nyelvben a struktúrát, és valami értelmes módon fordítsa. Mondjuk az alábbi Fortran programból:

      i = 0
 100  write (*, *) i
      if i - 100, 100, 120, 120
 120  continue
      end

ne azt csinálja, hogy

#include <iostream>
#include <iomanip>


int main(){
  int i = 0;
  label100: std::cout << i << std::endl;
  if(i - 100 < 0){
    goto label100;
  } else if(i - 100 == 0){
    goto label120;
  } else{
    goto label120;
  }
  label120: return 0;
}

hanem valami értelmesebbet. És akkor még nem foglalkoztunk azzal, ha mondjuk egy olyan nyelvet kell átfordítani, amiben van név szerinti átadás, tehát egy függvénynek egy változó helyett átadhatom azt hogy 'i+1' ha tudom, hogy a függvény belsejében van egy i változó, és akkor azt ott megcsinálja (Algol 60 call-by-name), vagy valami más olyan konstrukció, ami a target nyelvben nagyon nincs.

Kiderül a cikkből, hogy nem pontosan ugyanígy fordít?

Ha hozzáveszed azt a plusz információt, hogy az IBM-nél se mindenki tökhülye, akkor igen. Ahhoz ugyanis nem kellene AI, hogy a C-t egy portable assemblynek használva fordítson C-re, azt a GNUCobol is tud, valószínűleg nem is lenne olyan nehéz átírni, hogy az output java legyen.

> Ha hozzáveszed azt a plusz információt, hogy az IBM-nél se mindenki tökhülye, akkor igen.

 

Igazad van, nem mindenkit a magyar kormány fizet. Valahogy mindig az jut eszembe, hogy Juci megkérdezi a ChatGPT-t, hogyan kell a Word-öt elindítani, sikerül neki, utána másnap főcímen olvassuk, hogy az államigazgatás sikerrel AI-zik.

Egy szaros GCC is tud C++-ról assembly-re fordítani.

De C++-ról Fortran-ra vagy PL/1-re (és fordítva) nem tud, pláne nem úgy, hogy az eredmény egy épelméjű, olvasható, esetleg továbbfejleszthető kód legyen. Még a Bell Labs-féle f2c a Fortran-to-C átírást egész tűrhetően csinálta, de azért bonyolultabb nyelvek esetén ez nem olyan baromi könnyű. Nézd csak meg, hogy a MARST mit csinál az Algolból, pedig az még hasonlít is egy kicsit a C-re. Azt megnézném, amikor valaki csak úgy összedob egy PL/1-ről C++-ra fordító cuccot. (Okés, a COBOL egyszerűbb nyelv, de akkor is.)

Egyszerűen baromságot írtál. Nagyot akartál mondani. Nem jött be.

Ha egyik programnyelvet simán lehetne konvertálni bármely tetszőleges másik programnyelvre, akkor
1.) Nem küzdenének ezzel a fejlesztők
2.) Nem küzdene vele az üzleti oldal, hogy meg merjék-e lépni (go-nogo)
3.) Már 20-30 éve átírták volna a régi kódokat újabbakra, mivel akkor még több olyan fejlesztő volt, aki értett a régi nyelvekhez is
4.) Már önmagukban az adatstruktúrák átalakítása se triviális feladat
5.) A konverzió nem jelent egyben refaktorálást is. Refaktorálás nélkül egy 50-60 éves konvertált kód ugyanolyan használhatatlan marad.

Ha azt írtad volna, hogy egyik programnyelvet nagy valószínűséggel át lehet konvertálni bármely tetszőleges másik programnyelvre, akkor igaz lenne az állításod.

Most írja a cikk, hogy sikerült konvertálniuk. Az AI NP-teljes problémákat is megold mostanság?

 

Idáig abban a hiszemben éltem, hogy NP-teljes azt jelenti, hogy a konverzió nem polinomiális időben zajlik. Na most azután, hogy kiköpte pár milliárd sor COBOL kódra a megoldást, gyanítható, hogy mégiscsak polinomiálisan ment.

És elolvastad? Csak mert ott elég egyértelműen le van írva, hogy nem azt jelenti, amit írtál, annyira nem, hogy híres megoldatlan probléma, hogy P és NP ugyanaz-e, azaz,  a determinisztikus és a nemdeterminisztikus Turing-gépen polinomiális időben megoldható problémák azonosak-e. Az NP teljes pedig olyan NP probléma, amire a többi NP probléma visszavezethető, azaz, ha egy NP problémáról megmutatod, hogy P-ben van, akkor bebizonyítottad, hogy P=NP, és híres leszel.

Rohadtul nem csak annyi. A memória és az IO modellt is le kell követni, ráadásul sokszor a fejlesztők teljesítmény- vagy egyéb optimalizálási szempontból különleges és/vagy furcsa megoldásokat alkalmaznak, a rendszerek működésének mellékhatásait kihasználva. Na ezeket is szimulálni kell. A bug kaszkádokról nem is beszélve (azaz pl több bug együttes fennállása esetén a kód mégis a megfelelő eredményt adja, de ha valamelyik bugot kijavítod, elromlik a folyamat).

Konvertálni pedig a libeket is lehet, külső programokat meg ugyanúgy lehet hívni IPC-vel vagy akármivel, mint előtte.

( zZsOlTi v | 2023. 08. 23., sze – 21:40 )

Volt már ilyen csak AI nélkül (volt is szerencsém vele készült produktumhoz). 
 

https://groups.google.com/g/naca-automated-cobol-to-java-transcoding/ab…

Project NACA by Publicitas replaced an IBM mainframe with Intel servers on Linux. Project successfully ended on june 30, 2007. 4 millions lines of COBOL were 100% automatically trans-coded toward their Java equivalent.

Project tools released under GPL. at http://code.google.com/p/naca

http://media-tech.blogspot.com/2009/01/project-naca-open-sourcing-gpllg…

Most is van nekik, a G4-et használják (szőröstöl-bőröstül felvásárolták a holland Cornerstone-t 2020-ban), ezen dolgozam is a közelmúltban, igaz nem a Cobol, hanem a PL/I variánson (ez a nyelv kb ugyanolyan "öreg", mint a Cobol). Hát mit mondjak, a konvertált kód egyetlen előnye, hogy nem kell hozzá Mainframe (vagy Mainframe emulátor), hanem elfut bármin, ahol a JVM. Karban tartani ezt is ugyanolyan nehéz (ha nem még nehezebb), mint az eredeti forrást. Cserébe nincs mainframe licensz :)

( STP | 2023. 08. 23., sze – 21:58 )

M2M, IoT, Smart, most éppen AI

Okos hajszárító, okos hőmérő, AI vezérlés, stb. 98%-ban mind bullshit.

( NevemTeve | 2023. 08. 24., cs – 04:42 )

Következik-e ebből, hogy az elmúlt 60+ évben a Cobol-fordítóprogramok is AI-val müködtek? Vagy a Cobol->Assembly fordítás még megoldható hagyományos módszerrel, de a Cobol->Java fordítás már mágikusan nehéz?

( chx | 2023. 08. 24., cs – 06:51 )

TFH jól fog ez működni. Min fogják futtatni? z/OS-en? Ahol van z/OS, ott van mögötte drága és bevált staff, support, infra. Miért érné meg akkor COBOL-ról Java-ra migrálni, annak minden kockázatával és költségével? Meg tudják fizetni a COBOL programozókat, aprópénz a TCO-hoz képest.

Nem z/OS-en? A z/OS-ről eljövő projektek így szoktak működni:
- Mi lenne ha...
- Nem.
- De hát...
- Nem.
- Esetleg ha...
- Nem.

Aztán ha véletlenül mégis "Igen.", akkor egy drága goto fail, then backout lesz belőle.

echo crash > /dev/kmem

Igazából ez egy előre menekülés. Ha megnézed a videót alapvetően nem csak átfordítják a kódot, hanem kiszervezik modulokba, ami majd lehetőséget ad a további refaktorálásra. A cobol-lal az a gond, hogy most sincs fejlesztő aki értene hozzá, és nem is nagyon lesz utánpótlás. Sokkal egyszerűbb átfordítani az egészet java-ra, körberakni tesztekkel (ezt egyébként a tool megcsinálja!), majd szépen, lépés lépésre javítani rajta. Mivel java, innentől kezdve bármin is elfut, magyarul elindulhatnak abba az irányba, hogy lecseréljék a mainframe-eket egy másik megoldásra (ha ez indokolt). 

Itt egy videó az egész folyamatról.

https://www.ibm.com/products/watsonx-code-assistant

Azt hinném, hogy az IBM reményei szerint IBM cloudon fog futni. A COBOL-lal az a baj, hogy arra találták ki, hogy ne kelljen hozzá programozó, hanem a pénzügyesek maguk megoldják. A programozók ezt többnyire el is hiszik, és nem tanulják meg, a pénzügyesek meg nem hitték el.

A mainframe-ek (vagy a mainframe emulátorok, mint pl a Microfocus-nak ami van) nagyon drágák, és egyre drágábbak, ráadásul rohadtul vendor lock-in van. Fogynak a szakemberek is. Java elfut akármin, olcsó felhős cuccokon is. A DB lehet más is, nem csak DB2. Java programozó pedig rengeteg van. Ezért menekülnek.

Vagy három évtizede temetik a mainframe-et, szépen lassan nő a piaca. Menekülnek, ja.
"Java elfut akármin, olcsó felhős cuccokon is." - én is mindig erre gondolok, amikor az n+1. memory leak-es deployment miatt ~GB méretű JVM stdout és stderr fájlokat túrok. Hogy aztán horvath3 vagy kumar4 lássa, nem véletlenül küldöm vissza javításra a vackukat.

echo crash > /dev/kmem

A régi rendszerek is tele vannak bugokkal. Szarul kódolni minden nyelven lehet. Nemrég részt vettem egy eléggé nagy cég PL/I->Java konverziójában, és számtalan bugot fogtunk a forrásrendszerben, volt ami több évtizede benn volt. Hiába fut mainframe-en a szoftver, ha bugos. Túrtam mainframe logfájlokat is, nem is keveset emiatt, és semmivel sem könnyebb, mint a java-s vackok logjait.

Hogy jó-e az, hogy a Java irányba mennek a mainframe-ről, az más kérdés. Ennek van piaca. Nem mindenkinek éri meg mainframe-en folytatni.

"többségnek megéri MF-en folytatni" - hát nem, csak nem olyan könnyű leválni. Egy ilyen átállás egy nagyobb cégnél sok-sok év, még akkor is, ha van pénz+paripa. Nézzük meg a számokat 5-10 év múlva is.

És azt is nézzük meg, hogy kik az új belépők, és milyen alkalmazások miatt kell nekik mainframe. Kétlem, hogy Cobol meg PL/I tranzakciós rendszereket akarnak futtatni.

Ami tele van buggal azt "menedzser szempontból" könnyebb migrálni mert kisebb az SLA-csökkenés kockázata - mondván ugyanolyan sz@rt csak tudnak írni Java-ban is.
Nekem van dolgom egy rendszerrel, igen nehéz benne hibát találni, a microservice-es megoldás ezért szinte biztosan rosszabb SLA-t eredményez.
Szinte egyedül a demográfiai kockázat az a tényező ami megkérdőjelezhetetlen az egész történetben.

zászló, zászló, szív

( nagyjoco | 2023. 08. 24., cs – 10:05 )

Tanulság : minél tovább görgetjük a szarkupacokat magunk előtt, annál büdösebb meló lesz a végén megszabadulni tóle. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( gabrielakos v | 2023. 08. 24., cs – 12:33 )

A legnagyobb baj ezzel hogy a menedzserek szerint kurva jó ötlet és utána nekünk kell majd a szart takarítani.

De van más is.

A legacy szemétteleppel az is baj hogy rettenetesen nem mai elvek szerint készült, általában doksija sincs. 40-50 éve a cég is tök másképp működött mint ahogy most (kéne).

Így aztán a cobolban írt fekete dobozt konvertáljuk java-ban írt fekete dobozzá, ugyanúgy fogalmunk sincs pontosan mit csinál és maximum komparatívan tudjuk tesztelni.
Az rohadtul nem megy át a fejekben hogy az aktuális helyzet és a kívánt cél végiggondolását nem lehet elspórolni.

Az 1:1 átírás a lehető legnagyobb zsákutca.

Nem baj, legalább van munkánk ...

zászló, zászló, szív

Ez egy risk management probléma szerintem. Van egy futó rendszer, de nincs ember aki belenézzen, kijavítsa, stb. mert hogy elfogytak a cobol programozók, viszont cserébe az űberdrága

mainframe-en fut ami durván égeti a pénzt. Lehetne pénzt kérni maintenance-re, de azt sokkal nehezebb (nagyságrenddel nehezebb) elérni, mintsem egy új projektet indítani. Viszont valószínűleg

olyan mennyiségű kód van ott, hogy abból visszaépíteni az üzleti folyamatokat, igényeket, azokat kiszortírozni, és a többi, no, az nem menne át. Viszont ha azt mondjuk hogy figy, itt van egy tool,

ez segít nekünk reális időn belül java kódot csinálni a cobol-ból, aztán utána már majd összetákolják az indiaiak, azt el lehet adni. Eredmény: megszűnik a cobol függőség, van egy kódbázis amivel

már lehet valamit kezdeni, és a mainframe költségét is lehúzhatjuk a listáról. 

Elfogytak a Cobol programozók. Miből állna újabbakat képezni? Nem rakétatudomány a Cobol. Ráadásul nem csak mainframe-re léteznek Cobol fordítók, le lehet azokat fordítani akár PC-n is. A 90-es években, amikor még tananyag volt, és már volt PC-m, találtam PC-s Cobol fordítót, tehát akár azt is meg lehetne nézni, hogy átmigrálhatóak-e a programok a mainframe-ről egyszerű újrafordítással.

Google első találat: IBM® COBOL for Linux® on x86 - Overview | IBM

jepp, amire nem kötelezi őket jogszabály vagy nem hoz plusz pénzt, azt sohasem fogják módosíttatni, mert a pillanatnyi profit a cél. Gurul ameddig gurul és bíznak benne, hogy már ők máshol lesznek, amikor összedől. De még a jogszabályi kötelezettség is olyan, hogy ha egy nagy bank, azt mondja, hogy bocs nem sikerül határidőre, akkor lehet a törvényt módosítják inkább és halsztják évekkel as követelményt.

Nagyon veszélyes a cost / profit center felosztás. Főleg, hogy kevés a tiszta cost / profit center.

A bankok meg általában idióták és fösvények. Durván. Ha 100 Ft bevétel mellett mellett 1 fillér kiadásuk keletkezik, akkor már húzzák a fogukat, világvégét kiáltanak, lobbiznak a politikánál.
Bármilyen fejlesztést, technikai megújulást képesek a végletekig - akár évtizedekig - húzni.

Amint azt mondod hogy na akkor ezt a konvertált java-s kupacot nekiállok kubernetesen futtatni máris paradigmát is váltottál.

Régi kód:

- tranzakcionális
- batch orientlált, lineáris
- implicit serializált

Új platform:

- eventually consistent
- request-response oriented
- massively parallel

Ergo a régi kódód egy kupac szarrá változik.

zászló, zászló, szív