W poprzednim artykule opisałem, jak uzależnienie od dostawcy powstaje wskutek nawarstwiania się zależności od platform. Współczesne platformy programistyczne są wygodne, lecz wraz z tą wygodą często pojawiają się ograniczenia architektoniczne. Stają się widoczne dopiero wtedy, gdy zmiana okazuje się konieczna.
Istnieje inna droga. Wymaga bardziej świadomych decyzji, ale daje coś coraz rzadszego: rzeczywistą niezależność.
Wartością jest model decyzyjny, nie lista zakupów
Od 37signals nie warto uczyć się przez zastępowanie każdej usługi zarządzanej najnowszym narzędziem z ich ekosystemu. Warto natomiast sprawdzić, które możliwości mają znaczenie strategiczne, które zależności powodują nieproporcjonalnie wysoki koszt wyjścia oraz za jakie obowiązki operacyjne zespół naprawdę jest gotów odpowiadać.
Gdy analizuję system Rails z tej perspektywy, zadaję cztery pytania:
- Gdzie znajduje się zachowanie produktu? Reguły biznesowe powinny być widoczne w kodzie i testach, a nie rozproszone po panelach dostawców.
- Czy zespół potrafi utrzymać wybrany stos technologiczny? Własność technologii bez obserwowalności, kopii zapasowych, aktualizacji i przećwiczonych procedur odtwarzania jest jedynie ukrytym ryzykiem.
- Jaki jest najmniejszy wystarczający komponent? Kolejka oparta na bazie danych może uprościć jedno obciążenie, a dla innego nadal być złym wyborem.
- Czy zmianę można odwrócić? Etapowa wymiana z mierzalnymi kryteriami wyjścia jest bezpieczniejsza niż migracja platformy wynikająca z przekonań, a nie z potrzeb.
| Obszar | Pozostań przy usłudze zarządzanej, gdy… | Rozważ większą własność technologii, gdy… |
|---|---|---|
| Wdrażanie | Zespół zyskuje na obsłudze platformy więcej, niż płaci w kosztach i ograniczeniach | Ceny, limity lub własnościowe procesy blokują dostarczanie zmian |
| Zadania i pamięć podręczna | Obciążenie oraz wymagania dotyczące niezawodności uzasadniają wyspecjalizowaną infrastrukturę | Złożoność operacyjna jest niewspółmierna do rzeczywistego obciążenia |
| Monitorowanie | Usługa daje użyteczne pokrycie, z którego zespół faktycznie korzysta | Koszt rośnie, a najważniejsze ścieżki użytkownika nadal pozostają niewidoczne |
| Dane | Zarządzana obsługa naprawdę zmniejsza ryzyko związane z bazą danych | Eksport, rezydencja danych, dostęp lub ceny zagrażają kontroli nad produktem |
Celem nie jest samodzielne hostowanie wszystkiego. Chodzi o system, którego ważne granice są zrozumiałe, tryby awarii obserwowalne, a zależności pozostają świadomymi wyborami. Dziesięcioosobowa firma produktowa i 37signals nie powinny mieć identycznej infrastruktury. Obie mogą jednak wymagać, by wygoda nie oznaczała utraty własności technologii.
Jak wprowadzałbym ten stos technologiczny
Zacznij od inwentaryzacji, a nie od migracji. Dla każdej zależności opisz jej cel, miesięczny koszt, obciążenie operacyjne, przechowywane dane, koszt wyjścia i realną alternatywę. Wybierz jedną granicę systemu, na której uproszczenie przyniesie mierzalny rezultat, na przykład krótsze wdrożenia, mniej ruchomych elementów, krótszy czas odtwarzania albo niższe wydatki. Jeśli to możliwe, uruchom nowy komponent równolegle z dotychczasowym rozwiązaniem. Zdefiniuj warunki wycofania zmiany i udokumentuj wnioski zespołu, zanim przejdziesz do kolejnej warstwy.
W ten sposób filozofia własności technologii staje się praktyką zarządzania inżynierią: małymi decyzjami, jawnymi dowodami i zachowaną możliwością wyboru.
37signals podąża tą drogą od dwóch dekad. Ich podejście jest konsekwentne: rozpoznają rzeczywisty problem, budują rozwiązanie dopasowane do własnych potrzeb, a potem publikują je jako open source. W efekcie powstał ekosystem narzędzi, który daje alternatywę dla zależności od platform uznawanych przez większość zespołów za nieuniknione.
Powtarzalny schemat
Każdy duży projekt open source 37signals ma podobną historię. Zespół natrafia we własnej pracy na ograniczenie lub źródło frustracji, buduje rozwiązanie, a następnie dzieli się nim z innymi.
Spójrzmy na tę historię:
- DHH potrzebował frameworka webowego zgodnego z jego sposobem myślenia o tworzeniu aplikacji. Tak narodził się Ruby on Rails, który zmienił sposób, w jaki całe pokolenie uczyło się budowania produktów internetowych.
- Zespół chciał responsywności aplikacji jednostronicowych bez złożoności Reacta lub Vue. Przyjął i rozwinął Hotwire (Turbo + Stimulus) jako alternatywną architekturę.
- Potrzebne były natywne aplikacje mobilne dla Basecamp i HEY, ale bez utrzymywania osobnych baz kodu w Swift i Kotlinie. Hotwire Native rozszerzył podejście web-first na iOS i Androida.
- Zespół chciał wdrażać aplikacje na własnym sprzęcie bez złożoności Kubernetes. Kamal uprościł wdrożenia kontenerów Docker przez SSH.
- Okazało się, że w większości obciążeń Redis, Sidekiq i Memcached można zastąpić bazą danych. Solid Queue, Solid Cache i Solid Cable pokazały, że współczesne dyski SSD zmieniają rachunek wydajności.
- Potrzebny był szybszy serwer proxy HTTP/2. Tę lukę wypełnił Thruster.
- DHH przeszedł na Linuksa, częściowo z powodu frustracji polityką ekosystemu Apple, i potrzebował dopracowanego środowiska programistycznego. Omakub stał się standardowym zestawem dla Ubuntu, a Omarchy przeniósł tę samą filozofię do Arch Linux z myślą o bardziej odważnych użytkownikach.
A ostatnio:
- Pingdom nie zapewniał potrzebnej elastyczności monitorowania. Tak powstał Upright.
Żaden z tych projektów nie zaczął jako produkt. Wszystkie zaczęły się jako narzędzia wewnętrzne rozwiązujące rzeczywiste problemy na produkcji.
Upright jako najnowszy przykład
Upright wyraźnie pokazuje ten schemat. Firma 37signals przez lata płaciła Pingdom za monitorowanie Basecamp, HEY i Fizzy. Z czasem narastały problemy:
- Nie mogli dostosowywać testów do swoich potrzeb.
- Nie mieli kontroli nad regionami, z których uruchamiano testy.
- Nie mogli wykonywać uwierzytelnionych scenariuszy w przeglądarce bez dodatkowej opłaty.
- System był czarną skrzynką: sondy zgłaszały awarię i wywoływały alert, po czym znów działały, zanim ktokolwiek zdążył zbadać przyczynę.
Dlatego zbudowali własne rozwiązanie. Stos technologiczny jest przewidywalny: Rails, SQLite, Solid Queue i Kamal. Produkcyjne wdrożenie obsługujące pięć lokalizacji kosztuje łącznie około 110 dolarów miesięcznie. Minimalną konfigurację obejmującą dwie lokalizacje można utrzymać za mniej niż 20 dolarów.
Upright jest obecnie dostępny na GitHubie na licencji MIT. Schemat się powtarza: problem, rozwiązanie, open source.
Dlaczego własność technologii ma znaczenie
DHH jasno wyjaśniał motywację stojącą za tym podejściem:
Chmurowy kompleks przemysłowy przekonał wszystkich, że utrzymywanie serwerów jest niemal niewykonalne. Nie jest. Robiliśmy to przez dziesięciolecia, zanim powstał AWS.
W 2022 roku firma 37signals opuściła chmurę, kupiła własne serwery Dell i umieściła je w centrach danych. Szacowane oszczędności wyniosły 7 milionów dolarów w ciągu pięciu lat. DHH przedstawiał jednak tę decyzję jako coś więcej niż kwestię finansową:
Chodzi również o to, w jakim internecie chcemy działać w przyszłości. To po prostu tragiczne, że ten zdecentralizowany cud świata funkcjonuje dziś w dużej mierze na komputerach należących do garstki megakorporacji.
Ta filozofia wykracza poza infrastrukturę i obejmuje cały stos technologiczny. Każde opublikowane przez nich narzędzie usuwa jedną zależność. Solid Queue oznacza, że nie potrzebujesz już narzędzi Redis i Sidekiq. Solid Cache pozwala zrezygnować z Memcached. Kamal eliminuje konieczność korzystania z Kubernetes lub drogich platform PaaS. Upright sprawia, że do monitorowania syntetycznego nie potrzebujesz usług Pingdom ani Datadog.
Suma tych wyborów daje niezależność architektoniczną. Gdy kolejka zadań, pamięć podręczna, zaplecze WebSocket, system wdrożeń i monitorowanie pochodzą z jednego ekosystemu, a ten ekosystem jest open source, zachowujesz kontrolę nad przyszłością własnej infrastruktury.
Moment SQLite
Rails 8 jest ucieleśnieniem tej filozofii. Adaptery Solid (Queue, Cache, Cable) są teraz domyślne w nowych aplikacjach Rails. Nie jest to niszowy eksperyment, lecz nowy standard Rails. Wszystkie mogą działać na SQLite i korzystać z tej samej bazy danych co aplikacja.
Istniejące aplikacje nie muszą wdrażać całego stosu technologicznego naraz. Bezpieczna modernizacja Rails zaczyna się od pomiaru obecnej bazy danych, zadań, pamięci podręcznej, procesu wdrażania i ryzyk operacyjnych. Dopiero potem wprowadza prostsze komponenty tam, gdzie naprawdę usuwają koszty lub tryby awarii.
Założenie techniczne jest proste: dyski SSD i NVMe są na tyle szybkie, że baza danych może obsługiwać obciążenia, które wcześniej wymagały wyspecjalizowanych systemów działających w pamięci. W wielu aplikacjach eliminuje to całe kategorie infrastruktury.
Nie oznacza to, że SQLite jest rozwiązaniem zawsze lepszym od pozostałych. Chodzi o dostępność opcji. Mały zespół może zacząć od pojedynczej bazy SQLite i przejść na PostgreSQL wtedy, gdy stanie się to rzeczywiście potrzebne. Architektura nie zamyka go w decyzjach podjętych w najwcześniejszym okresie życia aplikacji.
Dzisiejszy ekosystem
Łączny dorobek 37signals i szerszej społeczności Rails tworzy spójny stos technologiczny:
| Obszar | Tradycyjne podejście | Ekosystem 37signals |
|---|---|---|
| Reaktywność frontendu | SPA w React lub Vue | Hotwire (Turbo + Stimulus) |
| Aplikacje mobilne | React Native / rozwiązania natywne | Hotwire Native |
| Przetwarzanie zadań | Redis + Sidekiq | Solid Queue + baza danych |
| Pamięć podręczna | Redis / Memcached | Solid Cache + baza danych |
| WebSocket | Redis pub/sub | Solid Cable + baza danych |
| Wdrażanie | Kubernetes / PaaS | Kamal + Docker + SSH |
| Terminacja SSL/HTTP2 | Konfiguracje nginx/Apache | Thruster |
| Monitorowanie syntetyczne | Pingdom / Datadog | Upright |
| Infrastruktura | AWS / GCP | Własny sprzęt lub VPS |
Każdy komponent jest opcjonalny. Możesz używać Solid Queue z PostgreSQL i wdrażać aplikację na Heroku. Za pomocą Kamal możesz wdrażać ją na instancjach DigitalOcean Droplets. Te narzędzia można ze sobą swobodnie łączyć, bez konieczności przyjęcia całego zestawu.
Rozpatrywane razem oferują jednak coś nietypowego: sposób wdrażania na produkcję, który nie zależy od dobrej woli ani decyzji cenowych pojedynczego dostawcy.
Ruby ma się lepiej niż kiedykolwiek
Narracja o umierającym Ruby utrzymuje się mimo dowodów wskazujących na coś przeciwnego. W wydaniu Rails 8.1 uczestniczyło ponad 500 współtwórców, którzy przygotowali 2500 commitów. Firmy takie jak Shopify, GitHub, Airbnb i Stripe nadal utrzymują rozbudowane aplikacje Rails.
Tempo rozwoju widać w samych narzędziach. Ten ekosystem wciąż przynosi nowatorskie rozwiązania, takie jak Hotwire, Kamal, adaptery Solid i Upright. Nie są to wydania utrzymaniowe ani drobne usprawnienia. To rzeczywiste innowacje w sposobie budowania i wdrażania aplikacji webowych.
37signals codziennie dostarcza produkty zbudowane przy użyciu tego stosu technologicznego. Basecamp i HEY obsługują płacących klientów. Publikowane narzędzia nie są teorią: działają na produkcji pod rzeczywistym obciążeniem.
Wybór niezależności
Podejście 37signals nie jest odpowiednie dla każdego. Utrzymywanie własnych serwerów wymaga wiedzy operacyjnej. Taki poziom niezależności wymaga większych kompetencji DevOps niż pełne powierzenie infrastruktury dostawcy chmury. Korzystanie z mniej popularnych narzędzi oznacza mniej odpowiedzi w Stack Overflow danych treningowych dla asystentów AI. Wybór mniej uczęszczanej drogi wiąże się z realnymi kosztami.
Alternatywa również ma swoją cenę. Zależności od platform narastają po cichu. Ceny zmieniają się bez zapowiedzi. Interfejsy API są wycofywane. Usługi znikają. Uzależnienie od dostawcy, które opisałem w poprzednim artykule, nie jest hipotetycznym problemem. To domyślny rezultat wygodnych decyzji podjętych bez uwzględnienia ich długofalowych konsekwencji.
37signals dowodzi, że istnieje inna droga. Możesz tworzyć nowoczesne aplikacje webowe bez oddawania kontroli nad architekturą. Możesz wdrażać je bez korzystania z Kubernetes. Możesz przetwarzać zadania i przechowywać dane w pamięci podręcznej bez infrastruktury Redis. Możesz monitorować usługi bez płacenia stawek charakterystycznych dla rozwiązań klasy enterprise.
Narzędzia są dostępne jako open source i sprawdzone na produkcji.
37signals pokazuje swój wybór poprzez dwadzieścia lat wkładu w rozwój open source. Dla reszty z nas wybór nadal pozostaje otwarty.
Wcześniejsza wersja tego artykułu ukazała się na Blog Visuality.pl.