EN

MarceliGrabowski

Inżynier backend/cloud od złożonych systemów i legacy Wrocław, Polska / zdalnie ● Otwarty na rozmowy techniczne i konsultingowe

Pomagam zespołom odzyskać kontrolę nad złożonymi systemami backendowymi, chmurowymi i legacy.

Pracuję przy pragmatycznej architekturze, modernizacji legacy, systemach Kotlin/Java i platformach chmurowych.

10+
Lat komercyjnego doświadczenia
Kotlin/Java
Główny stack

Czym się zajmuję

01

Przejęcie systemu legacy

Szybko ustalam, jak system naprawdę działa — zwłaszcza gdy dokumentacja jest niepełna, przestarzała albo powstała u zewnętrznego dostawcy.

02

Modernizacja backendu i chmury

Bez fantazji o wielkim przepisywaniu. Małe, uzasadnione kroki, które zmniejszają koszt, ryzyko albo ból operacyjny.

03

Backend Kotlin/Java

Najczęściej pracuję z Kotlinem, Javą, Spring Bootem, Ktorem, PostgreSQL i integracjami, w których dużo zależy od jakości danych.

04

Koszty, wydajność i ryzyko operacyjne w chmurze

Zanim zmienię architekturę, sprawdzam zachowanie obciążeń, ograniczenia runtime’u, metryki, logi i miejsca, które naprawdę generują koszt.

05

IoT i urządzenia połączone

Backend i chmura dla platform urządzeń połączonych, telemetrii, smart energy i procesów działających blisko świata fizycznego.

06

Tożsamość i uwierzytelnianie

Porządkuję przepływy logowania, integracje z dostawcami tożsamości, ograniczenia platformy i trudne przypadki operacyjne.

07

Pragmatyczne prowadzenie techniczne

Łączę fakty z kodu, zachowanie systemu, ograniczenia platformy i decyzje, które muszą podjąć ludzie po stronie produktu albo biznesu.

Jak pracuję

Zwykle zaczynam od zbudowania realnego modelu działania systemu — nie tylko od przeczytania dokumentacji.

Dokumentację traktuję jako punkt wyjścia. Sprawdzam założenia w kodzie, logach, metrykach, małych POC-ach i rozmowach z zespołem, a potem przekładam wnioski na praktyczne następne kroki.

KodZachowanie systemuLogiMetrykiKonfiguracjaPOC-e

Kiedy to ma sens

Najlepiej odnajduję się tam, gdzie system jest złożony, słabo udokumentowany i na tyle ważny, że zgadywanie robi się drogie.

01

System jest trudny do zrozumienia, a dokumentacja nie daje pewności.

02

Zespół musi przejąć system legacy albo system zbudowany przez zewnętrznego dostawcę.

03

Koszty chmury, wydajność albo ryzyka operacyjne stają się odczuwalnym problemem.

04

Trzeba podjąć decyzję backendową lub platformową przy niepełnych informacjach.

05

Produkt potrzebuje pragmatycznej modernizacji, a nie fantazji o przepisaniu wszystkiego od zera.

06

Potrzebna jest osoba, która łączy kod, ograniczenia platformy i decyzje interesariuszy.

Mniej interesuje mnie

Architektura dla samej architektury, rytuały clean code bez jasnej korzyści operacyjnej albo dowożenie funkcji bez kontekstu produktu i systemu.

Notatki techniczne

Dłuższe notatki techniczne są po angielsku na osobnej stronie, połączonej z tą wizytówką. Dotyczą przejmowania systemów, pragmatycznej architektury, chmury i decyzji technicznych.

Notatki techniczne
Opublikowane

How I build an operating model during legacy system takeover

Planowane

POC jako narzędzie decyzji, nie zabawka

Planowane

Analiza kosztów chmury bez zgadywania

Planowane

Kotlin + GraalVM w backendzie serverless: kiedy to ma sens

Kontakt

Jeśli brzmi to jak system, migracja albo decyzja techniczna, z którą się mierzysz, napisz krótko, o co chodzi.