Case study: Jak firma Plecto przeniosła swoją platformę cloud-to-cloud od hyperscalera do Scaleway

Migracja pełnej platformy produkcyjnej z AWS do Scaleway to zawsze ambitne przedsięwzięcie. Dla Plecto – europejskiego scale-upu specjalizującego się w śledzeniu wydajności i angażowaniu zespołów – projekt ten był nie tylko wyzwaniem technicznym, ale także strategiczną szansą na modernizację stosu technologicznego i odzyskanie kontroli nad kosztami chmury. Dzięki wsparciu zespołów Scaleway oraz Kaliop, firmie udało się skutecznie przeprowadzić migrację cloud-to-cloud, która połączyła dyscyplinę FinOps z szerszą transformacją w duchu DevOps.

Punkt wyjścia: przytłaczający rachunek

Platforma Plecto, historycznie osadzona na AWS, opierała się na usługach zarządzanych, takich jak Kinesis i RDS, maszynach wirtualnych dla Elasticsearch oraz warstwie aplikacyjnej wdrażanej przy minimalnej automatyzacji. Wraz z gwałtownym wzrostem bazy użytkowników, proporcjonalnie rosły koszty: usługi bazodanowe stanowiły główny wydatek, a niektóre komponenty generowały opłaty pomimo zerowego zużycia.

Poza obciążeniem finansowym, zespół inżynierski borykał się z manualnymi procesami wdrażania i brakiem podejścia Infrastructure as Code (IaC), co ograniczało skalowalność i pogłębiało dług technologiczny.

Dla Plecto kluczowe stało się zoptymalizowanie inwestycji w chmurę poprzez podejście FinOps, przy jednoczesnej transformacji architektury, która pozwoliłaby na wsparcie przyszłego wzrostu firmy.

Rola Scaleway i decyzja o migracji

Pod koniec 2024 roku Plecto rozpoczęło rozmowy ze Scaleway. Europejski dostawca chmury zaoferował optymalny miks usług IaaS oraz PaaS, konkurencyjny model rozliczeń oparty na rzeczywistym zużyciu oraz mechanizmy ograniczające podwójne fakturowanie w okresie przejściowym. Aby zaprojektować i przeprowadzić migrację, Scaleway szybko zaangażowało do projektu firmę Kaliop.

Pierwotny pomysł stopniowego przenoszenia kont klientów został porzucony – techniczne współzależności między systemami czyniły go zbyt ryzykownym. Jedynym realnym podejściem okazał się pełny cutover (całościowe przełączenie), poprzedzony drobiazgowymi przygotowaniami, aby zabezpieczyć każdy etap operacji.

Gruntowne przygotowania zakończone finalnym przełączeniem

Pierwsza faza skupiła się na modernizacji fundamentów technicznych. Potok danych w czasie rzeczywistym (data pipeline) został przeniesiony z Kinesis na Kafkę przy użyciu tymczasowej konfiguracji dual-publishing. Pozwoliło to na pełną walidację wydajności przed całkowitym przekierowaniem ruchu.

Równolegle przebudowano architekturę w oparciu o system Kubernetes. Procesy wdrożeniowe zostały zautomatyzowane poprzez GitHub, z wykorzystaniem rejestrów Scaleway dla obrazów Docker oraz narzędzia ArgoCD do ciągłego dostarczania (Continuous Deployment). Przejście na model Infrastructure as Code (IaC) przyniosło poprawę skalowalności i odporności systemu, jednocześnie znacząco ograniczając konieczność ręcznej obsługi operacji.

Właściwa migracja została przeprowadzona w ciągu jednego zaplanowanego weekendu. Bazy danych, Elasticsearch, Redis oraz pozostała część aplikacji zostały przełączone w ramach jednej, skoordynowanej operacji, poprzedzonej intensywnymi testami synchronizacji i odtwarzania danych. Przerwa w świadczeniu usług utrzymała się w założonym oknie czasowym, co zapewniło szybki i bezstratny powrót do pełnej operacyjności.

Optymalizacje po migracji

Sama migracja nie była końcem drogi. W kolejnych tygodniach przeprowadzono szereg optymalizacji. Dzięki kompresji komunikatów w Kafce udało się zredukować wolumen danych aż o trzy- do czterokrotnie. Równolegle poprawiono fragmenty kodu aplikacji, co zmniejszyło przepustowość komunikatów i podniosło ogólną wydajność systemu.

W obszarze monitoringu wdrożono pełny stos Observability: Thanos do długoterminowego przechowywania metryk, Loki do logów oraz Grafana do wizualizacji w czasie rzeczywistym. Deweloperzy zyskali pełną widoczność procesów (end-to-end), co jest kluczowe dla przewidywania problemów i precyzyjnego dostrajania platformy za pomocą dashboardów i celowanych alertów.

Z perspektywy FinOps, migracja została początkowo przeprowadzona przy celowo przewymiarowanych zasobach, aby zminimalizować ryzyko. Gdy tylko monitoring i optymalizacje zaczęły działać, infrastrukturę poddano procesowi right-sizingu (precyzyjnego dopasowania skali). W efekcie łączone koszty chmury zostały zredukowane o połowę w porównaniu do wydatków w AWS.

Wyciągnięte wnioski: czego firma Plecto nauczyła się podczas migracji

Doświadczenie Plecto dostarcza kilku cennych spostrzeżeń, które mogą posłużyć jako drogowskaz dla innych firm:

• Audyt wstępny jest niezbędny: pozwala on odkryć ukryte współzależności i pomaga doprecyzować strategię.

• Walidacja krytycznych komponentów przed przełączeniem to podstawa: równoległa konfiguracja Kinesis/Kafka odegrała tu decydującą rolę.

• Migracja to transformacja: przejście na kontenery i Kubernetes umożliwiło prawdziwą automatyzację i standaryzajcę infrastruktury.

• Migracja typu „one-shot” musi być zaplanowana jak operacja chirurgiczna: sukces zależy od testów synchronizacji i solidnych scenariuszy wycofania (fallback scenarios).

• Ciągła optymalizacja jest kluczem: większość zysków w zakresie wydajności i stabilności pojawia się już po samej migracji.

Przenosząc się z AWS do Scaleway, Plecto obniżyło koszty infrastruktury o połowę, poprawiając jednocześnie wydajność i niezawodność. Platforma działa obecnie na zmodernizowanej architekturze opartej na Kubernetes, Infrastructure as Code oraz w pełni zintegrowanym stosie Observability.

Ten projekt udowadnia, że migracja cloud-to-cloud to znacznie więcej niż tylko zmiana hostingu. To szansa na przemyślenie architektury, wdrożenie najlepszych praktyk DevOps i FinOps oraz zbudowanie bardziej odpornego i skalowalnego fundamentu technicznego.