Indulás: miért alapítottunk egy infrastruktúra-központú szoftvercéget

Ez a ProCat Solutions Kft. blogjának első bejegyzése. Budapesti mikrovállalkozás vagyunk, néhány fős csapat, és szoftvert fejlesztünk. Ez önmagában nem különleges: a városban több száz hasonló cég működik. Amiben szeretnénk különbözni, az a hozzáállás: mi nem a funkciólistából indulunk ki, hanem abból az infrastruktúrából, amin a rendszer majd élesben futni fog.

Miért nem “feature-first”?

Az elmúlt években több olyan projektet láttunk közelről, amely gyorsan, látványosan indult, aztán az első komolyabb terhelésnél vagy az első biztonsági incidensnél kiderült, hogy az alapok hiányoznak. A tipikus tünetek ismerősek:

• egyetlen szerver, amin minden fut, mentés nélkül,
• API-kulcsok a forráskódban, jogosultságkezelés nélkül,
• adatbázis, amit senki nem indexelt, mert a fejlesztői gépen gyors volt,
• deploy kézzel, SSH-n keresztül, péntek délután.

Ezek nem egzotikus hibák, hanem annak a következményei, hogy a rendszer “működik, ha megnyomom a gombot” állapotban készült, nem pedig “működik, ha ezer ember nyomja a gombot egyszerre, és közben elszáll egy diszk” állapotra.

Mi fordítva gondolkodunk. Először azt tisztázzuk, hol fog futni a rendszer, milyen terhelést kell kibírnia, mi történik hiba esetén, hogyan kerül ki az új verzió, és ki fér hozzá az adatokhoz. A funkciók erre az alapra épülnek. Ez nem jelenti azt, hogy minden projektet túltervezünk; azt jelenti, hogy a döntéseket tudatosan hozzuk meg, nem pedig utólag, kényszerből.

Mit értünk infrastruktúra-központú fejlesztés alatt?

Néhány konkrét elv, amit minden projektünkben követünk:

Production-ready architektúra az első naptól. A fejlesztői környezet ugyanúgy Dockerben fut, mint az éles. Ugyanaz az Nginx-konfiguráció, ugyanazok a környezeti változók, ugyanaz a PostgreSQL-verzió. Így a “nálam működik” jelenség eleve nem tud kialakulni.

Biztonságos API-struktúra. Minden API-t úgy tervezünk, mintha nyilvános lenne: hitelesítés, jogosultságkezelés, bemeneti validáció, rate limiting. Ez később megspórolja azt a munkát, amikor a belső API-ból hirtelen partnerek felé kitett API lesz.

Magas rendelkezésre állás. Nem minden projektnek van szüksége többzónás redundanciára, de mindegyiknek szüksége van automatikus mentésre, egészségügyi ellenőrzésre (health check), újraindulásra hiba esetén és egy dokumentált helyreállítási folyamatra.

Saját üzemeltetett infrastruktúra. VPS-eken és dedikált szervereken dolgozunk, Linux, Docker és Nginx alapokon. Ez nem a felhőszolgáltatók elutasítása, hanem egy tudatos választás: a legtöbb ügyfelünknek kiszámítható költségre és teljes kontrollra van szüksége, nem pedig egy percek alatt skálázódó, de nehezen átlátható számlára.

Milyen technológiákkal dolgozunk?

A stackünk szándékosan nem túl széles. Backend oldalon Node.js (NestJS és Express) és Laravel, adatbázisként PostgreSQL, gyorsítótárként és üzenetsorként Redis. Konténerizáláshoz Docker, reverse proxyként Nginx, alatta Linux. A frontend és a mobil oldal React, Angular és React Native.

Ezeket a technológiákat nem azért választottuk, mert divatosak, hanem mert évek óta ismerjük a hibáikat is. Egy technológiát akkor tudunk felelősen éles rendszerbe tenni, ha tudjuk, hogyan viselkedik memóriaszűke esetén, mit csinál, ha megszakad az adatbázis-kapcsolat, és hogyan lehet biztonságosan frissíteni.

Érdekel minket a telekommunikáció világa is (SIP, VoIP, PSTN-integráció), és figyeljük, mi történik a blockchain és a gépi tanulás területén, de ezekről majd akkor írunk, amikor lesz mögötte valós tapasztalat.

Miről fog szólni ez a blog?

Nem termékbemutatókról és nem sajtóközleményekről. Arról szeretnénk írni, amit a munka során tanulunk:

• konkrét architektúra-döntések és azok következményei,
• hibák, amiket elkövettünk, és amiket másoknak nem kellene,
• üzemeltetési tapasztalatok: monitorozás, mentés, terheléses tesztelés,
• új területek, ahová belépünk, és ahol az első lépéseket dokumentáljuk.

A célközönség a hozzánk hasonló fejlesztők és azok a döntéshozók, akik szeretnék érteni, mi történik a rendszerük motorháztetője alatt. Igyekszünk konkrétak lenni: ha egy megoldás nálunk nem vált be, azt is leírjuk.

Hogyan tovább?

Az első hónapokban a nagy terhelésű REST API-k tervezéséről és a többbérlős (multi-tenant) SaaS-architektúrákról tervezünk írni, mert ezek azok a területek, ahol most a legtöbb munkánk van. Ha valamelyik témához hozzá szeretnél szólni, vagy egy hasonló problémán dolgozol, az info@procats.hu címen elérsz minket.

Köszönjük, hogy elolvastad az első bejegyzést. A következőben már kód és konfiguráció is lesz.