Innovatív webalkalmazás fejlesztés az AWS Lambda platformon

AWS Lambda Fejlesztés magánügyfeleknek

Az AWS Lambda Fejlesztés akkor hasznos, ha egy webes feladatot gyorsan, külön szerver fenntartása nélkül kell megoldani. A lényeg egyszerű. A funkció csak akkor fut, amikor szükség van rá, így sok esetben nem kell állandóan működő háttérrendszert fizetni. Magánügyfélként ez főleg akkor érdekes, ha űrlapokat, értesítéseket, adatfeldolgozást, kisebb automatizálást vagy egy webalkalmazás háttérlogikáját szeretné kiszervezni egy online dolgozó szakembernek.

Én azt látom, hogy sok ügyfél nem teljes rendszert keres először, hanem egy jól körülhatárolt működő részt. Például egy rendelési űrlap adatainak feldolgozását. Vagy egy fájl feltöltése után induló automatikus ellenőrzést. Ilyenkor a szerver nélküli fejlesztés jó megoldás lehet, mert nem kell bonyolult üzemeltetésben gondolkodni az első napon.

A Qjob.hu felületén magánszemélyek is találhatnak olyan fejlesztőt, aki távolról dolgozik, egyeztet, kódot ír, majd átadja a beállított működést. Fontos, hogy itt nem egy nagy cég szolgáltatásáról van szó, hanem egyéni szakember munkájáról. Ezért a pontos feladatleírás, a hozzáférések rendje és a tesztelés különösen sokat számít.

AWS Lambda alapú online megoldások

Az AWS Lambda alapú fejlesztés gyakran kis, önálló funkciókkal indul. Egy ilyen funkció fogad egy kérést, feldolgoz adatot, majd visszaad egy választ. Ez lehet háttérben futó művelet, amelyet a felhasználó nem is lát. De lehet olyan rész is, amely egy weboldal vagy webalkalmazás működését támogatja.

Tipikus feladat az adatok átvétele egy űrlapból, e-mail értesítés küldése, fizetés utáni állapotfrissítés, fájlok rendezése, képek előfeldolgozása vagy külső szolgáltatások összekapcsolása. Szerintem az ilyen munkáknál a legfontosabb kérdés nem az, hogy mennyire divatos a technológia, hanem az, hogy a megoldás valóban egyszerűbbé teszi-e az ügyfél életét.

Volt olyan eset, amikor egy ügyfél minden nap kézzel másolt adatokat egy táblázatból egy másik rendszerbe. Nem nagyvállalati feladat volt. Csak ismétlődő, fárasztó munka. Egy rövid, jól megírt felhőfüggvény elég volt ahhoz, hogy a folyamat automatikusan fusson. A haszon nem látványos külső felületben jelent meg, hanem időben és kevesebb hibában.

Az online munka során a fejlesztő általában nem kér személyes találkozót. A feladat megértése üzenetben, videós egyeztetéssel vagy részletes leírással történik. A megrendelő átadja a szükséges hozzáféréseket, példafájlokat, adatmintákat és elvárt eredményeket. Ezután a szakember megtervezi, megírja és teszteli a funkciót.

AWS Lambda Fejlesztés árak és munkadíjak

Az AWS Lambda Fejlesztés ára főleg a feladat összetettségétől függ. Egy egyszerű értesítő funkció sokkal kevesebb munka, mint egy több szolgáltatást összekötő háttérfolyamat. A túl olcsó munka ezen a területen gyakran gyengébb minőséget jelent, mert a tesztelés, a hibakezelés és a jogosultságok beállítása nem maradhat ki.

Tapasztalatom szerint a reális ár nem csak a kódsorok számától függ. Számít az is, hogy van-e kész leírás, milyen állapotban vannak a meglévő rendszerek, kell-e adatbázis, kell-e jogosultságkezelés, és mennyi próba szükséges. Ha a fejlesztő csak a gyors megírást vállalja, de nem beszél tesztekről, naplózásról vagy hibás bemenetekről, az később gondot okozhat.

AWS Lambda fejlesztő kiválasztása

A megfelelő AWS Lambda fejlesztő kiválasztásánál nem elég azt nézni, hogy valaki ismeri-e a felhőszolgáltatást. A magánügyfélnek olyan szakemberre van szüksége, aki egyszerűen el tudja mondani, mit fog készíteni, milyen adatokkal dolgozik, és hol lehet később módosítani a működést. Ez különösen fontos, ha a megrendelő nem műszaki háttérrel érkezik.

Sokan ott hibáznak, hogy csak az óradíjat kérdezik meg. Ez érthető, de kevés. Jobb kérdés az, hogy milyen lépésekből áll a munka, mikor lesz próbaverzió, hogyan történik a hibák javítása, és milyen dokumentáció marad a végén. Egy felelős fejlesztő nem ígér mindent egy nap alatt, ha a feladatban több külső szolgáltatás is szerepel.

Érdemes portfóliót vagy korábbi példákat kérni. Nem kell pontosan ugyanaz a feladat. Elég, ha látszik, hogy a szakember már készített felhőalapú funkciót, automatizálást vagy háttérlogikát. A jó jel az, ha kérdez. Rákérdez az adatok formátumára, a hibás esetekre, a terhelésre és arra, hogy ki fogja használni a kész megoldást.

A kommunikáció minősége is döntő. Ha valaki már az első üzenetekben homályosan fogalmaz, később sem lesz könnyű vele dolgozni. De a túl hosszú műszaki magyarázat sem mindig előny. Magánügyfélként azt kell keresni, aki érthető nyelven ír, de nem egyszerűsíti le veszélyesen a feladatot.

Szerver nélküli fejlesztés menete

A szerver nélküli fejlesztés általában rövid egyeztetéssel indul. A megrendelő leírja, mit szeretne elérni. Nem baj, ha még nem tudja pontosan, milyen technikai megoldás kell. A lényeg az üzleti vagy gyakorlati cél. Például az, hogy egy beküldött adat automatikusan bekerüljön egy táblázatba, vagy egy fájl feldolgozása után értesítés menjen ki.

Ezután a fejlesztő pontosítja a folyamatot. Milyen bemenet érkezik. Milyen eredmény kell. Mi történjen hiba esetén. Ki kapjon értesítést. Hol legyenek tárolva az adatok. Ezek nem apróságok. Egy rosszul kezelt kivétel miatt a funkció látszólag működik, de csendben elveszíthet fontos adatokat.

A következő lépés a fejlesztés és a beállítás. Ide tartozhat a Lambda funkció, a jogosultságok, a kapcsolódó felhőszolgáltatások és az eseményindítók beállítása. Ha webalkalmazáshoz kapcsolódik a munka, akkor gyakran API is készül hozzá. A tesztelés során a szakember nem csak jó adatmintákkal próbálkozik, hanem hibás, hiányos vagy szokatlan adatokkal is.

A munka végén átadás következik. Ez lehet rövid leírás, hozzáférési útmutató, próbaeredmények listája vagy videós magyarázat. Szerintem ez a rész gyakran alulértékelt. Pedig a megrendelőnek később tudnia kell, mi készült el, hol lehet ellenőrizni a működést, és mikor kell újra fejlesztőhöz fordulni.

Online fejlesztési feladatok és határidők

Az online fejlesztési feladatoknál a határidő akkor tartható, ha a kiinduló anyagok rendben vannak. A fejlesztőnek szüksége lehet hozzáférésekre, példafájlokra, próbaadatokra, külső szolgáltatások leírására és arra, hogy a megrendelő gyorsan válaszoljon a kérdésekre. Ha ezek hiányoznak, a munka megáll.

Egy kisebb Lambda funkció néhány nap alatt elkészülhet. Egy összetettebb háttérfolyamat több hetet is igényelhet, főleg akkor, ha fizetési rendszer, adatbázis, felhasználói jogosultság vagy több külső kapcsolat is van benne. Nem mindig a kódírás a lassú rész. Gyakran a tesztadatok beszerzése vagy egy külső szolgáltatás beállítása vesz el több időt.

De a gyorsaság nem lehet az egyetlen cél. A felhőalapú fejlesztésnél a hibák sokszor csak éles használat közben derülnek ki, ha előtte nem volt elég próba. Ezért érdemes a határidőbe beépíteni egy rövid tesztidőszakot. Ilyenkor a megrendelő kipróbálja a funkciót valószerű helyzetekben, a szakember pedig javítja a kisebb hibákat.

A távoli kommunikáció akkor működik jól, ha minden fontos döntés írásban is megvan. Nem kell hosszú szerződés minden apró módosításhoz, de legyen nyoma annak, hogy mi számít kész eredménynek. Ez védi az ügyfelet és a fejlesztőt is.

Gyakori hibák AWS Lambda munkáknál

Az egyik leggyakoribb hiba a túl homályos feladatleírás. Ha csak annyi szerepel benne, hogy működjön automatikusan, abból a fejlesztő nem tud pontos eredményt készíteni. Meg kell határozni a bemenetet, a kimenetet, a kivételeket és a sikeres működés feltételeit.

A másik gond a jogosultságok kezelése. Egy Lambda funkció csak akkor tud biztonságosan dolgozni, ha pontosan annyi hozzáférést kap, amennyire szüksége van. Nem jó, ha mindenhez teljes jogot kap csak azért, mert úgy gyorsabb beállítani. Ez kényelmesnek tűnik, de hosszabb távon kockázatos.

Sokan nem gondolnak a naplózásra sem. Pedig amikor valami nem fut le, fontos tudni, mi történt. Volt-e hibás adat. Elérhető volt-e a külső rendszer. Túl nagy volt-e a fájl. Jó naplózás nélkül a hiba keresése találgatássá válik.

Az elvárásoknál is lehet félreértés. Egy felhőfüggvény nem mindig helyettesít teljes webalkalmazást. Nagyon jó kiszolgáló elem lehet, de nem minden problémára ez a legjobb válasz. Egy tapasztalt szakember ezt megmondja, még akkor is, ha így kisebb lesz a megbízás. Én ezt korrekt hozzáállásnak tartom.

AWS Lambda megoldás átadása és minőség

A kész AWS Lambda megoldás értéke nem csak abban van, hogy lefut. Akkor jó, ha a megrendelő érti az alapvető működését, tudja, milyen esemény indítja, milyen adatot dolgoz fel, és mi történik hiba esetén. Egy magánügyfélnek nem kell fejlesztővé válnia, de nem maradhat teljesen kiszolgáltatott sem.

Az átadás része lehet a rövid műszaki leírás, a beállított környezet bemutatása, a teszteredmények összefoglalása és a későbbi módosítási lehetőségek felsorolása. Ha a munka webalkalmazáshoz kapcsolódik, akkor érdemes külön ellenőrizni a felhasználói oldalt is. Nem elég, hogy a háttérben lefut a funkció. A felhasználónak is érthető visszajelzést kell kapnia.

Szerintem a jó minőség itt csendes dolog. Nem látványos. Egyszerűen nem omlik össze a folyamat, ha hiányzik egy mező, lassú egy külső szolgáltatás vagy rossz formátumú adat érkezik. A stabil működés sok apró döntésből áll össze, és ezekről érdemes már a megbízás elején beszélni.

Ha a feladat jól van megfogalmazva, a fejlesztő pedig világosan kommunikál, az AWS Lambda alapú munka magánügyfélként is átlátható marad. Nem kell nagy rendszerben gondolkodni minden esetben. Néha elég egy jól megírt funkció, amely pontosan azt végzi el, amire szükség van.