Merge branch 'MichaelCade:main' into main

2022/ko/Days/day01.md

@@ -23,11 +23,11 @@ date: '2022-04-17T10:12:40Z'
 
 위의 블로그를 읽고 저의 학습 여정의 수준이 매우 높을 것이라고 짐작하시는 분들을 위해 말씀드리면, 저는 그 분야들에 대해 전문가는 아닙니다만 유료이건 무료이건 어떤 형태로든 자료를 공유하고 싶었습니다. 우리는 모두 서로 다른 환경에 있을 것이니 각자에게 맞는 선택을 하시길 바랍니다.
 
-앞으로 90일간 저는 기본적인 영역들에 대해 다루고 자료들을 문서화 하려고 합니다. 커뮤니티의 적극적인 참여도 바라고 있습니다. 많은 분의 학습 여정과 자료의 공유를 통해 공개적으로 함께 도와가며 서로 배우길 바랍니다.
+앞으로 90일간 저는 기본적인 영역들에 대해 다루고 자료들을 문서화하려고 합니다. 커뮤니티의 적극적인 참여도 바라고 있습니다. 많은 분의 학습 여정과 자료의 공유를 통해 공개적으로 함께 도와가며 서로 배우길 바랍니다.
 
 프로젝트 리포지토리의 readme에 12주에 6일을 더한 분량의 섹션 별로 분할을 해두었습니다. 첫 6일간은 특정 영역에 뛰어들기 전에 데브옵스에 대한 전반적인 기본 지식들에 대해 학습할 것입니다. 반복해서 말씀드리면 저의 자료가 완벽하지 않습니다. 따라서 이 자료들이 유용하게 활용될 수 있도록 커뮤니티의 도움을 바랍니다.
 
-지금 이 순간에 공유하고 싶은 자료가 하나 더 있습니다. 모두가 꼼꼼히 살펴야하고,  스스로에 대한, 자신의 관심과 현재 위치를 마인드맵으로 그려야할, 그것은
+지금 이 순간에 공유하고 싶은 자료가 하나 더 있습니다. 모두가 꼼꼼히 살펴야 하고, 스스로에 대한, 자신의 관심과 현재 위치를 마인드맵으로 그려야 할, 그것은
 
 [DevOps Roadmap](https://roadmap.sh/devops)
 
@@ -35,30 +35,31 @@ date: '2022-04-17T10:12:40Z'
 
 ## 첫 단계 - 데브옵스란?
 
-소개드리고 싶은 유튜브 비디오나 블로그 글이 너무 많습니다. 하지만 우리는 90일의 도전을 시작했고 매일 한시간씩 새로운 것을 배우거나 데브옵스에 관해 배우기로 했으므로, "DevOps란 무엇인가"라는 높은 수준의 정보를 먼저 얻는 것이 좋다고 생각합니다.
+소개드리고 싶은 유튜브 비디오나 블로그 글이 너무 많습니다. 하지만 우리는 90일의 도전을 시작했고 매일 한 시간씩 새로운 것을 배우거나 데브옵스에 관해 배우기로 했으므로, "DevOps란 무엇인가"라는 높은 수준의 정보를 먼저 얻는 것이 좋다고 생각합니다.
 
 우선, 데브옵스는 도구가 아닙니다. 살 수 있는 것도 아니고, software SKU나 깃허브 레포지토리에서 다운로드 받을 수 있는 오픈 소스도 아닙니다. 또한 프로그래밍 언어도 아니고, 괴상한 흑마술도 아닙니다.
 
 데브옵스란 소프트웨어 개발에서 좀 더 현명하게 일하는 방법을 말합니다. - 잠깐... 혹시 소프트웨어 개발자가 아니라면 이 학습 과정을 중단해야 할까요??? 아닙니다.. 데브옵스란 소프트웨어 개발과 운영의 통합을 의미하기 때문입니다. 위에서 언급했듯이 저는 일반적으로 운영에 속하는 VM(가상머신)과 관련된 쪽에 있었지만, 커뮤니티에는 다양한 배경을 가진 사람들이 있습니다. 그리고 개인, 개발자, 운영자 그리고 QA 엔지니어 모두는 DevOps를 더 잘 이해함으로써 모범사례에 관해 동등하게 배울 수 있습니다.
 
-데브옵스는 이 목표를 달성하기 위한 일련의 관행입니다: 제품이 초기 아이디어 단계부터 최종 사용자, 내부 팀 또는 고객 등 모든 사용자에게 실제 운영 서비스로 전달되기 까지의 시간을 단축하는 것.
+데브옵스는 이 목표를 달성하기 위한 일련의 관행입니다: 제품이 초기 아이디어 단계부터 최종 사용자, 내부 팀 또는 고객 등 모든 사용자에게 실제 운영 서비스로 전달되기까지의 시간을 단축하는 것.
 
 첫 주에 다룰 또 다른 분야는 **애자일 방법론** 에 관한 것입니다. 애플리케이션을 지속적으로 전달(Continuous Delivery)하기 위해 데브옵스와 애자일은 주로 함께 다루어집니다.
 
-개략적으로 말해 데브옵스적 사고방식이나 문화는 길고 몇년이 걸릴 수 있는 소프트웨어 배포 프로세스를 더 작고, 자주 배포하는 방식으로 시간을 단축시키는 것입니다. 추가로 이해해야할 또 다른 핵심 포인트는 위에 언급한 개발, 운영, QA 팀간의 사일로를 무너트리는 것은 데브옵스 엔지니어의 책임입니다.
+개략적으로 말해 데브옵스적 사고방식이나 문화는 길고 몇 년이 걸릴 수 있는 소프트웨어 배포 프로세스를 더 작고, 자주 배포하는 방식으로 시간을 단축시키는 것입니다. 추가로 이해해야 할 또 다른 핵심 포인트는 위에 언급한 개발, 운영, QA 팀 간의 사일로를 무너트리는 것은 데브옵스 엔지니어의 책임입니다.
 
-데브옵스의 관점에서 보면 **개발, 테스트, 배포**는 모두 데브옵스 팀과 함께 해야하기 때문입니다.
+데브옵스의 관점에서 보면 **개발, 테스트, 배포**는 모두 데브옵스 팀과 함께해야 하기 때문입니다.
 
 최종적으로 이런 것을 효과적이고 효율적으로 하기 위해서는 **자동화**를 최대한 활용해야 합니다.
 
 ## 자료
 
-이곳을 학습 도구로 활용하기 위해 이 readme 파일에 추가적으로 자료를 덪붙이는 것에 대해 항상 열려있습니다.
+이곳을 학습 도구로 활용하기 위해 이 readme 파일에 추가적으로 자료를 덧붙이는 것에 대해 항상 열려있습니다.
 
 그리고 아래 동영상들을 꼭 보시기 바랍니다. 또한 위에 설명드린 내용에서 많은 인사이트를 얻었으면 합니다.
 
 - [DevOps in 5 Minutes](https://www.youtube.com/watch?v=Xrgk023l4lI)
 - [What is DevOps? Easy Way](https://www.youtube.com/watch?v=_Gpe1Zn-1fE&t=43s)
 - [DevOps roadmap 2022 | Success Roadmap 2022](https://www.youtube.com/watch?v=7l_n97Mt0ko)
+- [From Zero to DevOps Engineer - DevOps Roadmap for YOUR specific background](https://www.youtube.com/watch?v=G_nVMUtaqCk)
 
 여기까지 읽었다면 나에게 필요한 내용인지 아닌지 알 수 있을 것입니다. [Day 2](day02.md)

2022/ko/Days/day02.md

@@ -13,7 +13,7 @@ date: '2022-04-17T21:15:34Z'
 
 부디, 여러분이 자료를 찾고 [Day1 of #90DaysOfDevOps](day01.md) 페이지에 글을 올리면서 함께 참여하기를 바랍니다.
 
-첫 번째 글에서 짦게 다루었습니다만, 이제 더 깊이 있는 개념 그리고 애플리케이션을 만드는 것에는 두가지 주요 파트가 있다는 것에 대해 이해할 필요가 있습니다. 소프트웨어 개발자들이 애플리케이션을 작성하고 테스트하는 **개발** 파트와 애플리케이션을 서버에 배포하고 유지하는 **운영** 파트 입니다.
+첫 번째 글에서 짧게 다루었습니다만, 이제 더 깊이 있는 개념 그리고 애플리케이션을 만드는 것에는 두 가지 주요 파트가 있다는 것에 대해 이해할 필요가 있습니다. 소프트웨어 개발자들이 애플리케이션을 작성하고 테스트하는 **개발** 파트와 애플리케이션을 서버에 배포하고 유지하는 **운영** 파트 입니다.
 
 ## 데브옵스는 그 둘을 연결합니다.
 
@@ -39,27 +39,27 @@ To get to grips with DevOps or the tasks which a DevOps engineer would be carryi
 
 ## 이것도 알고, 저것도 알고
 
-네트워크 또는 인프라의 스페셜리스트가 될 필요는 없습니다. 서버를 올리고, 실행시키고 상호간 통신이 가능하도록 구성하는 방법에 대한 지식만 있으면됩니다. 마찬가지로 개발자가 될 필요는 없습니다. 프로그래밍 언어에 대한 기본적인 지식만 있으면 됩니다. 하지만 어느 한 분야의 전문가로써 데브옵스 업무에 참여할 수 있고, 이럴 경우 다른 분야에 적응하기 위한 매우 좋은 기반이 될 것입니다.
+네트워크 또는 인프라의 스페셜리스트가 될 필요는 없습니다. 서버를 올리고, 실행시키고 상호 간 통신이 가능하도록 구성하는 방법에 대한 지식만 있으면 됩니다. 마찬가지로 개발자가 될 필요는 없습니다. 프로그래밍 언어에 대한 기본적인 지식만 있으면 됩니다. 하지만 어느 한 분야의 전문가로서 데브옵스 업무에 참여할 수 있고, 이럴 경우 다른 분야에 적응하기 위한 매우 좋은 기반이 될 것입니다.
 
-또한 서버나 애플리케이션의 관리를 매일 인계받지 못할 수 도 있습니다.
+또한 서버나 애플리케이션의 관리를 매일 인계받지 못할 수도 있습니다.
 
-서버에 대해서만 이야기 했지만, 애플리케이션이 컨테이너로 실행되도록 개발해야 할 수 도 있습니다. 여전히 서버에서 실행하는 것이라곤 하나, 가상화, IaaS (클라우드 인프라 서비스)와 더불어 컨테이너화에 대한 이해도 필요합니다.
+서버에 대해서만 이야기했지만, 애플리케이션이 컨테이너로 실행되도록 개발해야 할 수도 있습니다. 여전히 서버에서 실행하는 것이라곤 하나, 가상화, IaaS (클라우드 인프라 서비스)와 더불어 컨테이너화에 대한 이해도 필요합니다.
 
 ## 고차원적인 개요
 
-한쪽에서 우리 개발자들이 애플리케이션을 위핸 시 기능들을 (버그 수정과 더불어) 추가합니다.
+한쪽에서 우리 개발자들이 애플리케이션을 위한 기능들을 (버그 수정과 더불어) 추가합니다.
 
 다른 한쪽에서는 실제 애플리케이션이 실행되고 필요 서비스들과 통신하도록 구성 및 관리되고 있는 서버, 인프라 내지는 환경이 있습니다.
 
 여기서 핵심은 버그 수정 및 새 기능이 추가된 버전을 운영 환경에 적용시켜 최종 사용자에게 제공하도록 하는 것입니다.
 
-새 애플리케이션 버전을 어떻게 출시하는가? 이것이 데브옵스 엔지니어의 핵심 업무 입니다. 테스트를 포함한 효과적이고 자동화된 방식을 지속적으로 고민해야합니다.
+새 애플리케이션 버전을 어떻게 출시하는가? 이것이 데브옵스 엔지니어의 핵심 업무입니다. 테스트를 포함한 효과적이고 자동화된 방식을 지속적으로 고민해야 합니다.
 
 여기서 오늘 학습을 끝내도록 하겠습니다. 부디 유용했기를 바랍니다. 앞으로 DevOps의 다양한 영역들과, 다양한 도구 및 프로세스들의 사용 이점에 대해서 깊이 있게 다루도록 하겠습니다.
 
 ## 자료
 
-이곳을 학습 도구로 활용하기 위해 이 readme 파일에 추가적으로 자료를 덪붙이는 것에 대해 항상 열려있습니다.
+이곳을 학습 도구로 활용하기 위해 이 readme 파일에 추가적으로 자료를 덧붙이는 것에 대해 항상 열려있습니다.
 
 그리고 아래 동영상들을 꼭 보시기 바랍니다. 또한 위에 설명드린 내용에서 많은 인사이트를 얻었으면 합니다.
 

2022/ko/Days/day03.md

@@ -0,0 +1,97 @@
+---
+title: '#90DaysOfDevOps - Application Focused - Day 3'
+published: false
+description: 90DaysOfDevOps - Application Focused
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048825
+---
+
+## 데브옵스 수명 주기 - 애플리케이션 중심
+
+앞으로 몇 주 동안 계속 진행하면서 지속적 개발, 테스트, 배포, 모니터에 대해 100% 반복해서 접하게 될 것입니다. DevOps 엔지니어 역할로 향하고 있다면 반복성이 익숙해질 것이지만 매번 지속적으로 향상시키는 것도 흥미를 유지하는 또 다른 요소입니다.
+
+이번 시간에는 애플리케이션을 처음부터 끝까지 살펴본 다음 다시 반복하듯 되돌아보는 고차원의 시각으로 살펴보겠습니다.
+
+### Development (개발)
+
+애플리케이션의 새로운 예를 들어 보겠습니다. 먼저 아무것도 만들어지지 않은 상태에서 개발자는 고객 또는 최종 사용자와 요구 사항을 논의하고 애플리케이션에 대한 일종의 계획이나 요구 사항을 마련해야 합니다. 그런 다음 요구 사항을 바탕으로 새로운 애플리케이션을 만들어야 합니다.
+
+이 단계의 도구와 관련해서는 애플리케이션을 작성하는 데 사용할 IDE와 프로그래밍 언어를 선택하는 것 외에는 실제 요구 사항이 없습니다.
+
+데브옵스 엔지니어로서 이 계획을 만들거나 최종 사용자를 위해 애플리케이션을 코딩하는 것은 여러분이 아니라 숙련된 개발자가 할 일이라는 점을 기억하세요.
+
+그러나 애플리케이션에 대한 최상의 인프라 결정을 내릴 수 있도록 일부 코드를 읽을 수 있는 것도 나쁘지 않을 것입니다.
+
+앞서 이 애플리케이션은 어떤 언어로든 작성할 수 있다고 언급했습니다. 중요한 것은 버전 관리 시스템을 사용하여 유지 관리해야 한다는 것인데, 이 부분은 나중에 자세히 다룰 것이며 특히 **Git**에 대해 자세히 살펴볼 것입니다.
+
+또한 이 프로젝트에서 한 명의 개발자가 작업하는 것이 아닐 수도 있지만, 이 경우에도 모범 사례에서는 코드를 저장하고 협업하기 위한 코드 저장소가 필요하며, 이는 비공개 또는 공개일 수 있고 호스팅되거나 비공개로 배포될 수 있으며 일반적으로 **GitHub 또는 GitLab**과 같은 코드 저장소가 코드 저장소로 사용되는 것을 듣게 될 것입니다. 이에 대해서는 나중에 **Git** 섹션에서 다시 다루겠습니다.
+
+### Testing (테스팅)
+
+이 단계에서는 요구 사항이 있고 애플리케이션이 개발되고 있습니다. 하지만 우리가 사용할 수 있는 모든 다양한 환경, 특히 선택한 프로그래밍 언어에서 코드를 테스트하고 있는지 확인해야 합니다.
+
+이 단계에서 QA는 버그를 테스트할 수 있으며, 테스트 환경을 시뮬레이션하는 데 컨테이너를 사용하는 경우가 많아져 전반적으로 물리적 또는 클라우드 인프라의 비용 오버헤드를 개선할 수 있습니다.
+
+이 단계는 또한 다음 영역인 지속적 통합의 일부로 자동화될 가능성이 높습니다.
+
+이 테스트를 자동화할 수 있다는 것은 수십, 수백, 심지어 수천 명의 QA 엔지니어가 이 작업을 수동으로 수행해야 하는 것과 비교하면 그 자체로 의미가 있으며, 이러한 엔지니어는 스택 내에서 다른 작업에 집중하여 워터폴 방법론을 사용하는 대부분의 기존 소프트웨어 릴리스에서 지체되는 경향이 있는 버그 및 소프트웨어 테스트 대신 더 빠르게 움직이고 더 많은 기능을 개발할 수 있습니다.
+
+### Integration (통합)
+
+매우 중요한 것은 통합이 데브옵스 라이프사이클의 중간에 있다는 것입니다. 개발자가 소스 코드에 변경 사항을 더 자주 커밋해야 하는 practice(관행)입니다. 이는 매일 또는 매주 단위로 이루어질 수 있습니다.
+
+커밋할 때마다 애플리케이션은 자동화된 테스트 단계를 거치게 되며, 이를 통해 다음 단계로 넘어가기 전에 문제나 버그를 조기에 발견할 수 있습니다.
+
+이제 이 단계에서 "하지만 우리는 애플리케이션을 만들지 않고 소프트웨어 공급업체에서 기성품을 구입합니다."라고 말할 수 있습니다. 많은 회사가 이렇게 하고 있고 앞으로도 계속 그렇게 할 것이며 위의 3단계에 집중하는 것은 소프트웨어 공급업체가 될 것이므로 걱정하지 마세요. 하지만 마지막 단계를 채택하면 기성품 배포를 더 빠르고 효율적으로 배포할 수 있으므로 여전히 채택하고 싶을 수도 있습니다.
+
+오늘 당장 상용 소프트웨어를 구매할 수도 있지만 내일이나 또는... 다음 직장에서 사용할 수도 있기 때문에 위의 지식을 갖추는 것만으로도 매우 중요하다고 말씀드리고 싶습니다.
+
+### Deployment (배포)
+
+Ok so we have our application built and tested against the requirements of our end user and we now need to go ahead and deploy this application into production for our end users to consume.
+
+This is the stage where the code is deployed to the production servers, now this is where things get extremely interesting and it is where the rest of our 86 days dives deeper into these areas. Because different applications require different possibly hardware or configurations. This is where **Application Configuration Management** and **Infrastructure as Code** could play a key part in your DevOps lifecycle. It might be that your application is **Containerised** but also available to run on a virtual machine. This then also leads us onto platforms like **Kubernetes** which would be orchestrating those containers and making sure you have the desired state available to your end users.
+
+Of these bold topics, we will go into more detail over the next few weeks to get a better foundational knowledge of what they are and when to use them.
+
+이제 최종 사용자의 요구 사항에 따라 애플리케이션을 빌드하고 테스트를 마쳤으므로 이제 최종 사용자가 사용할 수 있도록 이 애플리케이션을 프로덕션에 배포해야 합니다.
+
+이 단계는 코드를 프로덕션 서버에 배포하는 단계로, 이제부터 매우 흥미로운 일이 벌어지며 나머지 86일 동안 이러한 영역에 대해 더 자세히 알아볼 것입니다. 애플리케이션마다 필요한 하드웨어나 구성이 다르기 때문입니다. 바로 이 부분에서 **Application Configuration Management(애플리케이션 구성 관리)**와 **Infrastructure as Code(코드형 인프라)**가 데브옵스 라이프사이클에서 중요한 역할을 할 수 있습니다. 애플리케이션이 **Containerised(컨테이너화)**되어 있지만 가상 머신에서 실행할 수 있는 경우도 있을 수 있습니다. 그런 다음 이러한 컨테이너를 오케스트레이션하고 최종 사용자가 원하는 상태를 사용할 수 있도록 하는 **Kubernetes**와 같은 플랫폼으로 이어집니다.
+
+이 대담한 주제 중 앞으로 몇 주에 걸쳐 더 자세히 살펴보면서 컨테이너가 무엇이고 언제 사용하는지에 대한 기초 지식을 쌓을 것입니다.
+
+### Monitoring (관제)
+
+새로운 기능으로 지속적으로 업데이트하고 있는 애플리케이션이 있으며, 테스트 과정에서 문제점이 발견되지 않는지 확인하고 있습니다. 필요한 구성과 성능을 지속적으로 유지할 수 있는 애플리케이션이 우리 환경에서 실행되고 있습니다.
+
+하지만 이제 최종 사용자가 필요한 경험을 얻고 있는지 확인해야 합니다. 이 단계에서는 애플리케이션 성능을 지속적으로 모니터링하여 개발자가 향후 릴리스에서 애플리케이션을 개선하여 최종 사용자에게 더 나은 서비스를 제공할 수 있도록 더 나은 결정을 내릴 수 있도록 해야 합니다.
+
+또한 이 섹션에서는 구현된 기능에 대한 피드백을 수집하고 최종 사용자가 어떻게 개선하기를 원하는지에 대한 피드백을 수집할 것입니다.
+
+안정성은 여기서도 핵심 요소이며, 결국에는 애플리케이션이 필요할 때 항상 사용할 수 있기를 원합니다. 이는 지속적으로 모니터링해야 하는 다른 **observability, security and data management(관찰 가능성, 보안 및 데이터 관리)** 영역으로 이어지며, 피드백을 통해 애플리케이션을 지속적으로 개선, 업데이트 및 릴리스하는 데 항상 사용할 수 있습니다.
+
+특히 [@\_ediri](https://twitter.com/_ediri) 커뮤니티의 일부 의견은 이러한 지속적인 프로세스의 일부로 FinOps 팀도 참여해야 한다고 언급했습니다. 앱과 데이터는 어딘가에서 실행되고 저장되므로 리소스 관점에서 상황이 변경될 경우 비용이 클라우드 요금에 큰 재정적 고통을 주지 않도록 지속적으로 모니터링해야 합니다.
+
+위에서 언급한 "DevOps 엔지니어"에 대해서도 언급할 때가 되었다고 생각합니다. 많은 사람들이 DevOps 엔지니어라는 직책을 가지고 있지만, 이것은 DevOps 프로세스를 포지셔닝하는 이상적인 방법은 아닙니다. 제 말은 커뮤니티의 다른 사람들과 이야기할 때 데브옵스 엔지니어라는 직책이 누구의 목표가 되어서는 안 된다는 것입니다. 실제로 어떤 직책이든 여기에서 설명한 데브옵스 프로세스와 문화를 채택해야 하기 때문입니다. 데브옵스는 클라우드 네이티브 엔지니어/아키텍트, 가상화 관리자, 클라우드 아키텍트/엔지니어, 인프라 관리자와 같은 다양한 직책에서 사용되어야 합니다. 몇 가지 예를 들었지만, 위에서 DevOps 엔지니어를 사용한 이유는 위의 모든 직책에서 사용하는 프로세스의 범위 등을 강조하기 위해서입니다.
+
+## Resources
+
+I am always open to adding additional resources to these readme files as it is here as a learning tool.
+
+My advice is to watch all of the below and hopefully you also picked something up from the text and explanations above.
+
+학습 도구로서 이 Readme 파일에 추가 리소스를 추가하는 것은 언제나 열려 있습니다.
+
+아래의 내용을 모두 보시고 위의 텍스트와 설명에서 많은 것들을 얻으셨으면 좋겠습니다.
+
+- [Continuous Development](https://www.youtube.com/watch?v=UnjwVYAN7Ns) I will also add that this is focused on manufacturing but the lean culture can be closely followed with DevOps.
+- [Continuous Testing - IBM YouTube](https://www.youtube.com/watch?v=RYQbmjLgubM)
+- [Continuous Integration - IBM YouTube](https://www.youtube.com/watch?v=1er2cjUq1UI)
+- [Continuous Monitoring](https://www.youtube.com/watch?v=Zu53QQuYqJ0)
+- [The Remote Flow](https://www.notion.so/The-Remote-Flow-d90982e77a144f4f990c135f115f41c6)
+- [FinOps Foundation - What is FinOps](https://www.finops.org/introduction/what-is-finops/)
+- [**NOT FREE** The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win](https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290/)
+
+여기까지 왔다면 이곳이 자신이 원하는 곳인지 아닌지 알 수 있을 것입니다. 다음에 뵙겠습니다. [Day 4](day04.md).

2022/ko/Days/day04.md

@@ -0,0 +1,99 @@
+---
+title: '#90DaysOfDevOps - DevOps & Agile - Day 4'
+published: false
+description: 90DaysOfDevOps - DevOps & Agile
+tags: 'devops, 90daysofdevops, learning'
+cover_image: null
+canonical_url: null
+id: 1048700
+---
+
+## DevOps & Agile (데브옵스 & 애자일)
+
+데브옵스와 애자일의 차이점을 알고 계신가요? 데브옵스와 애자일은 독립적인 개념으로 형성되었습니다. 하지만 이제 이 두 용어는 융합되고 있습니다.
+
+이 글에서는 애자일과 데브옵스의 중요한 차이점을 살펴보고 이 둘이 긴밀하게 연결되어 있는 이유를 알아보겠습니다.
+
+이 분야를 배우면서 제가 본 공통적인 관점, 즉 목표와 프로세스가 비슷하지만 데브옵스와 애자일에 대해 조금 더 이해하는 것이 시작하기에 좋은 출발점이라고 생각합니다. 이 섹션에서는 이에 대해 간략하게 정리해 보려고 합니다.
+
+정의부터 시작하겠습니다.
+
+### Agile Development
+
+애자일은 제품의 큰 결과물을 한 번에 출시하기보다는 작은 결과물을 더 빠르게 제공하는 데 중점을 두는 접근 방식으로, 소프트웨어는 반복적으로 개발됩니다. 팀은 매주 또는 매달 점진적인 업데이트를 통해 새 버전을 출시합니다. 애자일의 최종 목표는 최종 사용자에게 최적의 경험을 제공하는 것입니다.
+
+### DevOps
+
+지난 며칠 동안 데브옵스의 최종 목표를 설명하는 몇 가지 다른 방법으로 이 문제를 다뤄왔습니다. 데브옵스는 일반적으로 소프트웨어 개발자와 운영 전문가 간의 협력을 기반으로
+및 소프트웨어 개발자와 운영 전문가 간의 협력을 기반으로 하는 배포 관행을 설명합니다. 데브옵스의 주요 이점은 간소화된 개발 프로세스를 제공하고 잘못된 커뮤니케이션을 최소화하는 것입니다.
+
+## 애자일과 데브옵스의 차이점은 무엇인가?
+
+차이점은 주로 선입견에 있습니다. 애자일과 데브옵스는 서로 다른 선입견을 가지고 있지만 서로를 돕고 있습니다. 애자일은 짧은 반복을 원하는데, 이는 데브옵스가 제공하는 자동화를 통해서만 가능합니다. 애자일은 고객이 특정 버전을 사용해보고 신속하게 피드백을 주기를 원하는데, 이는 데브옵스가 새로운 환경을 쉽게 만들 수 있을 때만 가능합니다.
+
+### Different participants (서로 다른 참여자)
+
+애자일은 최종 사용자와 개발자 간의 커뮤니케이션을 최적화하는 데 중점을 두는 반면 데브옵스는 개발자와 운영, 팀원을 대상으로 합니다. 애자일은 고객을 향한 외부 지향적인 반면 데브옵스는 일련의 내부 관행이라고 할 수 있습니다.
+
+### 팀
+
+애자일은 일반적으로 소프트웨어 개발자와 프로젝트 관리자에게 적용됩니다. 데브옵스 엔지니어의 역량은 제품 주기의 모든 단계에 관여하고 애자일 팀의 일원이므로 개발, QA(품질 보증) 및 운영이 교차하는 지점에 있습니다.
+
+### 적용된 프레임워크
+
+애자일에는 유연성과 투명성을 달성하기 위한 다양한 관리 프레임워크가 있습니다: Scrum > Kanban > Lean > Extreme > Crystal > Dynamic > Feature-Driven. 데브옵스는 협업을 통한 개발 접근 방식에 중점을 두지만 구체적인 방법론을 제공하지는 않습니다. 그러나 데브옵스는 코드형 인프라, 코드형 아키텍처, 모니터링, 자가 치유, 엔드투엔드 테스트 자동화와 같은 관행을 장려합니다. 그러나 이것은 그 자체로 프레임워크가 아니라 관행입니다.
+
+### 피드백
+
+애자일에서는 피드백의 주요 출처가 최종 사용자인 반면, 데브옵스에서는 이해관계자와 팀 자체의 피드백이 더 높은 우선순위를 갖습니다.
+
+### 대상 영역
+
+애자일은 배포 및 유지 관리보다 소프트웨어 개발에 더 중점을 둡니다. 데브옵스는 소프트웨어 개발에도 중점을 두지만 그 가치와 도구는 모니터링, 고가용성, 보안 및 데이터 보호와 같은 배포 및 릴리스 후 단계에도 적용됩니다.
+
+### 문서
+
+애자일은 문서화 및 모니터링보다 유연성과 당면한 작업에 우선순위를 둡니다. 반면 데브옵스는 프로젝트 문서를 필수 프로젝트 구성 요소 중 하나로 간주합니다.
+
+### 위험요소
+
+애자일 리스크는 방법론의 유연성에서 비롯됩니다. 애자일 프로젝트는 우선순위와 요구사항이 계속 변하기 때문에 예측하거나 평가하기가 어렵습니다.
+
+데브옵스 위험은 용어에 대한 오해와 적절한 도구의 부재에서 비롯됩니다. 어떤 사람들은 데브옵스를 개발 프로세스의 기본 구조를 바꾸지 못하는 배포 및 지속적 통합을 위한 소프트웨어 모음으로 간주합니다.
+
+### 사용되는 툴들
+
+애자일 도구는 경영진의 커뮤니케이션 협업, 메트릭 및 피드백 처리에 중점을 둡니다. 가장 인기 있는 애자일 도구로는 JIRA, Trello, Slack, Zoom, SurveyMonkey 등이 있습니다.
+
+데브옵스는 팀 커뮤니케이션, 소프트웨어 개발, 배포 및 통합을 위해 Jenkins, GitHub Actions, BitBucket 등과 같은 도구를 사용합니다. 애자일과 데브옵스는 초점과 범위가 약간 다르지만 핵심 가치는 거의 동일하므로 두 가지를 결합할 수 있습니다.
+
+## 모두 모아본다면... 좋은 선택일까요? 논의가 필요할까요?
+
+애자일과 데브옵스를 결합하면 다음과 같은 이점을 얻을 수 있습니다:
+
+- 유연한 관리와 강력한 기술.
+- 애자일 관행은 데브옵스 팀이 우선순위를 보다 효율적으로 소통하는 데 도움이 됩니다.
+- 데브옵스 관행을 위해 지불해야 하는 자동화 비용은 신속하고 자주 배포해야 하는 애자일 요구 사항에 따라 정당화됩니다.
+- 애자일 방식을 채택하는 팀은 협업을 개선하고 팀의 동기를 높이며 직원 이직률을 낮출 수 있습니다.
+- 결과적으로 제품 품질이 향상됩니다.
+
+애자일을 사용하면 이전 제품 개발 단계로 돌아가 오류를 수정하고 기술 부채의 누적을 방지할 수 있습니다. 애자일과 데브옵스를 동시에 도입하려면
+동시에 도입하려면 다음 7단계를 따르세요:
+
+1. 개발 팀과 운영 팀을 통합합니다.
+2. 빌드 및 운영 팀을 만들고 모든 개발 및 운영 관련 문제를 전체 DevOps 팀에서 논의합니다.
+3. 스프린트에 대한 접근 방식을 변경하고 우선순위를 지정하여 개발 작업과 동일한 가치를 지닌 DevOps 작업을 제공하세요. 개발 팀과 운영 팀이 다른 팀의 워크플로와 발생 가능한 문제에 대해 의견을 교환하도록 장려하세요.
+4. 모든 개발 단계에 QA를 포함하세요.
+5. 올바른 도구를 선택하세요.
+6. 가능한 모든 것을 자동화하세요.
+7. 가시적인 수치 결과물을 사용하여 측정하고 제어하세요.
+
+어떻게 생각하시나요? 다른 견해가 있으신가요? 개발자, 운영, QA 또는 애자일 및 DevOps에 대해 더 잘 이해하고 이에 대한 의견과 피드백을 전달해 주실 수 있는 분들의 의견을 듣고 싶습니다.
+
+### Resources
+
+- [DevOps for Developers – Day in the Life: DevOps Engineer in 2021](https://www.youtube.com/watch?v=2JymM0YoqGA)
+- [3 Things I wish I knew as a DevOps Engineer](https://www.youtube.com/watch?v=udRNM7YRdY4)
+- [How to become a DevOps Engineer feat. Shawn Powers](https://www.youtube.com/watch?v=kDQMjAQNvY4)
+
+여기까지 왔다면 이곳이 자신이 원하는 곳인지 아닌지 알 수 있을 것입니다. 다음에 뵙겠습니다. [Day 5](day05.md).

2023.md

@@ -107,12 +107,12 @@ Or contact us via Twitter, my handle is [@MichaelCade1](https://twitter.com/Mich
 ### AWS
 
 - [✔️] ☁️ 49 > [AWS Cloud Overview](2023/day49.md)
-- [✔️] ☁️ 50 > [Get a Free Tier Account & Enable Billing Alarms](2023/day50.md)
+- [✔️] ☁️ 50 > [Create Free Tier Account & Enable Billing Alarms](2023/day50.md)
 - [✔️] ☁️ 51 > [Infrastructure as Code (IaC) and CloudFormation](2023/day51.md)
-- [] ☁️ 52 > [](2023/day52.md)
-- [] ☁️ 53 > [](2023/day53.md)
-- [] ☁️ 54 > [](2023/day54.md)
-- [] ☁️ 55 > [](2023/day55.md)
+- [✔️] ☁️ 52 > [Identity and Access Management (IAM)](2023/day52.md)
+- [✔️] ☁️ 53 > [AWS Systems Manager](2023/day53.md)
+- [✔️] ☁️ 54 > [AWS CodeCommit](2023/day54.md)
+- [✔️] ☁️ 55 > [AWS CodePipeline](2023/day55.md)
 
 ### Red Hat OpenShift
 
@@ -136,8 +136,8 @@ Or contact us via Twitter, my handle is [@MichaelCade1](https://twitter.com/Mich
 
 ### Serverless
 
-- [] 👩🏿‍💻 70 > [](2023/day70.md)
-- [] 👩🏿‍💻 71 > [](2023/day71.md)
+- [✔️] 👩🏿‍💻 70 > [What is Serverless?](2023/day70.md)
+- [✔️] 👩🏿‍💻 71 > [Serverless Compute](2023/day71.md)
 - [] 👩🏿‍💻 72 > [](2023/day72.md)
 - [] 👩🏿‍💻 73 > [](2023/day73.md)
 - [] 👩🏿‍💻 74 > [](2023/day74.md)

2023/day49.md

@@ -1,5 +1,13 @@
 # Day 49: AWS Cloud Overview
 
+Welcome to the AWS section of the 90 Days of DevOps! Picking 7 items to learn about is difficult for several reasons:
+1. At last count, there were 250+ AWS services
+2. Each service could get it's own multi-day deep dive 😅
+
+Because of that, we're going to do a gentle intro that starts off easy, goes into some very DevOps-salient services, then ends with a section-capstone project that will give you a lot of exposure to AWS DevOps services.
+
+I hope you enjoy the next 7 days as much as I did creating them. If you have any questions feel free to ask!
+
 AWS Cloud is a cloud computing platform provided by Amazon Web Services (AWS). It offers a wide range of services, including computing, storage, networking, database, analytics, machine learning, security, and more. AWS Cloud allows businesses and organizations to access these services on a pay-as-you-go basis, which means they only pay for what they use and can scale their resources up or down as needed.
 
 ![](images/day49-1.png)

2023/day52.md

@@ -0,0 +1,56 @@
+# Day 52: Identity and Access Management (IAM)
+
+As cloud computing continues to gain popularity, more and more organizations are turning to cloud platforms to manage their infrastructure. However, with this comes the need to ensure proper security measures are in place to protect data and resources. One of the most critical tools for managing security in AWS is Identity and Access Management (IAM).
+
+## What is AWS IAM?
+|![](images/day52-1.png)| 
+|:-:|
+| <i>IAM is (1) WHO (2) CAN ACCESS (3) WHAT</i>|
+
+
+AWS IAM is a web service that allows you to manage users and their access to AWS resources. With IAM, you can create and manage AWS users and groups, control access to AWS resources, and set permissions that determine what actions users can perform on those resources. IAM provides fine-grained access control, which means that you can grant or deny permissions to specific resources at a granular level.
+
+IAM is an essential tool for securing your AWS resources. Without it, anyone with access to your AWS account would have unrestricted access to all your resources. With IAM, you can control who has access to your resources, what actions they can perform, and what resources they can access. IAM also enables you to create and manage multiple AWS accounts, which is essential as large organizations will always have many accounts that will need some level of interaction with each other:
+
+|![](images/day52-2.png)|
+|:-:|
+| <i>Multi-Account IAM access is essential knowledge</i>|
+
+
+## How to Get Started with AWS IAM
+
+Getting started with AWS IAM is straightforward. Here are the steps you need to follow:
+
+### Step 1: Create an AWS Account
+
+The first step is to create an AWS account if you don't already have one. We did this on day 50 so you should be good to go 😉
+
+### Step 2: Set up IAM
+
+Once you have an AWS account, you can set up IAM by navigating to the IAM console. The console is where you'll manage IAM users, groups, roles, and policies. 
+
+### Step 3: Create an IAM User
+
+The next step is to create an IAM user. An IAM user is an entity that you create in IAM that represents a person or service that needs access to your AWS resources. When you create an IAM user, you can specify the permissions that the user should have. One of the homework assignments from Day 50 was to [Create an IAM user](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html), if you haven't completed that go back and make one now. 
+
+### Step 4: Create an IAM Group
+
+After you've created an IAM user, the next step is to create an IAM group. An IAM group is a collection of IAM users. When you create an IAM group, you can specify the permissions that the group should have. Watch "IAM Basics" and read "IAM User Guide:Getting Started" in the resources section to accomplish this.
+
+### Step 5: Assign Permissions to the IAM Group
+
+Once you've created an IAM group, you can assign permissions to the group. This involves creating an IAM policy that defines the permissions that the group should have. You can then attach the policy to the group. Watch "IAM Tutorial & Deep Dive" and go through the IAM Tutorial in the resources section to accomplish this.
+
+### Step 6: Test the IAM User
+
+After you've assigned permissions to the IAM group, you can test the IAM user to ensure that they have the correct permissions. To do this, you can log in to the AWS Management Console using the IAM user's credentials and attempt to perform the actions that the user should be able to perform.
+
+## Resources:
+[IAM Basics](https://youtu.be/iF9fs8Rw4Uo)
+
+[IAM User Guide: Getting started](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started.html)
+
+[IAM Video Tutorial & Deep Dive](https://youtu.be/ExjW3HCFG1U)
+
+[IAM Tutorial: Delegate access across AWS accounts using IAM roles](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)
+

2023/day53.md

@@ -0,0 +1,49 @@
+# Day 53: AWS Systems Manager
+
+![](images/day53-01.png)
+
+AWS Systems Manager is a fully managed service that allows users to manage and automate operational tasks both on their AWS and on-premises resources. It provides a centralized platform for managing AWS resources, virtual machines, and applications. It enables DevOps professionals to automate operational tasks, maintain compliance, and reduce operational costs.
+
+With AWS Systems Manager, users can perform tasks such as automating patch management, automating OS and application deployments, creating and managing Amazon Machine Images (AMIs), and monitoring resource utilization. It also provides a set of tools for configuring and managing instances, which includes run commands, state manager, inventory, and maintenance windows.
+
+Furthermore, AWS Systems Manager provides a unified view of operational data, allowing users to visualize and monitor operational data across their AWS infrastructure, including EC2 instances, on-premises servers, and AWS services. This allows users to identify and resolve issues faster, improving operational efficiency and reducing downtime.
+
+## How to Get Started with AWS System Manager?
+
+Getting started with AWS System Manager is as easy as 1, 2, 3, 4 😄:
+
+![](images/day53-03.png)
+
+### Step 1: Navigate to the AWS System Manager Console
+
+Once you have an AWS account, create 2 windows servers and 2 linus servers (free tier of course 😉) and navigate to the AWS System Manager console. The console provides a unified interface for managing AWS resources, including EC2 instances, on-premises servers, and other resources:
+
+![](images/day53-02.png)
+Click the "get started" button and choose your preferred region (I picked us-east-1)
+
+### Step 2: Choose a configuration type
+
+The next step is to configure AWS Systems Manager to manage your resources. You can do this by selecting one of the quick setup common tasks (or create a custom setup type of your own choosing):
+![](images/day53-04.png)
+For my needs I'm going to choose "Patch Manager" - in the resources below we will have additional scenarios that you can experiment with. Watch "Patch and manage your AWS Instances in MINUTES with AWS Systems Manager" to see this step in action. 
+
+### Step 3: Specify configuration options
+
+Each configuration type has a unique set of parameters to apply for this step... 
+|![](images/day53-05.png)|
+|:-:|
+| <i>You will see something different depending on which quick start config you chose</i>|
+
+so I won't be getting into the required arguments for each one. Generally speaking the next step is to create a resource group to organize your resources. Resource groups are collections of resources that share common attributes. By grouping resources, you can view them collectively and apply policies and actions to them together. Watch "Patch and manage your AWS Instances in MINUTES with AWS Systems Manager" to see this step in action. 
+
+### Step 4: Deploy, Review, and Manage Your Resources
+
+Once you have created a resource group, you can view and manage your resources from the AWS System Manager console. You can also create automation workflows, run patch management, and perform other operations on your resources.
+
+## Resources:
+[AWS Systems Manager Introduction](https://youtu.be/pSVK-ingvfc)
+
+[Patch and manage your AWS Instances in MINUTES with AWS Systems Manager](https://youtu.be/DEQFJba3h4M)
+
+[Getting started with AWS System Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/getting-started-launch-managed-instance.html)
+

2023/day54.md

@@ -0,0 +1,32 @@
+# Day 54: AWS CodeCommit
+
+![](images/day54-01.png)
+
+
+AWS CodeCommit is a fully managed source control service provided by Amazon Web Services (AWS) that makes it easy for developers to host and manage private Git repositories. Think "GitHub but with less features" 🤣 (j/k, see the resource "CodeCommit vs GitHub" for a breakdown) It allows teams to collaborate on code and keep their code securely stored in the cloud, with support for secure access control, encryption, and automatic backups.
+
+With AWS CodeCommit, developers can easily create, manage, and collaborate on Git repositories with powerful code review and workflow tools. It integrates seamlessly with other AWS services like AWS CodePipeline and AWS CodeBuild, making it easier to build and deploy applications in a fully automated manner.
+
+Some key features of AWS CodeCommit include:
+
+- Git-based repositories with support for code reviews and pull requests
+- Integration with AWS Identity and Access Management (IAM) for secure access control (this is a big plus)
+- Encryption of data at rest and in transit
+- Highly scalable and available, with automatic backups and failover capabilities
+- Integration with other AWS developer tools like AWS CodePipeline and AWS CodeBuild
+
+In order to effectively leverage CodeCommit, you of course need to know how to use Git. There are [many](https://www.youtube.com/playlist?list=PL2rC-8e38bUXloBOYChAl0EcbbuVjbE3t) [excellent](https://youtu.be/tRZGeaHPoaw) [Git](https://youtu.be/USjZcfj8yxE) [tutorials](https://youtu.be/RGOj5yH7evk) out there, (and that's not my section anyway 😉) so I won't go into that myself.
+
+Overall, AWS CodeCommit is a powerful tool for teams that need to collaborate on code, manage their repositories securely, and streamline their development workflows.
+
+
+
+## Resources:
+
+[AWS CodeCommit User Guide](https://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html)
+
+[AWS CodeCommit Overview](https://youtu.be/5kFmfgFYOx4)
+
+[AWS CodeCommit tutorial: your first Repo, Commit and Push](https://youtu.be/t7M8pHCh5Xs)
+
+[AWS CodeCommit vs GitHub: Which will Shine in 2023?](https://appwrk.com/aws-codecommit-vs-github)

2023/day55.md

@@ -0,0 +1,62 @@
+# Day 55: AWS CodePipeline
+
+<i>On this last day of AWS services we are going to talk about a big one that has a lot of moving parts and integrations. There are a few free resources out there that will help in your learning/understanding of this... but honestly some of the best ones will cost you some money. I will list them out seperately in the resources section and call them out, but I would be remiss in NOT mentioning them as they are fantastic for learning this complex service</i>
+
+<b>CodePipeline</b> is a fully managed continuous delivery service that allows you to automate your IaC or software release processes. It enables you to create pipelines that build, test, and deploy your code changes continuously and (with proper testing in place) reliably:
+
+![](images/day55-01.jpg)
+
+With CodePipeline, you can create pipelines that automate your build, test, and deployment workflows, ensuring that your code changes are reliably deployed to your target environments. It enables you to achieve faster release cycles, improve collaboration among development and operations teams, and improve the overall quality and reliability of your software releases.
+
+AWS CodePipeline integrates with other AWS services: 
+- [Source Action Integrations](https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html#integrations-source)
+- [Build Action Integrations](https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html#integrations-build)
+- [Test Action Integrations](https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html#integrations-test)
+- [Deploy Action Integrations](https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html#integrations-deploy)
+- [Approval Action Integrations](https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html#integrations-approval)
+- [Invoke Action Integrations](https://docs.aws.amazon.com/codepipeline/latest/userguide/integrations-action-type.html#integrations-invoke)
+
+
+ It also integrates with third-party tools such as GitHub, Jenkins, and Bitbucket. You can use AWS CodePipeline to manage your application updates across multiple AWS accounts and regions.
+
+## Getting started with AWS CodePipeline
+
+To get started with AWS CodePipeline, there are several excellent [tutorials](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials.html) in the [AWS User Guide](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html). They all basically break down into the following 3 steps: 
+
+### Step 1: Create an IAM role
+
+You need to create an IAM role that allows AWS CodePipeline to access the AWS resources required to run your pipelines. To create an IAM role, review the steps from [Day 52](day52.md)
+
+### Step 2: Create a CodePipeline pipeline
+
+To create a CodePipeline pipeline, go to the AWS CodePipeline console, click on the "Create pipeline" button, and then follow the instructions to create your pipeline. You will need to specify the source location for your code, the build provider you want to use, the deployment provider you want to use, and the IAM role you created in step 2.
+
+### Step 3: Test and deploy your code changes
+
+Once you have created your CodePipeline pipeline, you can test and deploy your code changes. AWS CodePipeline will automatically build, test, and deploy your code changes to your target environments. You can monitor the progress of your pipeline in the AWS CodePipeline console.
+
+## Capstone Project
+To tie up this AWS section of the 90 Days of DevOps, I recommend that you go through Adrian Cantrill's excellent mini-project, the [CatPipeline](https://www.youtube.com/playlist?list=PLTk5ZYSbd9MgARTJHbAaRcGSn7EMfxRHm). In it you will be exposed to CodeCommit, CodeBuild, CodeDeploy, and CodePipeline in a fun little project that will give you a taste of a day in the life of a DevOps engineer. 
+- [YouTube CatPipeline Playlist](https://www.youtube.com/playlist?list=PLTk5ZYSbd9MgARTJHbAaRcGSn7EMfxRHm)
+- [GitHub CatPipeline Repo](https://github.com/acantril/learn-cantrill-io-labs/tree/master/aws-codepipeline-catpipeline) 
+
+
+## Resources (Free):
+
+[AWS: Real-world CodePipeline CI/CD Examples ](https://youtu.be/MNt2HGxClZ0)
+
+[AWS CodePipeline User Guide](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html)
+
+[AWS CodePipeline Tutorials](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials.html)
+
+[AWS CodeCommit tutorial: your first Repo, Commit and Push](https://youtu.be/t7M8pHCh5Xs)
+
+[AWS CodeCommit vs GitHub: Which will Shine in 2023?](https://appwrk.com/aws-codecommit-vs-github)
+
+## Resources (Paid):
+There are a number of <i>excellent</i> instructors out there and picking 2-3 is always hard, but [Adrian Cantrill](https://learn.cantrill.io/), [Andrew Brown](https://www.exampro.co/), and [Stephane Maarek](https://www.udemy.com/user/stephane-maarek/) always come to mind when discussing fantastic content out there. 
+
+## Final Thoughts
+I hope that this section of the 90 Days of DevOps has given you a taste of what is available in the AWS ecosystem. 
+
+Good luck in your studies! Up next is Red Hat OpenShift!

2023/day70.md

@@ -0,0 +1,17 @@
+# What is Serverless?
+
+The term "Serverless" has become quite the buzzword over these past few years, some folks today even arguing whether or not the term still holds weight. You may or may not have heard about serverless technology up to this point in your journey through development. But what exactly is serverless? What does it mean to design applications in a serverless manner? What constitutes a serverless service or offering? I hope to answer all these questions and more over this series of blog posts.
+
+As an [AWS Hero](https://aws.amazon.com/developer/community/heroes/kristi-perreault/?did=dh_card&trk=dh_card) and a Principal Software engineer at a large Fortune 100 enterprise, I have been focused solely on serverless technologies and enablement over the last 3 years. I have spoken quite extensively about our [serverless journey](https://youtu.be/ciCz8dnDuEs), [what serverless means in a large enterprise](https://syntax.fm/show/484/supper-club-70-000-serverless-functions-with-kristi-perreault-of-liberty-mutual), and [how to be successful in a corporate setting](https://www.youtube.com/watch?v=ctdviJ2Ewio). Everything I have learned has been through experience, on-the-job. The [serverless definition](https://aws.amazon.com/serverless/) I resonate with most states that serverless is event-driven, your resources scale up and down without you needing to manage them, and follows an "only pay for what you use" model. Let's break this down a bit further:
+
+- [Event-driven architecture](https://aws.amazon.com/event-driven-architecture/#:~:text=An%20event%2Ddriven%20architecture%20uses,on%20an%20e%2Dcommerce%20website.) is exactly how it sounds. You build your applications following the flow of your events. When x happens, I want to trigger y, to run service z. We write our serverless applications with this flow in mind.
+
+- Automatically scaling up and down as your service demands is a key component of serverless functionality. I fault the name "serverless" here a quite a bit, because contrary to popular belief, serverless does in fact include servers - you just don't need to manage them in the same way you would with your on-premises ecosystem or other cloud resources. You still need to provision the resources you need, and some configuration is required, but gone are the days of estimating exactly how much storage and processing power you need - your cloud provider handles this for you. This frees the developer up for focusing more on business code, and less on physical infrastructure.
+
+- With automatic scaling, this also lends you to only pay for exactly what you are using. You no longer need to buy and maintain a physical server you may only use to half its capacity, save for the one time of year your traffic hits its peak, for instance. You don't need to pay for all the storage and processing power you have to have "just in case" - you pay exactly for what you use, exactly when you need it. No more, no less.
+
+I am a large proponent of serverless, and I believe these are huge benefits to adopting serverless, but that does not mean it is for everyone or every architecture. I talk quite a bit about the concept of "[serverless-first](https://www.liberty-it.co.uk/stories/articles/tomorrow-talks-how-build-serverless-first-developer-experience)" design, meaning that you approach every architecture in a serverless manner first, and if that is not the most optimal design, you move on to other solutions like containers, relational databases, reserved compute instances, and so on. Equally as important, especially in a large enterprise, is to evaluate your time constraints and areas of expertise. Serverless is not going to be for everyone, and depending on your background, there can be a large learning curve associated with adopting it. The trade off is worth it, but if you do not have the adequate time or drive to dedicate to this transformation, you will not be successful.
+
+That being said, I hope to provide you with a strong starting point for the land of serverless. Over the next few days, we will be exploring serverless resources and services, from compute, to storage, to API design, and more. We will keep our discussions high-level, but I'll be sure to include relevant examples, resources, and further reading from other leading industry experts. No prerequisites are necessary, I just ask you approach each and every article with an open mind, continue to ask questions & provide feedback, and let's dive in!*
+
+*As a quick disclaimer - as I am an AWS Serverless Hero, most of the examples and explanations I give will reference the AWS ecosystem since that is where my expertise is. Many of the AWS services and tools we will discuss have equivalents across Azure, GCP, or other tooling. I will do my best to call these out going forward. This is part of a series that will be covered here, but I also encourage you to follow along on [Medium](https://kristiperreault.medium.com/what-is-serverless-1b46a5ffa7b3) or [Dev.to](https://dev.to/aws-heroes/what-is-serverless-4d4p) for more.

2023/day71.md

@@ -0,0 +1,25 @@
+Compute is one of the basic building blocks of building any application. What is your application aiming to accomplish? Where are you keeping your business logic? What are you _running_ and **how**?
+
+![Woman at computer. Image via Unsplash.](images/day71-1.jpg)
+
+The key compute resource everyone immediately associates serverless with is [AWS Lambda](https://aws.amazon.com/lambda/). I want to be clear here - AWS Lambda is a large part of the serverless ecosystem, BUT Lambda ≠ serverless. Just because you include a lambda function in your application does not automatically make you serverless. Likewise, just because you build a service completely out of lambda functions also does not mean you have a serverless application. Serverless is a mindset, a new way of thinking; there are tons of tools and services out there that will help you build serverless applications, but implementing them does not mean you have a serverless application. We need to be intentional with our design, and where & how we use these resources.
+
+**AWS Lambda**
+If you're in Azure, your equivalent service is [Azure Functions](https://learn.microsoft.com/en-us/azure/azure-functions/). For Google, this is [Google Functions](https://cloud.google.com/functions) (yes, AWS just HAD to be different). Regardless of its name, all of these services fulfill the same purpose - a small compute building block to house your business logic code. An AWS Lambda function is simply the code you want to run, written in your language of choice (I preference Python, but Typescript and Java are popular options). In your [infrastructure code](https://learn.microsoft.com/en-us/devops/deliver/what-is-infrastructure-as-code#:~:text=Infrastructure%20as%20code%20(IaC)%20uses,load%20balancers%2C%20and%20connection%20topologies.), you specify some [lambda function basics](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-function.html?highlight=create%20lambda%20function), like name, path to the business logic code, security role, and what runtime you're using, and optionally have the ability to control more parameters like timeout, concurrency, aliases, and more. Lambda even has built in integrations to other AWS services, such as [S3](https://aws.amazon.com/s3/) and [SQS](https://aws.amazon.com/sqs/) (we'll get to these) to make application development even easier. Additionally, [lambda functions are priced](https://aws.amazon.com/lambda/pricing/) based on the number of times they're invoked and the duration of time they run, making them exceptionally affordable.
+
+
+![Lambda is one single building block of a larger application. Image via Unsplash.](images/day71-3.jpg)
+
+Of course, there are cases where lambda functions may not be the best option for compute, if you have long-running, highly complex computational processes, lambda functions may not be the best fit for your application. If you're migrating an application to serverless, it's also very likely that this is not a 1:1 changeover. Throwing all of your code into one lambda function is not optimizing for serverless, meaning that your monolith architecture may need to be written into [microservices](https://aws.amazon.com/microservices/) to take full advantage of everything lambda and serverless has to offer. Whether you're migrating or building something brand new however, lambda functions are (dare I say) the choice for serverless compute as they're lightweight, easy to provision, and cost effective.
+
+**AWS Fargate**
+AWS defines [Fargate](https://docs.aws.amazon.com/AmazonECS/latest/userguide/what-is-fargate.html) as a 'serverless compute engine', but I prefer to define it as a serverless container. [Containers](https://aws.amazon.com/containers/services/) are an entirely different topic of discussion so I won't dive into them too much, but they do fall under the same "[modern applications](https://aws.amazon.com/modern-apps/)" umbrella that serverless does, making them a sort of sibling option. Containerizing an application is a fancy way of saying you are bundling all aspects of your application into a more portable service (ie, basically sticking your app into a box for ease of movement and use). This makes containers very popular for migrating applications, batch processing, AI/ML, and more.
+
+Fargate stands sort of in the middle as a container service that offers many of the same serverless benefits that lambda has - no need to manage your infrastructure, built-in integrations to other AWS services, and pay-as-you-go pricing. What makes you choose one compute option over the other then? In my experience, this really comes down to what you want your end product to be, what time you have, and what experience you have. Personally, Fargate is more of a 'lift-and-shift' solution for applications that you don't want to change much of, but need to move quickly and easily while wanting to take advantage of serverless benefits. It definitely has its place as part of other applications as well, but it also comes down to the level of comfort you or your teams have with serverless or containerization. Containers may be quicker to adopt, whereas serverless requires more of a mindset shift, and typically comes with some rearchitecting. I believe this does pay off tenfold in the long run, but given your particular use cases and time constraints, Fargate may be a better option.
+
+
+![Fargate is a serverless container service. Image via Unsplash.](images/day71-2.jpg)
+
+These two options pretty much sum up serverless compute, believe it or not. When it comes to your business logic code in AWS or other cloud provider, these two services cover most, if not all, serverless application needs. As we continue on in this series, you'll realize there are a ton of other 'supporting' serverless services for storage, APIs, orchestration, and more to dive into. I hope this has given you a good preview on serverless compute and what's to come, tune in tomorrow where we'll discuss the various serverless storage solutions available to us. See you then!
+
+*This is part of a series that will be covered here, but I also encourage you to follow along with the rest of the series on [Medium](https://kristiperreault.medium.com/serverless-compute-b19df2ea0935) or [Dev.to](https://dev.to/aws-heroes/serverless-compute-3bgo).