\u201eZr\u00f3bcie tak, \u017ceby dzia\u0142a\u0142o jak Netflix\u201d \u2013 to zdanie s\u0142ysza\u0142em od co najmniej trzech founder\u00f3w w ostatnim roku. Netflix jest symbolem perfekcyjnego skalowania: miliony u\u017cytkownik\u00f3w, zero lag\u00f3w, personalizacja rodem z science-fiction. Problem w tym, \u017ce budowa systemu na miar\u0119 Netflixa na starcie to jak zakup my\u015bliwca do wo\u017cenia warzyw na targ. Ko\u0144czy si\u0119 zwykle przeinwestowaniem, op\u00f3\u017anieniami i frustracj\u0105. W tym artykule poka\u017c\u0119 trzy realne pu\u0142apki, w kt\u00f3re wpadaj\u0105 firmy pr\u00f3buj\u0105ce skalowa\u0107 \u201ejak Netflix\u201d \u2013 i jak ich unikn\u0105\u0107.<\/p>\n
Mikroserwisy daj\u0105 obietnic\u0119 niezale\u017cnych zespo\u0142\u00f3w, \u0142atwiejszego skalowania i wdro\u017ce\u0144 bez przestoj\u00f3w. Netflix je uwielbia. Ale Netflix ma setki in\u017cynier\u00f3w i dekad\u0119 optymalizacji.<\/p>\n
Klient z bran\u017cy e-learningowej chcia\u0142 od razu mikroserwis\u00f3w: osobne serwisy do subskrypcji, do kurs\u00f3w, do user\u00f3w i do p\u0142atno\u015bci. Po 6 miesi\u0105cach mieli: 4 repozytoriami, 12 endpoint\u00f3w komunikuj\u0105cych si\u0119 przez REST, piek\u0142o z debugowaniem i zesp\u00f3\u0142 sp\u0119dzaj\u0105cy 30% czasu na obs\u0142udze narz\u0119dzi (Kubernetes, API gateway itp.). Tymczasem MVP mo\u017cna by\u0142o zrobi\u0107 w 2 miesi\u0105ce w monolitycznym Rails \u2013 i skalowa\u0107 p\u00f3\u017aniej.<\/p>\n
Mikroserwisy na starcie to jak budowa autostrady przed wybudowaniem fabryki samochod\u00f3w. Zwykle ko\u0144czy si\u0119 to marnowaniem pieni\u0119dzy na infrastruktur\u0119, kt\u00f3ra nie jest potrzebna, oraz spowolnieniem dostarczania funkcji biznesowych.<\/p>\n
Zacznij od monolit\u00f3w z wyra\u017anie oddzielonymi modu\u0142ami (np. w TypeScript lub Django). Gdy osi\u0105gniesz pewien pr\u00f3g \u2013 np. 10-20 tys. u\u017cytkownik\u00f3w lub kilka zespo\u0142\u00f3w \u2013 wtedy rozwa\u017c wydzielenie najcz\u0119\u015bciej zmienianych modu\u0142\u00f3w. Netflix te\u017c zaczyna\u0142 jako monolit.<\/p>\n
Founderzy cz\u0119sto my\u015bl\u0105: \u201eNetflix hostuje wszystko na AWS, wi\u0119c my te\u017c musimy mie\u0107 auto-scaling, Kubernetes, CI\/CD w 20 minut i monitoring jak u NASA\u201d.<\/p>\n
Startup fintechowy od razu wdro\u017cy\u0142 K8s i Terraform. Mieli trzy mikrous\u0142ugi i pi\u0119\u0107 \u015brodowisk (dev, stage, prod, QA, demo). Zatrudnili DevOps na pe\u0142en etat, kt\u00f3ry przez 3 miesi\u0105ce ustawia\u0142 pipeline\u2019y i konfiguracje. Aplikacja mia\u0142a 200 u\u017cytkownik\u00f3w. Tymczasem prosta maszyna VPS z r\u0119cznym wdro\u017ceniem przez rsync dzia\u0142a\u0142aby 5x taniej i szybciej.<\/p>\n
Nadmiarowa automatyzacja zabiera czas, kt\u00f3ry mo\u017cna przeznaczy\u0107 na rozw\u00f3j produktu. Poza tym \u2013 du\u017ce \u015brodowiska to du\u017ce rachunki za chmur\u0119. Netflix p\u0142aci miliony, ale ich nie odczuwa, bo ma przychody. Ma\u0142a firma mo\u017ce zbankrutowa\u0107 przez AWS, zanim zd\u0105\u017cy zarobi\u0107.<\/p>\n
Najpierw manualnie, potem automatyzuj. U\u017cyj prostego Docker Compose na pojedynczym serwerze. Je\u015bli potrzebujesz autoskalowania, wystarczy prosty skrypt na podstawie load balancera. Dopiero gdy zaczniesz sp\u0119dza\u0107 czas na r\u0119czn\u0105 obs\u0142ug\u0119, wprowad\u017a CI\/CD.<\/p>\n
Netflix u\u017cywa chaos engineeringu, event sourcingu, CQRS, w\u0142asnej CDN (Open Connect) i kilkudziesi\u0119ciu narz\u0119dzi open source. Ale ich problemy s\u0105 specyficzne: ogromna skala, potrzeba globalnej dystrybucji, odporno\u015b\u0107 na awarie region\u00f3w.<\/p>\n
SaaS do zarz\u0105dzania ma\u0142ymi sklepami (1000 klient\u00f3w) wdro\u017cy\u0142 event sourcing i CQRS, bo \u201eNetflix tak robi\u201d. Efekt: kod sta\u0142 si\u0119 skomplikowany, dodanie nowej funkcji trwa\u0142o tygodnie. Klienci mieli 1-2 zapytania na sekund\u0119 \u2013 monolit poradzi\u0142by sobie bez problemu.<\/p>\n
Ka\u017cdy wzorzec architektoniczny ma koszt. Event sourcing wymaga skomplikowanego cache\u2019owania i radzenia sobie z eventual consistency. Dla ma\u0142ej aplikacji to zb\u0119dna komplikacja. U\u017cywaj prostych rozwi\u0105za\u0144, dop\u00f3ki nie udowodnisz, \u017ce potrzebujesz wi\u0119cej.<\/p>\n
Zamiast patrze\u0107 na Netflix, analizuj w\u0142asne obci\u0105\u017cenia. Zmierz: liczba u\u017cytkownik\u00f3w, zapytania na sekund\u0119, wymagania czasowe, bud\u017cet. Dopasuj architektur\u0119 do tych danych, a nie do benchmark\u00f3w gigant\u00f3w.<\/p>\n
Netflix jest niesamowitym przyk\u0142adem skalowania, ale jego architektura powsta\u0142a przez lata ewolucji, a nie przez kopiowanie gotowych rozwi\u0105za\u0144. Je\u015bli tw\u00f3j startup pr\u00f3buje od razu by\u0107 jak Netflix, najprawdopodobniej sko\u0144czy jak Titanic \u2013 pi\u0119kny, ale ton\u0105cy.<\/p>\n
Dla kogo ten artyku\u0142?<\/strong><\/p>\n Dla founder\u00f3w i CTO, kt\u00f3rzy my\u015bl\u0105 o skalowaniu. Moja rada: zacznij od prostoty. Skaluj dopiero, gdy twoja aplikacja tego wymaga. A je\u015bli potrzebujesz pomocy w doborze odpowiedniej architektury \u2013 JurskiTech ma do\u015bwiadczenie w budowaniu skalowalnych rozwi\u0105za\u0144 od ma\u0142ych po \u015brednie firmy. Bez przep\u0142acania.<\/p>\n A ty?<\/strong><\/p>\n Czy tw\u00f3j zesp\u00f3\u0142 te\u017c wpad\u0142 w pu\u0142apk\u0119 przesadnego skalowania? Podziel si\u0119 w komentarzu \u2013 ch\u0119tnie poznam twoj\u0105 histori\u0119.<\/p>\n","protected":false},"excerpt":{"rendered":" Wst\u0119p \u201eZr\u00f3bcie tak, \u017ceby dzia\u0142a\u0142o jak Netflix\u201d \u2013 to zdanie s\u0142ysza\u0142em od co najmniej trzech founder\u00f3w w ostatnim roku. Netflix jest symbolem perfekcyjnego skalowania: miliony u\u017cytkownik\u00f3w, zero lag\u00f3w, personalizacja rodem z science-fiction. Problem w tym, \u017ce budowa systemu na miar\u0119 Netflixa na starcie to jak zakup my\u015bliwca do wo\u017cenia warzyw na targ. Ko\u0144czy si\u0119 zwykle<\/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":[276,617,190,475,379],"class_list":["post-2215","post","type-post","status-publish","format-standard","hentry","category-warto-wiedziec","tag-architektura-api","tag-b2b-saas","tag-bledy-firm","tag-cto","tag-globalne-skalowanie"],"_links":{"self":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2215","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=2215"}],"version-history":[{"count":0,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/posts\/2215\/revisions"}],"wp:attachment":[{"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/media?parent=2215"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/categories?post=2215"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/news.jurskitech.pl\/blog\/wp-json\/wp\/v2\/tags?post=2215"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}