Z pojedynczych systemów powstaje niezawodny proces.

Tak. Wszystkie usługi (6) można zaplanować jako odrębne pakiety prac. Wspólnie ustalamy sytuację wyjściową, wymagania wstępne i wynik, który jest Państwu potrzebny w pierwszej kolejności. Na podstronach opisujemy zakres każdej usługi i związane z nią decyzje techniczne.

Przed realizacją ustalane są cele, systemy, których to dotyczy, zakres współdziałania, wyniki i kryteria odbioru. Otwarte kwestie techniczne można najpierw wyjaśnić w ramach inwentaryzacji lub pilotażu. Dodatkowe zadania są oceniane pod kątem wpływu na nakład pracy i termin.

Dokumentacja, instruktaż i podział odpowiedzialności są uwzględniane w zamówieniu. Jeśli OTOKO® przejmuje bieżące zadania, uzgadniamy w tym celu zakres eksploatacji wraz z godzinami serwisowymi i ścieżkami eskalacji. Państwa zespół może też sam kontynuować prace na bazie wyników lub prowadzić je z dotychczasowymi partnerami.

Interfejs to więcej niż udany transfer danych. Nadawca i odbiorca muszą rozumieć to samo znaczenie danych, umieć obsłużyć błędy i wprowadzać zmiany w kontrolowany sposób. Planujemy architekturę, wdrażamy integracje i testujemy pełny przebieg procesu biznesowego. Uwzględniamy również starsze aplikacje i wymianę plików. Rozwiązanie techniczne jest dostosowane do Państwa wymagań co do aktualności danych, obciążenia, bezpieczeństwa i łatwości utrzymania.

Partnerzy i aplikacje potrzebują interfejsów, na których zachowaniu mogą polegać. Projektujemy kontrakty API, konfigurujemy dostęp i zabezpieczenia na bramie API (API Gateway) oraz zarządzamy wersjami, dokumentacją i zatwierdzeniami w całym cyklu życia.

Polityka API z konwencjami nazewnictwa, formatami błędów, wersjonowaniem i wymaganiami bezpieczeństwa Katalog interfejsów ze specyfikacją OpenAPI i osobą odpowiedzialną dla każdego API Budowa bramy z użyciem Kong, Apigee lub Azure API Management, integracja z Państwa systemem zarządzania tożsamością przez OAuth 2.0 i OpenID Connect Portal dla partnerów i deweloperów z zarządzaniem dostępem, kluczami i raportami użycia Cykl życia z procesem zatwierdzania, wycofywaniem starych wersji i powiadomieniami o zmianach

Polityka API i katalog interfejsów Gotowa do eksploatacji brama API z integracją zarządzania tożsamością Portal dla deweloperów z dokumentacją każdego API

Zaczynamy od procesów biznesowych podłączanych systemów: jakich danych potrzebują, jakie stany mogą zmieniać i jak rozpoznają błędy? REST, GraphQL lub gRPC wybieramy w zależności od zastosowania. Opis wykorzystuje format odpowiadający danemu protokołowi, na przykład OpenAPI dla odpowiednich API HTTP. Oprócz danych właściwych ustalamy paginację, limity czasowe, odpowiedzi błędów i zachowanie przy ponawianiu żądań. Przykłady i przypadki testowe pomagają zespołom korzystającym z interfejsu zintegrować go jeszcze przed zatwierdzeniem do produkcji.

Brama API może zarządzać dostępem, ograniczać liczbę żądań i wymuszać reguły techniczne. To, czy konkretny użytkownik może odczytać dane konkretnego zamówienia, musi dodatkowo rozstrzygnąć właściwa usługa. Zgodnie z tym podziałem planujemy weryfikację tokenów, tożsamości usług, przypisanie do dzierżawcy oraz rejestrowanie zdarzeń. Dla wywołań zapisujących określamy sposób obsługi ponawianych żądań. Stare wersje otrzymują przejrzysty proces wycofywania, aby zmiany nie przerywały niespodziewanie integracji z partnerami.

Testy kontraktowe sprawdzają zadeklarowaną strukturę; testy integracyjne i obciążeniowe uzupełniają obraz zachowania. Testujemy odrzucone żądania dostępu, nieprawidłowe dane wejściowe i przekroczenia czasu, podobnie jak udane wywołania. Przekazanie obejmuje specyfikację, konfigurację bramy API oraz zakresy odpowiedzialności. Na start potrzebujemy typowych konsumentów API, założeń dotyczących obciążenia oraz procesów biznesowych, które API ma umożliwiać.

Niezależny rozwój może pomagać, ale zbyt wiele rozproszonych usług może go też utrudniać. Sprawdzamy sensowne granice biznesowe i wdrażamy odpowiednią architekturę, obejmującą komunikację, odpowiedzialność za dane, dostarczanie oraz eksploatację.

Podział na domeny metodą Event Storming i Bounded Context wspólnie z działem biznesowym Platforma na Kubernetes z Helm, wdrożeniami GitOps i przestrzeniami nazw dla każdego zespołu Komunikacja między usługami przez REST, gRPC lub wiadomości, z warstwą Service Mesh do szyfrowania i routingu Przechowywanie danych dla każdej usługi z wzorcem Saga i Outbox dla transakcji rozproszonych Reguły eksploatacji dla logowania zdarzeń, konfiguracji, danych poufnych i odporności na awarie

Model domenowy z podziałem na usługi i interfejsami Platforma z pipeline'em wdrożeniowym jako kod Podręcznik eksploatacji z regułami dla każdej usługi

Wspólnie z działem biznesowym i zespołem programistycznym analizujemy pojęcia, reguły i zmiany. Funkcje, które regularnie trzeba zmieniać razem, nie powinny być lekkomyślnie rozdzielane. Modularny monolit może zapewnić jasne granice bez wprowadzania rozproszonej eksploatacji. Mikroserwisy mają sens tam, gdzie niezależne zespoły, profile obciążenia lub cykle dostarczania przynoszą uzasadnioną korzyść. Decyzję dokumentujemy wraz z jej konsekwencjami dla eksploatacji, zamiast wybierać architekturę wyłącznie dlatego, że jest modna.

Operacja obejmująca kilka usług nie ma automatycznie wspólnej transakcji bazodanowej. Planujemy przejścia stanów, tymczasową niespójność i działania kompensujące. Wzorzec outbox może pomóc w spójnym powiązaniu zmiany danych z publikowanym zdarzeniem. Ponowne próby wymagają biznesowej idempotentności, czyli zdefiniowanego wyniku przy ponownym przetworzeniu. Limity czasowe i zależności są ograniczane, aby wolna usługa nie blokowała całego łańcucha. Te reguły muszą być zrozumiałe i testowalne dla zaangażowanych zespołów.