Medium - DevOps Is Dead, Long Live NoOps
in Trend
Trend 파악을 위한 Medium 기고문 포스팅 - 데브옵스는 죽었습니다, 노옵스여 영원하라; 데브옵스가 왜 충분하지 않은지 배워봅시다.
Foto di Olalekan Oladipupo da Pixabay
이런 낚시성 제목을 붙여서 사과드립니다. 이런 속임수를 쓰는 것을 좋아하진 않지만 여러분의 주의를 끌고 싶었습니다. IT 트렌드에서 데브옵스는 요즘 너무나 유명한 단어입니다. 해당 단어는 몇년전 프론트엔드에서 SPA(Single Page Application)이 만연할 때 생겨났습니다.
저는 대중적으로 데브옵스가 기술로써 채택되었다고 생각합니다. 새로운 기술이 나타나면 선구자들이 적용을 하고 그 다음에 모두에게 널리 퍼지게 됩니다. 이런 일이 지난 몇년간 데브옵스에서 일어났습니다. 다음 몇년간은 이렇게 들어본 적 없는 단어가 유명해 질 것입니다: 노옵스.
What Is the Difference Between DevOps and NoOps?
데브옵스는 개발과 운영의 조합으로 개발을 담당하는 엔지니어, 운영을 담당하는 엔지니어들이 함께 협업을 하여 디자인부터 배포가지 서비스 라이프 사이클에서 함께 움직이는 것입니다. 노옵스의 의미는 운영이 없습니다. 논리적으로는 모든 플랫폼 관리 부분을 없애고 개발자들과 인프라 사이의 마찰을 줄이는 것입니다.
Why Do We Need DevOps?
기술저거 요구사항과 비즈니스 요구사항은 갈수록 어려워지고 IT 서비스들이 더욱 복잡해지게 만들고 있습니다. 이것이 배포가 가장 중요하고 모든 프로세스에서 협업을 해야하는 필요성 입니다.
클라우드에서 우리는 더이상 시스템 관리자가 필요없고 대신에 데브옵스 기술이나 비즈니스 기술이 더욱 요구됩니다. 데브옵스를 구현해서 이익을 보기 위해서는 배경의 배포 기술을 생각해야 합니다.
Why Didn’t We Have DevOps Before?
이 질문에는 많은 답변이 있을 수 있습니다. 여러분은 아마 시나리오가 간단했거나 충분한 문화가 아니었기 때문에 필요가 없었을 것이라고 생각할 겁니다. 이런 논쟁에 동의하는 바입니다만 문제의 근본은 다릅니다. 제 경험 상 더욱 큰 문제는 기술적인 것입니다. 자동화 배포 기술이 구현하기 어려웠던 시절입니다. 10년전 많은 시스템에서는 원클릭 빌드나 깃-플로우 같이 잘 정의된 워크 플로우가 없었습니다. 동시에 저렴한 CI 솔루션이 없었기 때문에 구현하기가 어려웠기 떄문에 구현되지 않았던 것입니다.
2009년에 .net 포탈에서 배포를 했었습니다. 처음으로 했던 작업이죠. 토요일 오전을 오픈소스 도구를 이용해서 자동화 배포 시스템을 만들려고 했지만 결국 포기했죠. 저는 그런 시스템을 유지보수 하는 것이 수동으로 배포하는 것보다 훨씬 비싸다는 것을 이해했습니다. 요즘에는 애져 데브옵스를 이용해서 10분만에 그냥 웹브라우저에서 할 수 있습니다. 시대가 변했습니다.
Why Do We Need More Than DevOps?
왜 데브옵스가 필요한지 이해하려면 많은 시간을 들여서 회사에 데브옵스를 알리면 됩니다. 여러분들은 괜찮다고 생각하시겠죠. 그것이 문제입니다. IT업계에서는 많은 것들이 여러분보다 더욱 빨리 변합니다. 시장 요구사항은 더욱 더 많아지고 여러분인 간단히 “변화에 지쳤어, 좀 쉬자” 라고 말할 수 없습니다. 클라우드의 도래로 많은 것이 복잡해졌습니다. 복잡한 솔루션을 구현할 수 있게 해주고 많은 문제를 해결하게 해주지만 더욱 많은 기술을 필요로 합니다.
여러분의 클라우드들은 확장 가능한채로 판매되지만 항상 데브옵스가 필요할 것입니다. 이 말은 어떤 부분에서는 항상 수동적인 노력이 들어간다는 것입니다. 프로세스의 많은 부분을 조작하는 사람이 필요한 것이죠. 이것이 구식으로 일하고 있다는 의미입니다. 노옵스의 목적은 개발과 운영의 조합으로 뭔가를 만들 필요가 없는 프로세스를 정의하는 것입니다
기본적으로 노옵스는 다음과 같은 접근입니다. 개발자가 저장소에 코드를 커밋하면 모든 것이 배포되는 것입니다. 지속적인 전달과 매우 유사하지만 더 나아간 것입니다. 배포에 관해서 우리는 응용프로그램에서만 얘기하고 인프라에 대해서는 말하지 않죠.
How NoOps Is Possible?
데브옵스가 그러했든 노옵스도 기술로인해 가능해 집니다. 많은 선택지가 있지만 다음과 같이 요약할 수 있습니다.
- PaaS 솔루션으로 Heroku나 Azure, AWS와 같은 클라우드 서비스에서 호스팅됩니다.
- AWS, Azure같은 큰 벤더사에서 서버리스 컴퓨팅을 빌려옵니다.
- 복제 가능한 인프라를 만듭니다 (거의 이부분에서만 오퍼레이션 작업이 필요합니다.)
이런 솔루션들은 인프라 부분을 해결하는데 좋으며 고전적인 배포 작업들은 이런 프로세스가 응용프로그램으로 전달될 수 있도록 합니다.
Not All That Glitters Is Gold
인프라 관리를 제거하는 생각이 매력적이라는 것을 인정합니다. 썪은 이를 뽑는 것과 같죠. 인프라는 관리 비용이 매우 높고 개발자와 운영 간의 마찰을 항상 빚어냅니다. 그러나 포인트는 또 다른 것입니다. 인프라가 문제가 아닙니다. 문제는 프로세스 입니다. 프로세스가 잘 설계되면 마찰이 없을 것이고 지연도 없으며 모든 것이 정확하게 잘 동작할 것입니다.
관리 비용이 부담스러우신가요? 전체 비용을 고려해 보세요, 관리 비용만 보는 것이 아니라요. 여러분의 클라우드기반 non-PaaS 인프라의 관리비용이 더욱 나온다고 하더라도 결국에 비용은 똑같아 질 것입니다. 혼란스러운시가요?
시크릿을 말씀드리겠습니다. 어떤 응용프로그램은 PaaS에서 배포될 수 있지만 다른 것은 아닙니다. 그게 다에요. 응용프로그램이 간단하다면 PaaS가 좋은 솔루션이며 데브옵스 인원들이 작업이 적어서 기뻐할 겁니다. 만약 넷플릭스와 같은 것을 런칭한다면 더욱 많은 컨트롤이 필요하겠죠. 그래서 결국에는 데브옵스나 노옵스가 없다는 것입니다. 오직 하나의 드라이버가 남습니다. 현명한 인프라를 만들어서 가능한한 적은 유지보수의 수고를 들이게 하고 모든 것을 자동화 시키는 것입니다. 구글 클라우드와 같은 거대한 클라우드 서비스를 이용하면 여러분의 시나리오에 맞는 최적의 솔루션을 찾게 될 것입니다. 따라서 이 관점에서 노옵스는 뭘까요? 클라우드 트랜스포메이션 트렌드의 또 다른 핫한 키워드입니다.
Summary
- 데브옵스를 넘어서 노옵스가 가능할 정도의 기술 수준이 되었다.
- 운영과 개발을 구분하지 않고 인프라를 잘 구축한다면 노옵스가 가능할 것이다.
- 거대한 클라우드 서비스 벤더사를 이용하자
