+48 501 250 220

Monolit jako usługa webowa i nowe funkcje budowane obok

Państwa stary system działa i zawiera reguły, których nikt nie chce pisać od nowa. Udostępniamy jego logikę jako usługę webową i jednorazowo zamykamy znane luki. Testy porównawcze sprawdzają, czy działanie pozostaje takie samo, a nowe funkcje powstają obok, w nowym stosie technologicznym.

Zamów przegląd systemu legacy (z oceną gotowości do API) Więcej o usłudze Migracja i modernizacja
  • Od 2015 r. ColdFusion i Lucee w systemach produkcyjnych, od 2012 r. PHP
  • Interfejsy REST i SOAP
  • Odpowiedź w ciągu jednego dnia roboczego
Duży zakreskowany blok z pomarańczowo obrysowanym otworem po prawej stronie; z otworu biegnie pięć cienkich linii do pięciu małych kwadratów

Kiedy stary system warto udostępnić jako usługę webową

Za dalszym korzystaniem ze starego systemu jako usługi webowej przemawiają te trzy sytuacje.

Nowy frontend lub nowa aplikacja mają korzystać z logiki

Państwa stary system oblicza, sprawdza lub tworzy coś, czego potrzebuje też nowy frontend, nowa aplikacja albo nowy partner. Zbudowanie tej logiki drugi raz byłoby drogie, a obie wersje z czasem by się rozjechały.

Raport z testu lub zapytanie klienta wskazuje luki

Profesjonalny test penetracyjny albo kwestionariusz klienta wskazuje podatności, na przykład cross-site scripting lub SQL injection. Przepisanie systemu trwa w takiej sytuacji często latami, a luki powinny zostać zamknięte wcześniej. Jeśli wynik jest pilny albo system nieznany, zaczynamy od oceny awaryjnej w 48 godzin.

Zespół chce nowego stosu, ale reguły są zapisane tylko w kodzie

W starym systemie tkwią reguły, których nikt nie spisał. Gdy wszystko powstaje od nowa, łatwo je zgubić.

Zakreskowany blok, czyli stary system, pośrodku; wskazują na niego trzy powody: nowy frontend jako okno z pomarańczową linią, raport z testu i stos nowych klocków

Jedno wejście do starego systemu, nowe funkcje obok

Stary system pozostaje jednym blokiem i dostaje porządne wejście: API. Nowe aplikacje i frontendy wywołują je i nie zależą od starego kodu.

Tak nowe powstaje krok po kroku obok starego. Specjaliści nazywają to podejście wzorcem Strangler Fig (otwiera się w nowym oknie).

Duży zakreskowany blok z otworem obrysowanym na pomarańczowo, od którego cienkie linie prowadzą do pięciu małych węzłów

Tak działamy: sześć kroków, każdy z pisemnym wynikiem

  1. Przegląd

    Ustalamy, które funkcje stanowią o wartości systemu, na przykład reguły, obliczenia i dokumenty, a które są splecione z interfejsem. Wynikiem jest mapa funkcji: co udostępniamy jako usługę, a co zostaje w starym systemie, wraz z uzasadnieniem.

  2. Jednorazowe zabezpieczenie

    Zamykamy znane luki, dbając o to, by działanie się nie zmieniło, i porównujemy wyniki przed zmianą i po niej. Raport wymienia, co naprawiliśmy, co pozostaje otwarte i dlaczego.

  3. API

    Udostępniamy logikę jako API, w formie REST z JSON albo SOAP z XML, z uwierzytelnianiem, limitem wywołań i rejestrowaniem zdarzeń. Opis zawiera punkty końcowe oraz przykłady zapytań i odpowiedzi.

  4. Nowe obok

    Nowe funkcje powstają w nowym stosie, który wywołuje API. Stary system działa przy tym dalej. Plan ustala kolejność etapów i drogę powrotu, gdyby któryś etap się nie sprawdził.

  5. Zastąpienie tam, gdzie to się opłaca

    Poszczególne części starego kodu zastępujemy dopiero wtedy, gdy koszt ich utrzymania lub zmian przewyższa koszt zastąpienia.

  6. Runbook

    Opisuje, jak prowadzić, monitorować i aktualizować API, także siłami Państwa zespołu lub innego dostawcy.

Pisać od nowa czy wykorzystać jako usługę?

Kryterium Wykorzystać jako usługę Napisać od nowa Zostawić bez zmian
Pasuje, gdy Logika działa i ma wartość, znane luki trzeba zamknąć, a nowy stos ma z niej korzystać. Framework nie jest już rozwijany, nie ma testów, a reguły biznesowe da się spisać. System jest stabilny, działa we wspieranej wersji i nikt nie potrzebuje nowego stosu.
Co się zmienia Jednorazowo zabezpieczamy stary system i dajemy mu API. Nowe powstaje obok. Wszystko powstaje od nowa. Reguły i dane przechodzą do nowego systemu. Nic.
Granica Nie każdy system się do tego nadaje. Pokazuje to przegląd. Do czasu zastąpienia działają dwa systemy, a reguły, których nikt nie spisał, mogą przepaść. Nowe aplikacje nie mogą korzystać z logiki, a znane luki pozostają otwarte.

Czego nie obiecujemy

  • Nie każdy system da się wykorzystać jako usługę. Jeśli logika jest spleciona z interfejsem, najpierw ją porządkujemy. Pokazuje to przegląd.
  • Jednorazowe zabezpieczenie nie jest testem penetracyjnym, certyfikatem ani gwarancją, że nie zostaną żadne luki. Testów penetracyjnych nie wykonujemy. Usuwamy luki, które wskazują raporty albo które znajdziemy podczas przeglądu.
  • To, że działanie się nie zmienia, testy porównawcze potwierdzają tylko dla sprawdzonych procesów.
  • Oszczędność w porównaniu z pisaniem od nowa podajemy dopiero wtedy, gdy przegląd oszacuje nakład pracy.
Rama z trzema prostokątami oznaczającymi to, co wchodzi w zakres; poza nią przerywany prostokąt na to, czego nie obejmuje; odcinek ramy między nimi jest pomarańczowy

Bezpieczny dostęp do starego systemu

API ma być jedynym dostępem do starego systemu z zewnątrz i stać za zaporą sieciową. Na życzenie stawiamy przed nim WAF z regułami dla Państwa aplikacji. To zmniejsza ryzyko, ale go nie usuwa i nie zastępuje usunięcia luk.

Jak zabezpieczamy sieć, serwery i dostęp administracyjny, opisuje usługa Administracja Linux i infrastruktura.

Trzy linie z lewej wchodzą do wąskiej bramki z pomarańczowym konturem; stamtąd jedna linia prowadzi do dużego zakreskowanego bloku, czyli starego systemu

Doświadczenie naszych inżynierów ze starymi systemami i interfejsami

Typy systemów
Platformy do obsługi kredytów, finansowania hipotecznego i leasingu oraz systemy do generowania dokumentów i umów

Jak pracujemy nad Państwa starym systemem

  • Kod, dane dostępowe i dokumentacja zostają u Państwa.
  • Zmiany w starym systemie wprowadzamy dopiero po Państwa akceptacji, z testami porównawczymi i drogą powrotu.
  • Mówimy też wprost, gdy droga przez usługę się nie opłaca.

A co, jeśli u nas ktoś będzie niedostępny? Dokumentację sporządzamy na życzenie. Repozytorium z reguły znajduje się u Państwa. Zastępstwo organizujemy na życzenie.

Więcej na stronach Doświadczenie i Współpraca.

Po lewej kartka z wierszami tekstu i linią podpisu z pomarańczowym haczykiem; strzałka wskazuje serwer narysowany przerywaną linią po prawej

Pierwszy krok: przegląd systemu legacy z oceną gotowości do API

Przegląd systemu legacy

Dla firm z systemem, którego nikt już dokładnie nie zna: przed aktualizacją, przed migracją lub przy zmianie dostawcy.

  • Inwentarz wersji i zależności
  • Mapa aplikacji, bazy danych, serwera i poczty e-mail
  • Rejestr ryzyk dotyczących bezpieczeństwa, wsparcia i wiedzy
  • Ocena kopii zapasowych i odtwarzania danych
  • Rekomendacja „zostać przy obecnej wersji, podnieść wersję lub migrować” z macierzą opcji, która obejmuje także „przeniesienie do kontenera” i „udostępnienie jako API”
  • Oszacowanie nakładu pracy w dniach

Cena obejmuje jeden system, czyli jedną aplikację wraz z jej bazą danych i serwerem. Kolejne systemy wyceniamy osobno.

Co zawiera wynik

Pisemny raport z inwentaryzacją, rejestrem ryzyk, rekomendacją i oszacowaniem nakładu pracy. Raport należy do Państwa.

od 3 800 € netto

Zwykle 5 dni roboczych

Zamów przegląd systemu legacy

Ocena awaryjna w 48 godzin

Dla firm, których programista lub dostawca nagle odszedł, a system musi mimo to działać dalej.

  • Inwentaryzacja: wersje, zależności, dostępy, kopie zapasowe, zaplanowane zadania, źródła danych i wysyłka poczty
  • Lista ryzyk, które wymagają natychmiastowej uwagi
  • Plan stabilizacji na pierwsze 5 dni i na pierwsze 30 dni
  • Krótkie omówienie wyników

Wynik otrzymują Państwo 48 godzin po uzyskaniu dostępu do systemu. Zmiany w systemie produkcyjnym i dalsze prace wykonujemy wyłącznie po Państwa zgodzie.

Co zawiera wynik

Pisemny raport ze stanem systemu, ryzykami wymagającymi natychmiastowej reakcji i planem stabilizacji. Raport należy do Państwa.

od 1 900 € netto

Zwykle 2 dni robocze

Zamów ocenę awaryjną w 48 godzin

Pytania o stary system jako usługę webową

Czy musimy przepisać system, żeby korzystać z nowego stosu technologicznego?

Nie. Jeśli stary system działa, udostępniamy jego logikę jako API i jednorazowo zamykamy znane luki. Funkcje mają przy tym pozostać bez zmian, co sprawdzają testy porównawcze. Nowe elementy budujemy obok, w nowym stosie, który korzysta z tego API.

Przepisanie od nowa rzadko się opłaca. Wchodzi w grę, gdy framework nie jest już rozwijany, brakuje testów, a reguły biznesowe da się spisać. Czy dotyczy to Państwa systemu, wyjaśnia Przegląd systemu legacy.

Czy API zmieni działanie starego systemu?

Celem jest, aby funkcje pozostały bez zmian. Zanim cokolwiek zmienimy, zapisujemy wyniki sprawdzanych procesów, a po zabezpieczeniu porównujemy je ze stanem sprzed zmiany. Dzięki temu odchylenia od razu widać.

Przy oprogramowaniu rozwijanym latami nie da się zagwarantować działania procesów, których nikt nie sprawdził. Dlatego razem z Państwem ustalamy, które procesy się liczą.

Czy tworzą i integrują Państwo interfejsy API (REST, SOAP)?

Tak. Tworzymy interfejsy i podłączamy systemy, zarówno przez REST i JSON, jak i przez SOAP i XML, łącznie z synchronizacją danych między aplikacjami. Typowe zastosowania opisujemy na stronie Rozwój i integracje.

Czy mogą Państwo przejąć system bez dokumentacji?

Tak, do tego służy Przegląd systemu legacy. Najpierw spisujemy to, co istnieje: wersje, zależności, zaplanowane zadania, źródła danych i trasy poczty. Sprawdzamy też, czy kopie zapasowe dają się odtworzyć.

To, że jeszcze nie znamy Państwa systemu, jest normalną sytuacją, a nie przeszkodą. Dopiero na podstawie ustaleń mówimy, czego system potrzebuje i co obejmowałaby bieżąca opieka. Raport należy do Państwa.

Kto utrzymuje stary kod po zabezpieczeniu?

To Państwo decydują. Kod i dokumentacja zostają u Państwa, a dzięki instrukcji operacyjnej (runbook) i opisowi API Państwa zespół lub inny dostawca może pracować dalej.

Na życzenie przejmujemy bieżące utrzymanie w ramach usługi Przejęcie i utrzymanie.

Ile trwa i ile kosztuje udostępnienie starego systemu jako usługi?

Wiarygodną liczbę można podać dopiero po przeglądzie. Czas i koszt zależą od tego, jak wyraźnie logika jest oddzielona od interfejsu, ilu funkcji potrzebują Państwo jako usługi i ile luk trzeba zamknąć.

Przegląd systemu legacy szacuje nakład pracy w dniach roboczych. Potem przedstawiamy ofertę, zanim cokolwiek Państwo zlecą.

Czy potrzebujemy do tego innego serwera?

Zwykle nie. API uruchamiamy na obecnym serwerze albo przed nim, za zaporą sieciową i na życzenie z WAF, którego reguły pasują do Państwa aplikacji.

Jeśli system działa na platformie bez aktualizacji bezpieczeństwa, aktualizacją lub przeniesieniem i tak trzeba się zająć. Przegląd obejmuje także tę kwestię.

Czy WAF wystarczy?

Samodzielnie nie. WAF, czyli zapora aplikacji internetowych, filtruje typowe ataki przed aplikacją i daje czas, ale nie zamyka luki w kodzie. Dlatego łączymy go z usuwaniem znanych podatności, segmentacją sieci i dostępem administracyjnym wyłącznie przez VPN.

WAF z regułami dopasowanymi do Państwa aplikacji wywołuje mniej fałszywych alarmów i zwykle chroni skuteczniej niż konfiguracja domyślna. Jeśli kodu nie da się szybko zmienić, WAF z izolacją systemu jest rozwiązaniem pomostowym do czasu aktualizacji. Ryzyko maleje wtedy, ale nie znika.

Który stary system ma dalej pracować?

Wystarczy podać technologię i wersję, co system robi i co nowego ma z niego korzystać. Odpowiadamy w ciągu jednego dnia roboczego.

Pola oznaczone jako „opcjonalnie” można zostawić puste.

Kontakt e-mailowy

Do kontaktu telefonicznego wystarczy numer: awarie całą dobę, w pozostałych sprawach w ciągu jednego dnia roboczego.

Jaki system, jaka technologia, co chcą Państwo osiągnąć? Prosimy nie przesyłać haseł ani poufnych dokumentów.

Odpowiedź w ciągu jednego dnia roboczego · bez zobowiązań

Wykorzystujemy Państwa dane wyłącznie do odpowiedzi na zapytanie. Prownex IT Services Sp. z o. o. jest administratorem danych. Okres przechowywania i Państwa prawa opisano w polityce prywatności.