Plusz:
Microservice szemlelet:
- ne akarjon mindent is egy app megcsinalni (e.g. ne monolitikus legyen), az architekturat ehhez kell igazitani
- kulonbozo app-ok kulonbozo eletciklussal futnak: van amihez gyakran hozzanyulunk, van amihez honapokig nem
- az app csak a business logikaval foglalkozzon, ne akarjon olyan dolgokkal foglalkozni, amit mas retegben szoktunk megoldani (pl. HTTPS terminalas, rate limiting)
- jol definialt API-kon keresztul kommunikaljanak a microservice-ek (swagger es tarsai)
- minel inkabb stateless legyen az app, ha ez nem megoldhato, akkor szukseg van Redis-re, vagy SQL/noSQL adatbazisra/docstore-ra, nyilvan ezekhez is erteni kell akkor
Egyeb:
- Lehessen konnyen rollbackelni
- N-1 es N verzios podok tudjanak egyutt futni (rolling update miatt, plusz ez kell a rollbackhez is)
- Egyseges logolas (JSON vs. plain text), log verbosity allithato legyen
- Feature flagekkel lehessen vezerelni
- Jol tesztelheto legyen (nem unit tesztekre gondolok, hanem kesobb CI soran)
- Gyakori perf. teszteles
- ha van kulso observability (Datadog es tarsai), akkor azt is bele kell fejleszteni ertelmesen (nem csak a logot belehanyni oszt jovan)
- A fejleszto lasson ra es erdekelje, hogy mi tortenik a commit utan:
- CI/CD pipeline-ok
- hogyan lehet logot nezni
- hogyan lehet trace-eket nezni
- alertek legyenek visszacsatolva
- mennyi cloud resource-t fogyaszt az app (-> FinOps)
- stb.
- WAF-hoz szabalyok irasa
- CDN
- IaC szemlelet
Ha ezek mind rendben vannak, akkor johetnek az olyan fincsi dolgok mint:
- Service-mesh
- A/B teszteles a felhasznalokkal
Az ilyen környezetek nagyon fejlesztő szemmel készülnek, cserében nagyon sok dolog hárul a fejlesztőre ahhoz, hogy ideálisan működjön, így nem opció, hogy a fejlesztőnek fogalma sincs, hol fog futni a cucca.
Ez a devops paradigma lenyege, hogy a fejlesztes es az uzemeltetes egy csapatban osszpontosul. Nincs mutogatas a masikra.