Optymalizacja wydajności w oparciu o  mikroserwisy

ING Bank Śląski

Jak przebudowaliśmy monolityczną architekturę usługi Finansowanie Dostawców

Aby odpowiedzieć na lawinowy wzrost liczby użytkowników, przeprowadziliśmy dużą transformację technologiczną.

O kliencie

ING Bank Śląski należy do holenderskiej grupy finansowej ING, która działa w ponad 40 krajach i zatrudnia 54 tys. ludzi.

W ramach długoletniej współpracy z ING Bankiem Śląskim realizujemy liczne projekty IT. Od kilku lat pracujemy nad największą bazą informacji o firmach w Polsce – ALEO.com. Jej użytkownicy mają dostęp do danych rejestrowych, dokumentów finansowych czy też sprawdzonych opinii i ocen klientów. Dodatkowo mogą korzystać z narzędzi zakupowych oraz sprzedażowych, a dzięki nim usprawniać procesy w swoich firmach.

Klient
ING Bank Śląski

 

Zobacz online

Stworzenie usługi "Finansowanie Dostawców"

W 2014 r. w ramach Aleo stworzyliśmy z ING Bankiem Śląskim innowacyjną na polskim rynku usługę Finansowanie Dostawców, opartą na modelu faktoringu odwróconego. Pozwala firmie na szybkie i łatwe sfinansowanie wybranych faktur przed terminem płatności. Dzięki zleceniu faktury do finansowania, dostawca błyskawicznie otrzymuje zapłatę po zrealizowaniu zamówienia, zaś odbiorca może opłacić fakturę w dogodnym, późniejszym terminie.

"Finansowanie Dostawców było pierwszym produktem bankowym dostępnym poza bankowością elektroniczną - na otwartej platformie Aleo.com".

Anna Sobotnik

Product Owner Finansowania Dostawców na Aleo.com

ING Bank Śląski S.A.

"Budując aplikację skupialiśmy się głównie na tym, by w jak najkrótszym czasie dostarczyć użytkownikom działającą funkcjonalność, pozwalającą na elastyczne dopasowywanie finansowania do potrzeb kupujących i sprzedających" - mówi Anna Sobotnik.

Wówczas naszym wspólnym celem było maksymalne skrócenie czasu wprowadzenia na rynek usługi „Finansowania Dostawców”. Szybki start oraz sprawdzenie potrzeb rynku przedłożyliśmy ponad skalowalność aplikacji. W praktyce aplikacja wytrzymywała jednak i tak dużo większy ruch i wolumen przetwarzanych faktur niż pierwotnie założyliśmy.

Potrzeby technologiczne związane z rozwojem biznesu

Między 2014 a 2017 r. liczba faktur obsługiwanych przez system wzrosła o rząd wielkości i stale rosła. Usługa „Finansowanie Dostawców” rozwijała się bardzo szybko, ale lawinowy wzrost liczby klientów miał też skutek uboczny - stopniowy spadek wydajności aplikacji. Regularnie monitorowaliśmy stan systemu, jednak ówczesna architektura systemu pozwalała nam jedynie na ograniczone skalowanie wertykalne. Biznes oczekiwał zaś efektywnego i niedrogiego skalowania, aby przygotować się na obsługę jeszcze większej ilości użytkowników. Jednocześnie oczekiwał, że równolegle będziemy rozbudowywać system o kolejne funkcje, co pomoże pozyskać kolejnych klientów.

Dlatego musieliśmy dopasować rozwiązania technologiczne do nowej rzeczywistości biznesowej - sukcesu Aleo i “Finansowania Dostawców”.

Dekompozycja architektury monolitycznej

Kluczową przeszkodą dla rozwoju technologicznego platformy była monolityczna architektura, w której podział domen biznesowych był realizowany na poziomie wewnętrznych komponentów jednej, dużej aplikacji. Dlatego postanowiliśmy wyodrębnić z Aleo usługę „Finansowanie Dostawców” według koncepcji architektury mikroserwisowej, wydzielając jej domenę i procesy biznesowe do dedykowanych systemów (mikroserwisów). Trzeba było również stworzyć nowy model danych. Zmiany dotyczyły całego systemu, w tym jego rdzenia.

W ten sposób chcieliśmy osiągnąć 2 cele:

umożliwienie obsłużenia stale rosnącej liczby klientów i transakcji finansowych.

wyeliminowanie ograniczeń wydajnościowych.

"Zdecydowaliśmy się na migrację do mikroserwisów, co pozwoliło nam uzyskać większą elastyczność wydajnościową i skalowalność, dodatkowo usprawniając procesy implementacji rozwiązań na środowisku produkcyjnym. Przy skali, którą osiągnęły Aleo.com i Finansowanie Dostawców ma to ogromne znaczenie".

Anna Sobotnik

Product Owner Finansowania Dostawców na Aleo.com

ING Bank Śląski S.A.

"Ze względu na ciągły rozwój Finansowania Dostawców w obszarach biznesowych, przechodziliśmy na architekturę mikroserwisową małymi krokami, realizowanymi obok rozwoju funkcjonalności" - podkreśla Anna Sobotnik.

Elastyczne skalowanie dzięki mikroserwisom

Na całym świecie giganci technologiczni przebudowują swoje aplikacje na ekosystem mikroserwisów. Z tego rozwiązania korzystają m.in. Netflix, Amazon, Uber, eBay czy Spotify. Dlaczego? Ponieważ mikroserwisy pozwalają sprawniej wprowadzać zmiany i reagować na potrzeby biznesowe.

W architekturze mikroserwisów wprowadzenie nowej funkcji odbywa się przez zmianę jednego z istniejących mikroserwisów. Dlatego wdrożenie sprowadza się często do wdrożenia tylko jednego mikroserwisu, bez ingerencji w całość aplikacji. Jest to proces prostszy i szybszy w porównaniu do monolitu, ponieważ nie trzeba w nim sprawdzać funkcjonowania całej aplikacji - wystarczy jedynie przetestować zmodyfikowany mikroserwis. Zmniejszamy również ryzyko błędów regresji, ponieważ testy weryfikujące automatycznie poprawność działania danej funkcji zostały napisane jeszcze zanim ona powstała.

Po migracji do mikroserwisów, klient zyskał możliwość elastycznego skalowania aplikacji. W przypadku, gdy „Finansowanie Dostawców” jest intensywniej wykorzystywane, zamiast skalować całą infrastrukturę Aleo, wystarczy zadbać jedynie o przeskalowanie mikroserwisów związanych z tą usługą. W praktyce oznacza to znaczną redukcję kosztów związanych z infrastrukturą sieciową, a tym samym oszczędności dla klienta.

W procesie dekompozycji architektury przez cały czas pamiętaliśmy o perspektywie użytkownika końcowego, dlatego równolegle dodawaliśmy do „Finansowania Dostawców” nowe funkcje. Nie chcieliśmy, by przebudowa architektury zahamowała regularne działania odpowiadające na bieżące wymagania biznesowe. Działaliśmy ewolucyjnie: poszerzaliśmy system o nowe funkcje równocześnie zmieniając infrastrukturę. Było to możliwe dzięki zastosowaniu podejścia zwinnego.

Test-Driven Development

W projekcie korzystaliśmy z metody Test-Driven Development (TDD). Zakłada ona, że właściwy kod aplikacji powstaje dopiero wtedy, gdy istnieją testy pozwalające na weryfikację poprawności jego działania, co zmniejsza ryzyko błędów regresji i wspiera wysokie pokrycie kodu testami jednostkowymi, co w efekcie znacznie obniża liczbę szeroko rozumianych błędów aplikacji.

"Dzięki zastosowaniu podejścia Test-Driven Development zaobserwowaliśmy mniejszą liczbę błędów regresyjnych, a to pozwala więcej czasu poświęcić na rozwijanie systemu w oparciu o doświadczenia naszych użytkowników".

Anna Sobotnik

Product Owner Finansowania Dostawców na Aleo.com

ING Bank Śląski S.A.

W TDD cały proces tworzenia aplikacji jest szybszy i bardziej elastyczny. Metodyka zapewnia programistom bezpieczne środowisko do wprowadzania skomplikowanych zmian, co szczególnie ważne w systemach finansowych. Nie trzeba też regularnie ręcznie weryfikować, czy poprzedni i nowo dodany kod aplikacji działają, ponieważ testy wykonują się automatycznie. Oszczędza to również czas, jaki poświęca się na opisanie i zgłoszenie znalezionego manualnie błędu.

Więcej na ten temat w artykule:

Jak TDD obniża koszty: case study

Zobacz więcej

Bartłomiej Kołakowski

Project Manager

Linkedin logo

Scrum

Cały projekt był realizowany w metodyce Scrum, należącej do rodziny metodyk Agile’owych. Dzięki temu Product Owner przez cały czas widział, na jakim etapie są prace, a zespół mógł szybko reagować na pojawiające się nowe potrzeby.

"Stosowanie metodyk Agile zarządzania projektami do wytwarzania oprogramowania kształtuje nie tylko zwinną infrastrukturę informatyczną, ale ma także swój udział w tworzeniu zwinnej kultury organizacyjnej firmy. Przekłada się to na zwinną filozofię myślenia o skomplikowanych zmianach, które można wykonać w sprawny i kontrolowany sposób".

Damian Karpiński

Architekt Systemów

e-point SA

Dążyliśmy do identyfikowania i eliminowania problemów, zapobiegania ich występowaniu w przyszłości oraz wypracowywaniu nowatorskich rozwiązań. Kierowaliśmy się imperatywem ciągłej poprawy, dokonywanej małymi krokami. Podczas retrospektyw cały zespół partnersko poszukiwał pomysłów na udoskonalenie obszarów omawianych na spotkaniu.

Dlatego wykorzystaliśmy wywodzące się z podejścia Lean elementy Kaizen oraz metodę 5 Why (5W), zaczerpniętą z Toyota Production System, która polega na zadaniu 5-krotnie pytania „dlaczego?” po znalezieniu problemu tak, by dotrzeć do realnej przyczyny. Ten mechanizm dobrze zilustrować przykładem.

W fabryce Toyoty pracownik wyrzuca na podłogę trociny...

Pytania  

    Odpowiedzi

1. Dlaczego wyrzuca Pan trociny na podłogę? Ponieważ podłoga jest śliska i zagraża bezpieczeństwu.
2. Dlaczego podłoga jest śliska i zagraża bezpieczeństwu? Ponieważ jest na niej olej.
3. Dlaczego jest na niej olej? Ponieważ maszyna przecieka.
4. Dlaczego maszyna przecieka? Ponieważ olej spływa przez złączkę.
5. Dlaczego tak się dzieje? Ponieważ osłonka złączki się zużyła.

Ta metoda pozwala rozłożyć problem na czynniki pierwsze.

Rezultaty i dalsze plany

Dzięki wprowadzonym zmianom ING Bank Śląski może skoncentrować się na pozyskiwaniu nowych klientów i skalowaniu biznesu. Zaobserwowano 3 kluczowe zmiany:

spadek liczby zgłoszeń serwisowych.

przyspieszenie procesu realizacji zmian.

zmniejszenie ryzyka błędów regresji.

Dlatego wspólnie planujemy dekompozycję do mikroserwisów całego systemu Aleo, a także przeprojektowanie Front-Endu oraz UX dla Finansowania Dostawców.

Podobne case studies