Czytam książkę i znajduję "...są inżynierami oprogramowania pracującymi w podejściu devops i specjalizującymi się w chmurze AWS." Co oznacza "podejście devops"? Ktoś mi potrafi wyjaśnić jakie są inne podejścia? Pewnie jest jakieś tzw. "podejście tradycyjne"?
1
1
podejście tradycyjne ->
- od bazy danych masz bazodanowca
- od infry masz osobnego gościa
- od frontendu frontendowca
-od backendu backendowca
podejście nowoczesne to miksowanie w różnych konfiugracjach umiejętności i tak deweloper + gość od infry = devops.
5
W korpo wersji tradycyjnej jest osobno zespół devow i osobno zespół opsów którzy często siedzą w innej lokalizacji. Załatwienie czegokolwiek trwa wieki bo to są osobne zespoły i wszystko musi iść oficjalnie przez ticketa.
Potem ktoś wpadł że jak się posadzi tych ludzi razem to praca idzie szybciej.
Ale co autor miał na myśli to nie wiem bo pojęcie devops zostali wypaczone na wszelkie możliwe sposoby
3
U mnie w pracy devops oznacza, że developer Javy powinien sobie sam ogarniać CI/CD, bazy danych (SQL/NoSQL/Cloud), deployment, networking, infra, konfigurację, Linuksa, AWSa i security.
No i jeszcze dobrze jakby rozumiał biznesowe aspekty tego co robi.
3
Tak mnie teraz na to naszło, że to w sumie by było śmieszne jakby ktoś zatrudniał do restauracji ludzi stosując metodykę devops. I tak kucharz musiałby sobie sam z dostarczonych przez pracodawcę materiałów patelnię wyklepać.
3
ToTomki napisał(a):
Tak mnie teraz na to naszło, że to w sumie by było śmieszne jakby ktoś zatrudniał do restauracji ludzi stosując metodykę devops. I tak kucharz musiałby sobie sam z dostarczonych przez pracodawcę materiałów patelnię wyklepać.
Czy ja wiem. Programista w podejściu DevOps serwera też sam nie będzie składał z podzespołów.
Ale pomyśl jakby kucharz potrzebował wyspecjalizowanej osoby od obsługi pierkarnika :P
1
Jakbym chciał bardzo iść w skrajności to bym wysłał kucharza do kopalni żeby wydobywał rudę żelaza
0
W każdej mniejszej czy większej organizacji jest IT które zajmuje się networkingiem, serwerami, storage, drukarkami, komputerami użyszkodników, aplikacjami, bezpieczeństwem, chmurą taką czy inną. Jak coś chciałeś to wystawiałeś ticket, dołczałeś uzasadnienie, uzyskiwałeś akceptacje co trwało przynajmniej kilka dni, jak nie tygodni. Bardzo często zespół nie mógł wydać wersji oprogramowania, a w timesheetach pojawiały się wpisy unutilized. Ktoś zobaczył na raporty, cyferki i wpadł na pomysł, że może programmersi sami ogarną sobie rzeczy których potrzebują.
1
Plus deployment i operacje są teraz często zautomatyzowane ze względu na duża skalę.
Napisałeś serwis to go sam (jako zespół) deployujesz i za niego odpowiadasz, a nie przerzucasz na druga stronę płota.
Czasami to może oznaczać bycie on-call.
3
Jednym zdaniem, jeżeli programiści nie tylko piszą ale również zajmują się administracją i supportem aplikacji na produkcji to jest to devops. Porównaj z podejściem "The wall" przerzucamy aplikację do adminów (bo gotowa lub menago myśli że gotowa) i już niech oni się nią zajmą.
Oprócz tego nurt devops to coś więcej:
- Infra as Code - czyli automatyzacja stawiania całych środowisk, instalacji oprogramowania, immutable VMs, Docker & k8s, generalnie rozwinięcie idei "pets vs cattle"
- Chmura i "sprzęt na zamówienie"
- Rozmywanie się kompetencji, admin to programista, programista to admin. Zespoły cross-functional, jedna lub więcej osoba w zespole ma kompetencje devopsa (potrafi obchodzi się z chmurą i adminowaniem)
- On-call i SRE
- Rozwinięcie idea observability, metryki, tracing, logi i monitoring security.
- Continuous delivery, feature flagi, master zawsze w stanie który da się wgrać na produkcję
Jak widać dużo tego, devops jest trochę jak inżyniera oprgramowania, czapa do której można wrzucić praktycznie wszystko. W tym roku np. modne są rozwiązania security które automatycznie wykrywają ataki itp. w chmurce.
Ludzie polecają książke The Phoenix Project - nie czytałem więc nie oceniam. DevOps jest jak pornografia jak zobaczę to będę wiedział...
3
Podejście DevOps, uzupełniając i upraszczając to co wyżej to sytuacja, kiedy:
Zespół projektowy odpowiada i ma wszystkie potrzebne kompetencje potrzebne do wyprodukowania i utrzymania produktu.
Wewnątrz zespołu istnieją różne role, niektóre bardziej Dev, niektóre bardziej Ops, ale powinny występować wszystkie, żeby nie trzeba było prosić kogoś spoza zespołu o takie rzeczy jak:
- zaprogramowanie czegoś
- skonfigurowanie repozytorium, pipeline, środowiska testowego
- rozwiązanie jakiegoś problemu z aplikacją na produkcji (czy to poprawka w kodzie, czy przebudowa statystyk w bazie danych, nadanie praw do jakiegoś serwerowego katalogu, konfiguracja usługi w chmurze, (w zależności od potrzeb jakie istnieją w projekcie)
Dość ściśle związane z tym jest pojęcie T-Shaped, co oznacza, że nie ma sztywnych, tradycyjnych podziałów ról pomiędzy członkami zespołu (wiem, lewactwo) na np. administratorów, programistów, testerów. Mogą występować specjalizacje, ale każdy członek zespołu powinien mieć jakieś pojęcie o czymkolwiek poza swoją działką, każdy obszar w projekcie powinien mieć więcej niż jedną osobę zdolną do grzebnięcia czegoś. Ma to 2 cele, które widzę:
- redukcja efektu bus factor, czyli zniknięcia kluczowej osoby z projektu, kiedy nagle się okazuje, że nikt nie ma pojęcia o jej działce i
Winter is comming - łatwiejsze i bardziej elastyczne wiązanie poszczególnych obszarów. Czyli programista, który ma jakieś pojęcie o testowaniu i monitoringu (i wizję, że będzie musiał to robić), napisze kod, który będzie łatwiejszy w monitorowaniu i testowaniu, a ktoś od CI/CD zrobi lepszą robotę, jeżeli będzie wiedział chociaż trochę o programowaniu itp.
Łatwiej będzie zrozumieć DevOps, jeżeli pomyślimy o tradycyjnym podejściu i jego problemach. Dev robił produkt, pisał dokumentację jak go instalować i utrzymywać, produkt szedł do Ops, który nie był w stanie zrobić nic w przypadku jakiegoś błędu na produkcji, a każda zmiana była problemem, bo wiadomo, że np. wytwórcom dokumentacji nie zależało w żaden sposób na jej jakości.