Oferta
Architektura IT i modernizacja
Architektura IT, integracje systemów, chmura i CI/CD budowane pod realną skalę firmy. Doradztwo techniczne i modernizacja istniejących systemów.
- Dla kogo
- Firmy decydujące o przepisaniu albo modernizacji
- Zakres
- Architektura, integracje, chmura i CI/CD
- Wynik
- Przegląd czytelny poza zespołem technicznym
- Zasada
- Rekomendacje niezwiązane z żadnym dostawcą
Co wchodzi w zakres
Przegląd architektury
Co jest w porządku, co jest ryzykiem i ile kosztuje w utrzymaniu.
Decyzja o kierunku
Przepisanie albo modernizacja etapami, rozstrzygnięte przed pierwszą linią kodu.
Dobór systemu do skali
Monolit z czytelnymi granicami modułów albo osobne usługi, gdy jest powód.
Integracje z regułą na błąd
Ponowienia, kolejka nieudanych zdarzeń i alert na zatrzymany przepływ.
Chmura dobrana do ruchu
Bywa droższa niż własny serwer, gdy architektura nie pasuje do profilu.
Infrastruktura jako kod
Terraform, środowisko testowe i produkcyjne z tego samego opisu.
Wycofanie wdrożenia
Powrót do poprzedniej wersji zamiast ręcznej naprawy na produkcji.
Bramki w CI/CD
Budowanie, testy, kontrakt tras i danych strukturalnych, higiena zależności.
Od czego zaczyna się decyzja o architekturze
Decyzja o architekturze rzadko daje się cofnąć bez kosztu. Przepisać system czy modernizować go etapami, jedna baza czy kilka, własny zespół czy dostawca. Te pytania rozstrzygamy przed pierwszą linią kodu, nie po niej.
Przegląd kończy się dokumentem, który da się przeczytać w firmie, nie tylko w zespole technicznym. Zawiera to, co jest w porządku, co jest ryzykiem, ile kosztuje w utrzymaniu i w jakiej kolejności to ruszać.
Jak dobieramy system do skali
Sam system dobieramy pod skalę, nie pod modę. Monolit z czytelnymi granicami modułów bywa lepszym wyborem niż mikrousługi, których nikt później nie utrzyma. Podział na osobne usługi ma sens dopiero wtedy, gdy istnieje konkretny powód, żeby wdrażać je osobno.
Integracja rzadko psuje się w dniu wdrożenia. Psuje się trzy miesiące później, gdy jeden system zmieni format danych, a drugi milczy o awarii. Dlatego ponowienia, kolejkę nieudanych zdarzeń i alert na zatrzymany przepływ projektujemy razem z samą integracją.
Chmura, infrastruktura i wydania
Chmura potrafi kosztować więcej niż własny serwer, jeśli architektura nie pasuje do profilu ruchu. Infrastrukturę opisujemy kodem w Terraform, a środowisko testowe i produkcyjne powstają z tego samego opisu. Wycofanie wdrożenia to powrót do poprzedniej wersji.
CI/CD spina to wszystko w jedną odpowiedź na pytanie, czy daną zmianę można wypuścić. Build przechodzi albo się zatrzymuje. Budowanie, testy, kontrola kontraktu tras i danych strukturalnych oraz higiena zależności przerywają build, zamiast trafiać na listę zaległości.
Narzędzia i standardy
- Cloudflare Workers
- Docker
- Terraform
- Microsoft Azure
- Google Cloud
- TypeScript
- Node.js
- NestJS
- RabbitMQ
- GraphQL
- SQL
- GitHub Actions
Dowód: przegląd dla BLS Katowice
Przegląd kończy się dokumentem, a przykład takiego dokumentu opisujemy przy konkretnym wdrożeniu.
- Wynik
- Co jest w porządku, co ryzykiem, w jakiej kolejności ruszać
- Niezależność
- Rekomendacje bez prowizji od dostawcy
- Kontrola w CI
- Własny pakiet npm z asercjami
Przykład takiego przeglądu opisujemy przy systemie dla BLS Katowice. Ten sam zestaw reguł pracuje na serwisach, na których powstał, razem z własnym pakietem audytowym wpiętym w CI każdego serwisu, który prowadzimy.
Co się zmienia po wdrożeniu
- Architektura dobrana do skali procesu, nie do mody technologicznej
- CI/CD odpowiada automatycznie na pytanie, czy zmianę można wypuścić
- Integracja ma jawną regułę na wypadek błędu, zanim dojdzie do pierwszej awarii
- Środowiska odtwarzalne z opisu w repozytorium, nie z czyjejś pamięci
- Wycofanie wdrożenia w jednym kroku, bez ręcznej naprawy na produkcji
- Rekomendacje niezwiązane z żadnym dostawcą
Typowe zastosowania
- Przegląd architektury przed decyzją o przepisaniu albo modernizacji systemu
- Wydzielenie modułu z rozrośniętej aplikacji i dopisanie testów wokół kodu bez pokrycia
- Migracja aplikacji z serwera dedykowanego do chmury, etapami z możliwością powrotu
- Integracja systemu sprzedaży z magazynem i księgowością przez API i kolejkę
- CI/CD z testami, kontrolą kontraktu tras i publikacją do produkcji
- Infrastruktura opisana w Terraform osobno dla środowiska testowego i produkcyjnego
Pytania, które padają najczęściej
Przepisać system czy modernizować go etapami?
Decyzja o architekturze rzadko daje się cofnąć bez kosztu, więc rozstrzygamy ją przed pierwszą linią kodu. Tak samo jedną bazę czy kilka oraz własny zespół czy dostawcę.
Czym kończy się przegląd architektury?
Dokumentem, który da się przeczytać w firmie, nie tylko w zespole technicznym. Zawiera to, co jest w porządku, co jest ryzykiem, ile kosztuje w utrzymaniu i w jakiej kolejności to ruszać.
Kiedy podział na mikrousługi ma sens?
Monolit z czytelnymi granicami modułów bywa lepszym wyborem niż mikrousługi, których nikt później nie utrzyma. Podział ma sens dopiero wtedy, gdy istnieje konkretny powód, żeby wdrażać usługi osobno.
Co się dzieje, gdy integracja przestanie działać?
Ponowienia, kolejka nieudanych zdarzeń i alert na zatrzymany przepływ powstają razem z samą integracją. Integracja rzadko psuje się w dniu wdrożenia, tylko wtedy, gdy jeden system zmieni format danych.
Czy chmura zawsze wychodzi taniej?
Chmura potrafi kosztować więcej niż własny serwer, jeśli architektura nie pasuje do profilu ruchu. Dlatego infrastrukturę opisujemy kodem w Terraform, a oba środowiska powstają z tego samego opisu.