Transformacja cyfrowa i migracja do chmury wymagają nowego podejścia do budowy aplikacji. Muszą one być gotowe do pracy w różnych środowiskach, co wymusza zmiany w architekturze aplikacji i sposobach ich rozwoju.
Biznes domaga się szybszego dostarczania aplikacji. Dla IT to zadanie staje się coraz trudniejsze ze względu na rosnącą złożoność środowisk informatycznych. Oprócz instancji on-premise i kilku typów chmury są coraz częściej spotyka się środowiska mieszane. Z badania przeprowadzonego przez Qualtrics dla Red Hata wynika, że 33% organizacji w swojej strategii nastawia się na wykorzystanie chmury hybrydowej. Inne rozwiązania (chmura prywatna, publiczna, multicloud) mają od 10 do 13% wskazań, a 16% przedsiębiorstw dopiero przygotowuje swoją strategię chmurową.
„Widać wprawdzie wiodącą strategię, nakierowaną na chmurę hybrydową, ale na obecnym etapie obraz jest bardzo rozproszony. Jeśli weźmiemy dla przykładu dziesięć największych banków w Polsce, to rozmowy z przedstawicielami ich zarządów jasno pokazują, że w każdym przypadku ta strategia jest nieco inna” – przyznaje Adam Wojtkowski, szef Red Hata w Polsce.
Chmura tworzy wyzwania dla developmentu
Techniczne uwarunkowania, które wpływają na wytwarzanie oprogramowania, bardzo silnie zmieniły się w ciągu ostatnich kilku lat. Wojciech Furmankiewicz zwraca uwagę, że objęły sam proces budowy aplikacji poprzez wykorzystanie metodyk Agile i DevOps, zmieniła się architektura aplikacji, coraz bardziej elastyczna, złożona z mikrousług. Aplikacje coraz rzadziej są umieszczane na serwerach fizycznych, ciągle trafiają na maszyny wirtualne, ale wysoką elastyczność zapewniły dopiero kontenery. Środowiskiem uruchomieniowym dla aplikacji staje się chmura, dająca elastyczność, a w modelach hybrydowym i multicloud dużą niezależność od konkretnych dostawców.
Te uwarunkowania, składające się na coraz wyższą dojrzałość IT w organizacjach, wymagają nowego podejścia do budowy aplikacji. „Na przykład we własnym data center nie miało znaczenia, czy działająca aplikacja obciąża procesor w 50 czy w 100%, bo już za niego w całości zapłaciliśmy. W chmurze płacimy za faktyczne obciążenie, więc pojawia się aspekt, jak przygotować aplikację, żeby działała w sposób optymalny” – wyjaśnia Wojtek.
„Chmura faktycznie nie jest wyzwaniem po stronie infrastruktury, ale developmentu” – przyznaje Aleksander Gawroński, który w mBanku odpowiada za infrastrukturę IT. Podejście Lift & Shift (poprawienie i migracja aplikacji do chmury) zdaniem Alka sprawdzi się tylko w specyficznych przypadkach, ale częściej doprowadzi do dużego wzrostu kosztów, zwłaszcza w firmach z dużymi zasobami aplikacji. „Dlatego w naszych planach strategicznych przewidujemy przejście na lekki development i wykorzystanie mikroserwisów, pozbywając się niepotrzebnego balastu legacy. Dokonamy przeglądu wykorzystywanych aplikacji i zdecydujemy, co powinno pozostać jako aplikacja monolityczna w naszym data center, na przykład z powodu kosztu zmian, co unowocześnimy do kontenerów, choć niekoniecznie z przeznaczeniem do chmury, a w końcu co trafi do chmury, a w tym jeszcze będzie dostępne jako SaaS” – tłumaczy Alek.
Kontenery uniezależnią aplikacje od infrastruktury
Przeniesienie wybranych systemów do chmury w mBanku zakończy się po kilku latach. Alek tłumaczy, że dział IT prowadzi normalne prace deweloperskie związane z rozwojem własnych aplikacji (jest ich około 400) i migracja będzie połączona z kalendarzem rozbudowy, żeby nie prowadzić oddzielnie prac nad nowymi funkcjami i przeniesieniem do chmury.
mBank stawia na chmurę hybrydową. Ponieważ trudno obecnie przewidzieć, jakie systemy trafią do instancji prywatnych, a jakie do chmury publicznej, ważną technologią dla rozwoju aplikacji już obecnie stały się kontenery, które uniezależniają oprogramowanie od środowiska uruchomieniowego. mBank korzysta przy tym zarówno z Kubernetes jak i OpenShifta, co wynika z podejścia mBanku do zasadniczych systemów: korzystanie z dwóch odmiennych rozwiązań zmniejsza ryzyko uzależnienia od jednego dostawcy lub jednej technologii.
Migracja do chmury i wynikające z niej zmiany developmentu aplikacji nie są procesami, które można planować w oparciu o konstrukcje teoretyczne – przestrzega Adam Wojtkowski, podając przykład banku, który chciał wykorzystać kontenery pozbawione jakichkolwiek dodatków vendorskich. Właśnie w teorii wydawało się, że to może doprowadzić do powstania aplikacji najbardziej niezależnych od platform uruchomieniowych. W praktyce okazało się, że komponenty łączące kontenery z architekturą, służące na przykład do orkiestracji lub automatyzacji są na tyle wydajne i wygodne, że nie ma sensu z nich rezygnować.
Open Source obniża barierę wejścia
Adam sugeruje inne podejście: skoro duża część narzędzi jest dostępna jako open source, można zastanowić się, kiedy wybrać wersję darmową, a kiedy zdecydować się na zakup subskrypcji. „W przypadku firm z dużymi zespołami developerskimi może okazać się, że subskrypcje pochłonęłyby znaczną część budżetu. Sami zdecydowanie to odradzamy. Jeśli polecamy na przykład OpenShifta do konteneryzacji, to tylko wtedy, gdy taki zakup ma sens. W pozostałych przypadkach można sięgnąć po społecznościowe rozwiązania, z których OpenShift wyrasta” – radził Adam.
Alek Gawroński przyznał, że w mBanku decyzja o zakupie OpenShifta dojrzewała przez kilkanaście miesięcy. „W naszych tabelkach tego zakupu w żaden sposób nie dawało się uzasadnić. Wiedzieliśmy, że to bardzo dobra technologia, dla wielu firm nawet najlepsza, ale droga. Dlatego początkowo weszliśmy w Kubernetes, co z perspektywy czasu było dobrą decyzją. Jednak Kubernetes w zastosowaniach produkcyjnych wymaga dorobienia całego stosu technologicznego, dopisania mechanizmów devopsowych czy do automatyzacji. Trudno znaleźć ludzi, którzy potrafią to zrobić, a jeśli już, to trzeba godzić się na wysokie stawki. Na końcu okazuje się, że to drogo kosztuje. W bezpośrednim porównaniu OpenShift okazuje się rozwiązaniem typu plug & play, z całym stosem technologicznym i wsparciem. Trzeba zawsze przeliczyć, czy ma się siły , żeby robić wszystko samemu, czy kupić rozwiązanie z pudełka i święty spokój. My początkowo zbagatelizowaliśmy ten problem” – przyznał Alek.
„Przepisywanie 400 aplikacji byłoby rzeczywiście absurdem. Podobnie jak Alek uważam, że najlepiej zacząć od przeglądu aplikacji i podzielić je na krytyczne, strategiczne i wspierające, a potem próbować znaleźć złoty środek między developmentem a produkcją. Tu trzeba odpowiedzieć na pytanie: czy pre-prod i produkcja muszą stać na jednej platformie? Dopiero wtedy można zbudować model ekonomiczny, który pokazuje, czy warto w coś inwestować, czy nie albo czy z punktu widzenia konkretnej organizacji coś jest drogie, czy nie” – dodał Adam.
Kultura organizacyjna wspiera sprawny development
Do tworzenia aplikacji nowoczesnych i innowacyjnych nie wystarczy doskonałość techniczna. Potrzebna jest sprzyjająca kultura organizacyjna. „Podstawowym warunkiem jest otwartość, gotowość na przyjęcie dobrego pomysł niezależnie od tego, czy zgłasza go właściciel firmy czy student-stażysta. Najlepsza idea musi wygrywać. Znaczenie otwartości ujawnia się dopiero z upływem czasu, kiedy widać, ile dzięki niej powstaje nowych aplikacji” – podkreślał Wojtek Furmankiewicz.
Bartosz Sornat z Aqua Solution wymienił kilka innych „miękkich” czynników, które podobnie jak otwartość usprawniają budowę aplikacji. To instytucja business ownera, selekcja projektów i transparentność finansowa. „Aspekty miękkie powodują zwykle więcej problemów niż technologia. Na przykład doświadczenie pokazuje, że zainteresowanie działów biznesowych aplikacją często maleje, kiedy wreszcie zostanie ona ukończona. Powołanie business ownera jasno wskazuje, kto ma być odbiorcą” – mówił Bartosz.
Wojtek zwracał uwagę, że otwartość ma też wspływ na bezpieczeństwo. „Otwartość można też rozumieć jako otwarty kod, który jest bezpieczny, dzięki temu, że każdy może go sprawdzić. Błędy i luki zdarzają się wszędzie, ale w otwartym oprogramowaniu społeczność developerów szybko je odnajduje. Jeśli koń trojański byłby przejrzysty, to niczego nie dałoby się w nim ukryć” – przekonywał Wojtek.
