Architektura mikrousług

Koncepcja budowania rozproszonych aplikacji złożonych z wielu komponentów ma długą historię. Najczęściej przejawiała się ona w formie SOA (Service-Oriented Architecture). Ta architektura szczyty popularności święciła 8 lat temu, obecnie powraca w postaci mikrousług.

Mikrousługi i SOA to podobne, ale jednak dwie różne rzeczy. Na ogólnym poziomie obie koncepcje wzięły się z frustracji budowania monolitycznych aplikacji. Zamiast tego proponują budowanie aplikacji jako zestawu usług, a nie jednego, monolitycznego kodu. Takie podejście ułatwia modyfikowanie aplikacji i ich utrzymanie. Dotyczy to w szczególności aplikacji internetowych, które powinny działać non-stop 24 godziny na dobę. Zakłada się, że wystarczy refaktoryzacja i ponowne wdrożenie kilku usług zamiast ponownej inżynierii i wypuszczania nowej wersji monolitu.

Rzeczywiste korzyści stają się lepiej widoczne, jeśli rozważymy całe portfolio aplikacji. Kiedy usługi są współdzielone, można wyeliminować powtarzające się prace. Zamiast zbioru monolitycznych aplikacji zarządzanych przez różne zespoły, z których każdy duplikuje wysiłki pozostałych, można skomponować swoje aplikacje z już istniejących usług, wdrożonych przez innych.

Zobacz również:

Zauważmy, że nie chodzi o ponowne wykorzystanie kodu, ale o używanie istniejących, działających usług jako części własnych aplikacji i zapewnianie komunikacji między nimi za pomocą API. Jeśli taka usługa jest udoskonalana, każda korzystająca z niej aplikacja korzysta na tym.

Oddolna inicjatywa

Wdrożenia SOA były z reguły inicjowane odgórnie przez menedżerów sfrustrowanych współpracą z wieloma samodzielnymi zespołami deweloperskimi opracowującymi wielokrotnie te same funkcje. Natomiast architektura mikrousług jest raczej inicjowana przez deweloperów. Ta grupa pracowników również nie lubi powtarzania tych samych prac, szczególnie jeśli trzeba pracować pod stale rosnącą presją, aby tworzyć coraz więcej coraz lepszych aplikacji. Często są to aplikacje mobilne i webowe, z różnymi warstwami prezentacji, ale podobnymi usługami działającymi w tle.

Wiele przemawia za mikrousługami

Panuje przekonanie, że SOA okazało się porażką. Nie jest to w pełni prawda, ponieważ w niektórych przypadkach ta architektura była stosowana z powodzeniem, czego przykładem jest Amazon. Jednakże trend SOA ostatecznie dokonał żywota w latach 2008-2009. Dlaczego warto więc zainteresować się mikrousługami? Jest kilka powodów.

Po pierwsze, jest to znacznie prostsza architektura. SOA wyrosło z usług webowych, które były zdefiniowane przez IBM i Microsoft korzystających z SOAP (Simple Object Access Protocol) oraz XML. Dzisiaj SOAP w większości został zastąpiony przez protokół REST (Representational State Transfer), który jest łatwiejszy do nauczenia i niesie ze sobą mniejszy narzut. Ponadto SOAP wymaga używania XML. Jest to język, z którym ciężko się pracuje. REST współpracuje z prostszym standardem wymiany danych JSON (JavaScript Object Notation), który deweloperzy zasadniczo preferują.

Istotne jest też słówko „mikro”. W czasach popularności SOA usługi mogły być dowolnej wielkości, włączając w to ciężkie aplikacje korporacyjne z wieloma interfejsami API, od których zależało działanie innych aplikacji. Kilku dużych producentów oprogramowania próbowało uczynić ich potężne aplikacje centrum środowiska SOA, co nie miało sensu. Mimo że nikt nie określił sztywnej granicy wielkości mikrousług, podstawowy koncept zakłada, że każda usługa realizuje pojedynczą funkcję.

Kolejny argument za mikrousługami to infrastruktura chmurowa. Dużym problemem w SOA było współdzielenie usług. Aby wdrożyć SOA, firmom doradzano wyszukanie wewnątrz organizacji najlepszych usług, z których mogłoby korzystać wiele aplikacji. Jeśli jednak zbyt wiele aplikacji jednocześnie dobijało się do tej samej usługi, następował spadek wydajności. Odpowiedzią na ten problem jest dzisiaj automatycznie skalującą się infrastruktura chmurowa.

Za mikrousługami przemawiają również nowe technologie kontenerów. Najwięcej uwagi przykuwa projekt Docker, który może dynamicznie przyspieszyć popularyzację architektury mikrousług. Demontaż monolitycznych aplikacji i podzielenie ich na szereg usług wymaga sporych nakładów. Docker i cały powstały wokół projektu ekosystem, m.in. rozwiązania Mesos i Kubernates, znacznie ułatwiają wdrażanie i zarządzanie mikrousługami.

Dzięki szybszym i niezawodniejszym sieciom mikrousługi mogą sprawnie działać. Obiekcje dotyczące SOA wynikały, m.in. z tego, że funkcjonowanie rozproszonych usług było uzależnione od sieci, co oznaczało ryzyko pojawienia się opóźnień, czy w ogóle braku komunikacji. Dzisiaj prawa fizyki wciąż działają, ale sieci stały się nieporównanie szybsze niż 10 lat temu.

Mikrousługi wywołują też mniej emocji i polityki. Oto powód, który okazał się gwoździem do trumny SOA: korzystanie z tej architektury wymagało dużych zmian organizacyjnych. Zakładano bowiem podział odpowiedzialności za usługi w zależności od funkcji biznesowych, które one spełniały. Architektura mikrousług, przeciwnie, rozprzestrzenia się organicznie jako rozsądny sposób na szybsze tworzenie aplikacji i unikanie zbędnych prac. Co istotne, od strony technologicznej korzysta z prostych, standardowych rozwiązań internetowych, zamiast z rozdętych systemów oferowanych przez producentów.

Oczywiście mikrousługi nie są idealnym rozwiązaniem w każdej sytuacji. Jednak jako kolejny etap rozwoju starej idei w wielu przypadkach opisuje metody pracy chętnie stosowane przez deweloperów.


TOP 200