Fülöp Dénes

Fülöp Dénes

  · 3 min read

2. rész: Monolitból a felhőbe: Hogyan kezdjük el az AWS migrációt jó döntésekkel?

Fejlesztői szemmel, üzleti szempontokat figyelembe véve mutatom meg, hogyan indulj el a felhő felé vezető úton.

Fejlesztői szemmel, üzleti szempontokat figyelembe véve mutatom meg, hogyan indulj el a felhő felé vezető úton.

Miért íródott ez a cikk?

Fejlesztőként sokáig nekem is csak annyi volt az AWS, hogy “ott fut a backend valahol”. Most viszont, hogy egyre több céges döntés mozog a felhő irányába, és én is az AWS Solutions Architect Associate tananyagát tanulom, világossá vált: az, hogy hogyan kezdünk el egy migrációt, stratégiai döntés, nem csak technikai.

Ez a cikk azoknak szól, akik hasonló cipőben járnak: fejlesztők, vezetők, CTO-k, akik szeretnének jól dönteni a migráció első lépéseiben – anélkül, hogy azonnal újra kellene írni mindent.

1. Tisztázzuk: Miért akarunk migrálni?

Migrációs célok
Migrációs célok

Bármilyen technológiai döntés előtt ez az első kérdés:

  • Költségcsökkentés?
  • Skálázhatóság?
  • Gyorsabb release ciklus?
  • Magasabb rendelkezésre állás?

Ha nincs világos üzleti cél, a migráció könnyen “technológia kedvéért technológia” típusú projektté válik – és az szinte mindig kudarc.

Példa:

Van egy stabil, 10 éve működő webshop. Jelenleg napi 1000 vásárlás. A cél: az év végére megduplázni a forgalmat. A jelenlegi szerver nem bírja majd. Ez üzleti érv a skálázásra – tehát van értelme a migráción gondolkodni.

2. Monolitikus app? Nem baj.

A legtöbb cég monolittal indul. Ez természetes. A probléma nem az, hogy monolitikus – hanem hogy nem skálázható és nehezen frissíthető.

Monolitikus Architektúra
Egy monolitikus architektúra ábrája

Fontos: Nem kell azonnal mikroszolgáltatásokká darabolni.

Kezdhetjük például így:

  • A frontend maradhat, ahol van.
  • Az adatbázis (pl. PostgreSQL) migrálható RDS-re.
  • A fájltárolás S3-ra költöztethető.
  • Az admin felület különválasztható és deploy-olható ECS-be vagy Lambda + API Gateway párosba.

Ez még nem teljes átalakítás – de elindulás a felhő felé.

3. Lift & Shift vs. Re-architect

lift-and-shift-vs-re-architect

Mi a különbség?

  • Lift & Shift: az alkalmazást minimális változtatással futtatjuk AWS-en (pl. EC2-n).
  • Re-architect: újratervezzük a rendszert úgy, hogy kihasználja az AWS képességeit (pl. Lambda, SQS, DynamoDB).

Mikor melyik?

HelyzetAjánlott stratégia
Időnyomás alatt vagyunk, gyors migráció kellLift & Shift
A rendszer amúgy is újraírásra szorulRe-architect
Kevés AWS tapasztalat van a csapatbanElőbb Lift & Shift, utána fokozatos újratervezés

Tipp: A kettő kombinálható. Nem kell „mindent vagy semmit” alapon gondolkodni.

4. Milyen AWS szolgáltatások jöhetnek szóba az első lépésekben?

aws-first-services

EC2 – ha szeretnél “szerű” megoldást

Virtuális szerverek, amikkel sokáig fejlesztőként dolgoztunk.

  • Jó választás, ha még nem vagyunk biztosak más szolgáltatásokban.

RDS – relációs adatbázis menedzselve

PostgreSQL, MySQL, MariaDB – menedzselt formában.

  • Kiváló monolit adatbázis költöztetéséhez.

S3 – objektumtárolás fájloknak, képeknek

CDN-nel kombinálva gyors és olcsó fájlkiszolgálás.

Lambda + API Gateway – első serverless kísérletekhez

Kis admin feladatok, webhook-ok, automatikus értesítések.

ECS (Fargate) – konténeres átmenet

Ha már van Dockerizált app, Fargate segítségével nem kell infrastruktúrát menedzselni.

5. A legnagyobb döntés: Mit NEM migrálunk most?

A fokozatos haladás egyik kulcsa, hogy tudjuk:

  • Mi az, amit most nem fogunk áthelyezni?
  • Mi az, amit később optimalizálunk?
  • Melyik rész a legtöbb értéket adja, ha modernizáljuk?

A migráció nem egy projekt, hanem egy út.

Ha minden fontos dolgot egyszerre akarunk áttenni, az rendszerint leálláshoz, csúszáshoz és frusztrációhoz vezet.

6. Mit vigyél magaddal ebből a cikkből?

Ahogy egyre jobban megismered az AWS-világát, egyre inkább az körvonalazódik, hogy nem kell mindenre tudni a választ. Az számít, hogy:

  • Képesek vagyunk-e releváns kérdéseket feltenni amikor egyszerre sok szempontnak érvényesülnie kell?
  • Látjuk-e az üzleti célokat?
  • Tudunk-e jól priorizálni?

A migráció nem DevOps feladat, hanem termékdöntés, üzleti döntés, és végül fejlesztési döntés is.


Zárás

Jó döntés lesz a migrálás, ha ismerjük a mérhető célt, ha egyszerre mindent NEM akarunk átalakítani, ha olyan szolgáltatásokat használunk amiket jól ismerünk vagy ismer a megbízott csapat!

Nem vagyok még szakértő, de napról napra jobban értem, milyen kérdések a fontosak.


Ha a céged migráció előtt áll, döntés előtt állsz vagy kérdésed van? Foglalj egy ingyenes konzultációt és nézzük meg, hogy a Code Factory csapata miben tud segíteni neked / nektek!

Köszönöm, hogy elolvastad! Remélem tetszettek ezek a gondolatok! Ha kiváncsi vagy miben tudunk segíteni neked nézz körül a szolgáltatásaink között!

Ha részletesebben is érdekel az AWS szolgáltatásaival kapcsolatos téma, töltsd le az ingyenes e-book-unkat.

Vissza a cikkekhez