POIT #128: 12 factor app z wykorzystaniem serwisów AWS

Witam w sto dwudziestym ósmym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest 12 factor app z wykorzystaniem serwisów AWS.

Dziś moim gościem jest Patryk Ziemkowski – absolwent Politechniki Poznańskiej, profesjonalnie Head of Development 32 osobowego teamu frontend / backend developerów w Apptension, a prywatnie tata małego Franka. Mówi o sobie, że jest prostym, typowym informatykiem, którego w wolnym czasie pochłaniają gry – ostatnio Wiedźmin 3.

W tym odcinku rozmawiamy o:

  • czym jest 12 factor app?
  • jak sprawdza się podejście oparte na 12 factor app?
  • czy aby jest stosować trzeba mieć aplikacje w chmurze?
  • czy musimy decydować się na wszystkie 12 punktów, czy też możemy wybierać?
  • mówimy o 12 Factor na AWS w kontekście:
    • Config,
    • Build, release, run,
    • Processes
    • Concurrency
    • Dev/prod parity
    • Logs
    • Admin processes
  • jakie są minusy takiego podejścia i vendor locka z AWS?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

To jest 128. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o Twelve Factor – App z wykorzystaniem AWS.

Przypominam, że w poprzednim odcinku rozmawiałem o Mobile jako o ścieżce kariery.

Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/128.

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut.

Sponsorem podcastu jest firma Apptension, wiodący polski twórca produktów cyfrowych i wydajnych, skalowalnych aplikacji.

Zerknij na ich portfolio na https://www.apptension.com/portfolio.

Nazywam się Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest, między innymi, ten podcast. Zostając patronem na platformie Patronite, możesz mi w tym pomóc już dziś. Wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły.

Jednocześnie bardzo dziękuję moim obecnym patronom.

A teraz życzę Ci już miłego słuchania.

 

Odpalamy!

 

Cześć! Mój dzisiejszy gość to absolwent Politechniki Poznańskiej, profesjonalnie Head of Development 32-osobowego teamu front end, back end developerów Apptension, a prywatnie tata małego franka. Mówi o sobie, że jest prostym, typowym informatykiem, którego w wolnym czasie pochłaniają gry. Ostatnio Wiedźmin 3. 

Moim i Waszym gościem jest Patryk Ziemkowski. 

Cześć, Patryk! Bardzo mi miło gościć Cię w podcaście! 

 

Cześć, tez mi miło tutaj być! 

 

Dzisiaj porozmawiamy sobie o temacie nieco bardziej techniczny, mianowicie o wykorzystaniu Twelve Factor-App, tego podejścia czy też zespołu, zbioru praktyk z wykorzystaniem konkretnie serwisów AWS. 

Na początku Patryk, zapytam jak każdego mojego gościa. Czy słuchasz podcastów? Jeśli tak, to może masz jakieś ulubione? 

 

Muszę przyznać, że nie słucham konkretnie jakiegoś podcastu, nie ma na pewno czegoś, co bym śledził na bieżąco. Zdarza mi się jak czegoś potrzebuję, czyli szukam czegoś związanego z nową technologią i chciałbym się dowiedzieć więcej, to wtedy czegoś przesłuchać. Zdarzyło mi się też słuchać Twój podcast, także ciesze się, że w ogóle tutaj jestem, bo podobał mi się ten podcast, którego słuchałem. 

Poza tym prywatnie czasem słucham podcastów, głównie związanych z rodzicielstwem ostatnio. To nic informatycznego, więc zostawię to na boku. 

 

Myślę, że możemy przejść do wyjaśnienia dla słuchaczy czym w ogóle jest Twelve Factors-App? 

Chciałbym na to spojrzeć z perspektywy developera, twórcy aplikacji, ale też ról, które towarzyszą wytwarzaniu oprogramowania. SysOps , DevOps, ale również klient końcowy, czy jakiekolwiek korzyści w ogóle płyną z tego podejścia dla klienta końcowego? 

 

Powiem swoimi słowami – byłaby to uniwersalna lista dobrych praktyk, które powinniśmy czy moglibyśmy stosować w naszych aplikacjach, systemach, które develop ujemy celem spowodowania, że będą skanowalne, łatwo deployowane na różnego rodzaju rozwiązania chmurowe, AWS w Heroku. Wspominam tutaj Heroku, bo tak naprawdę to oni są oryginalnie autorem tego Twelve Factor-App. Sami to pierwsi zaprezentowali. Nie wiem dokładnie, w którym roku, wydaje mi się, że w 2015, ale mogę się mylić. Wtedy widziałem pierwsze video z tym związane, ale to widać jeszcze wcześniej. 

 

Też wywodzi się ze środowiska Ruby on Rails i Heroku  było swego czasu naturalną platformą do hostowania aplikacji bądź do hobbystycznej, bądź klienckich i pamiętam, że faktycznie Heroku po raz pierwszy zaczął mówić o takim podejściu. 

Rozumiem, że to targetowało wówczas developerów. Natomiast teraz w tym ciągu wytwarzania oprogramowania mamy DevOpsów i na końcu klienta końcowego. 

Czy przychodzą Wam do głowy właśnie jakieś korzyści albo zyski, które też te grupy mają? 

Rozumiem, że dla programisty, dla developera może to być jakiś sposób, żeby ujednolicić wytwarzanie oprogramowania. Takie ujednolicenie powoduje, że jak nowa osoba dołącza do teamu, to też łatwiej pewne praktyki podłapać. 

Ale co z działem DevOps, co z klientem końcowym? Czy dla tych grup Twelve Factors-App ma jakieś znaczenie?

 

Jasne. Zacząłbym od grupy klientów, bo w zasadzie my wywodząc się z software house czy prowadząc tę techniczną stronę głównie, kiedy ewoluował nasz stack technologiczny i kiedy dotarliśmy do tego Twelve Factor-App mówiliśmy o tym, co otrzymuje klient, na drugim miejscu developerów, chociaż nie powiedziałbym, że dużo dalej to jest. 

Jeśli chodzi o klientów, to przede wszystkim to na co patrzą to buzzword wielki i skalowalność, czyli to, że możemy rzeczywiście uruchamiać aplikację wspierającą wielu, wielu użytkowników i jeśli potrzebujemy więcej, to z relatywną łatwością dodawać możliwość wsparcia większej liczby użytkowników. To jest na pewno jeden z zamysłów, którego ma doprowadzać wykorzystania Twelve Factor-App. 

 

Jeśli chodzi o klientów, to przede wszystkim to na co patrzą to buzzword wielki i skalowalność, czyli to, że możemy rzeczywiście uruchamiać aplikację wspierającą wielu, wielu użytkowników i jeśli potrzebujemy więcej, to z relatywną łatwością dodawać możliwość wsparcia większej liczby użytkowników. To jest na pewno jeden z zamysłów, którego ma doprowadzać wykorzystania Twelve Factor-App.

 

Drugą rzeczą to łatwość integracji z Continuous Delivery szeroko pojętym, które przede wszystkim zysk dla klienta ma taki, że jakiekolwiek zmiany, jakie potrzebuje, jakieś naprawdę błędów, jakieś nowe funkcje do zaimplementowania są wdrożone szybko i nie ma jakiegoś bardzo długiego cyklu, procesu oczekiwania na to, żeby przetestować, wrzucić nową wersję aplikacji, też stawianie nowych środowisk nie trwa bardzo długo, tylko jest relatywnie krótkie. 

Wszystko sprowadza się do tego, żeby szybko iterować. Tak naprawdę jest podsumowaniem dobrych praktyk, które pozwalają na pełnię zaimplementowania tego podejścia Agile. Trochę nie chciałem używać tego słowa, ale ten cały extreme programming – o to trochę chodzi. 

To jest z perspektywy klienta. Spytałeś o DevOpsów – jeśli chodzi o nas, to my staramy się nie wyróżniać osobnej roli DevOpsa, osobnego silosa w firmie, do którego przekazuje się ten deployment. To jest to, że Twelve Factor-App pozwala na to, żeby wciągnąć tego DevOpsa, te kompetencje do zespołu. Żeby to był jednak zamknięty zespół, który posiada w sobie pełne kompetencje do tego, żeby zbudować coś i to odpalić, również na serwerze. I trochę o to chodzi, że kontrakt między developerami, DevOpsami jest jaśniejszy, możemy odpalać aplikacje w bardzo podobnym, jak nie tym samym środowisku zarówno na środowiskach lokalnych, jak i na środowiskach produkcyjnych, co ostatecznie zdecydowanie upraszcza pracę jednej, drugiej części zespołu developerskiego. 

Wiem, że bardzo dużo firm rozdziela, także tutaj rzeczywiście duży zysk na to, że pojęcie u mnie działa, pojawia się zdecydowanie rzadziej. 

 

A z perspektywy software house jak Apptension? Czy takie podejście coś daje, jakieś zyski, korzyści? Na coś się przekłada, czy też raczej widzicie w tym tylko i wyłącznie praktykę developerską?

 

Przekłada się – to jest bardzo mocno powiązane. Dobre praktyki developerskie bardzo szybko przekładają się na zyski dla klienta, ale jeśli chodzi typowo o perspektywę software house’u, to warto byłoby wspomnieć o tym, że często projekty, które wykonuje software house, które wykonujemy są w jakiś sposób później klientowi poddawane. Czyli robimy całkowite hand off produktu, zdarzy się, że klient buduje wtedy jakiś swój własny zespół, który musi przejąć taki projekt. 

To jest to jak ze wszystkimi, dobrymi praktykami, jeśli się rzeczywiście za nimi podąża, to przekazanie takiego projektu do kolejnego zespołu developerskiego jest znacznie ważniejsze. Też samo zastosowanie Twelve Factor-App to jest coś, do czego to jest zrobione. 

 

To jest to jak ze wszystkimi, dobrymi praktykami, jeśli się rzeczywiście za nimi podąża, to przekazanie takiego projektu do kolejnego zespołu developerskiego jest znacznie ważniejsze. Też samo zastosowanie Twelve Factor-App to jest coś, do czego to jest zrobione. 

 

Dążyliśmy z Michałem bardzo długo, kolejnymi iteracjami, ulepszając z projektu na projekt ten nasz stack osiągnęliśmy w którymś momencie ten Twelve Factor-App nawet nie tyle, co starając się to robić, tylko „Ej! Spełniliśmy to!”, nawet nie zauważyliśmy. Wychodząc z założenia, że kod, który chcemy przekazać klientowi zamykając projekt czy przekazując zespołowi jest kompletny i posiada w sobie wszystko, łącznie z continuous integration, continuous deployment. 

To podejście stosowania tych 12 dobrych praktyk pozwala nam na to. Na to, byśmy mogli aplikację taką kompletną klientowi przekazać i nie ma sytuacji, w której klient dostaje projekt i nagle totalnie nie wie, co dalej z nim zrobić albo pohakowane są jakieś rzeczy po całym projekcie, co powoduje, że musi zatrudnić jakiegoś super drogiego SysOpsa, który będzie to w jakiś sposób odkopywał i wynajdywał co tam się zadziało. To jest w jakiś sposób przewidywalne. Przynajmniej taką mamy nadzieję, taki jest nasz zamiar i tak staramy się te aplikacje wytarzać. 

 

Jasne. To podejście czy też ten zbiór dobrych praktyk faktycznie wywodzi się z Heroku, czyli z takiej platformy passowej, ale obecnie jest dość szeroko stosowane w różnego typu chmurach publicznych. Stąd moje pytanie do Was: czy na ten moment rozwoju software developmentu, jakim jesteśmy, żeby zastosować Twelve Factor-App trzeba mieć aplikację w chmurze czy to nie jest wymóg?

 

Nie, nie trzeba, chociaż przyznam, że nie mam dużego doświadczenia z hostowaniem czegoś poza chmurą, chyba że powiemy coś o prostych GS-ach, DigitalOcean albo jakiś leanold.

Wciąż traktuję to jako rozwiązania chmurowe, ale jeśli mówimy o takich rozwiązaniach typowo in-house’owych, jakieś serwery ustawione w firmie, jest to też jak najbardziej możliwe, ponieważ może postawić lokalnie jakąś platformę Kubernetesa czy nawet korzystać z Docker Compose’a, które są w dużej części, właśnie – to jest zaleta tego Twelve Factor-App, że on pozwala w jakiś sposób doprowadzić do tego, żeby aplikacja była do dopalenia gdziekolwiek.

Można pójść krok dalej w przypadku rozwiązań mocno cloudowych, WS, poprowadzić do vendor lock-ina  i to się kłóci, ale niekoniecznie Twelve Factor-App akurat rozwiązuje ten problem. Tutaj doprowadza do tego, żeby aplikacja była w jakiś sposób przenaszalna, łatwa do odpalenia na środowiskach agnostycznie, o.

 

Jasne, rozumiem. Myślę, że warto też powiedzieć, że te dobre praktyki nie tyczą się stricte kodu w rozumieniu jak wzorce projektowe, prawda? Nie powiedzą nam bezpośrednio jakich praktyk użyć do zbudowania danej funkcjonalności, ale bardziej się tyczą tego, w jaki sposób uruchamiać, konstruować elementy tej aplikacji, żeby dało się później całość takiego ekosystemu skalować.

Agnostyczność, o której tutaj mówiłeś – zastanawiam się, czy to tyczy się tez języka i frameworka, czy to jest w jakiś sposób to, który język do projektu, jaki framework wybieramy może wpłynąć na to, że będziemy albo nie będziemy w stanie spełnić tych praktyk? Czy to jest jakoś ze sobą powiązane?

 

Nie, w żaden sposób Twelve Factor-App nie wymienia, nie, narzuca wykorzystania żadnego języka. Przykłady najróżniejsze, jeśli chodzi o pierwsze prezentacje Heroku, wydawało mi się, że są głównie w Javie, my pracujemy w Pythonie, używamy Timescripta, Node’a, także w zasadzie cokolwiek ktoś chciałby użyć, to może.

 

Myślę, że to dobrze świadczy. Warto też wspomnieć o tym, nie wiem, czy można nazwać ot manifestem, ale powiedzmy coś, co zbiera te zasady, jest nawet wersja polskojęzyczna Twelve Factor – zbiór tych wszystkich zasad, gdzie można je dokładnie przeczytać, natomiast zastanawiam się, czy to jest trochę jak ze Scrumem, że mówimy, że go mamy w momencie, kiedy według definicji spełniamy wszystkie założenia, bo kiedy coś pomijamy, to już właściwie jest to trochę wątpliwe, czy z Twelve Factor-App jest podobnie? Albo musimy wszystkie zasady spełniać, albo nie jesteśmy kompatybilni. Czy też możemy sobie tylko wybrać te elementy, które są w naszym projekcie zasadne, istotne, mają jakiś wpływ i dowolnie sobie to wybierać z tej palety?

 

Powiedziałbym, że nie trzeba spełniać wszystkich, z tym trzeba bardzo ostrożnie, zanim ktoś mocno się przyczepi tych słów. Powiem, jak to wyglądało u nas. My wprowadzaliśmy te punkty, części Twelve Factor-App w jakimś czasie i doszliśmy do momentu, w którym nasz stack, w którym projekty, które wykonujemy spełniają wszystkie te punkty.

Wykonywaliśmy te projekty w trakcie, które niekoniecznie wszystko spełniało, bo jeszcze nie potrafiliśmy, nie mieliśmy wystarczającej wiedzy czy też odpowiednio wybranych narzędzi, żeby to wszystko spełniać. Także jak najbardziej, da się z tym pracować. Zaletą jest to, że jeśli spełniamy wszystkie, to będziemy w pełni z tego korzystać. Wszystkie plusy otrzymamy i zdecydowanie ta aplikacja będzie wyższej jakości. Trudno byłoby powiedzieć, że spełniamy 50%, otrzymujemy jakieś 50% jakości, ale jak najbardziej są elementy, których jeśli nie spełniamy, to nie jest nic naprawdę strasznego. Trzeba myśleć o dobrych praktykach i o standardach jak o czymś, co musimy spełniać i inaczej mamy grzech i koniec, pójdziemy do piekła, tylko po prostu, jeśli stosujemy dobre praktyki, to możemy się spodziewać, że dług technologiczny, który będzie się wytwarzał w trakcie projektu będzie mniejszy i dążyć do tego, żeby spełniać jak najwięcej.

Jeśli znajdziemy jakąś praktykę, która w pewnym sensie koliduje z tym, co jest wymienione w Twelve Factor-App, ale lepiej działa dla nas, to jak najbardziej warto je stosować, bo to jest wszystko dla ludzi. Tak samo, jak kod, który piszemy. Wybieramy jakieś pewne standardy i czy to będą taby czy spacje, to już tam nie ma większego znaczenia dla samej aplikacji, ma to znaczenie dla ludzi.

Jeśli łatwiej jest nam pracować z wszystkimi, weźmy wszystkie. Jeśli chcemy jakichś kilka sobie powymieniać na coś innego, jeśli jest to możliwe, to jak najbardziej.

 

Czyli im więcej, tym lepiej, bo to się po prostu nam przysłuży, przysłuży się projektowi. Ale właśnie – to według mnie bardzo rozsądne podejście jest takie, że w sposób iteracyjny też możemy do tego podchodzić, nie musimy od razu wszystkiego, możemy wybrać to, co jest dla nas najistotniejsze i później sukcesywnie ewentualnie implementować pozostałe praktyki. Super.

 

Tak. My wybraliśmy sobie to, że na pewno chcemy mieć continuous integration, taki sposób. I chcemy spowodować wypchnięcie czegoś na repozytorium, jakiegoś frencha, doprowadziło do deploymentu środowiska devovego. Następnie, żebyśmy mogli to samo zrobić na QA czy tam stage’u, na produkcji. I wychodząc z tego założenia coraz bardziej rozwijaliśmy, dochodziliśmy do pewnego momentu, w którym – Okej, to mamy, teraz jakieś porządnie zrobiony continuous integration, to dodajmy sobie jakieś secrety, to w takim razie w jaki sposób robić to bezpiecznie. To samo się tak nabudowuje i w pewnym momencie osiągamy te wszystkie 12 punktów i niekoniecznie trzeba lecieć z tą historią w jakiś sposób czy jakiś plan wypracowywać sobie, jeśli co my to weźmiemy na warsztat, poznamy, przeczytamy, będziemy mieć to z tyłu głowy.

Sądzę, że i tak dojdziemy od tego etapu, w pewnym momencie nawet przypadkowo, co – jak przyznałem wcześniej, było naszą sytuacją, gdzie to jest coś, co poznaliśmy, rzeczywiście przyjęliśmy do siebie i pracowaliśmy, i rozwijaliśmy nasz stack i nagle się okazało, że nikt tego nie zweryfikował, a jednak już mamy i możemy tylko już ulepszyć dalej detale.

 

Właśnie, bo to nie są odrealnione zasady, tylko zbiór patyk, które są często stosowane mimowolnie. Wiele zespołów to stosuje, bo to są w naszej branży dobre praktyki, nie wiedząc nawet, że one wchodzą w skład tej listy.

Wszystkie te punkty można przeczytać na stornie 12factor.net – przeczytam, żebyśmy wiedzieli, o czym mówimy.

Pierwsza zasada – code base – jedno źródło kodu, śledzone systemem kontroli wersji, wiele wdrożeń, druga – zależności, jawnie zadeklaruj, wydziel zależności. Trzecia – konfiguracja, przechowuj konfigurację w środowisku.

Czwarta  – usługi wspierające, traktuj je jako przydzielone zasoby. Buduj, publikuj, uruchamiaj, oddzielaj etap budowania od uruchamiania. Szóste – procesy, uruchamiaj aplikację jako jeden lub więcej bezstanowych procesów.

Siódme – przydzielanie portów, udostępniaj usługi przez przydzielanie portów, ósme – współbieżność, skaluj poprzez odpowiednio dobrane procesy. Później jest jeszcze zbywalność, dziesiąta – jednolitość środowisk, jedenasta – stosuj logi i dwunasta – zarządzanie aplikacją odbywa się również przez jednorazowe procesy.

 

Podoba mi się, jak to przeczytałeś, bo brzmiało to, jak 12 przykazań.

 

Tak, coś w tym jest, faktycznie. Myślę, że tu mielibyśmy zamkniętą pierwszą część tego naszego dzisiejszego podcastu, takie wprowadzenie trochę do Twelve Factor-App, pokazanie szerszej perspektywy, w jaki sposób można to wykorzystać poprzez developerów, jak to może się przysłużyć klientom końcowym.

Chciałbym przejść do drugiej części, w której powiemy, jak te zasady możemy wykorzystać precyzyjnie na AWS. Jakie dobre praktyki czy jakie zasady Wy wypracowaliście implementując albo dostosowując Wasze aplikacje do tego zestawu zasad?

Oczywiście nie przejdziemy przez wszystkie z tych zasad, myślę, że wybierzemy sobie najistotniejsze albo przynajmniej w mojej opinii te, które najłatwiej można wdrożyć z wykorzystaniem AWS-a.

Chciałbym zacząć od konfiguracji. Dlaczego warto sekrety, konfigurację aplikacji z wykorzystaniem usług AWS-owych trzymać?

 

Jeśli chodzi konkretnie o ten punkt, to co jest w nim najistotniejsze to jest to, że wszystkie wartości, ta konfiguracja jest dostarczana do aplikacji za pomocą zmiennych środowiskowych. Te zmienne środowiskowe można w różny sposób zdefiniować, ale zanim przejdziemy do konkretu, jak to można rozwiązać na AWS, to warto byłoby porozmawiać na ten temat, dlaczego w ogóle zmiennych środowiskowych i do czego to doprowadza.

To, co jest bardzo istotne z naszej perspektywy, to jest to, że możemy oczywiście mieć środowiska zdeploywane do testowania. Będąc software housem, startupem, firmą, która otrzymuje swój produkt – to co jest istotne, to jest to, że oddając kolejne iteracje, dodając kolejne funkcje, ktoś musi je gdzieś przetestować. Zazwyczaj siedzi szereg testerów w zespole, który albo odpala manualne testy albo odpala testy automatyczne i musi gdzieś to wykonać.

 

To, co jest bardzo istotne z naszej perspektywy, to jest to, że możemy oczywiście mieć środowiska zdeploywane do testowania. Będąc software housem, startupem, firmą, która otrzymuje swój produkt – to co jest istotne, to jest to, że oddając kolejne iteracje, dodając kolejne funkcje, ktoś musi je gdzieś przetestować. Zazwyczaj siedzi szereg testerów w zespole, który albo odpala manualne testy albo odpala testy automatyczne i musi gdzieś to wykonać. 

 

Najpierw środowisko QA, później stage’owe, później produkcyjne i to, co jest ważne, powtarzane wielokrotnie, to jest to, żeby środowiska były do siebie jak najbardziej podobne. Praktycznie takie same. Jedyne, czym się różniły, to konfiguracją.

Jednym ze sposobów na to, żeby móc odpalać różne serwisy, różne kontenery z różnymi konfiguracjami, moglibyśmy wstrzykiwać do nich jakieś pliki. Jest w repozytorium plik z secretami, do czego to może doprowadzić? Jest to niebezpieczne, wszystko może gdzieś wyciec, jest to plain textem trzymane, nawet jeśli mamy prywatne repozytorium na GtiHubie, wciąż jest to trzymane plain textem, więc w zasadzie każde włamanie na GitHuba, wyciągnięcie tych repozytoriów doprowadza do utraty wszystkich secretów. Wiemy, że raczej nie jest to najlepszy pomysł.

Stąd właśnie zmienne środowiskowe, które są tym – czymś, co ma konfigurować dane środowisko i to, co jest u nich super, to jest to, że możemy je dostarczać z zewnątrz w jakiś sposób do danego. Budujemy powiedzmy jakiś obraz, dockera i możemy go odpalić ze zmiennymi środowiskowymi, dowolnymi, w różnych wersjach. Czyli ten sam obraz budujemy raz, odpalamy go na QA, stagingu i produkcji, i dostarczamy do nich zmienne środowiskowe, czyli przetestowanie czegoś na jednym środowisku łatwo pozwala pchnąć to dalej, do kolejnego środowiska bez konieczności ponownego budowania tego w jakiś sposób, także znacznie zwiększa to poczucie bezpieczeństwa, że rzeczywiście to, co zostało przetestowane, to zostało wypchnięte na produkcji.

Jeśli chodzi o AWS, z którego głównie my korzystamy. Są dwie możliwości na dostarczenie czegoś do zmiennych środowiskowych, zależnie oczywiście od tego, co wykorzystujemy do samego deploymentu, ale w przypadku elastic container service’u, jest to np. secret’s manager. To jest serwis AWS-owy, który pozwala zatrzymać wartości po jakimś kluczu, które są zaszyfrowane za pomocą klucza KMS. Ten klucz powoduje, że w momencie, kiedy są trzymane na wejściu, są zaszyfrowane.

Nikt, kto nie a dostępu do tego klucza nie może sobie tego odszyfrować. W jaki sposób wprowadzamy to do aplikacji? Większość serwisów AWS, które służą do jakiegoś deploymentu mają możliwość po prostu po to, że jak dodamy im jakieś prawa do tego, czy to na przywiązanie tego secretu danego swojego kontenera i automatyczne odszyfrowanie go tylko w momencie, kiedy startuje aplikacja, nawet gdy podglądamy sobie co tam się dzieje w tym kontenerze, ta wartość nigdy tam nie jest wypisana, ona dopiero podczas uruchomienia wewnątrz tego kontenera się znajduje.

Druga, która często jest wykorzystywana np. w przypadku server lessowych, jest Parameter Store, z system’s managera. One również są zaszyfrowane KMS-em, ale trochę się różni tym, że w momencie, kiedy są wstrzykiwane do lambdy to one nie są odczytywane w środku w Lambdzie, tylko w momencie deploymentu, czyli powiedzmy, że ktoś, kto ma dostęp do samej funkcji Lambdy jest w stanie sobie to przeczytać. To są dwa, główne bieguny możliwości na to, jak dostarczyć taki konflikt i to, co jest super, to że definiując jedną taką zmienną, jedną wartość, możemy ją dostarczyć zarówno do Lambdy czy do kontenera NCS-a, Pinstocka, jakby ktoś chciał, także jest to centralne miejsce, z którego pobieramy te wartości.

 

Okej, omówiliśmy zasadę trzecią związaną z konfiguracją. Myślę, że bardzo istotnym punktem jest piąty – build release run, oddzielenie procesu budowania od uruchamiania, co często wpisuje się w popularne i często stosowane pipeline’y CI.

Jak możemy podejść od tej zasady w przypadku AWS?

 

To jest mój ulubiony punkt! To jest coś, od czego my w ogóle wyszliśmy. Realna potrzeba. To, że chcemy zautomatyzować deploymenty. To, że – ten punkt mówi o tym, że powinniśmy rozdzielić ten… Nie mówię, o automatyzacji, ale sam release, samo wypchnięcie aplikacji z systemu na środowisko powinno odbyć się w trzech etapach.

Pierwszym etapem jest etap budowania tego kodu, czyli przygotowywania jakiejś paczki, czegoś, co jest zbudowanym kodem, który ma w sobie te binarki, te rzeczy potrzebne do samego publikowania.

Następnym etapem jest publikowanie release, który jest gotowy do tego, żeby go uruchomić. On otrzymuje identyfikator, datę czy numer, to nie jest w żaden sposób narzucane, często jest jakieś połączenie version z może nawet hashem commita Następnie jest uruchomienie. Wzięcie po prostu tej wcześniej przygotowanej paczki release’a do tego, żeby można było ja uruchomić na jakimś środowisku.

Jeśli podchodzimy w ten sposób do releasowania aplikacji, to jest bardzo łatwo dodać ten kolejny krok, czyli zautomatyzowanie tego. Wrzucenie na jakieś CI.

My historycznie zaczęliśmy pewnie jak większość ludzi od Jenkinsa, który jest świętym i potężnym narzędziem, ma w sobie dla nas jeden duży minus. Jego przenaszalność na kolejne środowisko dla klienta, ten offboarding, żeby przekazać klientowi całe środowisko, całą paczkę z kodem jest trudne. Jak najbardziej jest wykonalne, wszystko jest wykonalne, tylko wszystko kosztuje jakiś czas, a tutaj ta optymalizacja tego czasu, tego wykorzystania – to są pieniądze klienta. Każdy dzień, każda minuta na robieniu czegoś, co jest przetwarzalne jest kosztowne, klient niekoniecznie powinien płacić, bo skoro możemy to zrobić wielorazowo po to, żeby wykorzystać to wielokrotnie, no to powinniśmy tak do tego podejść.

Jenkinsa pozbyliśmy się w pewnym momencie i teraz korzystamy z AWS-owego code pipeline’a i to, co jest bardzo fajne w code pipeline, to jest to, że to jest CI, który jak konfigurujemy, od razu możemy zrobić bardzo dużo rzeczy samemu, ponieważ możemy zdefiniować cały pipeline, cały proces budowania, releasowania, uruchomienia tego za pomocą CDKA, czyli infrastructure as a code, a to jest też jeden z bardzo istotnych punktów, za którymi podążamy, to jest właśnie to, że możemy taki CI zbudować i on może być powtarzalny. Najpierw my możemy go sobie zdeployować na naszym koncie AWS-owym i mieć cały CI podczas developmentu, możemy mieć tam środowisko QA i staging, i ono jest w pełni obsługiwane tym CI-em. Klient, który będzie miał pewnie swoje konto później w produkcji również może mieć ten CI i on może być częścią tego jego konta, aplikacji i całego systemu.

Również developerzy, którzy później to przyjmą po nas korzystają z tego samego, nie muszą budować tego na nowo. Stąd właśnie cenimy sobie wykorzystanie właśnie tego code pipeline’u, code builda w trakcie. Chodzi o ten punkt, bo pozwala nam po prostu na te rzeczy. Oczywiście można to rozmawiać o tym, że można circle CI i inne rzeczy, które są dość podobne, bo też w repozytorium można przecież zawrzeć taką konfiguracją, ale to jest bardziej taka nasza opinia, że chcielibyśmy raczej ograniczać liczbę tych serwisów, o których klient, czyli developerzy muszą podróżować, poznawać, żeby to było mocno w jednym miejscu.

 

Następna zasada mówi nam o procesach, a mianowicie mówi nam o tym, żeby aplikacje uruchamiać jako wiele bezstanowych procesów. Jak to połączyć z AWS?

 

Z AWS akurat to jest dość łatwe. Jeśli chodzi o dzisiejszy development, to jak to w dzisiejszym świecie wygląda jest dość naturalne, ponieważ ten punkt mocno dotyka tego, że sam development powinien być bezstanowy. Myślę, że na to myślenie, że nie tworzymy już sticky sessions itd., że ogólnie zostało trochę wypełnienie w większości, więc nie jest to coś, do czego trzeba ludzi przekonywać. Aczkolwiek jeśli chodzi o podejście nasze w tej sytuacji, wykorzystujemy głównie elastic container service. Sam fakt, że to są kontenery uruchamiane na podstawie obrazów dockera, trochę w pewnym sensie to wymusza, ponieważ każdy kontener, który jest częścią takiego serwisu, każdy pot, może zostać w dowolnym momencie ubity i postawiony następny, także tutaj ta bezstanowość jest kluczowa w tym.

 

Z AWS akurat to jest dość łatwe. Jeśli chodzi o dzisiejszy development, to jak to w dzisiejszym świecie wygląda jest dość naturalne, ponieważ ten punkt mocno dotyka tego, że sam development powinien być bezstanowy.

 

Skoro możemy łatwo ubijać te procesy, możemy łatwo kolejne stawiać co tutaj wracam do tego, co na początku wspominałem, czyli o tej skalowalności aplikacji. Możemy w dowolnym momencie zespawnować sobie kilkadziesiąt dodatkowych kontenerów i to, że one nie mają stanu, to, że są odizolowanymi procesami same w sobie i robią jedną konkretną rzecz, pozwala nam na podłączenie do tego load balancera, który będzie kierował ruch do dowolnego z tych kontenerów i tylko podsumowując, elastic container service i elastic converter service to są właśnie te serwisy, które w ogóle na to pozwalają w dość łatwy sposób, ściśle związany też z dockerem.

 

Mówiłeś, że jedną z zalet ze stosowania Twelve Factor-App jest to, że możemy skalować aplikacje.  Praktyka ósma dosyć mocno się tego tyczy. Mówi o tym, że nasze skalowanie aplikacji powinno polegać na dokładaniu odpowiednich typów procesów. Np. kolejne procesy obsługujące web server czy też workery itd.

Jak Wy stosujecie tę praktykę w przypadku AWS-a?

 

Myślę, że to jest dość mocno spójne z tym, co powiedziałem jeszcze przed chwilą, czyli właśnie to, że korzystamy z elastic container service’u, który pozwala na definiowanie ile takich kontenerów chcielibyśmy, żeby chodziło.

 

Okej – gdy mówiliśmy o trzeciej zasadzie, o konfiguracji, wspomniałeś o tym, że istotne jest to, żebyśmy mieli środowiska deweloperskie, stagingowe, testerskie itd., podobne albo wręcz takie same, żeby one jedynie różniły się konfiguracją.

Jaki jest z tego zysk? Po co dążymy do tego, żeby te środowiska były takie same?

 

Trochę też o tym wspominałem wcześniej. To, co jest przede wszystkim zyskiem, to jest to, że jeśli dbamy o to, żeby to środowisko było jednolite zarówno na lokalnych maszynach, na środowiskach testerskich jak i na produkcji, to doprowadza do tego, że ten język, którym rozmawiamy między sobą, rozmawiamy DevOpsi i developerzy, testerzy, jest też jednolity, więc im więcej takich rzeczy ujednolicimy, to tym łatwiej jest nam z tym wszystkim pracować. Bardzo często słyszeliśmy, a tak naprawdę bym powiedział, że im bliżej byliśmy i im bliżej jesteśmy tego pełnego Twelve Factora, tym rzadziej słyszę i naprawdę gwarantuję Wam, że nie kłamię –  słowa: „u mnie działa”. Works on my machine.

Miałem kiedyś taką nalepkę na komputerze, już jej nie mam. To był bardzo duży ból, że zainstalujemy coś u siebie lokalnie, postaramy się, żeby rzeczywiście napisać ten kod i nie ma nic gorszego, jak to, jak po prostu deployujesz to i później się okazuje, że nie działa.

Później połowę swojego czasu developerskiego poświęcasz na jakieś debugowanie rzeczy, których nie powinieneś robić. No bo jaka jest różnica w tym, że ty to u siebie lokalnie odpaliłeś, a gdzieś zdalnie. O co chodzi, to o to, żeby doprowadzić do momentu, w którym możemy to, co skonfiguowlaiśmy, to co zdeployowaliśmy, co zbudowaliśmy u siebie nawet lokalnie, jesteśmy w stanie po prostu odpalić gdzieś na produkcji. To będzie ten sam kod, ta sama paczka. Jedyne, co się zmienia, to już wcześniej wspomniane zmienne środowiskowe. To są adresy do bazy danych, do serwisów, to są jakieś konkretne konfiguracje typu wyłączające d-bug. Żeby to były jedyne rzeczy, które się różnią.

Jeśli to uda nam się osiągnąć, to jest naprawdę bajka, bo te wszystkie problemy, które pojawiały się wcześniej, podstawowe rzeczy, przeszedł tu NPS, a tutaj nie przeszedł, głównie znikają.

Oczywiście nie żyjemy w jakimś perfekcyjnym świecie i zawsze się zdarzy, że podczas budowy środowiska produkcyjnego, budowy obrazu, który później byśmy mieli wykorzystać w środowisku poprodukcyjnym, padnie jakieś połączenie z internetem albo padnie jakieś miro, to możemy coraz dalej ulepszać, żeby usprawniać to wszystko, ale po prostu nie wszystko jesteśmy w stanie rozwiązać. Ten czas po prostu przynosi pecha, ale to, co jest najważniejsze tutaj to jest to, że możemy mieć dość wysoką pewność tego, że to, co odpaliliśmy u siebie również zadziała na produkcji i to, co przetestował tester również zadziała na produkcji, ponieważ testował to samo, a nie coś zupełnie innego.

 

Pewnie. Unikamy potencjalnych błędów, a im ten błąd jest wcześniej zauważony, tym wiemy, że ma mniejszy koszt naprawienia i przyspieszy nam cały development aplikacji.

W zasadzie 11 mówimy o logach. O tym, żeby traktować je jako trumien zdarzeń. Czy na AWS mamy jakieś serwisy, które umożliwiają nam właśnie takie traktowanie logów?

 

Tak! Jest bardzo przyjemny serwis, który nazywa się Cloudwatch. On domyślnie jest uruchomiony wszędzie, gdzie się ta, także czy korzystamy z lambdy czy ECS-a czy Bin Stocka.

To, co powiedział, to jest to, że jest już przygotowane pod to, żeby ten próg był spełniony. I powiedziałbym, że nie tylko na AWS, o to jest ogólnie założenie większości chmurowych rozwiązań, to jest to, że dowolna aplikacja, dowolny serwis, który coś chce zalogować to loguje to do stdIn, a później już te rozwiązania streamujące w jakiś sposób to przechwytują i standaryzują te logi, także tutaj znika potrzeba pisania jakichś customowych frameworków, które w jakiś sposób to standaryzują i to, co chcemy zrobić później z tym streamem tych logów, to już tak naprawdę nasza sprawa.

Czy my później to gdzieś jeszcze przepuścimy przez jakiś kolejny serwis, czy cokolwiek, mamy taką możliwość. Najważniejsze jest to, że dzięki Cloudwatchowi uzyskujemy centralne miejsce, w którym te eventy, te streamy się znajdują z wszelkich możliwych stron naszego systemu i są w tym samym formacie.

 

Okej. Gdy sobie spojrzymy na standardową aplikację webową, to myślę, że możemy tam wyróżnić trzy takie typy procesów. To jest proces, który obsługuje żądania od klientów, to jest proces obsługujący jakieś zadania w tle, background joby itd. i to są tzw. procesy administracyjne, np. migracje bazy danych. One muszą się też jakoś odbywać, muszą się też jakoś dziać. I ostatnia z tych zasad, z tych dobrych praktyk, o których dziś mówimy mówi nam o tym, żeby tego typu zadania czy procesy uruchamiać też jako takie osobne procesy, niezależne od wcześniejszych. Pytanie, jak to na AWS można zrealizować?

 

To, co jest jeszcze ważne to żeby procesy administracyjne odpalane były w środowisku, które jak najbardziej przypomina to środowisko samego systemu.

Czyli jeżeli jesteśmy na produkcji, to rzeczywiście uruchamiamy to. I tu świetny przykład to są migracje baz danych, czyli jeśli chcemy dopalić migracje bazowe na produkcji, to nie robi tego ktoś na swoim komputerze lokalnie, tylko jest to odpalane w takim samym kontenerze produkcyjnej aplikacji, która – powiedzmy tutaj back endu, który by chodził do serwowania samej aplikacji.

Nie próbujemy jakoś replikować, nie próbujemy ponownie postawić tego jakoś osobno, tylko wykorzystujemy ten sam obraz docelowy. Jeśli chodzi o AWS, w jaki sposób można do tego podejść, to wykorzystujemy containers service, który pozwala nam na uruchomienie raz, że serwisów, które serwują back end, dwa – wykorzystując ten sam obraz można odpalić tzw. taski i taski są niczym innym jak jednorazowym odpaleniem po prostu danego kontenera, który zamknie się, to jest koniec, nie zostaje odpalony ponownie. Typowy one off.

To jest to narzędzie, które wykorzystujemy do tego, żeby odpalić migrację bazy danych. Dodatkowo często takie zadania jednak są kaskadą, zależą od siebie nawzajem, zależy najpierw jeden, później rugi, trzeci, jak one wszystkie przejdą, to czarty, a jeśli nie, to piąty, to świetnym narzędziem, które pozwala na odpalanie czegoś takiego na AWS jest step functions, które właśnie można zdefiniować jako automat skończony, state machine, gdzie wejściem do kolejnego kroku będzie wyjście z wcześniejszych kroków. Są tam też jakieś warunki, można podefiniować co kiedy się dzieje i wszystko to można zdefiniować jako kod w CloudFormation, w CDK, w terraformie. Kto chce może do tego przejść na swój własny sposób, najważniejsze jest to, że takie narzędzia są udostępnione.

 

Myślę sobie, że gdyby ktoś chciał tworzyć nową aplikację z myślą o zastosowaniu wszystkich lub większości z tych zasad, o których mówiliśmy, to można je tak trochę potraktować jako framework, który jest też powtarzalny. Z punktu widzenia software house’u, każdy kolejny projekt prawie że mógłby się opierać o podobne klocki, podobne elementy. Czy z wykorzystaniem AWS da się zrobić powtarzalność, jakiś taki framework, boilerplate, który umożliwi nam użycie czy też ułatwi użycie tych zasad w kolejnych projektach?

 

Jak najbardziej można – jest to coś, co sami wykonaliśmy. Chciałbym jeszcze tylko powiedzieć, że w zasadzie oczywiście narzędzia należy dobierać do projektów, jakie mamy. Powiedziałbym, że my będąc software housem, kiedy bardzo często pracujemy przy projektach SaaSowych, czyli przygotowujemy jakiś projekt dla klienta typu start up, to rzeczywiście one są dość podobnej charakterystyki, czyli najczęściej potrzebują back end, front end, potrzebują workerów asynchronicznych, o których sam wspomniałeś.

To wszystko najczęściej implementowaliśmy w jakiś podobny sposób i postanowiliśmy to wszystko zamknąć w formie takiego boilerplate, czegoś co po prostu jest starterem dla kolejnych projektów.

Są to praktyki, które dość dużo czasu nam zajęły, żebyśmy je wypracowali i zaimplementowanie tego w postaci powtarzalnej infrastructure razy kod, to nie jest sprawą trywialną. Wymaga dość dużo wiedzy i oczywiście inkrementalne rozwijanie tego jest dużo lepsze niż pisanie tego za każdym razem w projekcie.

Wszystkie dobre rozwiązania, wszystkie poprawki, wszystkie rzeczy, które są cloud, jest rzeczą, która jest raczej trudna. Wszyscy chcą powiedzieć, że jest łatwa, ale mimo wszystko ogrom i tych serwisów, i drobnych kruczków, które tam są, praw itd., do rozwiązania tego wszystkiego nie jest to łatwe, więc zamknięcie tego w formie wcześniej przygotowanego, takiej bazy, którą można dowolnie rozbudowywać – tutaj mówimy o tym AWS boilerplate, który przygotował Apptension, który jest po prostu kodem, w którym można wziąć to repozytorium i tam jest folder back end, jest folder front end, w który można wsadzić sobie cokolwiek chcemy, ale jest pokonfigurowane, wszystko, co jest AWS-owe, jest skonfigurowany CS, jest automatyczna, podstawowa skalowalność, zdefiniowana. Są lambdy, można zdeployować funkcje, jest jakiś event skonfigurowany i to wszystko ze sobą pointegrowane w taki dość bezpieczny sposób, taki, który rzeczywiście rozwiązuje parędziesiąt napotkanych problemów, które dodatkowo właśnie CI posiada w sobie.

Wszystko można dowolnie zmienić, bo to jest po potu kod CDK, który jak ktoś chce usunąć jakiś serwis, to może, jak ktoś chce dodać swój, no to też może. To nie jest żadna paczka, która instalujemy i narzucamy jakieś CI.

 

Czy takie mocne przywiązanie się do dostawcy usług chmurowych, w tym przypadku AWS-a, czy to nie jest problem? To nie rodzi takiego vendor lock in-a, który może nas później po czasie ugryźć? Jak to widzisz?

 

To jest ogólnie trudny temat, na który jest wiele opinii i powiedziałbym, że ogólnie zgadzam się z tą myślą, że vendor lock in może być problemem, ale z drugiej strony, jak sobie myślę o tym – właśnie wychodząc poza takie purystyczne ramy developerskie, bo często właśnie narzucamy sobie takie rzeczy. Są dobre praktyki, są rzeczy, które musimy spełniać, inaczej źle.

Programiści potrafią być bardzo binarni. Dobrze albo źle, nie ma nic pośrodku. Trochę myślę, że jednak vendor lock in to jest coś za coś. Jest AWS, który udostępnia nam bardzo dużo fajnych serwisów, które oszczędzają bardzo dużo pracy, które zwiększają bezpieczeństwo naszej aplikacji, które pozwalają nam na zrobienie czegoś, czego sami bardzo często nie bylibyśmy w stanie zrobić. Można wskazywać oczywiście alternatywy, że używamy tego Kubernetesa i wszystkich rzeczy z nim związanych, jak najbardziej, moim zdaniem wymaga to większego know-how, większego kosztu wejścia developerów. Trochę psuje się nam też ta myśl, że chcemy, by wiedza w projektach była pełna, czyli że zespół potrafi wszystko zrobić. I trochę według nas łatwiej jest nam to osiągnąć na AWS, który jest bardziej user friendly. Wszystko sprowadza się do optymalizacji kosztów dla klienta.

 

Programiści potrafią być bardzo binarni. Dobrze albo źle, nie ma nic pośrodku.

 

Jeśli my wykorzystując AWS-a, który jest najpopularniejszym kodem i dostarczając taką pełną paczkę klientowi, powodujemy, że jemu łatwo jest zatrudnić developerów, którzy będą w stanie to kontynuować, no to pod tym względem jest to zdecydowany plus dla klienta. Nawet taki vendor lock in. W mojej karierze, póki co nie zdarzyło się – no dobra, może raz – żebyśmy musieli przenieść coś z jednego clouda na drugiego.

Na pewno to, co jest istotne w tym facie to jest to, że należy to klientowi oczywiście wcześniej przedstawić. Czyli powiedzieć, że to jest coś, na co się decydujemy w tym momencie. Jeśli chcemy pokryć tym podejściem, wykorzystujemy nasze wcześniej przygotowane rozwiązania, ten stack i vendor lock in, ale jest o tyle taniej – a możemy zrobić to bardziej diagnostycznie, ale będzie to zdecydowanie droższe, bo większość z tych rzeczy, które tutaj są spełnione w takim podejściu, które wypracowaliśmy przez lata i przez to, że AWS wiele rzeczy robi za nas, no to otrzymuje to out of the box.

Każdy zespół musi sam zdecydować co jest dla niego istotniejsze w danym momencie. Jeśli piszą czy tworzą aplikację, która nie ma zdefiniowanego, w jakim miejscu będzie możliwa do zdeployowania, to jak najbardziej nie może w ten sposób podchodzić, że wszystko leci na AWS i wtedy się dowiadujemy nagle, że nie może, ale jeśli od samego początku założenie jest takie, że AWS jest okej, klient to akceptuje i nie ma zamiaru przenosić się, bo technologia nie jest najważniejszą rzeczą całej aplikacji, to wtedy ten vendor lock in nie jest taki straszny.

 

Jasne. Patryk, bardzo Ci dziękuję za ciekawą rozmowę, za podzielenie się swoimi doświadczeniami i doświadczeniami z projektu. Myślę, że to taka cenna wiedza, która idzie właśnie z praktyki, a nie tylko z teorii.

Powiedz, gdzie Cię można znaleźć w internecie, jak się z tobą skontaktować?

 

W internecie można znaleźć mnie na LinkedInie i chyba do tego bym się ograniczył.

Biorę udział czasem w innych inicjatywach, które pojawiają się na naszym Instagramie Apptension czy chociażby ponownie na LinkedInie, Apptension, także ktokolwiek chciałby porozmawiać to może proszę o wiadomość na LinkedInie. Patryk Ziemkowski.

 

Świetnie, dodatkowo oczywiście wszystkie linki będą w notatce do odcinka. Dzięki Patryk jeszcze raz, do usłyszenia, cześć!

 

Dzięki, cześć!

 

To na tyle z tego, co przygotowałem dla Ciebie na dzisiaj Twelve Factor-App to bardzo dobra praktyka projektowania implementacji, wdrożenia i utrzymania aplikacji zwłaszcza w środowiskach chmurowych.

Po raz pierwszy z tym pojęciem spotkałem się uruchamiając aplikację na Heroku, które mocno je promowało.

Mam nadzieję, że dzięki temu, o czym dziś opowiadał Patryk wiesz jak połączyć Twelve Factor-App z AWS.

Jeśli ten odcinek był dla Ciebie interesujący i przydatny, odwdzięcz się, proszę, recenzją, oceną lub komentarzem w social mediach. Jeśli masz jakieś pytania, pisz śmiało na krzysztof@porozmawiajmyoit.pl. Zapraszam też do moich mediów społecznościowych.

Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o Twelve Factor-App z wykorzystaniem AWS.

Zapraszam do kolejnego odcinka już za tydzień!

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.