DeCOBOLizacja

Mam ( a właściwie klient ma) milion linii w COBOLu. Klienta to za dużo kosztuje (głównie to, że ten COBOL operuje na Oraclowych tabelach).

Wyliczyłem wstępnie, że przepisanie tego na javę nie opłaca się... zjemy większość budżetu. (cena 5$ za linijkę - wziąłem z różnych prezentacji o takim koszcie (ale raczej nie z sensownych badań - liczba znikąd trochę)).
Automatyczne konwersje. Wiem, że są - ale widziałem wyniki - JOBOL, a nie java.

Może na coś innego niż java?

W zasadzie to nawet chyba największym problem jest Oracle (z którym się ten COBOL łączy).
Może zostawić ten COBOL i spiąć go z Postgresem?

Ktoś ma jakieś doświadczenia? (@Koziołek)

Co dokładnie klienta za dużo kosztuje? Może da się wydzielić logikę z COBOLa, stworzyć osobny serwis, który obsługuje wyłącznie bazę danych, ma jakiegoś ORMa i zrefaktorować bazę danych?

W automatyczne konwertery kodu COBOLa do Javy bym chyba nigdy dobrowolnie nie szedł bo kod powinien reprezentować jakiś model biznesowy, a w przypadku takiego konwertera stracisz cały kontekst i będziesz musiał refaktorować wygenerowany kod tak czy siak.

Problem to koszty. Za tym stoi długa historia zawirowań technologicznych i politycznych. Tony rozwiązań specyficznych, wodotrysków (golden gate, oracle forms, exadata itp)
Generalnie wychodzi, że na dłuższą metę biznes na oraclu się nie spina - trzeba by wszystko od nowa wykupić i wycenić żeby się to spinało, a klient jest już mocno zrażony...

Może da się wydzielić logikę z COBOLa, stworzyć osobny serwis, który obsługuje wyłącznie bazę danych, ma jakiegoś ORMa i zrefaktorować bazę danych?

Oczywiście. Problemem jest skala. (nie Scala). Baz danych jest kilkadziesiąt (schematów i to tłustych - po 100 tabel powiedzmy. Edit: tu popadłem w przesade - takich większych baz jest z 7 typów, reszta to przez multitenancy, podobne schematy z małymi obocznościami). Serwisów są już dziesiątki (głównie w javie). Często grzebią w tych bazach danych bezpośrednio. Z tym, że cała ta reszta jest już jakoś opanowana. Wiemy co mniej więcej zrobić, trochę już just zrobione/ poprawione.
Tylko ten COBOL to taki nie bardzo ruszalny jest (to są kluczowe procesy batchowe ).

Ten milion linii w COBOLu to jak na typowy cobolowy dramat nawet całkiem mało. Ale mi wychodzi nadal, że za dużo na opłacalność migracji.
(Acha google, reddity, so i tym podobne jakoś poczytałem. Temat wałkowany milion razy ;-). Z tego wyszedł mi dość pesymistyczny obraz. Automat bez sensu, ręczne przepisanie za drogie).

A trzeba to od razu wszystko przepisywać? Nie można tylko fragmentami które potrzebują zmian, a to co działa i nie potrzebuje zmian zostawić póki co w spokoju? Przepisywanie w stylu big bang rzadko kiedy się sprawdza, lepiej kroić kawałek po kawałku.

Tak jak napisales. Najwiekszym bolem beda dane. Np. logika oparta na poprzednim/nastepnym "rekordzie" albo wrecz plikowa.

Poza tym COBOL jest bardzo szybki w tym co robi, ale nie jest to przetwarzanie zbiorowe (raczej wlasnie kursorowe), wiec jesli autorzy tej aplikacyjki poszli na skroty to... powodzenia.

1M SLOC + COBOL, to daje średnią złożoność 16.4k punkty funkcyjne (1 FP ~ 61 SLOC dla COBOLa). Przeciętny ziomek w bankowości zrobi 12 FP per month, czyli 1367 osobo-miesięcy (114 osobo-lat, masz robotę do emerytury i jeszcze trochę ;) ) ... Przyjmując stawkę kontraktora 400 EUR/day, to daje jakieś 11.5M EUR. Liczba też trochę z kosmosu, ale jeśli koszty licencji wychodzą np. 2M EUR za Oracle (o co bardzo łatwo..), to taka inwestycja może się zwrócić po 7-10 latach. Biznes jednak często patrzy w horyzoncie <5 lat, więc może być sceptyczny .

1. Koszty licencji mogą boleć - koszt licencji Oracle rząd wielkości większy niż koszt softu, który z tego korzysta

W takich przypadkach warto zrobić optymalizację licencji -> zatrudnić firmę, która z tego żyje i da rady "Ziomki, płacicie za 16 CPU, ale każdy z nich utylizowany jest w 15%, 4 CPU spokojnie uciągnie workload", "Macie włączone ficzery, z których nie korzystacie, a za które płacicie zylion $" etc.

2. Z czego ten COBOL korzysta do łączenia się z bazą? Jest jakoś przyspawany do Oracla grubym klientem? (np. PRO*Cobol)
   Czy może jakoś inaczej?

Jeśli PRO*Cobol, to można się zastanowić nad przeniesieniem procesów batchowych do PL/SQLa (kod w PRO*Cobolu i tak będzie wypchany SQLami).
To jako krok pośredni w przesiadce do Postgresa, którego PG/SQL ma sporą zgodność z PL/SQLem. Przeniesienie czegoś z PRO*... do PL\SQLa jest dużo prostsze, niż noszenie w drugą stronę (mowa o przetwarzaniu danych, a nie opcjach typu "a teraz weź wyślij maila").

3. Paradoksalnie Oracle może pomóc. Dane przerzucamy na Postgresa, stawiamy Oracle Database Gatewaya do Postgresa, klienci łączą się dalej do Oracle, ale rzeźbi Postgres. Oracle robi za taką
   przelotkę. Tyle teoria, trzeba by zrobić rozpoznanie bojem pod konkretny przypadek (ile faktycznie można by zaoszczędzić w ten sposób).

Profit:

• szansa na drastyczne zmniejszenie liczby CPU pod Oracle -> cięcie kosztów licencji
  Minusy:
• złożona architektura
• do postgresa też trzeba mieć support, więc płacimy komu innemu, być może mniej

Wielką niewiadomą jest ta replikacja via Oracle GG.

@jarekr000000: Rozumie ze glownie chcesz sie pozbyc bazy. Pytanie czy nie da sie zrobic analogicznie jakbys chcial np. wyprostowac daty timezony itp w calym systemie. Czyli po prostu zjesc slonia po kawalku. Zaczac od najwiekszej albo najmniejszej bazy (w zaleznosci jak straszny jest ten system). Przemigrowac dane i podpiac redundantnie nowa baze. Tak zeby aplikacja dzialala juz na nowym (ale jednoczesnie robiac wszystko co do tej pory na starym systemie tez, czyli system robi dwa razy ten sam kawalek pracy. Weryfikujemy czy dziala (tak jak to RAID robi) ). I po jakims czasie jak sie "ulezy" sprobowac odlaczyc stary kawalek i przelaczyc sie na nowy. Troche jak testy A/B. Bo obawiam sie ze Twoje pytanie moze byc z gatunku tych gdzie mozesz dostac latwe i proste rozwiazania, ale one beda po prostu zle.

@yarel -z wieloma rzeczami nieźle trafiłeś. Też mi wyszły podobne liczby. Biznes patrzy na 5 lat - dlatego jest problem. (dodatkowo są rzeczy poza cobolem, one dorzucają kolejne miliony do pieca).
Nie mamy Pro*Cobol, ale mamy coś domorosłego co przypomina.
Ten Oracle Database Gateway to coś o czym nie słyszałem - i to ciekawa koncepcja na okres przejściowy.

Oczywiście migracja kawałek po kawałku to ideał - ale mi wychodzi, że jak to będziemy robić to zjemy cały budżet na migrację (a nawet więcej) i jeszcze nadal będziemy płacić za licencję przez te x lat.
... i tego raczej biznes nie puści.

jarekr000000 napisał(a):

Problem to koszty. Za tym stoi długa historia zawirowań technologicznych i politycznych. Tony rozwiązań specyficznych, wodotrysków (golden gate, oracle forms, exadata itp)

To masz problem polityczny, a nie techniczny; proponuje go najpierw rozwiązać. Szkoda życia na pchnie się w taki projekt bez większych szans powodzenia (chyba że długoterminowo chcesz zostać ekspertem w takiej transformacji). Masz bogatego klienta (GG, Exadata), ale pewnie szuka oszczędności na poziomie IT i nie widzi (jeszcze) zysku ze zmiany architektury na taką która da mu dostęp do informacji na których mu zależy na bieżąco (a nie 'po' batchu). Wnioskując z zastosowania Exadata, ktoś kiedyś chciał mieć te dane 'tu i teraz'.

Technicznie, dowrzucasz warstwę (zaskoczenie, co nie?) - opakowując bazy i GG jakimś JMS cache (Ignite?). Takie sobie jezioro danych robisz (tylko trzeba uważać aby się w nim nie utopić). Jeśli możesz, próbujesz C-warstwę w to wpiąć. Teraz zadanie po zadaniu przerzucasz z C-batch do albo Java-batch, albo już docelowej architektury (wszystko na się generować na bieżąco?) Jakaś Kafką albo inna sikorką pewnie się trzeba będzie wesprzeć, jeśli masz podobne bazy danych to może jednak Cassandra byłaby tu lepsza, a nie duplikowanie podobnych schémas w osobnych instancjach Postgre? Przez cache dane piszesz do nowych i legacy instalacji, powoli te starsze ubijając.
Jak już się zabierzesz za analizowanie tego batch'a to się okaże, że są tam zadania których już nikt nie potrzebuje (można je wywalać w trakcie gdy trwa przepisywanie do Java). Są też takie które będzie trzeba po prostu napisać od nowa dopasowując to do nowej architektury. Tego nie będziesz wiedzieć, aż zabierzesz się za projekt więc nie ma co szacować na podstawie link kodu, etc.

Wracając do twojego problemu, nie ma co tego sprzedawać po koszcie samej IT transformacji, choć może budżet / dochody muszą gdzieś spalić lub możesz rozmawiać tylko z jakimś CIO z działu IT (lub, lub ... I zniknął w chmurze niewiadomych). Trzeba się dowiedzieć po co im ten system, co chcą osiągnąć i przy jakim budżecie.