Cześć. Ostatnio bardzo dużo pojawia się ofert pracy dla Developerów ze znajomością AWS/azure/GK.
W swojej karierze niestety nie miałem okazji z niczym takim pracować.
Obawiam się, że może mnie to wykluczyć z potencjalnej rekrutacji.
Chociaż wiem też, że byłbym się w stanie tego nauczyć.
Czy ktoś z obecnych miał taką sytuację?
Czy startowaliście na oferty gdzie potrzebny jest np. AWS, nie mając doświadczenia i dostaliście prace?
Fake it till you make it
Musisz wydać kilkaset $$$ i sobie postawiać maszynki by sie nauczyć, albo próbować coś robić na local-stacku
Free tier w AWS to często podpucha i jest sporo kruczków, trzeba sie mocno pilnować
CoderOne napisał(a):
Musisz wydać kilkaset $$$ i sobie postawiać maszynki by sie nauczyć, albo próbować coś robić na local-stacku
Free tier w AWS to często podpucha i jest sporo kruczków, trzeba sie mocno pilnować
oj tak byczku :D Tak samo jak Azure. Wszystko gratis, same niezbędne free rzeczy do szkolenia, a tu cyk rachuneczek na ok 300 zł.
Niby nic wielkiego, ale jakbym czegoś nie szukał w historii płatności to pewnie bym się o tym w życiu nie dowiedział, bo ściągało sobie z karty po cichutku :D
@cerrato ja akurat realizowałem jakiś scenariusz szkoleniowy, gdzie wszystko miało być bezpłatne, a podpucha polegała na tym że aby spasować do siebie wszystkie elementy scenariusza to trzeba było wybrać inną maszynkę wirtualną niż ta bezpłatna, najbardziej podstawowa, bo coś tam się nie zgadzało i nie chciało mnie przepuścić. A o tym, że maszynka zalecana okazała się płatna to już się dowiedziałem właściwie dopiero po tym jak zapłaciłem rachunek i przeglądałem rachunki na koncie azure.
Jak to mówią chmura, to tylko czyjś komputer... Do rzeczy.
Jeśli nie startujesz na Cloud Engineera czy Architekta, tylko patrzysz z perspektywy deva, który używa chmurowych zabawek do hostowania aplikacji bez wchodzenia w detale, to jest bardzo łatwo podkoloryzować podczas rozmowy. Opanuj podstawy chmury, jakiś cert typu Associate będzie przydatny i patrz:
Większość czasu pracujemy przy aplikacjach w architekturze kwadrat, kwadrat, beczka (frontend, backend, baza). Jak taką architekturę przełożyć na język chmury? Bardzo prosto:
Do tego dodaj zarządzanie domeną, jakiś Vault do trzymania secretów Azure KeyVault lub AWS Secrets Manager, monitoring za pomocą Azure Monitor/AWS CloudWatch. Infrastrukturę tworzyliśmy za pomocą Terraforma i gotowe.
Oczywiście zanim wyskoczysz z taką historyjką dobrze jest zbudować sobie takie rozwiazanie od zera w domu, bo diabeł tkwi w szczegółach i taka architektura jak wyżej mimo, ze wygląda prosto, to jednak trzeba się trochę napracować, żeby to wszystko pospinać do kupy. Do tego jak trafisz na ogarniętą osobę, to mogą paść bardziej szczegółowe pytania, takie jak:
https://mojasuperaplikacja.z19.web.core.windows.net
Powodzenia!
@Black007 Tak jak Pinek napisał. Problem z tym jest taki, że możesz trafić do miejsca gdzie dadzą ci prawa admina i możesz sobie krzywdę zrobić. Znam taką historię, nie powiem od kogo, ale gdybym strzelił w ten krzywy ryj, to bym się znokautował XD W dzisiejszych czasach nie brakuje januszexow i takie sytuacje się zdarzają niestety coraz częściej, a przynajmniej w mojej bańce.
Pomysł z free tierami jak już wyżej było napisane, też może być nietrafiony. Opcje:
Ja wprawdzie nie startowałem do firmy gdzie wymagano znajomości chmur wszelakich, ale zastałem w firmie AWS (chociaż go nie wymagano) i podstawowe rzeczy jestem w stanie zrobić. Natomiast bardzo słusznie napisał @Dregorio, ja dodam że ze znajomością rozwiązań chmurowych jest trochę jak z prawem jazdy kat. B- jak je masz, to zwykle masz jakieś tam umiejętności prowadzenia pojazdu (czasem słabe), ale samochodem osobowym większość tras zrobisz (to analogia do dev-a, który coś ma w chmurze robić- na podstawowym poziomie sobie większość poradzi). Sytuacja się komplikuje, jak wsadzą Cię do bolidu F1 albo do ciągnika siodłowego z wielką platformą, na której wieziesz np. łopaty wiatraka- tutaj jazda dla przeciętnego kierowcy bez umiejętności skończy się tym, że albo w ogóle nie ruszy albo się roztrzaska- to analogia do poważnych problemów w chmurze, gdzie nie wystarczy być devem, który postawił jedno środowisko i przerobił dwa tutoriale- tu już wymagany jest ktoś a la admin, który ma jakąś wiedzę, wie co robić w razie wtopy, wie co nieco o sieciach, zna jakieś kruczki itp.
gdzie nie wystarczy być devem, który postawił jedno środowisko i przerobił dwa tutoriale- tu już wymagany jest ktoś a la admin, który ma jakąś wiedzę, wie co robić w razie wtopy, wie co nieco o sieciach, zna jakieś kruczki itp.
Ale to inny case trochę. Dlaczego programista Java ma posiadać tak zaawansowaną znajomość chmury? Może jeszcze rozwiązania virtual WAN do tego dodajmy i routing BGP?
To jest zadanie Cloud Engineera/Archiecta, żeby zaprojektować i stworzyć środowisko w taki sposób aby było bezpieczne. W tym celu stosuje się Landing Zone'y i zespół od chmury dostarcza gotowe szablony, blue printy czy moduły w TF, z których programiści muszą korzystać.
Jeżeli ktoś wymaga od programisty postawienia i zarządzania środowiskiem chmurowym end ot end to jest oznaka do ewakuacji z firmy lub projektu bo to nie jest zadanie programisty Java czy czegokolwiek innego.
Bo można tego od niego oczekiwać
Ja polecam się pobawić aws z terraformem i localstack.
Jest masa zasobów które pasywnie mało kosztują. VPC z subnetami z publicznymi IP kosztuje nic o ile nic w tym nie zdeployujesz. Lambda kosztuje zasadniczo nic przy okazyjnym używaniu. Koszty S3 dla małej ilości obiektów są pomijalne. IAM nic nie kosztuje. Na GHA masz wystarczająco minut CI na odpalanie różnych rzeczy. ECS fargate do jobów i tego typu bytów jest tani. DynamoDB z pay-per-use jest stosunkowo tanie dla małego ruchu.
Pamiętaj tylko żeby albo odpalać aws-nuke albo (lepiej) wszystko trackować terraformem albo innym IaC, wtedy nie zapomnisz o jakimś syfie który z palca przez przypadek zdeployowałeś w korei południowej. Na Azure jest o tyle lepiej że wszystko* leży sobie w jakiejś resource groupie, jak zaorasz resource group to zasobów też już nie ma.
Wiesz jak brzmi ten post dla osób, które o AWS nic nie wiedzą (bo przecież o to chodzi, że nie umieją go)? ;D
Pracowałem w firmach jako Java Developer gdzie miałem coś robić w Cloudzie (Terraform/K8s) i raczej nie polecam. Robiłem na raz za dwie role.
Preferuję firmy, gdzie główny nacisk kładzie się na programowanie głównie. Np. teraz w mojej firmie jest Cloud -> AWS. Ale programiści mój zespół tego raczej nie ruszamy, głównie piszemy kod i wypushujemy do Githuba. Wiadomo, znaleźć logi, sprawdzić deployment, wersję, dopisać coś do yaml'a trzeba umieć, ale jest to wiedza podstawowa.
U mnie w zespole jest na tyle wymagająca sama praca jako programisty tj. projektowanie rozwiązań, tabel bazodanowych, pisaniu efektywnego kodu (bardzo dużo piszemy kodu wielowątkowego i asynchronicznego), do tego dochodzi review innych programistów, rozmowy z biznesem, spotkania Scrumowe. Że jak mam pomyśleć by jeszcze bawić się w samograjka co tam na AWSie będzie coś w Terraformie czy Pulumi tykał albo konfiguracji Gatewaya to spiepszyłbym z tej roboty, albo mógłbym robić ale za 35k netto + vat.
Żeby nie było, że jestem ignorantem to mam z Kubernetesa certyfikat (CKAD) z Azure Administratora oraz z AWS'a Solutions Architect Associate + Professional. Więc wiem o czym mówię. Firmy po prostu chcą ciąć koszta i szukają samograjków od wszystkiego. Tylko nie zdają sobie sprawy, że wtedy np. jakość kodu może spać, bo pracownik nie ma czasu i mocy kognitywnych pisać efektyny kod i wydajny.
Im więcej się narzuca obowiązków pracownikowi to tym mniej efektywny i wydajny jest.
PawelP6 napisał(a):
Pracowałem w firmach jako Java Developer gdzie miałem coś robić w Cloudzie (Terraform/K8s) i raczej nie polecam. Robiłem na raz za dwie role.
A u mnie właśnie od takich łączonych ról zaczęła się przygoda z chmurą i polecam, o ile jest to robione z głową*.
Inaczej od zera według mnie ciężko się nauczyć chmury żeby móc później spokojnie aplikować na role, które takiej znajomości wymagają.
*Co rozumiem przez łączenie takich ról z głową?
Między innymi to co wyżej pisał @markone_dev, czyli że to zespół platformowy składający się z Cloud Engineerów/Architektów/DevOpsów (zwał jak zwał...) zajmuje się przygotowaniem platformy i tzw. Landing Zone gdzie lądują zespoły aplikacyjne ze swoimi apkami. Wtedy od strony tego Terraforma i k8s owszem zajmujesz się trochę infrastrukturą, ale tylko w obrębie własnej aplikacji i wpasowujesz się w już opracowane wymagania dotyczące tej infry.
Np. możesz dostać namespace w ramach klastra k8s zarządzanego przez zespół platformowy i ja jak najbardziej jestem za tym, żeby to zespół aplikacyjny odpowiadał end to end za wdrożenie/monitoring/utrzymanie swojej aplikacji na takim klastrze. To czy zrobi to programista, czy do zespołu dołączy ktoś w roli "DevOpsa" i będzie się tym zajmował to już kwestia wtórna.
Tylko to już któryś w ostatnim czasie wątek o tym, że chmura jest co raz częściej wymagana, a ja biedak pracuję w legacy i jak się tej chmury nauczyć. No właśnie najlepiej w taki sposób, że jako programista zaczynasz się zajmować się takimi rzeczami jak tworzenie zasobów chmurowych pod swoją apkę i jej późniejsze wdrażanie i monitorowanie.
Chyba, że ktoś tego nie chce się uczyć i robić, ale wtedy jedynym rozwiązaniem pozostaje odrzucanie ofert gdzie wymagana jest znajomość chmury.
Klaun napisał(a):
PawelP6 napisał(a):
Np. możesz dostać namespace w ramach klastra k8s zarządzanego przez zespół platformowy i ja jak najbardziej jestem za tym, żeby to zespół aplikacyjny odpowiadał end to end za wdrożenie/monitoring/utrzymanie swojej aplikacji na takim klastrze.
Wtedy od strony tego Terraforma i k8s owszem zajmujesz się trochę infrastrukturą, ale tylko w obrębie własnej aplikacji i wpasowujesz się w już opracowane wymagania dotyczące tej infry.
Żeby nie było, ale to się sprawdza jak robisz sklep lokalny ale nie w firmach o globalnym zasięgu, np. bankach, insytutcjach finansowych raczej nie. Przełożenie tej odpowiedzialności co wyżej napisałeś na zespół programistów który i tak ma wiele rzeczy do ogarniania od strony biznesowej, implementacji, testach, wydajności, pisaniu efektywnego i wydajnego kodu to nic innego jak dołożenie im obowiązków.
Ewentualnym rozwiązaniem (moim zdaniem najlepszym) jest dostarczanie zespołu Developerskiemu przez zespół Devops gotowych modułów Terraformowych (takich bibliotek), by on sobie mógł jakoś dostosować parametry i puścić to na pipeline, ale nic więcej. Dzięki temu, zespół DevOps wie także, że każdy zespół Developerski używa tych samych modułów Terraformowych i w nich zawartych patternów. Może np. podbijać bibliotekę Terraformową i dać w emailu ogłoszenie. Wtedy zespół Devowy sobie podbija wersje modułu.
Robienie coś więcej przez zespół Dev to to proszenie się o problemy.
PawelP6 napisał(a):
Żeby nie było, ale to się sprawdza jak robisz sklep lokalny ale nie w firmach o globalnym zasięgu, np. bankach, insytutcjach finansowych raczej nie.
Nie, dlaczego? Przecież na tym m.in. polega metodyka DevOps, że to zespół aplikacyjny ma zajmować się wdrażaniem/utrzymaniem swojej aplikacji, a w chmurze też utrzymaniem swojej infrastruktury.
A podejście takie widziałem właśnie m.in. w bankach :)
Przełożenie tej odpowiedzialności co wyżej napisałeś na zespół programistów który i tak ma wiele rzeczy do ogarniania od strony biznesowej, implementacji, testach, wydajności, pisaniu efektywnego i wydajnego kodu to nic innego jak dołożenie im obowiązków.
Dołożenie obowiązków zespołom aplikacyjnym, ale zabranie obowiązków scentralizowanym zespołom "DevOps" (centralny zespół DevOps to trochę taki oksymoron jak dla mnie).
A raczej łatwiej jest skalować organizację w taki sposób, że jeśli potrzeba to do zespołów aplikacyjnych dorzucasz dodatkową osobę z jakimś tam pojęciem o infrze chmurowej niż tworzyć centralny zespół-moloch, który ma się zajmować wszystkimi projektami chmurowymi w ramach organizacji.
Już wystarczy że organizacje idące w chmurę muszą zbudować centralny zespół platformowy zajmujący się corem infrastruktury chmurowej (hybrid connectivity, identity, governance itp.), co zazwyczaj zajmuje im dobre miesiące jak nie dłużej :)
Przy czym ja nie mówię, że w skład zespołu aplikacyjnego wchodzi tylko zespół deweloperski, bo w skład takiego zespołu może też wchodzić gość od infry/chmury i nie widzę w tym nic złego.
Ewentualnym rozwiązaniem (moim zdaniem najlepszym) jest dostarczanie zespołu Developerskiemu przez zespół Devops gotowych modułów Terraformowych (takich bibliotek), by on sobie mógł jakoś dostosować parametry i puścić to na pipeline, ale nic więcej. Dzięki temu, zespół DevOps wie także, że każdy zespół Developerski używa tych samych modułów Terraformowych i w nich zawartych patternów. Może np. podbijać bibliotekę Terraformową i dać w emailu ogłoszenie. Wtedy zespół Devowy sobie podbija wersje modułu.
Akurat podejścia z jakimiś jedynymi słusznymi modułami to ja za bardzo nie lubię. Jeśli mówimy w kontekście chmury/k8s to od zapewnienia odpowiedniej konfiguracji usług zgodnie z wymaganiami są chmurowe polityki governance albo jakiś gatekeeper na klastrze, które po prostu zablokują deployment niepoprawnie skonfigurowanej usługi. A to czy zespół to sobie wdroży przez Terraform, Pulumi, czy jakiś CLI to już w idealnym świecie mogłoby zależeć tylko od ich preferencji.
Robienie coś więcej przez zespół Dev to to proszenie się o problemy.
Ja pisałem o zespole aplikacyjnym, a nie zespole deweloperskim. W składzie zespołu aplikacyjnego w poważnych projektach zazwyczaj występują też inne techniczne role jak jakiś tester, czy właśnie tzw. DevOps (potocznie mówiąc gość od infry). Przy czym tak jak napisałem - to czy zrobi to programista, czy do zespołu dołączy ktoś w roli "DevOpsa" i będzie się tym zajmował to już kwestia wtórna..
Tamten post w skrócie miał powiedzieć jedynie to że jeśli ktoś od dewelopera wymaga umiejętności skonfigurowania e2e platformy chmurowej dla całej organizacji to ma nie po kolei w głowie, ale jeśli wymaga tylko zajmowania się usługami wchodzącymi w skład projektu to zasadniczo nie widzę w tym nic złego i jest to według mnie najlepszy sposób na nauczenie się chmury.
Klaun napisał(a):
Akurat podejścia z jakimiś jedynymi słusznymi modułami to ja za bardzo nie lubię. Jeśli mówimy w kontekście chmury/k8s to od zapewnienia odpowiedniej konfiguracji usług zgodnie z wymaganiami są chmurowe polityki governance albo jakiś gatekeeper na klastrze, które po prostu zablokują deployment niepoprawnie skonfigurowanej usługi. A to czy zespół to sobie wdroży przez Terraform, Pulumi, czy jakiś CLI to już w idealnym świecie mogłoby zależeć tylko od ich preferencji.
Po tym, co piszesz, to odnoszę wrażenie że firma w której pracowałeś to chyba jakiś lokalny sklep internetowy na Podlasiu.
W większych korporacjach wygląda to inaczej. Opiszę Ci swoją argumentację.
Mając moduły Terraformowe, które pod spodem mają swoją logikę do stawiania klastra np. Kubernetesa, czy Redis'a, czy Gatewaya zespół DevOpsowy w pewien sposób jest stanie nakreślić standardy które panują w firmie. Moduł w Terraformie wygląda tak, że zazwyczaj podaje się zestaw parametrów wejściowych i dostaje się parametry wyjściowe. Ewentualnie lekkie dokonfigurowanie czegoś np. Identity, czy użytkownika, czy coś innego. Dane moduły są przechowywane na Githubie np. przestrzeni
Pawel6G - Infra - Modules.
W tej przestrzeni składowane są repozytoria z tymi modułami, do których zazwyczaj commitują goście z Clouda/Infrastruktury i udostępniają je całej firmie.
Następnie gdy dołącza nowy zespół to od razu wchodzi sobie w przestrzeń Pawel6G - Infra - Modules i widzi jakie moduły są. Chcą postawić klaster k8s na swojej subskrypcji AWSowej? Biorą dany moduł, czytają dokumentacje, ustawiają parametry wejściowe, puszczają na pipeline i mają cluster postawiony w 20 minut.
Gdyby każdy zespół w firmie miał tak robić jak Ty opisałeś, to pomyśl ile firma by straciła pieniędzy globalnie xD Niezły z Ciebie biznesmen.
Dodatkowo, gdy wyjdzie jakaś luka podatności bezpieczeństwa to jak masz 50 zespołów to jak to wystarczy by tylko w centralnym module ją załatać i globalnie podbić dla wszystkich zespołów dany moduł.
Dodatkowo, dzięki takiemu podejściu w firmie każdy zespół ma utarte standardy DevOpsowe i łatwo np. pracownikom przechodzić z zespołu do zespołu, czy podjąć jakieś zastępsto.
Klaun napisał(a):
PawelP6 napisał(a):
. A to czy zespół to sobie wdroży przez Terraform, Pulumi, czy jakiś CLI to już w idealnym świecie mogłoby zależeć tylko od ich preferencji.
Jeszcze raz pomyśl sobie jak masz zespołów 50 devowych i daj im wolną amerykankę by sobie infrę robili w czym tam chcą xD A potem zapanuj nad tym.
Teraz zastanów się, przejdź na spokojnie wokół bloku i przemyśl moje rozwiązanie o którym napisałem zamiast je negować.
To się nazywa Platform Engineering i to jest obecnie na topie.
Kiedyś nie było Terraforma, k8s itd.
DevOps to się zaczynał jak admini nie gadali z developerami i był problem np. zrobić deploy .wara na webserver, bo się coś wywalało. Oczywiście wina zawsze była tej drugiej strony.
PawelP6 napisał(a):
Po tym, co piszesz, to odnoszę wrażenie że firma w której pracowałeś to chyba jakiś lokalny sklep internetowy na Podlasiu.
W większych korporacjach wygląda to inaczej. Opiszę Ci swoją argumentację.
Wrażenie możesz mieć, ale już pisałem, że widziałem takie podejście m.in. w bankach (a pracowałem w kilku jako konsultant właśnie przy wdrażaniu platform chmurowych).
Mając moduły Terraformowe, które pod spodem mają swoją logikę do stawiania klastra np. Kubernetesa, czy Redis'a, czy Gatewaya zespół DevOpsowy w pewien sposób jest stanie nakreślić standardy które panują w firmie. Moduł w Terraformie wygląda tak, że zazwyczaj podaje się zestaw parametrów wejściowych i dostaje się parametry wyjściowe. Ewentualnie lekkie dokonfigurowanie czegoś np. Identity, czy użytkownika, czy coś innego. Dane moduły są przechowywane na Githubie np. przestrzeni
Pawel6G - Infra - Modules.W tej przestrzeni składowane są repozytoria z tymi modułami, do których zazwyczaj commitują goście z Clouda/Infrastruktury i udostępniają je całej firmie.
Następnie gdy dołącza nowy zespół to od razu wchodzi sobie w przestrzeń Pawel6G - Infra - Modules i widzi jakie moduły są.Gdyby każdy zespół w firmie miał tak robić jak Ty opisałeś, to pomyśl ile firma by straciła pieniędzy globalnie xD Niezły z Ciebie biznesmen.
Dodatkowo, dzięki takiemu podejściu w firmie każdy zespół ma utarte standardy DevOpsowe i łatwo np. pracownikom przechodzić z zespołu do zespołu, czy podjąć jakieś zastępsto.
Fajnie, ale ja nigdzie nie pisałem, że podejście ze współdzielonymi jedynymi słusznymi modułami nie działa i nie ma zalet, tylko że ja takiego podejścia nie lubię. Tak samo jak bym nie lubił podejścia gdzie masz jedyną słuszną bibliotekę do logowania, obsługi kolejek, cacheowania czy czegoś podobnego utrzymywaną przez jakiś centralny zespół i jak ci czegoś brakuje to pisz tickety i czekaj dniami/tygodniami aż zaimplementują coś co sam byś sobie zrobił w kilka godzin.
A podejścia z takimi modułami nie lubię, bo żeby obsłużyć potrzeby wielu różnych zespołów zazwyczaj i tak kończy się na tym, że taki moduł nie wprowadza jakiejś zbyt dużej abstrakcji nad modułem dostarczonym przez provider Terraformowy dla danej chmury. Jak już wspomniałeś o Redisie to zobacz sobie na możliwości konfiguracji Redisa w Azure i powiedz co tam jest takiego trudnego, że centralny moduł będący przykryciem tego wbudowanego by wnosił jakąś wielką wartość? https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/redis_cache Większość tego co jest dostępne do skonfigurowania i tak by musiało być wystawione jako parametry xD Ewentualnie co by mogło zostać ukryte to jakieś konfiguracje security typu wersja TLS, wymaganie szyfrowania ruchu albo włączony/wyłączony dostęp publiczny (całe 3 propertiesy będące boolem, albo enumem). Tylko marny według mnie wtedy z takiego modułu pożytek, jak tą poprawną konfigurację i tak zapewnisz (bo musisz) politykami po stronie chmury.
Kolejne jest to, że i tak nie wymusisz na każdym stosowania tych modułów (a przynajmniej ja nie znam sensownego sposobu żeby to zrobić, gdzie nawet jakbym znał to bym tego nie chciał robić 
), więc na potrzeby standaryzacji i spełnienia wymogów pod kątem security/compliance i tak potrzebujesz mieć zaimplementowane chmurowe polityki governance.
Chcą postawić klaster k8s na swojej subskrypcji AWSowej? Biorą dany moduł, czytają dokumentacje, ustawiają parametry wejściowe, puszczają na pipeline i mają cluster postawiony w 20 minut.
Czyli mniej więcej wygląda to wtedy tak samo jak w sytuacji gdy nie masz swojego modułu tylko korzystasz z modułu dostarczonego przez providera dla danej chmury. Wchodzisz do dokumentacjij, ustawiasz parametry wejściowe, puszczasz pipeline i w 20 minut masz klaster.
Dodatkowo, gdy wyjdzie jakaś luka podatności bezpieczeństwa to jak masz 50 zespołów to jak to wystarczy by tylko w centralnym module ją załatać i globalnie podbić dla wszystkich zespołów dany moduł.
Nie wiem jak chcesz to globalnie podbić, ja jestem zwolennikiem podejścia gdzie to zespoły aplikacyjne odpowiadają za szablony IaC dla swojego projektu, więc co najwyżej mógłbyś ich poinformować że jest nowa wersja modułu i niech podbijają po swojej stronie. Ale wtedy dokładnie to samo mógłbyś zrobić nie mając swoich modułów 
Poza tym, patrząc że w IaC zazwyczaj deklaratywnie na dość wysokim poziomie abstrakcji definiujesz co ma się wytworzyć, to tak na szybko nie wiem o jakich lukach bezpieczeństwa mówisz. Bo jak to luka od strony usługi to dostawca chmury zazwyczaj to poprawi sam po swojej stronie bez twojej ingerencji, a jak to niepoprawne skonfigurowanie usługi i wymaga to np. zmiany jakiegoś propertiesa konfiguracyjnego to tak samo ogarniesz to mając własny moduł albo go nie mając bo:
non-compliant zasobach odpali akcję remediation i przestawi co trzeba
Jeszcze raz pomyśl sobie jak masz zespołów 50 devowych i daj im wolną amerykankę by sobie infrę robili w czym tam chcą xD A potem zapanuj nad tym.
Teraz zastanów się, przejdź na spokojnie wokół bloku i przemyśl moje rozwiązanie o którym napisałem zamiast je negować.
A pomyśl co się stanie jak każdy zespół będzie mógł od strony kodu pisać w różnych językach i używać dowolnych bibliotek, a nie tylko tych jedynych słusznych.
A nie, czekaj. Nic się nie stanie i zazwyczaj tak to wygląda, że nie masz jedynego słusznego stacku we wszystkich projektach.
Mając moduły Terraformowe, które pod spodem mają swoją logikę do stawiania klastra np. Kubernetesa, czy Redis'a, czy Gatewaya zespół DevOpsowy w pewien sposób jest stanie nakreślić standardy które panują w firmie.
W teorii. Bardzo szybko dojdziesz do problemów opisanych przez @Klaun Każdy projekt ma inne wymagania i nie da się dostarczyć jednego modułu dla wszystkich bo zawsze znajdzie się ktoś kogo taki szablon będzie ograniczał. I co? Powiesz mu autorytarnie NIE? Że ma robić jak mądre głowy nakazały i basta? Dobre sobie... Zaraz byś miał na głowie wniosek o zrobienie wyjątku bo to strategiczny projekt. A jak wiemy w korpo każdy projekt jest strategiczny.
Jeszcze raz pomyśl sobie jak masz zespołów 50 devowych i daj im wolną amerykankę by sobie infrę robili w czym tam chcą xD A potem zapanuj nad tym.
Nieprawda. W moim dużym korpo właśnie tak to działa. Mamy 1000 razy więcej zespołów i korzystamy z różnych chmur AWS, Azure i GCP. Kluczem do sukcesu jest landing zone'a z ustawionymi politykami, sieciami, routingiem, transit gatewayem żeby się wpiąć do sieci wewnętrznej i kilkoma innymi rzeczami oraz narzędzie CSRM które automatycznie monitoruje całą infrastrukturę chmurową. Dzięki temu tworząc konto np w AWS dostaję już podstawową sieć i polityki. Nie muszę kombinować z ręcznym deployem Transit Gatewaya, żeby spiąć się z siecią wewnętrzną.
W tej sytuacji jeżeli twoje rozwiązanie nie spełnia wymagań/reguł zdefiniowanych w CSRM, to dostajesz automatyczny monit i musisz zareagować i to poprawić. Brak reakcji z twojej strony skutkuje zablokowaniem konta. Chcesz postawić infrę Terraformem? Proszę bardzo. A może Pulumi? Nie ma sprawy. Jak coś spieprzysz albo zrobisz niezgodnie ze sztuką, np będziesz chciał wystawić VM-kę z publicznym IP to albo polityka Landing Zone'y ci nie pozwoli albo pójdzie monit z CSRM i odpowiedni ludzie się tym zainteresują a w przypadku braku twojej reakcji ci ją wyłączą.
Inny przykład z mojego podwórka - nie da się utworzyć publicznego S3 bucketu. Polityka landing zone'y ci na to nie pozwala.
Tak to się właśnie robi we współczesnym świecie. To o czym piszesz - wspólne moduły TF-a to sobie możesz na poziomie prooduktu organizować, ale nie na poziomie globalnym przedsiębiorstwa gdzie masz tysiące zespołów i różne stacki technologiczne.
Klaun napisał(a):
(a pracowałem w kilku jako konsultant właśnie przy wdrażaniu platform chmurowych).
A przy ich utrzymaniu też czy gwarancja do bramy i się nie znamy?
No nie przy utrzymaniu, bo od tego były zespoły platformowe po stronie klienta.
Tylko jak już w początkowej fazie przy migracji kilkunastu projektów ciężko jest napisać moduł TF będący jednocześnie abstrakcją nad modułem z providera, która rzeczywiście upraszcza wdrożenia i nie powoduje problemów z tym że zespół X potrzebuje tego, a zespół Y i Z jednak czegoś czego nasza abstrakcja nie uwzględnia to tym bardziej będzie to trudne jak pojawi się 100 kolejnych projektów mających korzystać z tego modułu.
Więc nie wiem do czego dążymy z tym pytaniem, ale utrzymanie to tutaj chyba tylko jeszcze bardziej pokaże, że takie rozwiązanie się nie zeskaluje i ostatecznie zespoły będą wołały nie korzystać z tych centralnych modułów i wracamy do tego, że zgodność z organizacyjnymi regułami musi być zapewniona w inny sposób.
Zmierzamy do tego, że robisz rozwiązanie tak żeby było odhaczone i elo, i z tym masz doświadczenie, a nie ze zrobieniem solidnej infrastruktury, która ma działać długoterminowo dla dużej organizacji. Ja nie mówię, że nie masz ogólnie racji. Mówię tylko, że próbujesz nam wmówić, że masz rację, bo masz autorytet, a Twój autorytet jest, delikatnie mówiąc, wątpliwy.
ToTomki napisał(a):
Zmierzamy do tego, że robisz rozwiązanie tak żeby było odhaczone i elo
Robię tak żeby było jak najlepiej zgodnie z moim aktualnym stanem wiedzy na podstawie doświadczenia i na podstawie dokumentacji cloud adoption framework różnych dostawców chmurowych.
Mówię tylko, że próbujesz nam wmówić, że masz rację, bo masz autorytet, a Twój autorytet jest, delikatnie mówiąc, wątpliwy.
? A gdzie ja się wypowiadam z tonem, że jest tak jak ja mówię i kropka?
Bo ja to raczej z drugiej strony widzę takie zagrywki, np. właśnie teraz twoją gdzie to sobie wymyśliłeś że nie robię tak żeby było dobrze, tylko żeby było odhaczone.
Przecież wcześniej za każdym razem podawałem argumenty dlaczego według mnie ten albo inny sposób nie zadziała, albo nie ma znaczących zalet nad alternatywami.
Przejrzyj może jeszcze raz kilka ostatnich wypowiedzi w tym wątku i spróbuj na spokojnie określić kto próbuje się wypowiadać z pozycji autorytetu, a kto argumentuje to co pisze. Bo tak na szybko to ja na razie usłyszałem że:
Więc proponuję po prostu odnieść się do moich argumentów z poprzednich 2-3 postów 
Ja się odniosłem tylko do jednego argumentu, który widzę że jest wadliwy, nic więcej.
markone_dev napisał(a):
W teorii. Bardzo szybko dojdziesz do problemów opisanych przez @Klaun Każdy projekt ma inne wymagania i nie da się dostarczyć jednego modułu dla wszystkich bo zawsze znajdzie się ktoś kogo taki szablon będzie ograniczał. I co? Powiesz mu autorytarnie NIE?
Pracuje w korpo gdzie liczba pracowników to 8k a przychód to około +- 5 miliardów dolarów rocznie.
Tam jak nowy zespół przychodzi to na większość rzeczy są gotowe moduły Terraformowe przygotowane przez zespół platformowy DevOpsów. Są gotowe moduły np. Kubernetesa, Kafki, Gateway'e, Redisa, Identity, Argo no dosłownie większość. Tak samo były moduły do stawiania baz danych.
Większość zespołów Java mają dość utartą ścieżkę developemtnu rzeczy i ten pomysł świetnie się sprawdza.
markone_dev napisał(a):
Powiesz mu autorytarnie NIE?
Trzeba się obracać wokół rozwiązań, które panują w danej firmie. Jeżeli zasadne będzie utworzenie nowego modułu na potrzeby jakiegoś zespołu, biznesowo się to będzie spinało i miało uzasadnienie to taki moduł można stworzyć.
Klaun napisał(a):
A to czy zespół to sobie wdroży przez Terraform, Pulumi, czy jakiś CLI to już w idealnym świecie mogłoby zależeć tylko od ich preferencji.
Tak, daj Devom wolną amerykankę w dużym korpo, niech każdy zespół stawia infrę w czym chce i nie zważaj na koszta. Niech każdy zespół stawia Kubernetesa na swój sposób, tak samo Kafke. Łatwo w ten sposób przepalać hajs. Ale jak firma pali dolarami w piecu to można i tak. Modne to było za czasów Covida.
To co opisujesz to średniowieczne podejście, gdzie jest jakiś centralny zespół który "wie lepiej". Niczym się to nie różni od niesławnych architektów z wieży z kości słoniowej, którzy mówią wszystkim zespołom co mogą i czego nie mogą.
Nikt ci nie broni tworzyć modułów terraformowych i wymuszania na wszystkich zespołach używania terraforma i tych jedynych wspaniałych modułów, z tym, że jest to podejście średniowieczne i nie sprawdzające się w obecnych czasach na poziomie dużych przedsiębiorstw, które używają różnych chmur i różnych narzędzi.
Obecnie wdraża się rozwiązania bardziej elastycznie i daje więcej swobody zespołom w dobrze technologii i architektury swoich rozwiązań. Kluczem do sukcesu jest wdrożenie procesów i narzędzi do observability i monitoringu, nie tylko wspomniany wyżej przeze mnie CSRM, ale też FinOps jak choćby Flexera, gdzie dobrze widać który zespół/projekt generuje jakie koszty, landing zone'y dla nowych kont chmurowych i rozwiązania self-service za pomocą których zespoły mogą sobie zamawiać usługi na podstawie przedefiniowanych szablonów.
Więc podsumowując masz zespół Cloud Platform który dostarcza procesy i narzędzia typu governance, observability, landind-zone'y. Mogą być też jakieś moduły Terraformowe jak ktoś chce ich użyć, ale kluczem jest tutaj danie swobody zespołom produktowym, bo to oni wiedzą lepiej czego potrzebują.
PawelP6 napisał(a):
Trzeba się obracać wokół rozwiązań, które panują w danej firmie. Jeżeli zasadne będzie utworzenie nowego modułu na potrzeby jakiegoś zespołu, biznesowo się to będzie spinało i miało uzasadnienie to taki moduł można stworzyć.
Takie rozwiązanie to chmurowy odpowienik in-house'owego frameworka do klepania aplikacji. Tyle, że dla niepoznaki framework jest rozbity na mniejsze moduły. To może działać, da się tak stworzyć soft robiący pieniądze, owszem, ale nasze community dawno stwierdziło, że zazwyczaj nie ma to sensu i jest tylko kulą u nogi, o ile nie jesteś Googlem czy Facebookiem - chociaż i oni często wchodzą na minę.
PawelP6 napisał(a):
Tak, daj Devom wolną amerykankę w dużym korpo, niech każdy zespół stawia infrę w czym chce i nie zważaj na koszta. Niech każdy zespół stawia Kubernetesa na swój sposób, tak samo Kafke. Łatwo w ten sposób przepalać hajs. Ale jak firma pali dolarami w piecu to można i tak. Modne to było za czasów Covida.
Do kontrolowania budżetu są inne narzędzia, moduły terraforma na niewiele się zdadzą jak jakaś apka zacznie ci logować 10gb danych na minutę.
markone_dev napisał(a):
To co opisujesz to średniowieczne podejście, gdzie jest jakiś centralny zespół który "wie lepiej". Niczym się to nie różni od niesławnych architektów z wieży z kości słoniowej, którzy mówią wszystkim zespołom co mogą i czego nie mogą.
Nikt ci nie broni tworzyć modułów terraformowych i wymuszania na wszystkich zespołach używania terraforma i tych jedynych wspaniałych modułów, z tym, że jest to podejście średniowieczne i nie sprawdzające się w obecnych czasach na poziomie dużych przedsiębiorstw, które używają różnych chmur i różnych narzędzi.
Obecnie wdraża się rozwiązania bardziej elastycznie i daje więcej swobody zespołom w dobrze technologii i architektury swoich rozwiązań. Kluczem do sukcesu jest wdrożenie procesów i narzędzi do observability i monitoringu, nie tylko wspomniany wyżej przeze mnie CSRM, ale też FinOps jak choćby Flexera, gdzie dobrze widać który zespół/projekt generuje jakie koszty, landing zone'y dla nowych kont chmurowych i rozwiązania self-service za pomocą których zespoły mogą sobie zamawiać usługi na podstawie przedefiniowanych szablonów.
Więc podsumowując masz zespół Cloud Platform który dostarcza procesy i narzędzia typu governance, observability, landind-zone'y. Mogą być też jakieś moduły Terraformowe jak ktoś chce ich użyć, ale kluczem jest tutaj danie swobody zespołom produktowym, bo to oni wiedzą lepiej czego potrzebują.
Dzięki za uświadomienie mnie, bo nie byłem tego świadom. Bazowałem na tym co mam w firmie i myślałem że to fajne rozwiązanie, bo mi to bardzo pracę ułatwia. Dzięki temu jestem odciążony od pracy DevOpsowej i mogę się więcej skupić na programowaniu, rozmawianiu z biznesem, testowaniem. Nie wiedziałem, że to średniowieczne podejście.