Czy brak spójności może przyspieszyć i pomóc w rozwoju oprogramowania?
Na pierwszy rzut oka tytuł wygląda jak bzdura i herezja. Każdy, kto choć trochę popracował w niespójnym środowisku, w kodzie i architekturze w których brakuje jednej, spójnej wizji popuka się w głowę i zamknie tą kartę.
Poczekajcie, zobaczcie co do powiedzenia ma Sam Newman, twórca koncepcji mikroserwisów, konsultant z wieloletnim doświadczeniem i autor kilku książek w tym temacie:
Jakim cudem brak spójności może być czymś zamierzonym? Zostańcie ze mną, a wszystko stanie się jasne.
1500+ releasów w ciągu roku…
Tak, z taką prędkością porusza się całe portfolio serwisów dostępnych w ramach Amazon Web Services. Jest to imponująca liczba, nawet biorąc pod uwagę, że portfolio liczy ponad 200 usług, bo liczba 1500 obejmuje tylko największe i średnie zmiany. Śmiało można powiedzieć, że cała platforma ewoluuje codziennie – czego sam doświadczyłem, gdzie w przeciągu jednego miesiąca 3x zmienił się w całkiem nietrywialny sposób interfejs użytkownika w ramach jednej usługi.
Jak tak olbrzymia organizacja może poruszać się z taką prędkością? Tylko i wyłącznie przez podział na mniejsze zespoły produktowe, które są odpowiedzialne od A do Z za dany produkt.
Nie wiemy, czy to dalej prawda ale w Amazonie każdy taki zespół jest konstruowany zgodnie z heurystyką o specjalnej nazwie: Two Pizza Team – oznacza to nie mniej, nie więcej, że zespół powinien być tak duży, żeby ich członkowie mogli zostać wykarmieni przez dwie pizze. Złośliwi mówią, że nikt nie doprecyzował, czy mamy do czynienia z pizzą włoską czy amerykańską (która jest większa).
Tempo zmian jest imponujące, w takim razie zastanówmy się czy to jest ten wspaniały złoty środek? Czy właśnie znaleźliśmy Złotego Graala? Niestety nie, ponieważ wytwarzanie oprogramowania to sztuka kompromisów.
Szybkość obniża precyzję…
W tym przypadku cierpi trochę spójność, w szczególności ta dotycząca interfejsu użytkownika. Jeśli pracowaliście choć trochę w konsoli AWSowej, wiecie doskonale jak różne potrafią być interfejsy, nawet od strony stylistyki. W szczególności to widać przy usługach, które są stabilne i nie rozszerzane od dawna.
Taka niespójność wynika z tego, że za każdy komponent odpowiada osobny zespół (lub przy niektórych zawieszono pracę). Dokładnie tak, jak to opisuje w książce Microservices Sam Newman, w rozdziale dotyczącym zalet i konsekwencji wprowadzenia tej architektury w przedsiębiorstwie. Jedną z korzyści jest uwolnienie zespołu odpowiedzialnego za dany komponent, i umożliwienie im rozwoju niezależnie od całej reszty – dzięki temu mogą skupić się na tym co jest naprawdę dla nich ważne, jednocześnie przesuwając mniej ważne rzeczy (umówmy się, że ładna konsola webowa dla platformy chmurowej to nie jest najważniejsza funkcjonalność).
Można by się zastanowić dlaczego nie mamy podobnych problemów z API oraz dlaczego integracja pomiędzy komponentami nie jest obarczona takimi samymi problemami. Ależ mamy! Przykład jest nawet dostępny w tym wątku (połączenie dwóch usług i dostarczenie wsparcia EKS w serwisie AWS Fargate zajęło prawie 2 lata). Ale dzięki temu, mamy większą prędkość i w ramach naszego komponentu możemy być szybsi i bardziej elastyczni.
A jak jest u Was? Wolelibyście być niezależni, czy uważacie, że spójność jest najważniejsza i powinna być utrzymywana ponad wszystko. Podzielcie się swoim zdaniem w komentarzach!