Dług techniczny do skalowania: unikanie bankructwa

Rozdroże jest nieuniknioną rzeczą, przez którą musi przejść każda odnosząca sukcesy firma programistyczna. Nie jest to zły MVP, który przeszedł test dopasowania produktu do rynku, ale wieloaspektowy system, który obsługuje tysiące lub miliony użytkowników. Ale pod powierzchnią kryje się coś jeszcze. Nowe wersje pojawiają się powoli. Tygodnie spędza się na opracowywaniu prostych zmian. Tempo naprawiania błędów jest wyższe niż tempo korygowania starych problemów. Kod źródłowy sprawia, że inżynierowie poświęcają więcej czasu na walkę niż na tworzenie nowych funkcji. Taki scenariusz rozgrywa się w branży technologicznej z przerażającą częstotliwością. Firmy, które wydawały się skazane na sukces, są dławione przez własny początkowy sukces i muszą albo funkcjonować w stanie pobłażliwej stagnacji, albo ponownie zatrzymać swój rozwój, podejmując kosztowne działania związane z przebudową. Winowajcami nie są bynajmniej słabi programiści ani brak zasobów. Przyczyny leżą raczej w podstawowych decyzjach architektonicznych, które zostały podjęte w tych fatalnych pierwszych miesiącach, kiedy to szybkość wprowadzenia produktu na rynek była ważniejsza niż długoterminowa łatwość utrzymania. Jednym z najważniejszych obszarów wiedzy każdego lidera kierującego rozwijającą się organizacją technologiczną jest zrozumienie, jak decyzje techniczne sprawdzają się w dłuższej perspektywie czasowej. Wybory dokonywane dzisiaj mogą albo przyspieszyć rozwój w przyszłości, albo spowodować powstanie niewidzialnych ograniczeń hamujących wszystkie inne inicjatywy. Różnica między firmami, które się rozwijają, a tymi, które ponoszą porażkę, często polega na mądrym wykorzystaniu architektury w odpowiednim czasie.

Istnieją skróty między prototypem a oprogramowaniem gotowym do produkcji, które mają być krótkotrwałe, ale mają bardzo długi okres zwrotu. Rozwój na początkowych etapach będzie z natury skupiał się na szybkim prototypowaniu i bezpośredniej funkcjonalności, a nie na tak abstrakcyjnych kwestiach, jak modułowość lub rozszerzalność. Metoda ta jest całkowicie racjonalna, gdy głównym celem jest potwierdzenie hipotez, a także wykorzystanie możliwości rynkowych przed wejściem konkurencji. Jednak takie taktyczne zwycięstwa mogą prowadzić do powstania strategicznych słabości. Architektury monolityczne, które wydawały się atrakcyjne w przypadku małych grup, okazują się być wąskim gardłem w miarę rozwoju organizacji. Schematy baz danych, które były optymalne przy pierwszym użyciu, trudno jest zmienić, aby obsługiwały nowe funkcje. Setki systemów uwierzytelniania użytkowników załamują się pod ciężarem tysięcy. Wzorce integracji, które były skuteczne w przypadku kilku usług stron trzecich, okazują się niemożliwe do kontrolowania ze względu na skalę ekosystemu.

Nieefektywny interfejs API może bez problemu obsługiwać bieżące obciążenie ruchem, ale ulegnie całkowitej awarii, gdy wykorzystanie podwoi się. Ściśle powiązana baza kodu może początkowo umożliwiać szybkie opracowywanie funkcji, ale wraz ze wzrostem wielkości zespołu równoległe opracowywanie może stać się jeszcze trudniejsze. Firmy często mają tendencję do błędnej interpretacji tych symptomów jako przejściowych problemów związanych z rozwojem, które nie mają charakteru systemowego i wymagają korekty architektury. Kierownictwo może sądzić, że większa liczba inżynierów przyspieszy proces rozwoju, ale szybko zdaje sobie sprawę, że dodatkowe obciążenie związane z koordynacją i konflikty kodów w rzeczywistości spowalniają rozwój. Problemy związane z wydajnością są rozwiązywane poprzez zwiększenie mocy serwerów zamiast wprowadzenia podstawowych ulepszeń w zakresie wydajności. Problemy związane z bezpieczeństwem są rozwiązywane za pomocą punktowych rozwiązań, a nie kompleksowej analizy systemu. Konsekwencje ekonomiczne i zakres oddziaływania wykraczają daleko poza produktywność inżynierii. Wpływa to na doświadczenia klientów, ponieważ systemy są mniej stabilne i mniej responsywne. Gdy platforma nie jest w stanie obsłużyć potencjalnych klientów korporacyjnych, tracisz możliwości sprzedaży. Przewaga konkurencyjna maleje, ponieważ funkcje rozwijają się powoli. Utrudnia to proces rekrutacji, ponieważ inżynierowie nie chcą pracować w organizacjach, które mają problemy techniczne.

Budowanie architektury modułowej

Aby skutecznie opracować architekturę, konieczna jest znajomość zasad, które pomagają stworzyć dobry projekt, a także praktycznych ograniczeń, które należy uwzględnić przy podejmowaniu decyzji o wdrożeniu danego rozwiązania. Podstawą jest modułowość i rozdzielenie zadań. Opracowane systemy strukturyzują funkcjonalność w postaci odrębnych elementów, zdefiniowanych interfejsów i obowiązków. Taka strategia pozwala zespołom tworzyć i wprowadzać zmiany lub wymieniać poszczególne części bez zakłócania działania całego systemu. Architektury zorientowane na usługi są dobrym przykładem tej koncepcji w ujęciu ogólnym. Zamiast tworzyć monolityczne aplikacje, w których wszystkie funkcje wykorzystują ten sam kod źródłowy i są wdrażane w podobny sposób, organizacje mogą podzielić systemy na dedykowane usługi, które współdziałają za pośrednictwem spójnych interfejsów API. Usługi są niezależne i mogą być opracowywane, testowane i wdrażane przez różne zespoły jednocześnie, nie kolidując ze sobą.

Sztuczka polega na zdefiniowaniu odrębnych umów między różnymi sekcjami systemu i uniknięciu ścisłego powiązania, które powoduje propagację zmian we wszystkich kierunkach w całej bazie kodu.

Kwestie związane z architekturą danych

Szczególną uwagę należy zwrócić na architekturę danych, ponieważ takie decyzje mogą okazać się najdroższe do cofnięcia w przypadku baz danych. Schemat optymalizacji przypadków użycia może stanowić poważne utrudnienie w przypadku zmiany wymagań. Efektywne firmy inwestują w modele danych, które są wystarczająco elastyczne, aby wspierać rozwój bez konieczności przeprowadzania hurtowych migracji. Może to mieć następującą formę:

• Wybór baz danych dokumentów zamiast relacyjnych baz danych w oparciu o wasze potrzeby
• Stosuj strategię wersjonowania danych.
• Tworzenie API, które ukrywają podstawowe implementacje pamięci masowej

Równoważenie obecnych i przyszłych potrzeb

Wymagania dotyczące skalowalności powinny stanowić równowagę między obecnymi wymaganiami a przyszłymi możliwościami. Kiedy projektujecie zbyt skomplikowane rozwiązania problemów, które mogą nigdy nie wystąpić, marnujecie zasoby i komplikujecie sprawy bardziej niż to konieczne. Rozwiązania, które są niedostatecznie zaprojektowane, aby dostosować się do przewidywalnego wzrostu, powodują eksponencjalny wzrost długu technicznego. Najlepszym rozwiązaniem jest rozpoznanie wąskich gardeł skalowalności na wczesnym etapie i wdrożenie architektury, która może płynnie skalować się pod obciążeniem.

Obserwowalność i bezpieczeństwo

Obserwowalność jest kolejnym czynnikiem architektonicznym, który ma kluczowe znaczenie i zazwyczaj nie jest brany pod uwagę na początkowych etapach rozwoju. Każdy system, który nie posiada dokładnych funkcji rejestrowania, monitorowania i debugowania, staje się trudniejszy w utrzymaniu, ponieważ staje się bardziej złożony. Znacznie tańsze jest wbudowanie obserwowalności w architekturę na początku niż w późniejszym czasie, a doświadczenia te są nieocenione dla optymalizacji i rozwiązywania problemów. To samo dotyczy architektury bezpieczeństwa, która również stanowi wczesną inwestycję. Zastosowanie podstawowych komponentów uwierzytelniania, autoryzacji i ochrony danych pozwoli na szybkie opracowywanie funkcji bez ponoszenia kosztów związanych z bezpieczeństwem. Z drugiej strony, podejście do bezpieczeństwa jako kwestii drugorzędnej wiąże się zazwyczaj z wysokimi kosztami przeprojektowania w przypadku zmiany wymagań dotyczących zgodności lub modeli zagrożeń.

Podejmowanie decyzji technicznych

Firmy, które chcą uniknąć pułapek architektonicznych, powinny wdrożyć modele podejmowania decyzji technicznych, które są równomiernie wyważone pod względem tempa krótkoterminowego i wytrzymałości długoterminowej. Obejmuje to:

• Opracowywanie procedur przeglądu architektury dotyczących głównych wyborów technicznych
• Dokumentowanie kompromisów
• Często oceniaj zadłużenie techniczne w stosunku do priorytetów biznesowych

Testowanie i integracja

Inwestycja w automatyczne testowanie i ciągłą integrację opłaca się również tym, że pozwala na pewną refaktoryzację i inwestycje architektoniczne. Gdy zespoły są w stanie szybko potwierdzić zmiany, mają większe szanse na wdrożenie proaktywnych dostosowań, zamiast odkładać proces konserwacji na czas nieokreślony. Równoległy rozwój jest również możliwy dzięki kompleksowym zestawom testów, które identyfikują problemy z integracją na wczesnym etapie.

Przegląd kodu i dzielenie się wiedzą

Podczas przeglądu kodu należy sprawdzić zarówno implikacje architektoniczne, jak i poprawność działania. Tylko przeglądy dotyczące bezpośredniej funkcjonalności nie dają możliwości wykrycia i naprawienia problemów strukturalnych, zanim staną się one utrwalone. Poprawę jakości decyzji w całej organizacji można osiągnąć poprzez szkolenie inżynierów w zakresie identyfikowania i komunikowania kompromisów architektonicznych.

Częste prezentacje techniczne i spotkania dotyczące architektury pozwalają zachować wspólne zrozumienie w kontekście rozrastających się zespołów inżynierów.

Regularne przeglądy architektury

Regularne oceny architektury dają możliwość nabrania dystansu do codziennych prac rozwojowych i przeanalizowania stanu systemów w szerszej perspektywie. Takie przeglądy powinny pozwolić ustalić, skąd wzięło się zadłużenie techniczne, czy obecna architektura odpowiada potrzebom firmy i co można zrobić, aby ją ulepszyć, tak aby zapewnić optymalny zwrot z inwestycji inżynieryjnych.

Proces skalowania po uruchomieniu z pewnością będzie ewolucją architektury, ale nie musi to oznaczać kosztownych przeróbek ani nawet stagnacji w rozwoju. Firmy, które na początku podejmują rozważne decyzje architektoniczne, mają większe szanse na osiągnięcie zrównoważonego rozwoju, podczas gdy firmy, które pomijają aspekty strukturalne, zazwyczaj tracą swoje osiągnięcia. Większość firm technologicznych, które mogą pochwalić się udanymi modelami, nie traktuje architektury jako decyzji, ale jako ciągłą dyscyplinę. Tworzycie systemy zdolne do płynnego rozwoju, inwestujecie w narzędzia i procesy niezbędne do wprowadzania pewnych zmian oraz posiadacie wiedzę na temat architektury, która pozwala wam dokonywać dobrych kompromisów, gdy naprawdę ma to znaczenie. Koszt dyscypliny architektonicznej jest niczym w porównaniu z kosztem bankructwa technicznego. Dzięki świadomości, że decyzje podjęte na wczesnym etapie mnożą się wraz z upływem czasu, oraz dzięki konsekwentnemu stosowaniu sprawdzonych zasad architektonicznych, organizacje będą w stanie opracować oprogramowanie, które w dłuższej perspektywie tylko zwiększy ich sukces. Nie jest kwestią, czy pojawią się problemy architektoniczne, ale czy zostaną one zauważone i rozwiązane, zanim staną się problemami pozornie nie do pokonania.