- 너무 올드함. (아직도.. 프로젝트를 war로 패키징한 다음 톰캣에 직접 업로드 -> 이런 작업 자체가 시간 낭비)
- 고객사의 새로운 요구사항을 빠르게 대응하기 어려움.
👨💻 Cloud Native란?
- 요약 : 효율적인 애플리케이션 구축 & 운영 방법
(사람마다, 업체마다 Cloud Native의 정의가 다르다. 다만, 공통적으로 추구하는 목적은 위와 같다.)
👨💻 구체적으로 어떻게 하라는건데?
1. 컨테이너를 사용(ex, 도커) -> 우수한 환경 일관성과 빠른 배포, 이식성 및 확장성을 제공
2. MSA 도입 -> 여러 팀이 동시에 어플리케이션의 서로 다른 부분을 구축 및 테스트 -> 소프트웨어 개발 속도 촉진
3. 지속적인 통합 -> 개발자들은 소프트웨어 빌드를 신속하게 반복 가능
4. 코드형 인프라를 사용 -> 서버, 스토리지 및 네트워킹 배포 소요시간 단축
5. 데브옵스 -> 개발자와 운영자가 한 팀! 우린 친구칭구
👨💻 Cloud Native의 핵심
- 애플리케이션을 효율적으로 완성하려면 어떻게 만들고, 배포하고 운영해야 하는지.. 그것을 고민하는 것이 핵심.
- 애플리케이션이 어디에 있는지는 중요하지 않음(데이터센터에 있던 or AWS에 있던.. 무관심)
한 줄 요약 : 현존하는 시스템 개발 & 운영에 좋은 방법들 대잔치!
👨💻 DevOps를 이해하기 위해 반드시 알아야하는 사상
운영팀과 개발팀의 사상을 알아야합니다.
- 운영팀의 사상은 안정성입니다. 이 시스템은 어제도 잘되고, 오늘도 잘되고, 내일도 잘되야합니다.
- 개발팀의 사상은 날짜를 지킨 납품입니다. 계획된 날짜에 배포하는게 목적입니다. 심지어, 시스템에 에러가 나도 상관없습니다.(배포하면 내 일은 끝이야! 운영팀이 어떻게든 해주겠지! 하하)
👨💻 DevOps의 탄생배경
개발팀이 에러가 폭주하는 프로그램을 납품하고 다른 프로젝트에 투입됨 -> 프로그램에서 에러가 폭주해서 고객사가 열받음 -> 고객사가 운영팀에게 컴플레인(실상은 쌍욕)을 검. -> 운영팀이 빡쳐서 개발팀에게 프로그램을 납품 전에 QA 및 깐깐한 산출물 전달을 요구하기 시작함 -> 점점 서비스 대응이 느려짐 ->시장에서 도태됨
사람 사는 세상은 다 똑같나보다
👨💻 DevOps의 목적?
- 빠른 서비스 대응 -> 고객에게 더 큰가치를 빠르게 제공 -> 시장에서 살아남는 것
👨💻 즉, DevOps란?
- 개발자 + 운영자 한 팀으로 만드는 것
* DevOps는 조직구조를 개편한다는 의미. 데브옵스는 기술이 아니다. 자동배포,
에자일 도입, 문화.. 등등은 DevOps의 핵심과 멀다.
ex)
- 주문(MSA)팀 : 개발자 + 운영자(IT팀, 유지보수, 배포, 정보보안)
- 상품(MSA)팀 : 개발자 + 운영자(IT팀, 유지보수, 배포, 정보보안)가 한 팀이 되도록 조직구조를 바꾼다는 의미입니다.
*12-Factors
클라우드 네이티브는 12-Factors가 핵심이다. 프로젝트 구조를 잡고 배포구조를 잡을 때, 12-Factors를 지킨다면 확장성있고 이식성 있는 프로젝트를 만들 수 있다. MSA를 하거나 Cloud native로 배포한다고 한다면 꼭 알아야하는 이정표이다. 이것은 어떻게 해야하는지에 대한 얘기이며 다음 포스팅에서 집중적으로 다뤄보도록 하겠습니다.