Mentionsy

Sponsorem odcinka jest mBank SA.

Nazywam się Krzysztof Kępiński, tworzę ten podcast, napisałem też książkę Marka osobista w branży IT i lubię jak ludzie z naszej branży rozwijają się z głową, a nie na oślep.

Cześć, moim waszym gościem jest IT Deputy Director w mBank SA, doświadczony deweloper i architekt oprogramowania, lider zespołu i menadżer w mBanku, z którym związany jest zawodowo od kilkunastu lat.

Dobrze, to chciałbym Cię właśnie poprosić na wstępie, żebyś opowiedział o tym dużym, wówczas tajemniczym projekcie, który zajawiłeś podczas naszej ostatniej rozmowy, projekcie Houston, czyli dużej zmiany technologicznej w części korporacyjnej mBanku.

Ale na końcu okazało się, że to jest taka pełna transformacja w obszarze core banking w części korporacyjnej, bo to jest migracja całego kodu źródłowego systemu ze starych technologii, mieliśmy taką technologię JBasic, do dotneta, bazy danych ze starej technologii JBase do Postgresa, to też migracja User Interface i User Experience, zupełna poprawa, zmiana ze starego Visual Basic

którego na szczęście nawet nie mieliśmy kodów, do nowoczesnej aplikacji webowej, angularowej, gdzie nasz pracownik banku, bo to jest aplikacja używana przez pracownika banku, to jak każdy cywilizowany człowiek jest w stanie wysłać sobie link do danej transakcji, do danego obiektu, w starym systemie to było niemożliwe.

o tym też będę mówił, więc w zasadzie zmieniło się wszystko w obszarze core banking.

Ta stara zupełnie nie funkcjonuje, nie sprawdza, nie weryfikuje danych i w ogóle ten disaster recovery to jest w ogóle dramat.

Więc to jest język programowania i baza danych i cały runtime, który jest pod spodem, który w zasadzie musimy wymienić.

Więc jakby sama definicja problemu.

Więc założyliśmy, że bez testów automatycznych, bez podejścia do tego, jak zweryfikować, że ten system tak samo dobrze i tak samo źle działa, no bez tego nie mamy szans się wdrożyć.

To na pewno mniejsza liczba transakcji niż w części detalicznej.

Poza taką naturalną konsekwencją obsługi dużych firm, czyli czasami kilkadziesiąt tysięcy przerawów od jednego klienta na raz, mamy na przykład międzybank, czyli obsługę rachunków banków zagranicznych, banków polskich.

I to jest czasami kilka tysięcy przerawów dziennie, ale na kwotę około 150 miliardów polskich złotych.

I to są te zasady, które rządzą korporacją.

Tutaj mamy dużych klientów, mamy duże transakcje i do tego duży wpływ na rynek bankowy w Polsce.

Często ważne było, żeby raz dziennie dany proces uruchomił się, przetworzył dwie transakcje.

Najgorsze były te obszary, które faktycznie przez dawę, od dawna nie były dotykane i modyfikowane i w zasadzie wkraczaliśmy tam znowu po raz pierwszy.

W zasadzie można byłoby powiedzieć, że Houston był programem, który zaczął się 9 lat temu.

Błąd w kodzie, ale takim starym kodzie, który był niedotykany przez pewnie 20 lat, jeszcze nawet nie napisany w Polsce, spowodował, że w wyniku innych naszych rozwiązań, które się toczyły i zaczęły działać w systemie produkcyjnym, mieliśmy duży problem, duży błąd w systemie, który potem sprzątaliśmy.

Mamy monolit, który jest posadzony na jednej maszynie i mamy jakiś disaster recovery, które na szczęście nie musimy z niego korzystać.

Jeśli chodzi o obszary, w których my pracowaliśmy, no to dotknęło na końcu całego IT, który pracuje z częścią kooperacyjną, no bo dotknęło samego systemu centralnego zespołów deweloperskich.

to jest też coś, co spowodowało, że zarówno z Kubernetesem, jak i z nowoczesną bazą danych, nasze disaster recovery jest, liczy się w minutach, możemy spać spokojnie, wiemy, że ten element infrastruktury działa poprawnie.

Tak, o disaster recovery mówiłem, to jest bardzo ważny element, coraz bardziej ważny element, szczególnie gdy zaczynamy się rozpraszać.

Mamy takie narzędzie, które zbudowaliśmy zaraz na samym początku Houstona, które miało za zadanie wycisnąć z organizacji testy automatyczne.

I zrobiła to w narzędziu, zrobiła to ustawiając odpowiednie parametry transakcji w ciągu godziny, weryfikując różne możliwości, bo miała możliwość eksperymentowania, bez tego, co do tego momentu było takim naszym

Tak, i teraz to, co jest jeszcze ważne, bo to architektura nie jest dla samej siebie, ona jest po coś.

Trzeba wziąć pod uwagę, że przez te 9 lat ten ruch transakcyjny w banku urósł znacząco.

W ostatniej fazie to były setki ludzi z biznesu, którzy razem z nami to weryfikowali, zachowali systemu, testowali, pomogli nam zrobić Big Bang i wdrożenie, więc na samym końcu to był olbrzymi zespół, który dołożył kropeczkę

I nie zawsze było tak, jak jest teraz, że piszemy testy automatyczne, że mamy ich coraz więcej, umiemy pisać dokumentację i piszemy to jeszcze w nowożytnym języku, który daje się jakoś ustrukturyzować.

Więc duża praca w niepewności, czy to zachowanie, które obserwujemy, to była intencja dewelopera 10 lat temu, czy może to jest bug, który stał się featurem, czy może to jest coś, co nas może uderzyć w przyszłości, bo do tej pory nie było takiej transakcji.

Bylibyśmy dwa, trzy, pięć lat wcześniej tak naprawdę i chyba tego byśmy nie uzasadnili, dlaczego tak długo nad tym pracujemy.

W ogóle ta translacja to jest niesamowita rzecz, która się wydarzyła.

No i na końcu efekt mamy taki, że jeśli kod był napisany przez normalnego dewelopera, który troszeczkę wie o kodowaniu, to ładny kod w JBasicu był ładny w dotnecie, a ten brzydki nadal jest brzydki.

Teraz nam się dopiero otworzyły drzwi współpracy z firmami zewnętrznymi, no bo Postgresa zna kilka firm na rynku.

Kubernetes tak samo.

Sam J-Basic, tylko że w nowszej formie w Stanach Zjednoczonych jest językiem, który jest rozpoznawany, ale w zupełnie nowszej wersji, nie to, co u nas funkcjonuje od 2004 roku.

Jak za pięć lat sprawdzić ten moduł, który właśnie napisałeś?

ale większość zespołu, która pracowała, po prostu przeszła na nowe technologie, chociażby pod pretekstem pisania testów automatycznych, już dawno, dawno temu i dla nich to nie był problem.

Na samym końcu taka rzecz, która nas jakby spowodowała w ogóle, że to się wszystko udało, to są testy porównawcze.

Udało się rozwiązać tak naprawdę te zależności i zrobić to w ten sposób, żeby to testy porównawcze tych 600 procesów, które działają w trakcie dnia w systemie, żeby były miarodajne i żeby pokazać, że faktycznie to zachowuje się bit do bita tak samo jak w starej technologii.

Ale tak, to są te podstawowe zasady, mierzenie.

Mieliśmy zespoły, które zajmowały się i systemem centralnym, i systemami na około, które były opisane w .net czy w C++.

Klasyczny opór przed zmianą jest nowy, wygląda tak samo, ale jest nowy, więc może trochę bez sensu z tego korzystać.

I tak samo chyba ważne to jest z perspektywy zarządzających, że to był projekt, który wyrywał się wszelkim ramom.

Bo my nie dość, że trwaliśmy 9 lat, to jeszcze 9 lat bez zmiany nazwy, bo to jest taka sztuczka czasami zmienić nazwę projektu i wtedy będzie wiadomo, że jest nowy projekt, 2 lata trwa.

W zasadzie tak można sobie pomyśleć, że to nie był projekt, bo projekt to znaczy jakąś roadmapę, jakiś milestone.