Optymalizacja wydajności usługi ING Banku
ING Bank Śląski
Przebudowa architektury usługi Finansowanie Dostawców z wykorzystaniem mikroserwisó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.
Optymalizacja wydajności w oparciu o mikroserwisy
Finansowanie Dostawców to innowacyjna usługa stworzona wraz z ING Bankiem Śląskim.
Optymalizacja wydajności w oparciu o mikroserwisy
Serwis umożliwia szybkie i łatwe sfinansowanie faktur przed upływem terminu płatności.
Stworzenie usługi "Finansowanie Dostawców"
W 2014 r. w ramach ALEO.com 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".
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.com 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.com 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".
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.com, 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".
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.
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".
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
|
|
| 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.com, a także przeprojektowanie Front-Endu oraz UX dla Finansowania Dostawców.
Możemy pomóc również Tobie. Napisz do nas, a my przeprowadzimy analizę Twoich potrzeb biznesowych i ustalimy, co możemy zrobić, aby poprawić doświadczenia pracowników i klientów Twojej firmy.
Porozmawiajmy. Napisz do nas.