WebSphere Application Server to komercyjny serwer aplikacyjny IBM, w którym uruchamiane są aplikacje zgodne ze standardem Java EE. Zapewnia im środowisko wykonawcze, zarządzanie zasobami, zabezpieczenia i klastrowanie. Decyzja o nim rzadko dotyczy technologii samej w sobie — dotyczy tego, ile organizacja chce płacić za przewidywalność systemów, które zarabiają już dziś.
Na skróty
Czego dowiesz się z artykułu:
- Jaki rachunek organizacja płaci, zanim w ogóle padnie pytanie o środowisko uruchomieniowe
- Jakie warunki muszą wystąpić razem, żeby utrzymanie serwera aplikacyjnego tej klasy było uzasadnione
- W jakich sytuacjach serwer aplikacyjny przestaje być odpowiedzią na realny problem
- Jakie alternatywy pozostają i jaką cenę niesie każda z nich
- Co organizacja podpisuje na lata, decydując się zostać przy obecnym środowisku
Dla kogo ten artykuł:
- Kierownicy utrzymania odpowiedzialni za środowiska aplikacyjne w modelu Java EE
- Architekci rozstrzygający o kierunku modernizacji systemów, które zarabiają dziś
- Menedżerowie planujący budżet licencji, kompetencji i okien serwisowych
Jaki rachunek płaci organizacja, zanim padnie pytanie o środowisko uruchomieniowe?
Rozmowa nigdy nie zaczyna się od nazwy produktu. Zaczyna się od rachunku, który ktoś już podpisuje: odnowienie wsparcia producenta w budżecie utrzymania, okno serwisowe negocjowane z biznesem z wyprzedzeniem, audytor pytający, kto i kiedy wdrożył konkretną wersję aplikacji rozliczeniowej, oraz kurcząca się grupa osób, które potrafią przeczytać konfigurację środowiska bez cudzej pomocy. Ten koszt jest ponoszony niezależnie od tego, czy ktokolwiek podejmie decyzję — i to on, a nie ciekawość technologiczna, otwiera temat.
Problem ma odmiany, a ich pomylenie jest najdroższym błędem tej decyzji. Pierwsza odmiana to aplikacje, które opierają się na usługach kontenera: transakcje rozproszone obejmujące bazę i kolejkę, pule połączeń, deklaratywne role dostępu, replikacja sesji między węzłami. Systemy tej klasy pracują w bankowości, ubezpieczeniach, rozliczeniach operatorów telekomunikacyjnych i w integracjach wokół systemów ERP — czyli tam, gdzie błąd nie kończy się komunikatem na ekranie, tylko korektą księgową. Tutaj problemem jest utrzymanie gwarancji, których aplikacja sama nie realizuje.
Druga odmiana to presja modernizacyjna. Sprzęt kończy cykl życia, producent publikuje datę zakończenia wsparcia dla wersji, nowy zespół chce wdrażać w kontenerach, a dział bezpieczeństwa pyta o rozdzielenie środowisk. Wtedy pytanie brzmi już nie „jak to utrzymać”, tylko „zostać czy migrować”, a odpowiedź kosztuje w obie strony. Warto zauważyć, że rozstrzyga się tu warstwa, w której wykonuje się kod aplikacji — a nie warstwa, z której zarządza się infrastrukturą; to są rozstrzygnięcia osobne, o osobnych budżetach. Pytania, które w takiej rozmowie wracają najczęściej, zebrano w tekście o migracji aplikacji on-premise do chmury.
Kiedy serwer aplikacyjny tej klasy jest właściwą odpowiedzią?
Utrzymanie środowiska tej klasy broni się wtedy, gdy występują razem trzy warunki, a nie gdy spełniony jest którykolwiek z nich osobno.
- Aplikacja realnie korzysta z usług kontenera. Transakcje obejmujące bazę danych i kolejkę komunikatów jednocześnie, zarządzanie pulami połączeń i deklaratywne bezpieczeństwo to funkcje, których odtworzenie w kodzie aplikacji jest projektem samym w sobie, a nie refaktoryzacją.
- Organizacja potrzebuje wsparcia producenta z określonym czasem reakcji. Gdy niedostępność systemu ma cenę zapisaną w umowie z klientem, możliwość eskalacji do dostawcy środowiska jest częścią odpowiedzi na to ryzyko, a nie luksusem.
- Zmienność aplikacji jest niska, a koszt regresji wysoki. Moduł zmieniany raz na kwartał, obwarowany testami akceptacyjnymi i zgodą regulatora, nie zyskuje na skróceniu cyklu wdrożeniowego tyle, ile traci na przepisaniu.
Gdy te warunki występują razem, utrzymanie serwera aplikacyjnego przestaje być zaległością technologiczną i staje się świadomą decyzją. Zakres kompetencji potrzebnych do prowadzenia takiego środowiska — profile i węzły, konsola administracyjna, administracja skryptowa, zabezpieczenia oraz diagnostyka — obejmuje szkolenie WebSphere Application Server V9 Administration.
Kiedy nie utrzymywać serwera aplikacyjnego tej klasy?
Najczęstszym błędem jest utrzymywanie pełnego serwera aplikacyjnego dla aplikacji, która nie korzysta z żadnej jego usługi. Kod pakowany do archiwum wdrożeniowego, ale obsługujący własne połączenia do bazy, własną autoryzację i własną obsługę sesji, płaci pełną cenę środowiska i nie odbiera z niego niczego poza miejscem, w którym się uruchamia. Decyzja o pozostaniu jest wtedy oparta na rozpędzie, nie na potrzebie.
Drugi przypadek to rytm wydań. Środowisko, w którym zmiana konfiguracji propaguje się przez komórkę i wymaga uzgodnionego okna, ustawia częstotliwość wdrożeń niezależnie od tego, czego chce zespół produktowy. Jeżeli produkt wymaga wdrożeń tygodniowych albo częstszych, to nie aplikacja jest wąskim gardłem, tylko model operacyjny środowiska. Trzeci przypadek to nowy system budowany od zera: wybór serwera aplikacyjnego dla produktu, który dopiero powstaje, oznacza odziedziczenie modelu utrzymania zaprojektowanego dla innego rytmu pracy i innego profilu ryzyka. Żaden z tych przypadków nie znika przez to, że licencja została już opłacona — koszt utopiony nie jest argumentem za utrzymaniem środowiska.
Jakie są alternatywy i ile kosztują?
Najbliższą drogą jest lekki serwer aplikacyjny tego samego producenta, uruchamiany z konfiguracją opisaną w pliku i startujący w czasie liczonym w sekundach; sposób jego konfigurowania opisuje Open Liberty Documentation. Cena tej drogi to weryfikacja, które funkcje kontenera aplikacja faktycznie wykorzystuje, oraz przeniesienie konfiguracji zasobów z konsoli do repozytorium.
Drugą drogą jest oparcie się na samym standardzie zamiast na produkcie. Zestaw specyfikacji publikowany jako Jakarta EE Specifications pozwala przenieść aplikację między implementacjami różnych dostawców, ale ceną jest zmiana przestrzeni nazw pakietów i ponowna certyfikacja integracji z systemami zewnętrznymi. Trzecia droga to przeniesienie całego środowiska do chmury albo na platformę kontenerową; dokumentacja produktowa IBM WebSphere Application Server — product overview opisuje ten wariant jako wspierany, co nie znaczy, że jest darmowy — organizacja kupuje wtedy nową warstwę operacyjną i nowy zestaw kompetencji. Jak wygląda ta droga rozpisana na etapy, pokazuje tekst o strategii cloud native.
Co organizacja podpisuje, zostając przy obecnym środowisku?
Koszt serwera aplikacyjnego nie leży w instalacji, tylko w latach, które po niej następują. Odnowienia wsparcia rozliczane są od mocy obliczeniowej, więc rachunek rośnie razem ze sprzętem, nawet jeśli aplikacja się nie zmienia. Cykl życia produktu narzuca własny kalendarz aktualizacji, niezależny od planu rozwoju systemu, a każda aktualizacja niesie regresję w środowiskach, które testuje się rzadko.
Do tego dochodzi ryzyko kadrowe. Osób, które potrafią odczytać topologię komórki, przeanalizować zrzut pamięci i odtworzyć konfigurację zasobów po awarii, ubywa szybciej niż systemów, które tego wymagają. Organizacja utrzymująca takie środowisko powinna traktować dokumentację topologii i przygotowanie następców jako element planu ciągłości działania, a nie jako zadanie odkładane na spokojniejszy kwartał. Prowadzenie środowiska rozproszonego, w którym komórka obejmuje węzły na wielu maszynach, jest przy tym osobną kompetencją — obejmuje ją szkolenie WebSphere Application Server V9 Administration in a Federated Environment.
FAQ — najczęściej zadawane pytania
Czy serwer aplikacyjny tej klasy jest technologią schyłkową?
Nie w sensie, w jakim to słowo bywa używane. Środowisko jest wspierane produktowo i rozwijane w wariantach kontenerowych, a systemy, które na nim pracują, rozliczają realne pieniądze. Schyłkowy bywa natomiast konkretny sposób jego użycia: pojedyncza komórka utrzymywana ręcznie, bez odtwarzalnej konfiguracji i bez planu następstwa kompetencyjnego. To jest problem organizacyjny, nie produktowy.
Czy przejście na lekki serwer tego samego producenta to ta sama praca co zmiana stosu?
Nie. Migracja w obrębie rodziny produktowej dotyczy głównie konfiguracji i sposobu jej dostarczania, a kontrakt programistyczny pozostaje w większości nienaruszony. Zmiana stosu na inny model programowania oznacza natomiast przepisanie warstwy integracyjnej, ponowne zaprojektowanie transakcji i nową ścieżkę testów. Mylenie tych dwóch prac jest najczęstszym źródłem przekroczeń harmonogramu w projektach modernizacyjnych.
Od czego zacząć ocenę, czy zostać przy obecnym środowisku?
Od inwentaryzacji usług kontenera, z których aplikacja faktycznie korzysta, i od zestawienia ich z kosztem utrzymania zapisanym w budżecie operacyjnym. Jeżeli lista wykorzystywanych usług jest krótka, a rachunek długi, decyzja praktycznie zapada sama. Jeżeli lista jest długa, kolejnym pytaniem nie jest „czy migrować”, tylko „ile kosztuje odtworzenie tych gwarancji gdzie indziej”.