Czy wiesz jak zbudować system, który pozwoli na łatwe i częste dostarczanie użytkownikom nowych funkcji? Czy wiesz co zrobić, aby jedna zmiana nie powodowała niedostępności całej aplikacji? Odpowiedź na te pytania może przynieść wykorzystanie mikroserwisów.
fot. materiały prasowe
Mikroserwisy. Co to takiego?
To usługi, które realizują funkcję z pojedynczego obszaru biznesu (jak np. aktualizacja pozycji ciężarówek na mapie). Nie jest więc mikroserwisem np. cały panel CRM, realizujący różne funkcje. Dodatkowo, przygotowanie jednej mikrousługi powinno trwać nie więcej niż kilka tygodni.
Kiedy warto wykorzystać?
Mikrousługi nie stanowią złotego środka i nie powinny być stosowane w każdym kontekście. W szczególności, przejście na architekturę mikroserwisową stoi pod znakiem zapytania, gdy:
1. Potrzebujemy zbudować szybki prototyp (weryfikacja pierwszej, bazowej hipotezy jak klienci przyjmą zupełnie nową ofertę na rynku, bez potrzeby stosowania najlepszych praktyk – w modelu quick&dirty, gdy produkt w ogóle nie istnieje),
2. Utrzymujemy produkt, który nie będzie już rozwijany,
3. Pracujemy w kilkuosobowym, stacjonarnym zespole, którego członkowie świetnie się znają, a jednocześnie każdy z nich z osobna zna cały system.
… i dlaczego warto po nie sięgnąć, gdy użytkownicy wchodzą drzwiami i oknami
Jeżeli budujemy platformę digitalową dla dużej liczby użytkowników i chcemy ją szybko rozbudowywać, architektura mikroserwisowa jest idealna do sprawdzania jak użytkownicy zareagują na nowe rozwiązania.
1. W architekturze mikroserwisowej wprowadzenie nowej funkcji odbywa się przez zmianę jednego z istniejących mikroserwisów lub dodanie nowego. Wdrożenie zmian sprowadza się zatem często do wdrożenia jednego mikroserwisu. Jest to proces prostszy i szybszy w porównaniu do monolitu, bo nie trzeba w nim sprawdzać funkcjonowania całej aplikacji – wystarczy przetestować dodany/zmieniony mikroserwis.
2. Możliwości skalowania w wybranym obszarze – jeżeli dany mikroserwis będzie intensywnie wykorzystywany, zamiast inwestować w infrastrukturę wspierającą cały system, możemy doinwestować tylko wybrany fragment. W praktyce oznacza to możliwość sporej redukcji kosztów.
3. Łatwiejsze i pełniejsze pokrycie kodu testami automatycznymi. Pozwalają one wcześniej wykrywać i usuwać błędy – a to z kolei przekłada się ostatecznie na skrócenie cyklu wydawania nowych wersji.
–
Jacek Popko
Chief of Consulting RST Software Masters / Founder of Usability LAB
Absolwent wydziału Zarządzania i Informatyki na Uniwersytecie Ekonomicznym we Wrocławiu. Twórca Usability LAB, marki konsultingowej świadczącej usługi doradcze i projektowe dla finansów i bankowości, przedsięwzięć startup oraz e-commerce. Należy do The Interaction Design Foundation oraz ACM: SIG-CHI. Udziela się jako wykładowca i prelegent. Współpracował z Alior Bank, Carrefour, Cisco, Empik, LUX MED, Orange, PGE, PKO, Santander Consumer Bank. Pasjonat UX.
