Gdybym mia\u0142 z\u0142ot\u00f3wk\u0119 za ka\u017cdego CTO, kt\u00f3ry m\u00f3wi mi: \u201ePrzechodzimy na mikroserwisy, bo musimy by\u0107 skalowalni\u201d, m\u00f3g\u0142bym ju\u017c dawno przej\u015b\u0107 na emerytur\u0119. Problem w tym, \u017ce w 80% przypadk\u00f3w to decyzja oparta na mitach, a nie realnych potrzebach biznesowych.<\/p>\n
W JurskiTech widzieli\u015bmy startupy, kt\u00f3re zjad\u0142y z\u0119by na monolicie i \u015bwietnie ros\u0142y. Widzieli\u015bmy te\u017c firmy, kt\u00f3re po przej\u015bciu na mikroserwisy zwolni\u0142y rozw\u00f3j o po\u0142ow\u0119, a ich koszty infrastruktury wzros\u0142y trzykrotnie. Nie chodzi o to, by demonizowa\u0107 mikroserwisy \u2013 to pot\u0119\u017cne narz\u0119dzie. Ale jak ka\u017cde narz\u0119dzie, ma swoje miejsce i czas.<\/p>\n
Oto trzy najcz\u0119stsze mity, kt\u00f3re widz\u0119 w rozmowach z founderami i CTO ma\u0142ych firm.<\/p>\n
To chyba najniebezpieczniejsze przekonanie. Na pierwszy rzut oka mikroserwisy wydaj\u0105 si\u0119 oszcz\u0119dne \u2013 w ko\u0144cu mo\u017cesz skalowa\u0107 tylko te fragmenty systemu, kt\u00f3re tego potrzebuj\u0105. Ale rzeczywisto\u015b\u0107 bywa brutalna.<\/p>\n
Kiedy jedna z naszych klientek, platforma SaaS z 20 tysi\u0105cami u\u017cytkownik\u00f3w, przesz\u0142a z monolitu na mikroserwisy, jej miesi\u0119czne koszty chmury wzros\u0142y z 500 do 1500 dolar\u00f3w. Dlaczego? Bo nagle potrzebowa\u0142a osobnych instancji dla ka\u017cdego serwisu, dodatkowych narz\u0119dzi do monitorowania, logowania i komunikacji mi\u0119dzy serwisami. Do tego dosz\u0142y op\u0142aty za us\u0142ugi typu service mesh, API gateway czy kolejki wiadomo\u015bci.<\/p>\n
Co gorsza, zesp\u00f3\u0142 programistyczny \u2013 zamiast skupi\u0107 si\u0119 na rozwoju produktu \u2013 sp\u0119dza\u0142 godziny na debugowaniu problem\u00f3w z sieci\u0105 i sp\u00f3jno\u015bci\u0105 danych. W monolicie transakcja by\u0142a prosta: zapisz zam\u00f3wienie, zaktualizuj stan magazynowy, wy\u015blij mail. W mikroserwisach ka\u017cde z tych zada\u0144 to osobny serwis, a zapewnienie, \u017ce wszystkie zako\u0144cz\u0105 si\u0119 sukcesem, wymaga skomplikowanych wzorc\u00f3w jak Saga czy Two-Phase Commit.<\/p>\n
Koszty operacyjne r\u00f3wnie\u017c poszybowa\u0142y w g\u00f3r\u0119. Zatrudnienie specjalisty od Kubernetes czy AWS ECS to wydatek rz\u0119du 15\u201325 tysi\u0119cy miesi\u0119cznie. Dla ma\u0142ej firmy to cz\u0119sto przepa\u015b\u0107.<\/p>\n
Kiedy mikroserwisy s\u0105 ta\u0144sze?<\/strong> Gdy masz wyra\u017anie odseparowane domeny, kt\u00f3re ewoluuj\u0105 niezale\u017cnie, i zesp\u00f3\u0142, kt\u00f3ry potrafi utrzyma\u0107 z\u0142o\u017cono\u015b\u0107. Dla wi\u0119kszo\u015bci firm z zespo\u0142em poni\u017cej 15 os\u00f3b monolit \u2013 nawet ten dobrze zorganizowany, modularny \u2013 b\u0119dzie ta\u0144szy i szybszy.<\/p>\n Znam to z autopsji. Kiedy pracowa\u0142em nad aplikacj\u0105 e-commerce, mieli\u015bmy monolit z 50 tysi\u0105cami linii kodu. Ka\u017cda zmiana wymaga\u0142a test\u00f3w ca\u0142ego systemu, a wdro\u017cenie trwa\u0142o godzin\u0119. Postanowili\u015bmy podzieli\u0107 go na 8 mikroserwis\u00f3w. Efekt? Czas wdro\u017cenia jednej funkcji wzr\u00f3s\u0142 z godziny do dw\u00f3ch dni.<\/p>\n Paradoks? Nie. Rzecz w tym, \u017ce ka\u017cdy mikroserwis to osobna aplikacja, kt\u00f3r\u0105 trzeba zbudowa\u0107, przetestowa\u0107, wdro\u017cy\u0107 i monitorowa\u0107. Dodaj do tego zarz\u0105dzanie wersjami API, konsystencj\u0105 danych i komunikacj\u0105 asynchroniczn\u0105. Nagle prosta zmiana \u2013 dodanie pola do formularza zam\u00f3wienia \u2013 wymaga aktualizacji trzech serwis\u00f3w, napisania migracji bazy danych dla ka\u017cdego z nich i skoordynowania wdro\u017cenia.<\/p>\n Co wi\u0119cej, zespo\u0142y cz\u0119sto staj\u0105 si\u0119 silosami. Ka\u017cdy zesp\u00f3\u0142 dba o sw\u00f3j serwis, ale nikt nie my\u015bli o ca\u0142o\u015bci. Pojawiaj\u0105 si\u0119 problemy z duplikacj\u0105 logiki, niesp\u00f3jnymi interfejsami i trudnym debugowaniem w \u015brodowisku rozproszonym. Zamiast szybciej, robi si\u0119 wolniej.<\/p>\n Prawda jest taka:<\/strong> Monolit pozwala na szybkie prototypowanie i \u0142atwe refaktoryzacje na wczesnym etapie. Mikroserwisy maj\u0105 sens, gdy domeny biznesowe s\u0105 stabilne, a zespo\u0142y mog\u0105 pracowa\u0107 niezale\u017cnie. Dla startupu czy ma\u0142ej firmy monolit to cz\u0119sto lepsza \u015bcie\u017cka \u2013 o ile jest dobrze zaprojektowany (np. z u\u017cyciem wzorca hexagonal architecture).<\/p>\n Skalowalno\u015b\u0107 to \u015awi\u0119ty Graal architektury. Ale czy naprawd\u0119 potrzebujesz mikroserwis\u00f3w, by obs\u0142u\u017cy\u0107 10 tysi\u0119cy u\u017cytkownik\u00f3w?<\/p>\n Wi\u0119kszo\u015b\u0107 ma\u0142ych firm nie ma problemu ze skalowaniem horyzontalnym. Monolit z odpowiednim cache\u2019em, optymalizacj\u0105 bazy danych i load balancerem obs\u0142u\u017cy setki tysi\u0119cy u\u017cytkownik\u00f3w bez problemu. We\u017amy przyk\u0142ad platformy e-commerce, kt\u00f3ra dzia\u0142a\u0142a na monolicie w Ruby on Rails. Przez dwa lata obs\u0142ugiwa\u0142a 50 tysi\u0119cy zam\u00f3wie\u0144 dziennie, u\u017cywaj\u0105c zaledwie 4 serwer\u00f3w aplikacyjnych i jednej bazy danych z replikacj\u0105.<\/p>\n Mikroserwisy rozwi\u0105zuj\u0105 problemy skalowalno\u015bci, kt\u00f3re pojawiaj\u0105 si\u0119 dopiero przy bardzo du\u017cych wolumenach \u2013 rz\u0119du milion\u00f3w u\u017cytkownik\u00f3w. Do tego czasu lepiej skupi\u0107 si\u0119 na tym, co naprawd\u0119 przynosi warto\u015b\u0107: na produkcie i klientach.<\/p>\n Co wi\u0119cej, skalowanie mikroserwis\u00f3w bywa piek\u0142em. Gdy jeden serwis staje si\u0119 w\u0105skim gard\u0142em, skalowanie go wymaga nie tylko dodania instancji, ale te\u017c zarz\u0105dzania stanem, sesjami i sp\u00f3jno\u015bci\u0105 danych. W praktyce cz\u0119sto okazuje si\u0119, \u017ce zamiast skalowa\u0107 jeden serwis, musisz przeprojektowa\u0107 ca\u0142\u0105 architektur\u0119.<\/p>\n Alternatyw\u0105<\/strong> jest podej\u015bcie modularnego monolitu, w kt\u00f3rym kod jest podzielony na modu\u0142y, ale wdra\u017cany jako ca\u0142o\u015b\u0107. Mo\u017cesz p\u00f3\u017aniej wyci\u0105gn\u0105\u0107 wybrane modu\u0142y do osobnych serwis\u00f3w, gdy naprawd\u0119 tego potrzebujesz. To strategia, kt\u00f3r\u0105 stosuj\u0105 m.in. Shopify i Etsy \u2013 i dzia\u0142a.<\/p>\n Nie twierdz\u0119, \u017ce mikroserwisy s\u0105 z\u0142e. S\u0105 \u015bwietne, gdy:<\/p>\n Dla wi\u0119kszo\u015bci ma\u0142ych firm lepszym rozwi\u0105zaniem b\u0119dzie monolit z dobrze zaprojektowan\u0105 architektur\u0105 wewn\u0119trzn\u0105. Zaufaj mi \u2013 widzia\u0142em startupy, kt\u00f3re zbudowa\u0142y MVP w 3 miesi\u0105ce jako monolit, a potem w ci\u0105gu roku, gdy mieli ju\u017c 100 tysi\u0119cy u\u017cytkownik\u00f3w, wyci\u0105gn\u0119li pierwsze 2\u20133 serwisy do mikroserwis\u00f3w. To by\u0142o p\u0142ynne i tanie.<\/p>\n Mikroserwisy to narz\u0119dzie, a nie cel. Zanim podejmiesz decyzj\u0119, zadaj sobie pytanie: czy faktycznie masz problem, kt\u00f3ry mikroserwisy rozwi\u0105zuj\u0105? Czy mo\u017ce gonisz za mod\u0105?<\/p>\n W JurskiTech pomagamy firmom znale\u017a\u0107 z\u0142oty \u015brodek mi\u0119dzy skalowalno\u015bci\u0105 a kosztami. Je\u015bli zastanawiasz si\u0119 nad wyborem architektury, usi\u0105d\u017a z zespo\u0142em i przeanalizuj realne potrzeby. Cz\u0119sto okazuje si\u0119, \u017ce lepszym rozwi\u0105zaniem jest optymalizacja tego, co ju\u017c masz.<\/p>\n Bo najdro\u017cszy kod to ten, kt\u00f3ry piszesz, zanim go potrzebujesz.<\/p>\n","protected":false},"excerpt":{"rendered":" Mikroserwisy w ma\u0142ej firmie: 3 mity, kt\u00f3re kosztuj\u0105 Ci\u0119 pieni\u0105dze Gdybym mia\u0142 z\u0142ot\u00f3wk\u0119 za ka\u017cdego CTO, kt\u00f3ry m\u00f3wi mi: \u201ePrzechodzimy na mikroserwisy, bo musimy by\u0107 skalowalni\u201d, m\u00f3g\u0142bym ju\u017c dawno przej\u015b\u0107 na emerytur\u0119. Problem w tym, \u017ce w 80% przypadk\u00f3w to decyzja oparta na mitach, a nie realnych potrzebach biznesowych. W JurskiTech widzieli\u015bmy startupy, kt\u00f3re zjad\u0142y<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[7],"tags":[140,276,570,154,24],"class_list":["post-2528","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-analityka","tag-architektura-api","tag-mala-firma","tag-mikroserwisy","tag-skalowalnosc"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2528","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/comments?post=2528"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2528\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2528"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2528"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2528"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Mit 2: Mikroserwisy zawsze przyspieszaj\u0105 rozw\u00f3j<\/h3>\n
Mit 3: Mikroserwisy to jedyna droga do skalowalno\u015bci<\/h3>\n
Kiedy mikroserwisy maj\u0105 sens?<\/h3>\n
\n
Podsumowanie<\/h3>\n