DevOps와 NoOps

🍳머리말

DevOps, NoOps 배경 및 하는 일 등을 설명하는 글입니다. Kubenetes in action이라는 책을 일부 요약한 글입니다.

---

📕DevOps

📔 배경

  📑 개발 process의 변화

 전체 app의 개발 process와 production에서 app을 처리하는 방식에 변화가 있었습니다. 과거에는 개발 팀이 app 개발 후 운영팀에게 package형태로 넘겨주면 운영팀은 app을 배포, 관리, 실행을 맡았습니다. 그러나 지금은 app을 개발하는 사람이 배포에도 참여하고 전체 life-cycle을 함께 관리할 수 있게 팀을 구성하고 운용하는 것이 배포까지의 단계가 줄고 더 효율적이기 때문에 바뀌게 되었습니다. 또한 큰 변화에 대해서만 배포를 하게 된다면 그 사이 변화로 system의 위험이 증가하며 이를 막기 위해 작은 배포를 반복하게 된다면 변화가 작아 위험 또한 작아지게 됩니다. 배포의 단계를 줄이기 위해, risk를 적게 가지기 위해 개발과 운영 부문이 협력이 필수적이게 되었습니다. 이런 생각이 개발에서 운영까지를 하나의 통합된 process를 묶게 되었고 tool, system을 표준화하며 협업하고 효율적 의사소통을 추구하며 manual 작업을 가능한 자동화하여 code통합, test, release과정이 자동화될 수 있도록 환경을 구축하게 됩니다.

이런 작업방식을 DevOps라고 부릅니다.

📔 장점

  📑 문제에 대한 이해도 상승

 개발자가 app 실행에 더 많은 시간을 투자하면 사용자가 무엇을 필요로 하고, 어떤 문제가 있는지 잘 이해할 수 있게 됩니다. 또한 운영 팀이 app을 유지하는 동안 직면하는 문제를 더 잘 알 수 있게 됩니다. app배포까지의 단계가 짧으므로 사용자의 feedback으로 추가 개발 여부를 검토할 수 있습니다. 가장 좋은 방법은 운영 담당자를 거치지 않고 배포하는 것입니다. 따라서 app을 개발자가 직접 배포까지 하게 됩니다. 다행히 이는 기본 infra와 hardware구성을 몰라도 가능합니다.

---

📕NoOps

📔 배경

개발자와 system관리자는 고객이 잘 사용할 수 있는 software를 전달한다는 동일한 목표를 달성하려고 하지만 각자의 목표와 동기는 다릅니다.

  📑 개발자

 새로운 기능을 개발해 UX를 개선하는 것을 좋아합니다. 기본 os의 보안 patch와 해당 사항 관련해서 최신화가 되었는지 확인하는 것을 system관리자에게 맡기고 싶어합니다.

 📑 운영팀

 제품 배포와 운영하는 hardware infra를 담당하고 system 보안, 활용, 개발자의 입장에서는 우선순위가 높지 않은 측면에 신경을 씁니다. 모든 app 구성요소의 상호 의존성에 대처하기를 원하지 않으며, 기본 운영체제나 infra를 변경했을 때 app 전체 동작에 어떤 영향을 미칠지는 고려하지 않습니다.

 

hardware infra를 알 필요 없이 관리자는 따로 두며 운영 팀을 거치지 않고 개발자가 직접 app을 build, test, 배포하는 방식이 단순하고 이상적입니다. 이를 cloud를 이용해 자동화한다면 이를 NoOps라고 합니다. 이들은 실행 중인 app의 특성을 꼭 알 필요는 없습니다.

 

📕 결론

kubernetes는 이들 모두를 가능하게 합니다. app을 배포, 실행하는 단일 platform으로 실제 hardware를 추상화하고 노출하므로 개발자는 system 관리자의 도움 없이 app을 구성하고 배포할 수 있습니다. system 관리자는 app에 대해 모르더라도 기본 infra를 유지하고 가동하는데에 집중할 수 있습니다.

---

📕 참조

 

DevOps 

DevOps - Wikipedia

NoOps

What is NoOps? - Definition from WhatIs.com