Sytuacja kobiet w IT w 2024 roku
8.05.20194 min
Natalie Conklin

Natalie ConklinSenior Technology Executive

3 powody, dla których warto budować systemy monolityczne

Dowiedz się, w jakich 3 sytuacjach opłaci Ci się budowa systemu monolitycznego.

3 powody, dla których warto budować systemy monolityczne

Zastanawiasz się nad tytułem "3 powody, dla których warto budować systemy monolityczne"? Owszem, mam na myśli celowo je budować.

Zalecanie monolitycznej architektury w dzisiejszych czasach brzmi trochę jak zalecanie przetaczania krwi na gorączkę, ale pozwól, że opowiem więcej.

Długoterminowo, aby zapewnić skalowalność, łatwość obsługi, elastyczność i wszystkie inne pozytywne cechy (w tym własne zdrowie psychiczne), prawdopodobnie będziesz chciał opracować i wdrożyć swoją aplikację na architekturze mikroserwisów. Jeśli jednak budujesz nową aplikację, Twoja firma i zespół deweloperski mogą nie być jeszcze gotowi na ironiczną złożoność związaną z rozbijaniem systemu na proste usługi. Prędkość, z jaką możesz się znaleźć na rynku i czas na nim spędzony mogą przebić wartością samą elegancję… i bardzo dobrze!

Dlaczego warto?

Po pierwsze

Pierwszym powodem, dla którego warto zbudować system monolityczny, jest pomoc w oswajaniu niewiadomych. Weź do ręki jakąkolwiek książkę lub artykuł na temat rozpoczęcia pracy z mikroserwisami, a opisze Ci ona proces podziału systemu na usługi składowe. Ale jeśli dopiero zaczynasz, nie masz jeszcze systemu do dzielenia. Określenie potrzebnych wymagań może okazać się trudne, a tym bardziej próba rozłożenia tych wymagań na zestaw luźno powiązanych usług z dobrze zdefiniowanymi interfejsami.

Przy ilości niewiadomych na takim początku, prawdopodobieństwo uzyskania analizy chociaż trochę zgodnej z prawdą, graniczy z cudem.

Główną przesłanką powstania metodologii agile-style jest umożliwienie odkrywania iteracyjnego, ponieważ jest prawie niemożliwe, aby odkryć wszystko od razu. Podobnie, ale znacznie łatwiej jest rozpoznać usługi składowe systemu, gdy masz konkretne wydanie lub dwa pod ręką.

Tak więc na początku po prostu zacznij! Zbuduj system początkowy, nie martwiąc się, czy robisz to dobrze. Na tym etapie nie ma żadnej prawidłowej metody. Sztuka polega na znalezieniu równowagi między ciągłym zwiększaniem funkcjonalności i rozpoczęciem oddzielania określonych usług, w miarę jak mgła się rozwiewa, najlepiej przed nagromadzeniem multum długu technicznego. To podejście przyrostowe do architektury, traktowane z troską, będzie szybsze i skuteczniejsze niż próba zbudowania wszystkiego prawidłowo, bez posiadania żadnej wiedzy.

Po drugie

Drugim powodem do rozważenia monolitycznej architektury jest potencjalny brak gotowości zespołu. Nawet jeśli system jest dość dobrze zdefiniowany, podzielenie systemu na usługi składowe nie zawsze jest proste. Czy warto ryzykować i próbować pokonać samemu karkołomną procedurę w Javie (każdy system wymaga przynajmniej jednej takiej procedury), która wymknęła się spod kontroli? Rozważając nad pojedynczą usługą - jak mała musi być wystarczająco mała? Podczas gdy normalnym zaleceniem jest kontynuowanie, dopóki usługa będzie logicznie wykonywała tylko jedną rzecz, to np. w pędzącym świecie Big-Data, zbyt mała może mieć poważne konsekwencje dla wydajności.

Najważniejsze jest to, że zawsze trzeba rozważyć kompromisy, a zespół potrzebuje odpowiedniego zestawu umiejętności, aby z powodzeniem zrównoważyć te decyzje. Jeśli Twój zespół ma małe doświadczenie z mikroserwisami, warto zainwestować w szkolenie, aby zespół mógł je poznać. Być może warto także zatrudnić nowe talenty w zespole.

Ponieważ niewiele firm może sobie pozwolić na wstrzymanie rozwoju na rzecz przekwalifikowania pracowników, zespół w międzyczasie prawdopodobnie będzie musiał nadal tworzyć przy użyciu tradycyjnych praktyk. Choć będzie to wymagało kolejnej reorganizacji w przyszłości, prawdopodobnie nadal osiągniesz lepszy wynik, niż gdyby zespół parł do przodu, zupełnie nieprzygotowany. Zaufaj mi, we wczesnych wersjach prób z mikroserwisami występuje wiele procesów reorganizacyjnych.

Po trzecie

Wreszcie, monolityczny system może być Twoją najszybszą drogą, prowadzącą na rynek, a w wielu przypadkach ta prędkość jest ważniejsza niż idealna architektura. Dla wielu firm, zwłaszcza startupów pracujących z ograniczonym finansowaniem, szybkie uruchomienie sprzedaży ma wielkie znaczenie dla przetrwania. Chociaż mikroserwisy ostatecznie ułatwią życie, ta łatwość wiąże się z pewnymi początkowymi kosztami, które mogą wymagać większej dojrzałości, by sobie z nimi poradzić.

Dobra architektura mikroserwisów jest elegancko prosta, ale nie jest łatwa, szybka ani przypadkowa. Obecnie istnieje wiele świetnych, dojrzałych przykładów mikroserwisów na dużą skalę - w tym Twitter, Amazon, Spotify, LinkedIn— ale nie bez powodu wszystkie zaczynały jako aplikacje monolityczne, a dopiero później ewoluowały. Nigdy nie pozwól, aby dążenie do doskonałości technicznej stało na drodze sukcesu biznesowego. Pragmatyczna architektura oznacza, że ​​wybory technologiczne powinny wspierać potrzeby biznesowe, a nie odwrotnie.

Kiedy to zły wybór?

Chociaż powinno to być oczywiste, to sytuacja przeciwieństwa każdego z tych scenariuszy jest świetnym powodem, aby NIE budować monolitycznej architektury. Jeśli Twoja aplikacja jest już dość dobrze zdefiniowana, Twój zespół zna się na mikroserwisach, a Twoja firma ma czas i pieniądze na cykle rozwojowe, to absolutnie musisz zainwestować w architekturę mikroserwisów.

Podsumowanie

Długoterminowe korzyści z tej ścieżki są już dobrze znane i udokumentowane. Ale jeśli jeszcze nie dobiłeś do tej mety, wciąż masz inne możliwości. Zdefiniuj swoją sytuację, zaplanuj swoją ścieżkę i wykonuj iterację w konkretnym celu. Nadal poprawisz swoją sytuację, a z czasem otrzymasz architekturę godną wystąpień na eventach, która nadąży za twoimi wymaganiami biznesowymi.

<p>Loading...</p>