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.
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ę procesu. 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 psuje się zwykle kilka miesięcy po wdrożeniu, 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: decyzje architektoniczne z nazwaną ceną
Przegląd kończy się decyzją, a każda decyzja ma swój koszt. Podajemy go przy wdrożeniach, które go mają.
- 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
System dla Best Assistance trzyma trzy powierzchnie na jednym zapleczu i jednym modelu danych, więc zgłoszenie z terenu i sprawa prowadzona przy biurku to ten sam rekord. Ceną tego wyboru jest to, że żadnej z trzech powierzchni nie da się zmodernizować bez ruszania pozostałych. Cyber Katalog rozdziela dane według ich rodzaju i źródła: aktualności, oferty pracy i firmy mają osobne bazy, a proxy Listy Ostrzeżeń CSIRT NASK działa jako osobna usługa, bo ma inne źródło danych i inny cykl życia.
Co się zmienia po wdrożeniu
- Architektura dobrana do skali procesu
- 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, podobnie jak wybór między jedną bazą a kilkoma oraz między własnym zespołem a 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ą, bo integracja psuje się zwykle kilka miesięcy po wdrożeniu, gdy jeden system zmieni format danych, a drugi milczy o awarii.
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.