Modernizacja systemów informatycznych

Modernizacja oprogramowania legacy, czyli modernizacja aplikacji, to zmiana stosu, architektury albo infrastruktury działającej aplikacji bez utraty tego, co już działa. Nasze usługi modernizacji aplikacji korzystają ze zwykłych strategii: replatformingu, refaktoryzacji i aktualizacji frameworków, zmiany architektury oraz wymiany pojedynczego modułu. Do tej samej pracy często należy zmiana silnika bazy danych i opisanie infrastruktury w kodzie. Robimy to w ramach Platform & Cloud Engineering, obok szerszej usługi Custom Software Development.

• Replatforming. Backend, który ładuje i przetwarza dane z modemów Zeronest (ETL), przenieśliśmy z AWS Lambda i DynamoDB na Django, PostgreSQL i Celery, jak opisujemy niżej.
• Refaktoryzacja. We wrześniu 2025 r. przeprowadziliśmy refaktoryzację ETL, który przetwarza odczyty urządzeń Zeronest.
• Aktualizacje frameworków. Enerace przeszło na Python 3.13 i Django 5 między kwietniem a czerwcem 2025 r., a jego aplikacja mobilna dostała nowszy React Native między lutym a marcem 2026 r. Klient z sektora przemysłowego przeniósł front end z Vue 2 na Vue 3, z Vuetify 3 na Vuetify 4 i na Vite. Nasz zespół ocenił Vue 3 jako wyraźną poprawę względem wersji 2, a przejście na Vite jako zdecydowany plus.
• Zmiana architektury. Na platformie klienta przemysłowego nowe funkcje powstają jako mikroserwisy w Django i FastAPI.
• Zmiana silnika bazy danych. W 2025 r. producent oprogramowania dla centrów monitoringu przeniósł swój produkt z MS SQL na PostgreSQL w środowisku Windows. Przygotowaliśmy procedury i konfigurację wdrożeń oraz zmigrowaliśmy schemat i dane. Przeanalizowaliśmy zmiany dialektu SQL w kodzie Pascala i zautomatyzowaliśmy je. Przeszkoliliśmy też zespół klienta z PostgreSQL i jego administracji oraz zaprojektowaliśmy replikację, failover i wysoką dostępność.
• Infrastruktura jako kod. W Skyfri wprowadziliśmy Terraform obok ARM Templates i skryptów Azure CLI, których klient używał już wcześniej, zaczynając od MVP powiadomień. W retrospektywie z listopada 2024 r. liczba serwisów z pełnym CI/CD i infrastrukturą jako kodem rosła.
• Wymiana modułu. W Skyfri budujemy nowy system IoT na Azure IoT Hub i IoT Edge, który ma zastąpić obecny system zbierania danych z urządzeń. W tym samym projekcie komponenty interfejsu trafiają do biblioteki, która rośnie razem z produktem, Mock Service Worker pozwala uruchamiać front end na symulowanych odpowiedziach API, zanim powstanie backend, a system zarządzania energią obsługuje wiele baterii, bo został zbudowany z modułów.

Jakie systemy i aplikacje modernizujemy

Większość systemów, które trzeba zmodernizować, działa na kilku technologiach. Platforma klienta przemysłowego, którą przejęliśmy, łączy .NET, Ruby on Rails, FastAPI, Django, Vue, aplikacje na Androida i iOS oraz Terraform. Mieszany stos to dla nas normalny punkt startu, więc planujemy pracę moduł po module. Gdy zaczynał się audyt Skyfri, stos tworzyły React, C# i ASP.NET, Python i pyspark, Kusto/ADX, Databricks i Azure.

W zakresie są interfejsy webowe, usługi backendowe i potoki danych, aplikacje mobilne na Androida i iOS oraz cała infrastruktura pod nimi.

Modernizacja zaczyna się od audytu bieżących produktów i stosu klienta. W Skyfri w Oslo audyt trwał od 20 listopada 2023 r. do 7 stycznia 2024 r. Klient poprosił nas o wskazanie, co zmienić w procesie budowy produktu i w wydajności, więc przejrzeliśmy istniejące projekty i cały stos.

Po audycie kolejność zmian ustaliliśmy razem z klientem. Pracujemy jako część zespołu Skyfri, obok kolegów w Oslo.

Przepisać czy zmieniać krok po kroku? To, co działa stabilnie, zostaje, a nowe funkcje trafiają do nowych modułów. Na platformie przemysłowej starsze elementy w .NET i Ruby on Rails działają stabilnie, więc zostają w systemie i zmieniamy je stopniowo, a nowe moduły powstają w Django i FastAPI.

Kod należy do Ciebie. Prawa autorskie przechodzą na Ciebie z każdą płatnością i dostajesz kod źródłowy. Repozytorium robocze, z którego korzystamy, zostaje w naszym kontrolowanym środowisku.

W Zeronest zmienialiśmy działające oprogramowanie etapami. W pierwszym tygodniu sierpnia 2024 r. backend w Django powstał jako nowa aplikacja, z automatycznym wdrażaniem na AWS ECS oraz logowaniem przez AWS Cognito i modelami instalacji. Nowy proces ETL dla danych z modemów zbudowaliśmy we wrześniu i październiku 2024 r. Starą Lambdę, scheduler i DynamoDB wyłączaliśmy najpierw w środowisku deweloperskim, a potem na produkcji, od grudnia 2024 r. do kwietnia 2025 r. Dane przechodziły w czterech etapach:

1. Start: we wrześniu 2024 r. wykresy budowane z danych falownika i licznika nadal czytały z tabeli odczytów w DynamoDB.
2. Od października 2024 r. zadanie Celery uruchamiane co 2 minuty zapisywało przetworzone odczyty w PostgreSQL.
3. Od stycznia 2025 r. ETL pobierał odczyty urządzeń bezpośrednio z API platformy IoT i zapisywał je w PostgreSQL.
4. Tydzień później endpointy odczytów czytały już z PostgreSQL.

ETL zapisuje surowe odczyty urządzeń, więc przetworzone dane można później przeliczyć na podstawie zapisanych odczytów. W kodzie backendu nie ma już DynamoDB. Aktualizacje trwały na działającym systemie: docelowy poziom API Androida w sierpniu 2025 r. i React Native między kwietniem a lipcem 2026 r.

Jeden backend w Django i PostgreSQL obsługuje cały przepływ danych Zeronest: odczyty, alerty, agregaty, prognozy, sterowanie falownikami i powiadomienia. Pobiera, waliduje i łączy odczyty urządzeń, liczy agregaty co minutę, 15 minut, godzinę i dobę oraz pobiera ceny taryf rynku dnia następnego ze statystykami cen. Tworzy też prognozę na dzień następny i inicjalizuje nowe instalacje. W retrospektywie technicznej naszego zespołu z lutego 2025 r. ETL na Django i PostgreSQL znalazł się wśród tego, co działało dobrze, razem z kompletnym procesem automatycznych wdrożeń.

Dane i alerty

Dwa alerty pilnują ETL. Pierwszy odpala się, gdy zadanie ETL dla modemu nie wykona się 4 razy w ciągu godziny, drugi, gdy najnowsze dane modemu w bazie są starsze niż 20 minut.

Gdy odczyty jednego urządzenia w instalacji dotrą z opóźnieniem, ETL wczytuje zapisane odczyty drugiego urządzenia, łączy je od nowa i aktualizuje połączone dane modemu.

Model danych dopuszcza kilka falowników w jednej instalacji, z których jeden jest główny, a ETL pobiera dane falownika głównego. Obsługę dwóch falowników w ETL dodaliśmy we wrześniu 2026 r.

Profile sterowania falownikami edytuje się w panelu administracyjnym, z walidacją, podglądem i instrukcją, obok modułów dla poszczególnych producentów. Testy sprawdzają, że przykładowe profile odtwarzają zachowanie dotychczasowych modułów.

Działanie

Od lipca 2026 r. zadania w tle działają na czterech kolejkach Celery z osobnymi workerami: głównej, zarządzania urządzeniami, ETL oraz agregatów i prognoz. Sterowanie falownikiem uruchamia się co minutę, agregaty według harmonogramu, a prognoza stanu falownika co godzinę. ETL rozwijał się po zmianie platformy: alerty w styczniu 2025 r., agregaty minutowe w czerwcu 2025 r., a w sierpniu 2026 r. osobne potoki dla modemów DIN 200 i DIN 300.

Między v5.0.0 w listopadzie 2024 r. a v7.5.0 w listopadzie 2025 r. oznaczyliśmy 25 wydań, średnio jedno na dwa tygodnie. Backend ma ponad 1500 testów automatycznych, CI przy każdym pull requeście uruchamia lint, sprawdzenie formatu i testy na PostgreSQL, a pipeline GitHub Actions buduje obraz Docker, wysyła go do ECR, uruchamia moduł backendu w Terraformie i skrypt po wdrożeniu.

Enerace rozwija się w jednej aplikacji od 2019 r.: użytkownicy, dane rynkowe, kontrakty, formuły, dokumenty, faktury, przetargi, a od stycznia 2026 r. także dane o produkcji energii.

Platforma pod spodem była aktualizowana po drodze:

• Infrastruktura. Pierwsza konfiguracja AWS w CloudFormation, z siecią VPC i bazą RDS, pochodzi z listopada 2019 r., a Redis w ElastiCache pojawił się miesiąc później. Środowiska ECS Fargate są opisane w Terraformie od lutego 2023 r.
• CI/CD. GitLab CI działa od listopada 2021 r. Od sierpnia 2024 r. GitHub Actions buduje obrazy Django i Nginx, wysyła je do ECR i wdraża przez Terraform.
• Wersje. Django 3.2 w 2022 r., potem Django 5.2 i PostgreSQL 16.9 wiosną 2025 r. Obraz bazowy przeszedł na Debian Trixie we wrześniu 2026 r., a Terraform ustawił PostgreSQL 17.11 dla produkcji i stagingu w październiku 2026 r.

Pracujemy na AWS, Azure i Hetznerze. Przy migracjach do chmury domyślnie wybieramy AWS z Terraformem, bo naszym zdaniem AWS ma najlepsze narzędzia. Azure to kolejna platforma, z której korzystamy, a przykładem jest Skyfri. Szerszy zakres opisuje strona Cloud Application Development.

Po modernizacji system może zostać u nas w utrzymaniu w ramach SLA ustalonego w umowie, jak opisujemy w Support & Maintenance. Hypercare po wdrożeniu jest możliwy, a jego zakres i czas ustalamy przed startem. Jak postępujemy z dostępami i danymi, opisuje strona Security & GDPR.

Napisz do nas przez formularz kontaktowy albo umów bezpłatną rozmowę discovery. Odpowiadamy w ciągu 48 godzin w dni robocze. Podstawowe discovery to bezpłatne spotkanie. Przy większym zakresie nasze warsztaty discovery obejmują zakres, mapę drogową i szacunek kosztu oraz czasu.