Előző fejezet: 7. Hálózati port hozzárendelés

Következő fejezet: 9. Eldobhatóság

Szolgáltatásunkat a nagyobb terheléshez -az állapot nélküli- folyamat modellünknek köszönhetően méretezzük át menet közben.

Minden számítógépes program futtatása egy vagy több folyamatként (process) jeleníthető meg. A webes alkalmazások sokféle folyamat végrehajtási formát ölthetnek. Például a PHP folyamatok az Apache által a háttérben indított alfolyamatokként (child process) futnak, a kérések mennyiségéhez igazodva. A Java folyamatok épp az ellenkezőleg, a JVM egy méretes főfolyamatot (uberprocess) szolgáltat, ami induláskor a rendszer (CPU és memória) erőforrásainak egy jelentős részét lefoglalja, és a párhuzamosságot belső szálakkal kezeli. Mindkét esetben a futó folyamat(ok) csak minimális szinten láthatók az alkalmazás fejlesztője szemszögéből.

A skálázást fejezzük ki folyamatokban, a terhelés sokféleségét pedig fejezzük ki folyamattípusokban.

Tizenkét tényezős alkalmazás esetén a folyamatok elsőrendű állapolgárok. A folyamatok a tizenkét tényezős alkalmazásban nagyon erősen másolják a unix világ folyamat modeljét ami szolgáltatás daemon-okat futtat. Ezt a modellt felhasználva a fejlesztő a különböző terhelésekhez különböző típusú folyamatokat rendelve építheti fel az alkalmazását. Például a HTTP kéréseket kiszolgálhatják web folyamatok, a hosszú ideig futó háttérfeladatokat pedig kiszolgálhatják munkavégző (worker) folyamatok.

Ez nem zárja ki az egyes folyamatok saját belső párhuzamos tevékenységét (multiplexing) több szálon a futó viruális gép (VM) belsejében, vagy a Twisted, az EventMachine vagy Node.js vagy hasonló környezetekben található az aszinkron/eseményvezérelt felépítést. De a virtuális gép (VM) alapú rendszer maga csak egyféle nagy lehet (függőleges skálázással a gépet tudjuk alatta megnövelni), így az alkalmazásnak képesnek kell lennie a különböző folyamatokat több gépre leosztva futni, amenniyben párhuzamos (vízszintes) skálázódásra van szükség.

A folyamatmodell kíválósága akkor ragyog fel igazán, ha a megnövekedett terhelésre válaszul az egyszerre kiszolgáló folyamatok számát meg kell növelni (vizszintesen kell skálázni). A tizenkét tényezős alkalmazás semmit sem megosztó, párhuzamosan (vízszintesen) építhető természetének köszönhetően a párhuzamos végrehajtási kapacitás növelése egyszerű és megbízható művelet. A különböző folyamattípusok együttese és ezen belül az egyes folyamattípusokból futó folyamatok számát szokás folyamatkialakításnak hívni.

A tizenkét tényezős alkalmazás sosem démonizál vagy ír PID állományt. Helyette az operációs rendszer folyamatvezérlőjére támaszkodik (mint a systemd, vagy az elosztott folyamatvezérlő felhős környezetben, vagy a Foreman-hoz hasonló eszközök fejlesztési környezetben) a kimeneti adatfolyam vezérléséhez, a bedőlt folyamatokra adott válaszhoz és a felhasználó által kezdeményezett újraindítások és leállások kezeléséhez.

The Twelve-Factor App: VIII. Concurrency

Hazánkban huszonkétezer betöltetlen álláshely van az informatikus szakmában. Elszaladtak a fizetések is, nem ritka, hogy egy tapasztalt informatikus, egymillió forintot vagy többet keres havonta. Kérdés, ennek ellenére miért nem vonzó a pálya.

Elsőre azt mondanánk, a matekkal van a hiba. De nem a képességekkel: ha az egyetemi rendszer évente maximum ötezer új informatikust dob a piacra (akiknek alig a fele marad idehaza), akkor tíz esztendő kellene a hiány pótlására, feltételezve, hogy közben nem születnek újabb álláshelyek. 

De születnek. Folyamatosan. Sőt! Komplett szakmák nőnek ki a földből!

Mit tegyünk? Növeljük az egyetemi férőhelyek számát a tízszeresére? Ha megnézzük, hogy milyen szakembereket képez a rendszer, látható: nem ez a megoldás. Mert milyen ember esik ki mondjuk a progmatról (programozó, matematikus szak) öt év után? Egy tudós. Egy remek elméleti szakember, aki még nem fejlesztett mobiltelefonra appot, de ki tud agyalni egy új, minden eddiginél hatékonyabb keresési algoritmust. A munkaerőpiacon nem őket várják. A sok éves egyetemi képzés, pontosan arra való, mint száz éve: tudóspalántákat képezni. Az informatika pedig pontosan annyi tudóst igényel, mint harminc éve: maroknyit. Talán még annyit se.

Az amerikai szoftverházak rengeteg kutatási területet kebeleztek be, A frissen végzett tudósokra sem elsősorban idehaza van szükség, el is mennek szép számmal külföldre. Itthon nem kell saját keresőalgoritmust vagy képtömörítési eljárást fejleszteni, ez a roham elmúlt. A korábbi évek kutatási területeiből hétköznapi fejlesztési alkotóelemek lettek: térkép-API, Bluetooth-API, MP4-API. Fröccsöntött építőkocka mindegyik, akár egy doboz legóban. 

Ráadásul, ha valaki nem elméleti alapokat, hanem a gyakorlatban tüstént hasznosítható tudást szeretne elsajátítani, az az ötéves képzést nagy ívben kerülje el, mert öt esztendő múlva már emlékezni sem fog arra technológiára, amelyből ma vizsgát tesz. 

De akkor miféle informatikusra lenne szükség a hazai cégeknél? Nos, a piac húszezer főnyi olyan munkavállalót tudna felszippantani, akik új tömörítőalgoritmust ugyan nem találnak fel, ám képesek hatékonyan építeni a meglévő kockákból. Építsünk Bluetooth alapú, okosórán futó, weblapról felügyelhető, felhőben adatot tároló vérnyomásmérőt! Szükségünk lenne egy olyan logisztikai rendszerre, amely RFID-vel ellátott csomagok pontos helyét ki tudja rajzolni Google-térképen, akár épületen belül is. Ezt a sort vég nélkül folytathatnám, mert a feladatok 99 százaléka ilyen. 

 Ha marad a húsz-, sőt lassan harmincezres létszámhiány, Magyarország lehúzhatja a redőnyt. Ha viszont megoldjuk a feladványt és pótoljuk a hiányt, a GDP rögtön ugrik egy nagyot. 

Honnan fogunk előrángatni húszezer szakembert? A hiányzó munkáskéz az országban szétszórva ma valamilyen más jellegű munkát végez: pénztáros, raktáros vagy hasonló. Ám ők valójában mind informatikusok. Elég pár szót váltani velük, és kiderül, hogy lemezt formáznak, Bluetootht hekkelnek, appokkal kísérleteznek, van saját weblapjuk, esetleg egy webáruházuk, s előszeretettel végeznének valamilyen szellemileg magasabb szintű munkát a mostani helyett. Belőlük lehet a jövő nemzedéke! Belőlük lehet a jövő szakembergárdáját kiképezni! De nem öt év, hanem néhány hónap alatt. 

Persze akad itt még egy "aprócska" probléma, melyet úgy hívnak: percepció. A fiatalok számára nem vonzó az informatikus pálya. A magas fizetést nem hiszik el, a programozást felfoghatatlanul bonyolultnak tartják, és sokan még mindig úgy gondolják, az informatikusok kockás inges, szemüveges lúzerek. 

Pedig pozitív példa, sztárcég van sok Magyarországon is. Mégis minél messzebbre kerülünk Budapesttől, annál kevésbé gondolják a fiatalok, hogy lenne keresnivalójuk ezen a területen. Felvilágosító kampányra lenne szükség, de ezt senki nem vállalja fel. Varga Mihály nemzetgazdasági miniszter ugyan nemrég bejelentette: 2,5 milliárd forintot adnak négyezer informatikus képzésére, ám a sorok között olvasva az is kiderül, hogy négy év alatt négyezer, azaz huszonkét év alatt 22 ezer a"terv". Ennyi idő nincs a probléma megoldására. Vonzóvá és elérhetővé kell tenni a szakmát, eloszlatva a tévhiteket: informatikában már nem zsenikre, hanem "kőművesekre" lenne szükség.  

 https://www.vg.hu/velemeny/a-huszonketezres-csapdaja-2-697309/

A Microsoft magyarul is közzétett egy meglehetősen kidolgozott ajánlást, ha az Azure-ba tervezünk érdemes belenézni. Íme a tartalomjegyzék:

Az útmutató felépítése

Az Útmutató az Azure alkalmazásarchitektúrájához több lépésből áll az architektúrától és tervezéstől az implementálásig. Minden lépés mellé támogató útmutatást is nyújtunk, amely segítséget nyújt az alkalmazásarchitektúra megtervezésében.

Architektúrastílusok. A legelső döntés a legfontosabb. Milyen típusú architektúrát szeretnénk használni? Lehet mikroszolgáltatási architektúra, hagyományosabb N rétegű alkalmazás, vagy big data-megoldás is. Hét különböző architektúrastílust határoztunk meg. Mindegyiknek megvannak a maga előnyei és kihívásai.

➤ Az Azure-referenciaarchitektúrák bemutatják az Azure-beli ajánlott telepítéseket, valamint a skálázhatóságra, a rendelkezésre állásra, a kezelhetőségre és a biztonságra vonatkozó megfontolandó szempontokat. A legtöbb esetben üzembe helyezhető Resource Manager-sablonokat is tartalmaznak.

Technológiai lehetőségek. Két technológiai döntést már a legelején meg kell hozni, mivel ezek a teljes architektúrára hatással vannak. Ez a két döntés pedig nem más, mint a számítási és az adattárolási technológiák kiválasztása. A számítás kifejezés azon számítási erőforrások futtatási modelljére utal, amelyeken az alkalmazás fut. A tárolási technológiák közé tartoznak az adatbázisok, valamint az üzenetsorokhoz, a gyorsítótárakhoz, az IoT-adatokhoz, a strukturálatlan naplóadatokhoz, és az alkalmazás által megőrizni kívánt bármely egyéb adathoz használt adattárak is.

➤ A Számítási lehetőségek és a Tárolási lehetőségek szakasz részletes összehasonlításokat tartalmaz a számítási és tárolási szolgáltatások kiválasztásához.

Tervezési alapelvek. A tervezés folyamata során a következő tíz magas szintű tervezési alapelvet kell betartani.

➤ Az Ajánlott eljárások cikkek specifikus útmutatást nyújtanak többek között olyan területeken, mint az automatikus skálázás, a gyorsítótárazás, az adatparticionálás vagy az API-tervezés.

Pillérek. Egy sikeres felhőalkalmazás a szoftverminőség következő öt alappillérére koncentrál: skálázhatóság, rendelkezésre állás, rugalmasság, felügyelet és biztonság.

➤ A Tervezés-áttekintési ellenőrzőlisták segítségével ellenőrizheti, hogy a terve megfelel-e ezeknek a minőségi alappilléreknek.

Tervezési minták felhőkhöz. Ezek a tervezési minták hasznosak megbízható, skálázható és biztonságos Azure-beli alkalmazások létrehozásához. Minden minta egy problémát, egy problémáról szóló mintát és egy Azure-alapú példát ismertet.

➤ Tekintse át a felhőkhöz készült tervezési minták teljes katalógusát.

Előző fejezet: 6. Folyamatok

Következő fejezet: 8. Párhuzamos folyamatok

Tegyük a szolgáltatásainkat port hozzárendeléssel elérhetővé.

A webes alkalmazások néha webszerver konténerekben futnak. Például, a PHP alkalmazások egy Apache HTTPD modul belsejében vagy a Java alkalmazások futhatnak egy Tomcat belsejében.

A 12 tényezős alkalmazásfejlesztés követelményeinek megfelelő alkalmazás teljes egészében önálló, nem támaszkodik egy további webszerver szolgáltatásaira ahhoz, hogy webes felületet hozzon létre. A webes alkalmazás a HTTP szolgáltatását egy porthoz rendelve kínálja, és ezen a porton figyelve várja a hozzá intézett kéréseket.

A fejlesztő lokális gépén, a fejlesztési környezetben ez megoldható egy szolgáltatási URL-en keresztül. Például a http://localhost:5000/ felkeresésével férünk hozzá az alkalmazásunk szolgáltatásaihoz. Ha telepítjük az alkalmazást, akkor pedig az útválasztó réteg kezeli a nyilvános címre érkező kéréseket és továbbítja a porthoz rendelt webes folyamathoz.

Ezt általában úgy oldjuk meg, hogy webszerver könyvtárat adunk az alkalmazásunkhoz függőségi definíció segítségével, mint például a Tornado a Python esetében, Thin a Rubynál, a Jetty a Javá-hoz és az egyéb JVM alapú nyelvekhez. Vagy a Kestrel az ASP.NET Core esetén. Ez az alkalmazás keretein belül történik. Így az alkalmazásunknak csak a port hozzárendelésben kell megállapodnia -amin a kéréseket kiszolgálja- a futtatási környezettel.

A HTTP nem az egyetlen szolgáltatás, amit porthoz rendelve lehet szolgáltatni. Majdnem mindenfajta szerver szolgáltatást nyujtó alkalmazás képes a bejövő kéréseket kiszolgálni, ha a folyamatát porthoz rendeljük. Ideértve akár az ejabberd (XMPP-ről beszélünk) és a Redis (a Redis protokol) is.

Vegyük észre, hogy a port-hozzárendeléses megközelítés eredményeként bármelyik alkalmazás képes háttér kiszolgálója lenni egy másik alkalmazásnak, ha a szolgáltatási URL-jét erőforrás szolgáltatásként az őt használó alkalmazás konfigurációjában megadjuk.

The Twelve-Factor App: VII. Port binding

Egy D-Link DNS 320-as NAS-t használok itthon, illetve kisebb vállalati környezetben való üzemeltetésre is nyugodt szívvel szoktam ajánlani. Van természetesen olyan eset, ahol biztosan nem ez lesz a megfelelő (mert lassú, mert Synology kell, mert 4 fiókosnál kisebb nem jó, mert…), próba szerencse, vagy mondhatom azt is, hogy környezet-, illetve kockázatelemzés, felmérés, ajánlás.

Szeptembertől a NetAcademia az R70 Irodaházban bérel irodá(ka)t. Új hely, új élet, új Windows. Online cég vagyunk, már olyan nagy gépszámmal sem rendelkezünk, az összesen 2 db irodai számítógépünket azért csak megszokásból is WDS-ből telepítettem. Ha már új Windows, akkor miért ne lehetne mondjuk a legújabb, amit a MAPS előfizetésünkből le lehet tölteni? Ez jelenleg a 1709-es, amit a közönség „Fall Creators Update” néven ismer.

Az új verzió viszont már az SMBv1-et fel sem telepíti, be sem kapcsolja alapértelmezetten. Na, ezen a ponton válik világossá, hogy mi köze van a D-Link NAS-nak a történethez (bár a WDS-ből telepítés bevallom, hogy csak töltelék miatt került bele :) ). A kicsi NAS-unk még bizony pontosan ezen a protokollon keresztül érhető el, ha a fájlmegosztásait nézzük. És mivel a 1709-es Windows 10 meg makacs módon kevésbé támogatja már ezt a verziót, ezért itt rögtön egy szívroham közeli állapot következik, amikor a megosztások tallózásánál bizony semmit sem látunk. Lehet, hogy van rá update, ami felokosítja, vagy lehet, hogy ki lehet dobni a kukába, azonban általában egy csak Windowshoz értő rendszergazda kevésbé piszkálja a Linux-ot futtató NAS lelkét.

A legszebb dolog az egészben az, hogy ha:

• pingeted a NAS-t, ő válaszol. Miért is ne tenné, hiszen mi köze van a pingelésnek az SMB-hez?
• ha csak a megosztásait akarod tallózni, akkor azt mondja, hogy ilyen eszköz márpedig nincs.
• ha hálózatmonitorozol, akkor látod? Maximum, hogy SMBv1. De ettől még nem biztos, hogy rájössz, hogy itt bizony ingoványos talaj van a két kommunikáló fél között.
• ha viszont csatolnád, mint hálózati meghajtó az egyik megosztását, akkor viszont jön a szép hibaüzenet, ami pont erre az SMBv1 nem támogatásra figyelmeztet. RTFszöveg (az RTFM után szabadon…)

Marad a másik megoldás: Nézzük meg, hogy nem-e lehet-e mégiscsak bekapcsolni-e a Windowsból-e az SMBv1-et-e? Kutakodva mindenfelé, leginkább azt írja az internet népe, hogy hogyan lehet kikapcsolni GPO-ból, Registryből, PWS-ből, Optional Features közül. Hopp, ez utóbbi ismerős lehet, ha itt ki lehet kapcsolni, nézzük meg, hogy az új verzióban megvan-e a visszakapcsolás lehetősége. A Windows fícsörök gyors ki-bekapcsolásához az optionalfeatures.exe-t futtatjuk, és láss csodát, ott az opció, hogy vissza tudjuk kapcsolni a támogatást.

Egy restart, egy újra próbálkozás, és huhh, megmenekültünk!

Házi feladat. Miért kell az SMBv1-et kidobni? Miért jó a v2, v3? Miért ne kapcsoljuk vissza a v1-et?

Nyilván átmeneti megoldásnak, tűzoltásnak azért csak jó lesz, de fel lehet venni a feladatlistánkra, hogy foglalkozzunk a témával a közeljövőben (azaz lehet, hogy mégsem ússzuk meg a Linux lelkivilágának piszkálását).

Ha valakinek még kétséges lett volna, hogy érdemes-e az Azure-ral foglalkozni.

Az Azure a Microsoft úgynevezett felhőszolgáltatása. Ez azt jelenti, hogy high-tech számítógép központokban Microsoft rendszermérnökök által üzemeltetett szervereken mindenféle, de tényleg mindenféle informatikai infrastruktúrát bérelhetünk. Ezzel a Microsoft nem egyedülálló, még még csak nem is úttörő, van az Amazonnak az AWS ami azért előbb volt, mint az Azure, a Goggle-nak a GoogleCloudPlatform, és jó néhányat lehetne még sorolni a kisebbekből is.

Mi az Azure-t használjuk elsősorban, ennek az oka az lehet, hogy bár Microsoft infrastruktúrát az Aws-en is lehet bérelni, az Azure egy Microsofton szocializálódott fejlesztő számára inkább hazai pálya. Így hát joggal tudom mondani, hogy az elmúlt két évben látványos a fejlődés az Azure-on, Windows, Linux, illetve ilyen alapú kulcsrakész komplex csomagok elérhetőek (RabbitMQ, ElasticSearch, kölönféle virtualizációs szervermegoldáson keresztül, a teljes listát nem lehet felsorolni). Azt azért lehet mondani, hogy elsősorban PC architektúrájú megoldások elérhetőek.

És az egyik előnye a sok közül a felhőszolgáltatásoknak, hogy akár egy napra, vagy akár egy órára kipróbálhatjuk az elérhető legnagyobb teljesítményű gépeket, vagy a belőlük alkotott hálózatokat, mivel az elszámolás lehető teszi, hogy bekapcsoljuk, majd ha már nem kell kikapcsoljuk őket.

Ide érkezik a Cray szuperszámítógépek által kínált kimagaslóan nagy teljesítmény, a kifejezetten számításigényes műveletek támogatásához. Ezzel, ami egykor csak kiváltságosok számára volt elérhető, egy karnyújtásnyira kerül.

(Véletlenül tudom, hogy indul C# tanfolyam teljesen kezdőknek,Vagy inkább .NET Standard, de ez csak a csomó a kákán. A Standard a specifikáció, a Core pedig az implementáció, hogy két jól hangzó idegen szóval ékesítsem a mondatot, vagyis ugyanazt eredményezik bizonyos szempontból.

Őszinte leszek, azt sem tudtam, hogy a Fiddlert (is) a Telerik jegyzi, de használni használtam már http/https forgalom figyeléséhez, API teszteléséhez. A lényeg, hogy egy igazi Microsoft-os termét az Internet Explorer(!) Program Managerétől Windows-ra (a Program Manager-ről itt olvashatsz, és még egy cikk a témában), 2003-ból, amit 2012-ben megvásárolt a Telerik.

Hát most multiplatformossá válik, köszönhetően a .NET Core lehetőségeinek:

FiddlerCore for .NET Standard and Fiddler Orchestra—the Future of Fiddler

Szép új C# világ :)

(Véletlenül tudom, hogy indul C# tanfolyam teljesen kezdőknek a jövő héten. Aki belevág, nem tesz rossz lóra.)

Nagy teljesítményű, jól skálázható, robosztus és hatékonyan programozható, nagymértékben párhuzamosan végrehajtható alkalmazások készítéséhez használják az Actor modell-t.

Legelőször is a Microsoftnak van saját Actor model implementációja (Orleans). Például a Halo4 és Halo5  játékok hálózati kiszolgálásának ez a háttere.

Aztán, ha akarjuk valamennyire ide lehet számolni az Azure Service Fabric szolgáltatását is.

Az Akka.NET-ről már volt említés itt a blogon, ő az eredeti Akka portolása .NET alá, amit néhány civil kezdett néhány éve.

Ez itt egy jó áttekintő összehasonlítás az Akka.NET és az Orleans tulajdonságairól, ez pedig az Akka csapat összehasonlítása az Akka és az Orleans környezetekről.

Szóval ehhez képes nagy dolog, hogy az Akka.NET csatlakozott a .NET alapítványhoz:

Akka.NET has Joined the .NET Foundation

A magasabb szintű programozási nyelvek egyik leghatásosabb eszköze a változók használata. A változók egyszerű, könnyen áttekinthető használata. Nem kell már beírni a regiszterbe, ha egy számot a következő műveletben fel szeretnénk használni, és a sztringek misztikus kezelése is sokat egyszerűsödött, ha valaki mondjuk például C#-ot használ.

Ez tehát elmondható a számokról, szövegekről, egyszóval, (szakmai szargonban) az érték típusokról. A hivatkozás típusok (amikor egy bonyolultabb konstrukciót hozunk létre és használjuk, szintén zsargonban osztályt példányosítunk) azért még adnak munkát rendesen.

Legalábbis, az Automapper előtt ez volt a helyzet.

Ha például egy jármű típust hozunk létre, megadva, hogy hány kereke, ajtaja, miegymás értéke van, ami őt jellemzi, majd szeretnénk ezzel kezdeni valamit, akkor két lehetőségünk is van. Ez az autó valahol csücsül a memóriában, és az őt "tartalmazó" változóban a rá mutató hivatkozás segítségével érhetjük el. Műveletet végezhetünk rajta, megszüntethetjük, vagy ezt a hivatkozást betehetjük egy másik változóba.

Vagy, létrehozhatunk egy másik autót, egy másik helyen a memóriában, és szépen végigmenve az autó tulajdonságain, egyesével átmásolhatjuk az ajtók számát, a kerekek számát és a többi jellemzőt. Gyakorlatilag  értékadást szimulálva, mindha egy számot írnánk egyik változóból a másikba.

Legalábbis, az Automapper előtt ez volt a helyzet.

Az AutoMapper egy nyílt forráskódú eszköz, .NET fejlesztőknek C# nyelven. Nuget-tel települ, és a küldetése az, hogy ha nem referencia, hanem érték szerint szeretnénk értékadást végezni két osztály típusú változó között, akkor nem kell egyesével kézzel végigmenni egy osztály felületén és minden tulajdonságot lemásolni, hanem egy lépésben egy értékadással elvégezhetjük. Ez triviális módon megy, ha azonos típusú példányokról van szó.

De az AutoMapper nem áll meg itt, hanem képes különböző típusok közötti konverzióra, listák közötti értékadásra egy lépésben, nem felejti el, ha időközben változott az osztály definíció, és már színt is nyilvántartunk az autó példányban, a .NET Standard támogatással nem csak windows-on, de linuxon, androidon és iOS-en is bevethető, és még sorolhatnám a képességeit napestig.

És hogy miért írtam ezt a sokmindent? Eddig is lehetett sejteni, hogy ez egy jó irány, persze meg kellett tanulni a használatát, és ez néha nem esik jól az embernek. De az irány az valahogy mégis rendben lévőnek látszott.

Nos, ezt most már a .NET alapítvány is hasonlóan gondolja:

AutoMapper joins the .NET Foundation