W świecie Monolith v/s Microservices toczy się wiele dyskusji. Większość mojej wczesnej kariery spędziłem na budowaniu monolitów i oczywiście, gdy architektury zorientowane na usługi zaczęły się zakorzeniać, przyjęliśmy je z dużym powodzeniem.

Moje doświadczenie

Nie muszę tu brzmieć fajnie i rzucać w ludzi takimi rzeczami jak prawo Conwaya. Moje ograniczone doświadczenie nauczyło mnie, że mieliśmy pojedyncze osoby, małe zespoły i duże zespoły, którym wyraźnie przydzielono opiekę nad określonym modułem (nazwij to usługą, jeśli chcesz). W ramach swoich obowiązków musieli wykonać następujące czynności:

• Musieli go posiadać
• Musieli to utrzymać
• Musieli się o tym komunikować
• Twórz interoperacyjne interfejsy API, które honorują umowy
• Przetestuj własne oprogramowanie
• Pamiętaj o testach integracyjnych
• Być w stanie określić sposób wdrażania swoich rzeczy w środowiskach
• Debuguj i, co ważne, śledź wywołanie w ogólnym schemacie rzeczy.

Tu nie chodzi o Monolit czy Mikroserwisy

Naprawdę nie ma złotego środka. Nie ma ostatecznego kąta przejścia na mikroserwisy lub monolitu. Każdy, kto mówi o pójściu w jedną lub drugą stronę, nie ma złych intencji, próbując cię przekonać, ale z należytym szacunkiem, każda organizacja i jej zespoły programistyczne będą inne, ich wymagania będą inne, jak muszą ewoluować lub wspierać nowe usługi/urządzenia będą inne. Będziesz musiał najpierw zająć miejsce kierowcy, aby zrozumieć własną organizację, zanim ślepo przyjmiesz jakikolwiek pogląd na dużą firmę lub osobę wpływową.

W żadnym momencie żadna organizacja nie powinna lekceważyć potrzeby zarządzania zespołami ludzi, wprowadzania w nich pewnego porządku, automatyzacji, testowania, zapewnienia zespołom swobody i elastyczności w wyborze narzędzi, a jednocześnie utrzymywania ich w dyscyplinie i nie tylko.

Odłóż na chwilę kwestię monolitów i mikroserwisów na bok. Czy zajmujesz się podstawowymi problemami, takimi jak komunikacja w zespole, hierarchia, podejmowanie decyzji, dyscyplina i higiena inżynierii oprogramowania, pokrycie testów, automatyzacja, autonomia i inne? Pomyśl o tym przez chwilę.

Co polecam?

W mojej książce wolę spojrzeć na aplikację w całości i przede wszystkim, dlaczego w ogóle istnieje? Po uzyskaniu tych odpowiedzi przyjrzyj się, jakie są przypadki użycia lub podróże użytkowników, z którymi użytkownicy wchodzą w interakcję z Twoją aplikacją? Dla mnie ostatecznie sprowadza się to do:

1. Potrzebujesz wydajnego procesu (w pełni zautomatyzowanego lub nie), aby rozwijać i wdrażać swoją aplikację w różnych środowiskach i móc przenosić wersje między nimi.
2. Potrzebujesz wydajnego procesu śledzenia zmian w kodzie źródłowym do tego, co zostało wdrożone w środowisku produkcyjnym.
3. Wreszcie, co najważniejsze, kiedy dzieje się gówno i co się stanie, czy masz możliwość śledzenia i śledzenia tego, co się dzieje, zlokalizowania komponentu, który powoduje problem, skutecznego debugowania i zrozumienia pierwotnej przyczyny, a następnie posiadania procesu wdrożenia zmiany, aby złagodzić skutki dla użytkowników.

Teraz, jeśli monolity i/lub architektura mikrousług mogą pomóc ci rozwiązać ten problem, biorąc pod uwagę ograniczenia twojej organizacji, idź z tym. Nie jesteś Google, Facebook, Microsoft, Amazon, a oni nie są tobą. Nie musisz nawet od razu porównywać się z innymi organizacjami, które mogą być bardziej inteligentne, zwinne lub którekolwiek z tych cech.

Wszystko, co musisz zrobić, to w prawdziwym duchu zbudować zdrową kulturę w swojej organizacji, która jest otwarta na dyskusję i zaczyna mierzyć to, co zaleca DORA :

• Czas przywrócić usługę
• Zmień wskaźnik awaryjności
• Czas oczekiwania na zmiany
• Częstotliwość wdrażania.

Moją końcową uwagą jest skupienie się na tym, co sprawia, że ​​dostarczasz oprogramowanie wydajnie (koszty, operacje i wszystko wliczone). Wszystko inne jest jak debata w wiadomościach o 21:00.