Migracja na Spring Boot w banku inwestycyjnym

Z powodzeniem dokonaliście migracji na Spring Boot w dużym banku inwestycyjnym.

Robert Kapała: Tak, przekształciliśmy system korzystający z wielu różnych, niespójnych serwerów aplikacyjnych w proste rozwiązanie oparte o samodzielne moduły, zbudowane za pomocą Spring Boot i Java 8.

Piotr Gwiazda: Migracja trwała w sumie prawie 15 miesięcy, ale to nie był nasz główny cel projektu. Dostarczaliśmy nową część systemu, natomiast migracja stała się koniecznością w międzyczasie. Okazała się jednak bardzo dużym sukcesem, który umożliwił pracować jednocześnie na starym i nowym systemie. Polegała na przeniesieniu dwóch części systemu na środowisko Javy 8 i komponenty oparte na Spring Boot. Pierwsza cześć działała na Javie 6 i serwerze WebLogic. Druga – na Javie 7 i serwerze JBoss.

Robert: Otworzyło to przed nami ogromne możliwości: uprościło całą naszą infrastrukturę i przyspieszyło deployment na produkcji – z kilku godzin do jednej.

Piotr: Zgadza się, choć zaznaczmy, że masz tu na myśli proces releasowania – bo sam deploy trwa teraz kilka minut.

Robert: Przyspieszyło to nasz lokalny deployment: na WebLogicu nie byliśmy w stanie deployować aplikacji lokalnie – na Spring Boot jest to możliwe. Dzięki tej migracji nasza normalna, codzienna praca stała się zdecydowanie szybsza.

Co sprawiło, że zdecydowaliście się na Spring Boot?

Robert: Spring Boot umożliwia łatwe tworzenie niezależnych, samodzielnych microserwisów. Mogą być deployowane jako pojedynczy, wykonywalny plik .jar. Zrywa z potrzebą utrzymywania serwerów aplikacyjnych jako środowiska uruchomieniowego – serwer web jest częścią integralną (do wyboru Jetty, Tomcat, Undertow). Serwer jest aktualizowany tak samo jak każda inna zależność. Dzięki tym wszystkim funkcjonalnościom Spring Boot powoduje, ze bardziej skupiamy się na samej aplikacji, niż na rzeczach dookoła niej.

Piotr: Główną cechą Spring Boot, która zdecydowała o jego implementacji jest elastyczność. Stanęliśmy przed następującym problemem: mamy kod, który datuje się wstecz nawet do 2002 roku, i jednocześnie mamy całkowicie nowe moduły stworzone przez nas – jak uruchomić to wszystko na jednej platformie? Przeanalizowaliśmy obecne zależności, biblioteki i frameworki, oraz te przejęte kawałki kodu. Niektóre rozwiazania są oparte na bardzo starych czy wręcz egzotycznych frameworkach. Nie było mowy ich migracji, ponieważ caly czas ktos z nich korzysta. Dodatkowo nie ma możliwości, żeby uruchamiać te frameworki na współczesnym kontenerze JEE. Doszliśmy do wniosku, że Spring Boot jest na tyle elastyczny, że pozwoli wymienić komponenty potrzebne do uruchomienia ze starymi komponentami i ukryć cały poziom skomplikowania tych starych aplikacji pod pewnym poziomem abstrakcji. Dostępna liczba „starterów” dla Spring Boot powoduje, że staje się to bardzo proste.

Robert: Piotrek zadał w tym momencie pytanie do całego zespołu: w którą stronę chcemy iść, jaką platformę wybrać? Ja osobiście zaczałem się interesować tematem Spring Boota i obejrzałem kilka prezentacji Josha Longa – a te po prostu trzeba zobaczyć, żeby zrozumieć co dają. Można więc powiedzieć, że jest tu pewien element tzw. hype’u – toteż, aby nie podjąć pochopnej decyzji technicznej, postanowiliśmy zacząć od przygotowania dem, żeby zobaczyć jak Spring Boot sprawdza się na mniejszym, pokazowym przykładzie. Kolejnym etapem była próba podważenia tej decyzji przez cały zespół – każdy starał się znaleźć jakieś słabe punkty. A jeżeli takowe były – doczytać, douczyć się i upewnić się, że dobrze rozumiemy tę technologię. Lista zastrzeżeń została w ten sposób całkowicie wyczerpania i wiedzieliśmy, że to dobre podejście.

Piotr: Bardzo szybko wyeliminowaliśmy serwery aplikacyjne – z trzech głównych powodów:

  • Serwer aplikacyjny to middleware który trzeba utrzymywać. W idealnym świecie, serwery aplikacyjne powinny być dostarczane, supportowane, a zespół developerski powinien na nich tylko uruchamiać swój kod. Ale nie żyjemy w świecie idealnym i nikt nie chce tych serwerów aplikacyjnych utrzymywać – to trochę taka, nie do końca jasno współdzielona odpowiedzialność. To z kolei często prowadzi do niezgody między zespołami operations i development. A skoro nikt nie chce tego utrzymywać, to może lepiej w ogóle z nich zrezygnować?
  • Znaczne zwiększenie nakładu pracy — zadanie mogłoby się okazać niemożliwe kosztowo – np. w związku z uruchamianiem pewnych bibliotek na JBossie. Mówię to mając doświadczenia z różnymi wersjami JBossa i serwerami aplikacyjnymi.
  • I wreszcie powód oczywisty – koszt licencji. A ten, zarówno w przypadku WebLogic jak i JBossa, nie jest pomijalny. Naturalnie był to argument istotny dla klienta.

Przeprowadzona przez Was migracja dotyczy systemu w banku inwestycyjnym. Pod względem developerskim jest to z pewnością specyficzne środowisko.


Piotr:
Tak, to nie była migracja 1:1 na zasadzie: zdejmujemy kod z serwera i uruchamiamy na Spring Boot – system musiała być podzielony na mniejsze moduły i migrowany kawałkami. To jest podstawowe wyzwanie w pracy dla banku inwestycyjnego – nie możemy powiedzieć: „słuchajcie, zatrzymujemy świat, zatrzymujemy development i robimy migrację”. Często pracujemy na aplikacjach krytycznych, ale z drugiej strony nie możemy sobie pozwolić na przestój w rozwoju – jeśli jakaś funkcjonalność jest potrzebna, to trzeba ją wprowadzić. Dlatego kluczowa jest płynność – wszystko musi odbyć się bez dłuższego zatrzymania samego systemu.

Robert: Banki inwestycyjne to z pewnością specyficzne środowisko. I choć często jest tak, że oprogramowanie nie są najświeższe, to z drugiej strony bywa wolne od błędów, ponieważ było używane wystarczająco długo, żeby wyeliminować wszystkie błędy. Dlatego migrując daną aplikację musimy mieć pewność, że ona będzie działać – że nie zmienimy jej zachowania. Jej działanie może być krytyczne dla banku.

Piotr: Generalnie rzecz biorąc, trzeba mieć otwarty umysł. To, że dany system działa w jakiś niespotykany sposób może tak naprawdę wynikać z tego, że inna, równie stara i równie nietypowa aplikacja świetnie z nią współpracuje – i to od wielu lat. Nie wszystko co wygląda podejrzanie musi być złe – bardzo możliwe, że ktoś po prostu korzysta z danego rozwiązania w specyficzny sposób.

Jeśli chodzi o software, panuje przekonanie, że duże banki są pełne archaicznych, nieefektywnych rozwiązań, i że pozostają niechętne nowym technologiom.

Piotr: Ja bym chciał w tym miejscu zerwać z pewnym stereotypem. Oczywiście w banku inwestycyjnym wiele systemów jest starych. Tyle, że te systemy zarabiają pieniądze, i niezależnie od tego jak bardzo ktoś lubi nowe technologie, głównym ich celem jest zarabianie pieniędzy, a nie zabawa z nowymi technologiami. Dlatego trzeba przestawić się na następujący sposób myślenia: dla banku inwestycyjnego oprogramowanie to nie jest wartość, tylko koszt. Jak rachunek za prąd. Musisz go zapłacić żeby wykonać swoją pracę – nie dasz rady bez prądu, tak jak nie dasz rady bez oprogramowania. Celem software’u jest zaspokojenie potrzeb biznesowych – i jeśli znajdziemy argumenty, żeby te koszty zmniejszyć, to zawsze będą to dobre argumenty.  

Dlatego w banku inwestycyjnym bardzo dobrze działa słowo „wydajność”. Nie mówię tu wyłącznie o wydajności systemów, ale o tym jak płynnie wprowadzać potrzebne zmiany i w jaki sposób tanio dostarczać nowe funkcjonalności. Tu właśnie mamy do czynienia z tym stereotypem, z którym chciałbym zerwać – choć bankowość nie jest gałęzią, która poprosi nas o wprowadzenie nowych technologii (choć ma też takie obszary), to na pewno nie jest na nie zamknięta. Trzeba po prostu przedstawić dobre argumenty i udowodnić, że te nowe technologie przyniosą wymierne korzyści.

Czy wobec tego przekonanie klienta do przejścia na Spring Boot wymagało dużo wysiłku z Waszej strony?

Piotr: Wbrew pozorom nie – bo przedstawiliśmy dobre argumenty. Klient sam rozumiał, że niektóre z używanych technologii są przestarzałe, czy nawet u kresu utrzymywalności. Jednocześnie pojawiły się pewne problemy licencyjne i jasne było, że trzeba znaleźć jakieś rozwiązanie. Naszą rolą było popchnięcie tego dalej – zamiast przenosić się z jednej starej technologii na inną starą technologię – i za chwilę znów być w tym samym miejscu z tym samym problemem – zaproponowaliśmy rozwiązanie, które pozwoli aktywnie rozwijać przejętą aplikację jako żyjący kawałek oprogramowania, a nie relikt przeszłości.

Robert: Kluczem było zdobycie zaufania ze strony klienta, a jak wiadomo, zaufanie ma w tej branży fundamentalne znaczenie. Jak wspomniał Piotr, cały proces migracji wykonywany był małymi krokami. Przenosimy jeden fragment systemu, upewniamy się, że on działa, i dopiero wtedy idziemy dalej. Żeby zdobyć zaufanie banku, musieliśmy zapewnić, że cały proces jest wspierany od początku do końca. Nie mogło być tak, że w momencie pojawienia się jakiegoś problemu podczas wdrożenia to już nie interesowało developerów. Musieliśmy upewnić się, że nowa wersja będzie poprawnie funkcjonować na produkcji.

Migracja na Spring Boot - dobre praktyki

  • Metoda małych kroków Przede wszystkim skupmy się na tym, żeby dany moduł przenosić na raz i nie starać się robić innych operacji w tym samym kroku – to się może skończyć bardzo źle. Jeżeli przenosimy dany kawałek, upewniamy się, że wszystko działa poprawnie i dopiero wtedy przechodzimy do kolejnego kroku.
  • Migracja przede wszystkim Jeżeli robimy migracje i bierzemy dany moduł „na warsztat”, to bardzo kuszące staje się dokonywanie w nim zmian i usprawnień. Starajmy się tego nie robić: wykonujemy minimum pracy potrzebnej, aby dokonać migracji. Uporządkowania lepiej dokonać w kolejnym kroku – gdy już działamy na Spring Boot i kiedy pierwszy moduł jest na produkcji. Wówczas wprowadzanie zmian jest i łatwiejsze, i bezpieczniejsze.
  • Ryzyko Zawsze pamiętaj o ryzyku. Jest to pojęcie równie ważne jak zysk. Gdy dokonujemy migracji nie tyle warto, co wręcz trzeba oddzielić release’y infrastruktury od releasów funkcjonalności! Czyli jeżeli dostarczamy migracji infrastruktury – nie wprowadzamy żadnych zmian funkcjonalnych. Jeżeli w danej wersji wprowadzamy funkcjonalności, nie ruszamy infrastruktury. Mieszanie tych procesów to recepta na masę problemów.
  • Rollback Zawsze warto mieć dobry rollback plan. Może okazać się – zwłaszcza w takim miejscu jak bank inwestycyjny – że systemy są ze sobą gęsto połączone, że jest ich wiele i trzeba przygotować się na sytuację, w której któryś z nich przestanie współpracować – nawet jeśli początkowo wszystko wyglądało dobrze. 
  • Testy Priorytetem powinno być też opracowanie testów automatycznych. Dla przykładu: mieliśmy do opracowania moduł, który takich testów nie miał wcale. Przed migracją zdecydowaliśmy, że pierwszym krokiem będzie dopisanie testów. Gdy rozpoczęliśmy migrację okazało się to strzałem w dziesiątkę. Ta sama technologia użyta w nowym środowisku uruchomieniowym dawała nieco inne rezultaty. Dzięki testom udało się nam namierzyć wszystkie problemy i uzyskać pewność, że moduł działa dokładnie tak jak przed migracją.
  • Trudne początki Warto mieć świadomość faktu, że migracja pierwszego modułu może być nieco dłuższa niż całej reszty – obowiązuje tu pewna krzywa uczenia się: przyswajamy nowe technologie, poznajemy całą infrastrukturę itd. Natomiast jeżeli sumiennie wykonamy pierwsze kroki, to cała reszta szybko się zwraca i kolejne moduły migruje się znacznie łatwiej.
  • Cieszcie się sukcesem! Gdy wychodzi nowa funkcjonalność, którą widać na ekranie, użytkownicy mówią: „Tak, jesteśmy zadowoleni, ułatwia to naszą pracę, podoba nam się” itd. W przypadku zmian infrastruktury niestety nikt tego nie zauważa – ponieważ dobre zmiany w tej materii są przezroczyste. Zespół developerski powinien jednak w jakiś zauważalny sposób celebrować to, że udało się zrobić coś fajnego. O ile pamiętam, na twitterze pojawiło się zdjęcie naszego tortu „Goodbye WebLogic & Java 6!” – to był fajny znak dla świata, że idziemy na przód, i że faktycznie udało się coś zmienić.
Success cake!

W tym miejscu bardzo chcielibyśmy podziękować wszystkim w zespole – bo to nie była tylko nasza praca, ale też całego zespołu. Nawet jeśli ktoś nie robił konkretnych zmian w kodzie pod kątem migracji, to cała reszta zespołu w tym czasie zajmowała się funkcjonalnościami. Wielkie dzięki dla: Piotra Kosmowskiego, Bartek Stasikowskiego, Paweł Możdżonka, Pawła Korusa i Michała Wasiaka!

Piotr Gwiazda & Robert Kapała