Szerdán volt az Ericcson-ban egy Java User Meetup ahol két előadás is mikroszervizekről szólt. Kimondták amit sokan ki szoktak mondani, hogy mikroszervízeknek akkor van értelme, ha már nagyon magas a rendszer komplexitása és ideje részekre bontani. De ez szerintem csak részben igaz. Nem maga a bonyolultság a jó indok, hanem a kultúrális és technológiai távolság az egyes modulok között.
Ha van egy eszement bonyolult monolitikus szoftver, amit ugyanannál a cégnél hasonló szerződési konstrukcióval dolgozó, hasonló tudású emberek fejlesztenek rétegenként ugyanazokon a nyelveken, és később a szoftvert is egy hardveren fogják üzemeltetni, ott nem látom az értelmét bevállalni a mikroszervízekkel járó plusz munkát.
Milyen kultúrális és technológiai távolságokra gondolok:
- Más csapat, más cégnél fejleszt egy komponenst. Ilyenkor nem kell hogy ugyanazt a programozási nyelvet vagy paradigmát használják. Egyik csapat fejleszthet .NET-ben, a másik Java-ban.
- Egyik csapat vízesés modellt használhat, a másik lehet scrum.
- Ha még ugyanazt a programozási nyelvet is használják, de merőben különböző a csapatok álláspontja a kód minőségéről, akkor ismét előnyös ha galvanikusan szét vannak választva a bizonyos modulok. Jobb ha nem írnak egymás kódjába, jobb ha nem hívják direktben egymás kódját.
- A szolgáltatásoknak lehetnek egymástól eltérő biztonsági követelményei. Egyik szolgáltatásnak elég egy sima replikált adatbázisszerver, de a másik szolgáltatás adatait komolyabb biztonsági intézkedésekkel kell védeni vasajtók mögött.
- Eltérő skálázhatósági igények: Például egy szoftver adminisztrációs felületének és publikus felületének teljesen más skálázhatósági igényei vannak.
- Eltérő platform igények. Egy Android App vagy egy mikrokontrollerben futó szoftver is lehet mikroszervíz, nemcsak a szervereken felhőben futó szoftverek.
- A szoftver bizonyos komponensei nem egyformán vesznek részt a bizniszben. Van amelyik funkció hozza a pénzt, van amelyik viszi, van amelyiket más módszerekkel kell fejleszteni hogy kiszolgálja a növekvő felhasználói igényeket. Van amelyik komponenst jobb ha egy olyan résztvevő fejleszt, aki szakértője az adott üzleti területnek.
- Lehet hogy bizonyos komponenst külön is el lehet adni. Bizonyos komponenseknek rövidebb lehet az üzleti ciklusa, ami igencsak előnyös a cash-flow szempontjából. Na a végére elmentem közgazdászba.
Egy monolitikus szoftvert általában jól látható vertikális GUI funkcionalitások mentén próbálnak szétválasztani mikroszervizekre. Pedig ezek a prekoncepciók nem mindig helyesek. Itt is azt kellene keresni, hogy melyik az a választóvonal, ahol ki lehetne használni az eltérő kultúrális és technológiai távolságokban rejlő lehetőségeket. Leválasztani, outsource-olni, olyan programozási nyelven megírni ami pont jó az adott feladathoz, olyan adatbázist használni ami pont jó, olyan csapatokat ráküldeni akik értenek is hozzá, satöbbi.
De biztos vagyok benne hogy még sok olyan szofvert fogok látni ami csak azért mikroszervíz alapú, mert az éppen menő. És csalódások is lesznek. Még nem jött el az idő, hogy a mikroszervizek elérjék a hype-görbe mélypontját.
