Jeśli chcesz wiedzieć, jak organizacja buduje oprogramowanie, poproś o wgląd w fakturę za infrastrukturę, a nie w diagram architektury.
Co faktura mówi o architekturze
Wydatki na chmurę traktuje się często jako problem zakupowy, do rozwiązania przez negocjowanie rabatów i proszenie zespołów o rozwagę. Lepiej rozumieć je jako pomiar decyzji inżynierskich, i jest to pomiar niezwykle szczery.
Powtarza się kilka wzorców.
Moce obliczeniowe zapewnione na szczyt, który trwa godzinę dziennie. Infrastruktura wymiarowana na najgorszy przypadek i opłacana nieprzerwanie, bo skalowania nigdy nie zbudowano, a teraz wydaje się to ryzykowne.
Dane przemieszczające się między miejscami, między którymi nie musiały się przemieszczać. Opłaty za transfer to bezpośredni podatek od projektu, w którym komponenty stale się ze sobą komunikujące zostały umieszczone osobno.
Pamięć masowa, której nikt nie usunął. Kopie zapasowe, logi, migawki i porzucone woluminy narastające bezterminowo, bo nigdy nie napisano polityki cyklu życia danych.
Środowiska działające poza godzinami pracy. Infrastruktura deweloperska i testowa w pełnym rozmiarze przez całą noc i w weekendy.
Usługi zarządzane wybrane dla wygody przy wolumenach, przy których przestały się opłacać, co było słuszną decyzją na początku i nigdy nie zostało zweryfikowane ponownie.
Uporczywy przepał to architektura, która coś ci mówi, a osobą, która potrafi to odczytać, jest inżynier, nie księgowy.
To praktyczny argument za tym, żeby uczyć kosztu jako właściwości inżynierskiej, obok opóźnienia i dostępności. Zespoły, które widzą koszt swoich własnych decyzji, podejmują inne decyzje, a efekt jest zwykle większy niż jakikolwiek wynegocjowany rabat.
Co obejmuje ten kierunek
Zakres: główne platformy chmurowe, kontenery, orkiestracja, ciągła integracja i dostarczanie, niezawodność i skalowanie.
Cztery obszary.
Platformy chmurowe. Moc obliczeniowa, pamięć masowa, sieć, tożsamość i usługi zarządzane, które zastępują rzeczy, które zespoły kiedyś same utrzymywały.
Dostarczanie. Pipeline'y, testy automatyczne, strategie wdrożeń i praktyka wydawania oprogramowania.
Operacje. Obserwowalność, reagowanie na incydenty, pojemność i koszt.
Infrastruktura jako kod. Definiowanie środowisk w wersjonowanych definicjach zamiast ręcznie.
DevOps to była zmiana odpowiedzialności, nie nazwa stanowiska
Pierwotny pomysł był prosty: rozdzielenie ludzi, którzy budują oprogramowanie, od ludzi, którzy je obsługują, daje słabe rezultaty po obu stronach. Deweloperzy wypuszczają rzeczy trudne w obsłudze, bo nie ponoszą konsekwencji. Zespoły operacyjne blokują zmiany, bo ponoszą konsekwencje i nie mają wpływu na projekt.
Proponowanym rozwiązaniem była wspólna odpowiedzialność. Ludzie budujący system uczestniczą w jego obsłudze, co zmienia to, co budują.
W wielu organizacjach stało się coś innego. Powstał zespół DevOps, otrzymał pipeline'y i infrastrukturę i został ustawiony między developmentem a produkcją. Czyli poprzedni układ pod nową nazwą, z tym samym przekazywaniem odpowiedzialności.
Trzy rzeczy odróżniające prawdziwą zmianę od zmiany etykiety.
Kogo wzywa się, gdy coś się psuje. Jeśli odpowiedzią nigdy nie są ludzie, którzy to napisali, pętla sprzężenia zwrotnego, dzięki której pomysł działa, nie istnieje.
Czy zespoły mogą wdrażać bez zgłoszenia. Samoobsługowa infrastruktura z barierami ochronnymi jest sednem sprawy. Kolejka przed innym zespołem – nie.
Czy operacyjność jest zaprojektowana od początku. Logowanie, metryki, health checki, łagodna degradacja i bezpieczny rollback to cechy projektowe, i są nieobecne, gdy nikt budujący system nie musi go obsługiwać.
Coraz popularniejsze ujęcie platform engineering to sensowna ewolucja: zespół platformowy buduje utwardzoną drogę, a zespoły produktowe są właścicielami swoich usług na tej drodze. To działa, gdy platforma zmniejsza tarcie, a zawodzi, gdy znów staje się bramkarzem.
Gdzie to się mieści w domenie
Cloud computing i DevOps to szósty z ośmiu kierunków w domenie AI, danych i informatyki Astra Trainer, i to tu inżynieria oprogramowania spotyka się z operacjami. Opiera się na informatyce w zakresie modelu systemów i sieci oraz na systemach IT i sieciach komputerowych w zakresie rozumienia infrastruktury, którą abstrakcje chmury ukrywają, a nie usuwają.
Łączy się ściśle z cyberbezpieczeństwem, bo duża część współczesnej ekspozycji na ryzyko pochodzi z błędnej konfiguracji chmury, oraz z data science, którego pipeline'y i platformy działają właśnie tutaj. Zobacz osiem kierunków tutaj.
Kubernetes to system rozproszony, który teraz obsługujesz
Orkiestracja kontenerów stała się niemal domyślnym wyborem, a uczciwa ocena jest bardziej złożona, niż sugeruje tempo adopcji.
To, co dostajesz, jest realne: spójne wdrożenia, samonaprawa, deklaratywna konfiguracja, przenośność między środowiskami i wspólne słownictwo przenoszące się między pracodawcami.
To, co kosztuje, to system rozproszony ze znaczną powierzchnią operacyjną. Sieć, pamięć masowa, tożsamość, aktualizacje, zarządzanie zasobami i duży ekosystem komponentów, które trzeba utrzymywać aktualne i kompatybilne. Debugowanie problemu może wymagać zrozumienia kilku warstw naraz, a tryby awarii są obce ludziom przychodzącym z tradycyjnej infrastruktury.
Trzy pytania warte zadania przed wdrożeniem i warte ponownego zadania później.
Czy masz skalę, przy której to się opłaca? Korzyści rosną wraz z liczbą usług i zespołów. Dla garstki usług prostsze zarządzane środowiska obliczeniowe często dają więcej przy dużo mniejszym nakładzie na obsługę.
Kto to obsługuje? Albo dedykowany, kompetentny zespół, albo usługa zarządzana, w której dostawca obsługuje płaszczyznę kontrolną, albo uczciwe przyznanie, że obciążenie operacyjne spadnie na ludzi, którzy się na to nie pisali.
Jaka jest alternatywa, którą odrzucasz? Zarządzane usługi kontenerowe i platformy serverless obsługują szeroki zakres obciążeń przy ułamku złożoności, i często są odrzucane bez porównania.
Wdrożenie tego, bo to standard, bez odpowiedniej skali czy zdolności operacyjnej, to jeden z droższych wzorców we współczesnej infrastrukturze, i objawia się jako problemy z niezawodnością przypisywane czemuś innemu.
Niezawodność to decyzja, nie aspiracja
Najbardziej przydatne przeformułowanie w tym kierunku, bo zamienia spór w rachunek.
Każdy mówi, że chce wysokiej dostępności. Dostępność ma stromo rosnącą krzywą kosztu, a każdy dodatkowy poziom niezawodności wymaga zdecydowanie więcej inżynierii, więcej redundancji i więcej dyscypliny operacyjnej niż poprzedni.
Cztery idee, które czynią tę rozmowę praktyczną.
Definiuj niezawodność z perspektywy użytkownika. Nie czy serwer działa, tylko czy działa to, czego ludzie potrzebują, mierzone w terminach zrozumiałych dla kogoś spoza inżynierii.
Ustal wyraźny cel i zaakceptuj jego konsekwencje. Cel zakłada dopuszczalny margines awarii. Ten margines to budżet, a wydawanie go na zaplanowane ryzyko jest jak najbardziej uzasadnione.
Użyj marginesu do sterowania zmianami. Gdy niezawodność wyraźnie mieści się w celu, wdrażaj szybciej i podejmuj więcej ryzyka. Gdy nie mieści się, zwolnij i stabilizuj. To zamienia wieczny spór między tempem a stabilnością we wspólny pomiar.
Ucz się z incydentów bez szukania winnych. Przegląd, który wskazuje, kto popełnił błąd, tworzy ludzi ukrywających błędy. Przegląd, który wskazuje, jakie warunki umożliwiły błąd, tworzy systemy odporne na niego.
Role, nazwane wprost
Inżynierowie i architekci chmury.
Inżynierowie DevOps i platform engineering.
Site reliability engineerzy.
Inżynierowie infrastruktury pracujący w kodzie, nie w konsolach.
Specjaliści od Kubernetesa i platform kontenerowych.
Inżynierowie obserwowalności, rosnąca specjalizacja.
Specjaliści od kosztów i efektywności chmury, łączący rozumienie inżynierskie i komercyjne.
Inżynierowie release i delivery.
Specjaliści od migracji do chmury, gdzie praca jest w równym stopniu organizacyjna, co techniczna.
Kogo można w to przeszkolić
Administratorzy systemów. Największa i najbardziej naturalna pula. Rozumieją systemy operacyjne, sieci i to, co psuje się na produkcji. Czego im brakuje, to praktyki programistycznej: kontrola wersji, testowanie, code review i traktowanie infrastruktury jak oprogramowania.
Inżynierowie sieci. W stronę sieci chmurowych – koncepcyjnie znajomych, ale różniących się na tyle w implementacji, że wymagają realnej nauki.
Inżynierowie oprogramowania. W stronę ról platformowych i niezawodnościowych, potrzebujących połowy operacyjnej i sieciowej.
Administratorzy baz danych. W stronę zarządzanych usług danych i niezawodności.
Personel wsparcia i operacji. W stronę obserwowalności i reagowania na incydenty, mając już instynkt, co się liczy o trzeciej nad ranem.
Inżynierowie bezpieczeństwa. W stronę inżynierii bezpieczeństwa chmury – jednej z najrzadszych dostępnych kombinacji.
Analitycy finansowi pracujący razem z inżynierami, w stronę inżynierii kosztów, gdzie połowa komercyjna już jest obecna.
Konfiguracja, lokalizacja danych i obowiązki ciągłości działania. Błędna konfiguracja chmury to jedna z głównych przyczyn wycieków danych, a dostęp do systemów produkcyjnych powinien być kontrolowany, logowany i podlegać zarządzaniu zmianą. Miejsce przechowywania i przetwarzania danych ma konsekwencje prawne wynikające z ochrony danych i przepisów sektorowych, a wymagania różnią się między jurysdykcjami. Sektory regulowane mają dodatkowe obowiązki dotyczące outsourcingu, testów odporności i planowania wyjścia. Astra Trainer buduje kompetencje inżynierskie i świadomość, gdzie te obowiązki mają zastosowanie. To nie jest porada prawna ani z zakresu zgodności i nie zastępuje wykwalifikowanej oceny.
Co z tego wynieść
Faktura za infrastrukturę to odczyt decyzji architektonicznych, a uporczywy przepał to problem inżynierski przebrany za zakupowy.
DevOps opisywał zmianę w tym, kto ponosi konsekwencje działania oprogramowania, a osobny zespół DevOps często odbudowuje mur, który miał zlikwidować.
Kubernetes daje realną wartość przy realnej skali i przynosi system rozproszony, który teraz obsługujesz – koszt regularnie niedoszacowywany.
Cele niezawodności to decyzje biznesowe ze stromą krzywą kosztu, a jasne określenie celu zamienia wieczny spór we wspólny pomiar.
A twoi administratorzy systemów to najlepsze dostępne źródło inżynierów chmury. Luka dotyczy praktyki programistycznej, nie rozumienia infrastruktury.
Dlaczego koszt chmury to kwestia inżynierska?
Bo faktura odzwierciedla decyzje projektowe: moce zapewnione na rzadkie szczyty, dane przemieszczające się między komponentami, które powinny być razem, pamięć masowa, której nikt nie usuwa, środowiska działające poza godzinami pracy i usługi zarządzane wybrane przy wolumenach, gdzie przestały się opłacać.
Co faktycznie oznaczał DevOps?
Wspólną odpowiedzialność za budowę i obsługę oprogramowania, tak żeby ludzie projektujący system ponosili konsekwencje jego obsługi. Stworzenie osobnego zespołu DevOps między developmentem a produkcją odtwarza przekazywanie odpowiedzialności, które miało zniknąć.
Czy każda organizacja powinna używać Kubernetesa?
Nie. Opłaca się przy wielu usługach i zespołach i przynosi system rozproszony ze znaczną powierzchnią operacyjną. Dla garstki usług zarządzane kontenery lub platformy serverless często dają więcej przy dużo mniejszym nakładzie na obsługę.
Jak ustalać cele niezawodności?
Wyraźnie, z perspektywy użytkownika, rozumiejąc, że każdy dodatkowy poziom dostępności kosztuje znacznie więcej. Powstały margines na awarie staje się budżetem, który steruje tym, ile ryzyka zmian podejmuje zespół.
Kto dobrze przekwalifikowuje się do ról w chmurze i DevOps?
Najpierw administratorzy systemów, potrzebujący praktyki programistycznej, nie wiedzy o infrastrukturze. Potem inżynierowie sieci w stronę sieci chmurowych, deweloperzy w stronę platform i niezawodności oraz personel wsparcia w stronę obserwowalności i reagowania na incydenty.