Najważniejszą rzeczą do zapamiętania w przypadku mikrousług jest to, że nie dotyczą one głównie rozwiązywania problemów technicznych, ale problemów organizacyjnych. Kiedy więc patrzymy na to, czy organizacja powinna używać mikrousług i jak te usługi są wdrażane, musimy sprawdzić, czy organizacja ma problemy, które rozwiązuje styl mikrousług.
Odpowiedź na pytanie dotyczące architektury będzie zatem zależeć głównie od wielkości zespołu technologicznego, struktury organizacyjnej, wieku Twojego produktu, bieżących praktyk wdrażania i tego, jak mogą się one zmienić w perspektywie średnioterminowej.
Na przykład, jeśli Twoja organizacja:
- ma mniej niż 25 pracowników technicznych,
- zorganizowane w 1 lub 2 zespoły,
- z których każdy działa na dowolnej części produktu,
- który ma mniej niż 12 miesięcy,
- i jest wdrażany od razu regularnie (np. codziennie, co tydzień, co miesiąc),
- i org nie ma zamiaru szybko rosnąć,
wtedy prawie na pewno chcesz na razie zapomnieć o mikrousługach. W takiej sytuacji zespół wciąż jest nowy w nauce domeny, więc prawdopodobnie nie wiedzą wszystkiego, co powinni wiedzieć, aby naprawdę zrozumieć, jaki byłby świetny sposób na podzielenie systemu na architekturę rozproszoną. Oznacza to, że jeśli podzielą go teraz, prawdopodobnie będą chcieli później zmienić granice, a to stanie się bardzo kosztowne, gdy masz już system rozproszony, a jednocześnie jest o wiele prostszy w monolicie. Co więcej, tylko niewielki zespół, który może pracować nad (i wspierać) dowolną częścią systemu, nie ma powodu, aby inwestować w budowę platformy, w której poszczególne zespoły mogłyby wdrażać i utrzymywać poszczególne usługi. Organizacja na tym etapie zwykle będzie znacznie bardziej zainteresowana wyszukiwaniem klientów i szybkim iterowaniem produktu, być może nawet jego obracaniem, w przeciwieństwie do tworzenia autonomii zespołów i budowania skalowalnej, odpornej architektury. Monolityczna architektura ma w tym momencie sens, ale:dobrze zaprojektowany monolit, z wyraźnymi granicami komponentów wymuszonymi przez interfejsy API i enkapsulowanym dostępem do danych, co ułatwia późniejsze przeniesienie usług do oddzielnych procesów.
Spójrzmy trochę dalej i rozważmy organizację, która jest ...
- ponad 50 pracowników technicznych,
- zorganizowane w 7 zespołów,
- z których każdy działa tylko w określonych obszarach produktu,
- który ma 3 lata,
- i ma zespoły, które chcą wdrożyć swoją pracę niezależnie od tego, co robią inne zespoły.
Taka organizacja zdecydowanie powinna budować architekturę rozproszoną. Jeśli tego nie zrobią, a zamiast tego wszystkie te zespoły będą pracowały w monolicie, napotkają wszelkiego rodzaju problemy organizacyjne, przy czym zespoły muszą koordynować swoją pracę, zwalniają wydawanie, gdy jeden zespół kończy kontrolę jakości swojej nowej funkcji, łatka wdraża się jako duży problem dla personelu i klientów. Co więcej, dzięki dojrzałemu produktowi organizacja powinna wiedzieć wystarczająco dużo o tej dziedzinie, aby móc rozsądnie podzielić zarówno domenę, jak i zespoły (w tej kolejności; patrz prawo Conwaya) na rozsądne, autonomiczne jednostki, które mogą robić postępy, minimalizując jednocześnie koordynację.
Wygląda na to, że już wybrałeś mikrousługi. W zależności od tego, gdzie siedzisz na powyższych skalach, być może chcesz ponownie podjąć tę decyzję.
Jeśli chcesz nadal tworzyć mikrousługi, ale wdrażać je wszystkie w jednym kontenerze, wiedz, że nie ma w tym nic złegojeśli pasuje to do sposobu, w jaki obecnie działa Twoja organizacja. Czy w przyszłości spowoduje to problemy w strukturze projektu? Cóż, jeśli odniesiesz sukces, a Twoja organizacja się rozwinie, prawdopodobnie nadejdzie czas, w którym to wdrożenie z pojedynczym kontenerem nie będzie już najlepiej pasować, w szczególności, gdy zespoły zaczną posiadać usługi i będą chciały wdrożyć tylko swoją usługę bez wdrażania całej aplikacji . Ale ta autonomia będzie kosztować dodatkową pracę i złożoność i może nie przynieść żadnych korzyści w tym momencie. To, że w przyszłości nie będzie to właściwe podejście dla twojego systemu, nie oznacza, że nie jest to właściwe podejście na dziś. Sztuką jest pilnować go i wiedzieć, kiedy dokonać dodatkowej inwestycji.