02Obszar kompetencji

Chmura i inżynieria platform

Gdzie mają działać Twoje systemy - i dlaczego.

Projektujemy, budujemy i utrzymujemy platformy, na których działają Twoje systemy: Azure jako podstawę, AWS jako pełnoprawną alternatywę, własne serwery, gdy to lepszy wybór. Platformę dobieramy do obciążenia - jeden zabezpieczony serwer, gdy to wystarcza, automatycznie skalowane grupy maszyn albo kontenery w Kubernetesie, gdy nie. Każda platforma, którą budujemy, jest opisana w kodzie, monitorowana od pierwszego wdrożenia i dostępna z internetu tylko w tych miejscach, w których naprawdę musi - reszta pozostaje zamknięta. Jeśli szukasz samej sieci - szaf, zasilania, okablowania, segmentacji - opisujemy ją w Sieciach i łączności w przedsiębiorstwie.

W skrócie
  • Zaczynamy od najmniejszej konfiguracji, która spełnia wymagania, i od razu mówimy, co się stanie, gdy urośniesz: czy wystarczy dołożyć maszyny, czy dopiero wtedy zacznie mieć sens Kubernetes.
  • Każdy serwer, który instalujemy u Ciebie, ma od pierwszego dnia skonfigurowane zdalne zarządzanie sprzętem - uruchomisz go ponownie bez dojazdu do serwerowni, także wtedy, gdy system operacyjny się nie ładuje.
  • Konfiguracja w kodzie (Terraform, Ansible) zamiast ręcznych ustawień w panelu - każdą zmianę widać w historii, sprawdzamy ją przed wdrożeniem i możemy wrócić do znanego stanu. Platformę da się odtworzyć od zera, a nie tylko opisać, jak powstała.
  • Platformę budujemy na Twoim koncie i Twoim sprzęcie - subskrypcja, domena i rachunek są Twoje od pierwszego dnia. Jeśli we własnym zespole nie masz nikogo, kto mógłby ją prowadzić, oferujemy zarządzanie po naszej stronie: jako osobną decyzję, nie jako warunek.
  • Serwery GPU budujemy na tych samych zasadach co resztę platformy: opisane w kodzie, monitorowane od pierwszego dnia i z policzoną alternatywą, zanim cokolwiek kupisz.
Jak dobieramy rozwiązania

Zanim polecimy platformę, odpowiadamy na siedem pytań:

  1. 01

    Charakter obciążenia - równo przez cały dzień, skokowo w godzinach szczytu, raz na dobę w nocy czy przez kilka minut dziennie; to przesądza, czy będzie to maszyna wirtualna, grupa skalowania, kontener czy funkcja.

  2. 02

    Gdzie dane mogą się znajdować - region, kraj, Twój własny budynek. Przy danych osobowych i danych Twoich klientów decydują o tym przepisy i umowy, a dopiero potem wydajność; przy danych, które i tak są jawne, nie ma czego rozstrzygać - liczy się wydajność i koszt.

  3. 03

    Kto to utrzymuje na co dzień - Twój dział IT, jeden administrator albo my.

  4. 04

    Struktura kosztów - capex czy opex, rezerwacja mocy na dłuższy okres czy płatność za bieżące użycie, i który poziom usługi wystarcza.

  5. 05

    Dostęp z internetu - prywatnie przez tunel, publicznie za bramą Zero Trust albo świadomie publicznie.

  6. 06

    Skalowanie - czy wzrost, którego się spodziewasz, zmieści się na tym, co budujemy, czy wymusi przebudowę. Czasem odpowiedź brzmi: nie urośnie i nie musi.

  7. 07

    Co już masz - własna część chmury (tenant), szafa, licencje, za które już płacisz.

Usługi zarządzane w chmurze opłacają się wtedy, gdy wykorzystasz to, co kupujesz: elastyczność, gotową obsługę, jeden rachunek. Gdy nie wykorzystasz, bardziej opłacalny jest dobrze prowadzony serwer, który już masz - albo pozostawienie tego, co działa u obecnego dostawcy. Powiemy Ci, który to przypadek.

Co budujemy

Azure

  • Moc obliczeniowa dobrana do obciążenia - zabezpieczone maszyny wirtualne pod pojedyncze usługi; Virtual Machine Scale Sets z regułami, które dokładają maszyny, gdy obciążenie rośnie, i zabierają je, gdy spada; App Service, gdy aplikacja webowa skorzysta z zarządzanego środowiska, slotów wdrożeniowych i wbudowanego skalowania; AKS, gdy usług i środowisk jest dość, by orkiestrator się opłacił.
  • Zasoby opisane w kodzie - subskrypcje, grupy zasobów, sieci wirtualne i maszyny zapisujemy w Terraformie, a w Bicepie tam, gdzie środowisko już z niego korzysta. Dostęp opiera się na rolach i tożsamościach zarządzanych zamiast współdzielonych haseł.
  • Sieć w Azure - sieci wirtualne, grupy zabezpieczeń, bramy VPN, prywatne punkty końcowe i peering. A jeśli masz też sieć fizyczną, projektują ją ci sami ludzie.
  • Dyski i pamięć obiektowa - dyski zarządzane i Blob Storage pod maszyny, bazy zarządzane tam, gdzie wymaga tego aplikacja.
  • Monitoring - Azure Monitor, Application Insights i Log Analytics skonfigurowane, zanim system przyjmie pierwsze obciążenie, z alertami, które docierają do człowieka.

Usługa zarządzana, z której nie korzystasz, to wciąż usługa, za którą płacisz. Platforma jako usługa zarabia na siebie wtedy, gdy zdejmuje z Ciebie pracę, którą ktoś musiałby wykonać.

AWS i multicloud

  • AWS jako pełnoprawna alternatywa - EC2 z grupami Auto Scaling, projekt VPC z podsieciami, tablicami tras i grupami zabezpieczeń, role IAM zamiast kluczy dostępowych, S3, RDS oraz EKS tam, gdzie Kubernetes jest właściwym narzędziem. Ta sama dyscyplina co w Azure: wszystko w Terraformie, monitoring od pierwszego dnia.
  • Azure i AWS razem - VPC i VNet połączone tunelami IPsec z BGP, żeby systemy po obu stronach widziały się tak, jakby stały w jednej sieci.

Multicloud z wyboru to strategia; multicloud przez przypadek to dwa rachunki i dwa komplety awarii. Jeśli już korzystasz z dwóch chmur, powiemy, który to przypadek.

Kontenery i Kubernetes

  • Docker Compose na maszynie wirtualnej - do kilku usług, które i tak działają razem; proste w prowadzeniu, proste w przekazaniu.
  • k3s - lekki Kubernetes do małych klastrów (kilku serwerów pracujących jako jedna całość) i serwerów brzegowych, gdzie pełna dystrybucja byłaby za duża na to zadanie.
  • Kubernetes z Helmem, AKS albo EKS - gdy liczba usług, zespołów albo środowisk uzasadnia koszt klastra; zarządzany przez chmurę tam, gdzie zdejmuje z Ciebie pracę.

Kubernetes do trzech kontenerów to koszt utrzymania bez korzyści; Compose wystarczy, dopóki wymagania się nie zmienią.

Serwery u Ciebie

  • HPE, Dell, Supermicro, Lenovo - w szafie i wolnostojące, od starszych generacji po bieżące, ze zdalnym zarządzaniem sprzętem (iLO, iDRAC, IPMI) ustawionym od pierwszego dnia.
  • Fabrycznie nowe albo poleasingowe - sprawdzone serwery z drugiej ręki dają tę samą platformę za ułamek ceny katalogowej, gdy to właściwy wybór.
  • Hybryda z chmurą - serwery u Ciebie połączone z Azure albo AWS tunelem site-to-site, dzięki czemu tożsamość, kopie zapasowe czy dodatkowa moc mogą być w chmurze, a reszta zostaje na miejscu.
  • Szafy, zasilanie i sieć wokół nich - opisane w Sieciach i łączności w przedsiębiorstwie; robi je ten sam zespół.

Sprzęt u Ciebie, którego nikt nie prowadzi, to rachunek zapłacony z góry za usługę, której nikt nie świadczy.

Wirtualizacja i pamięć masowa

  • Proxmox VE z Ceph - gdy wymagania uzasadniają klaster serwerów, domyślnie wybieramy Proxmox: prowadzony Terraformem i Ansible albo z panelu, z rozproszoną pamięcią masową, która przeżyje awarię węzła.
  • VMware ESXi i vCenter z vSAN - tam, gdzie już działa, albo gdy środowisko jest dość duże, żeby się opłacało; vSAN wtedy, gdy pamięć masowa ma stać w tych samych serwerach. Koszt licencji jest dziś częścią projektu, a nie sprawą na potem.
  • Nutanix - gdy jeden dostawca oprogramowania do wirtualizacji, pamięci masowej i zarządzania pasuje do tego, jak firma chce pracować.
  • Hyper-V i lokalne Active Directory (Windows Server) - konfigurujemy je i utrzymujemy tam, gdzie już pracują albo gdzie wymaga ich oprogramowanie, z którego korzysta firma. W nowych środowiskach proponujemy platformy wymienione wyżej, a do kont i logowania - Entra ID.
  • Migracja z VMware na Proxmox - zaplanowana i przećwiczona, obciążenie po obciążeniu, gdy zmiany w licencjonowaniu sprawiają, że zaczyna się opłacać.
  • Kopie zapasowe i odtwarzanie - przećwiczone odtworzenie, z ustalonym czasem przestoju i dopuszczalną stratą danych, opisujemy w Niezawodności, bezpieczeństwie i utrzymaniu; platformę projektujemy tak, żeby było wykonalne.

Klaster, którego nie odtworzysz z kodu, to klaster, którego będziesz się bał dotknąć.

Platforma w kodzie, tożsamość i dostęp z internetu

  • Terraform, Ansible, cloud-init - infrastruktura i konfiguracja w Gicie; zmiany przejrzane, wdrożone i odwracalne.
  • Hasła, klucze i tokeny - trzymane w sejfie i regularnie wymieniane, nigdy w plikach ani w pipeline'ach.
  • Jeden dostawca tożsamości - u większości naszych klientów Entra ID, albo ten dostawca OpenID Connect czy SAML, z którego już korzystasz. To katalog, na którym wszystko stoi: role w Azure, dostęp przez VPN i Zero Trust oraz logowanie do produktów i narzędzi, które dostarczamy. Nikt nie dostaje dostępu domyślnie - dostęp się przyznaje. A tam, gdzie część ludzi nie ma i nie będzie miała własnego konta w katalogu - na hali, przy maszynach - projektujemy dla nich osobne wejście i mówimy wprost, co ono kosztuje w bezpieczeństwie.
  • Zaprojektowany dostęp z internetu - usługi prywatne osiągalne wyłącznie przez WireGuard, publiczne za Cloudflare Tunnel i Zero Trust Access; na serwerach wyłączamy wszystko, czego działająca na nich usługa nie potrzebuje.

Hasło albo klucz w repozytorium przestaje być tajemnicą w dniu, w którym ktoś to repozytorium sklonuje.

Infrastruktura GPU i AI

  • Serwery GPU - zbudowane, zainstalowane i skonfigurowane do trenowania modeli oraz wnioskowania (uruchamiania wytrenowanych modeli), u Ciebie albo jako instancje GPU w Azure.

Wynajem mocy GPU na miesiąc jest tani; własny serwer GPU pracujący dwa dni w tygodniu już nie. Porównamy oba, zanim kupisz.

Jak prowadzimy projekt

Zawsze w tej samej kolejności:

  1. 01

    Rozpoznanie - jakie są obciążenia, gdzie mogą się znajdować dane, kto to utrzymuje, co już masz.

  2. 02

    Projektowanie - platforma, dostęp z internetu i model kosztowy uzgodnione z Tobą przed budową. Powiemy Ci, jeśli tańszą opcją jest to, co już masz.

  3. 03

    Budowa - wszystko w kodzie od samego początku, dokumentowane na bieżąco. Rozmawiasz bezpośrednio z inżynierami, którzy budują Twoją platformę, bez pośredników. Ilekroć o to poprosisz, pokazujemy, na jakim etapie jest praca względem harmonogramu.

  4. 04

    Wdrożenie - przełączenia w czasie, który najmniej zakłóca pracę firmy.

  5. 05

    Testy i dokumentacja - prowadzone równolegle z budową: monitoring, dostępy i instrukcje operacyjne są gotowe przed przekazaniem.

  6. 06

    Wsparcie - zostajemy na SLA tak długo, jak jest potrzebne: do dnia, w którym Twój dział IT przejmuje system, albo przez kolejne lata. Długość ustalasz Ty - nikogo nie wiążemy na czas, którego sam nie wybrał.

Co dostajesz

Na koniec projektu przekazujemy Ci:

  • Kod infrastruktury w repozytorium, które należy do Ciebie
  • Schemat architektury i mapę dostępu z internetu: co skąd jest osiągalne
  • Spisane dostępy administracyjne, a przy serwerach u Ciebie także zdalne zarządzanie sprzętem
  • Monitoring i alerty podpięte do kogoś, kto je zobaczy
  • Model kosztowy platformy zaktualizowany do stanu po wdrożeniu
  • Instrukcje operacyjne dla następnego inżyniera
ENPL