블로그

DevOps 도입을 막는 세 가지 사항

로리 맥비티 썸네일
로리 맥비티
2017년 3월 16일 게시

 

아니, 당신은 아닙니다. 너. 임원들은 현장에 있는 임원들만큼 DevOps에 열광하지 않습니다. 그 답은 다음 세 가지 핵심 문제 중 하나에서 찾을 수 있습니다.

성과가 우수한 조직은 DevOps를 도입했을 뿐만 아니라 수용하기도 했습니다. Puppet Labs의 획기적인 DevOps 보고서는 지난 2년 동안 이러한 사실을 보여주었고, 내년에는 이러한 관계가 다시 한 번 강화될 것으로 예상합니다. 여러 업계 조사와 연구에 따르면 많은 기업이 DevOps를 도입하고 있습니다. 하지만 과거에 민첩하고 간결한 앱 개발 방법론을 채택했던 것처럼, 채택한다는 것이 항상 우리가 생각하는 바를 의미하는 것은 아닙니다. 조직이 앱 개발을 위해 "애자일 도입"이란 실제로 의미하는 바는 프로젝트 중 상대적으로 소수의 비율만이 애자일을 사용하고 있다는 것입니다. 그렇다고 해서 그들이 모든 프로젝트에 북극 탐험을 도입해 전적으로 북극 탐험에 나섰던 것은 아니다.

역할별 devops 전략 soad17

DevOps에도 동일한 것이 적용되는 듯합니다. 응답자들은 열정적으로 도입하고 결과를 실현하고 있지만, 임원진은 전반적으로 이 접근 방식에 여전히 미온적인 것으로 보이며, "전략적 영향"이 전년 대비 2%포인트만 상승했습니다. 2016년 15%에서 2017년 17%로, 당사의 애플리케이션 제공 현황 설문 조사에 따르면 그렇습니다. 클라우드 아키텍트와 자신을 "DevOps" 역할이라고 규정한 사람들은 DevOps 이니셔티브에 전력을 기울이고 있으며 프로덕션에서 장벽을 넘을 수도 있지만, 임원들은 여전히 이 접근 방식을 받아들이는 데 뒤처져 있습니다. 이는 "조직"이 반드시 DevOps를 전적으로(수용)하지는 않는다는 것을 의미합니다.

IT 및 비즈니스 리더십이 DevOps에 따뜻한 환영을 표하지 못하는 데에는 세 가지 주요 문제가 있을 것으로 보입니다.

  1. 시간 . 기존 방식에서 클라우드로, 모놀리스 방식에서 마이크로서비스로, 수동 방식에서 자동화 방식으로의 마이그레이션 사고방식이 필요한 모든 종류의 내부 IT 프로젝트는 때때로 시간 낭비에 불과하다고 여겨집니다. 이러한 프로젝트는 기업의 성장에 직접적으로 기여하지 않기 때문에 기업 이해관계자가 이런 프로젝트에 투자하는 시간을 지원하는 것은 부담스러울 수 있습니다. DevOps를 지지하는 사람들은 기업 리더에게 이런 프로젝트를 추진함으로써 얻을 수 있는 명확한 목표와 기대 이점을 설명하는 것이 마땅합니다. 비용 절감이든 IT 대응력 향상이든, 기업이 투자에 따른 예상 수익을 이해하여 노력을 지지하고 동참하도록 하는 것이 중요합니다. 저축한 1페니는 번 1페니가 될 수 있지만, 투자한 1페니는 종종 번 10페니가 됩니다. 지금 DevOps에 투자하면 조직은 나중에 그 보상을 받을 수 있습니다.
     
  2. 분열.  어떤 IT 리더도 업무 중단의 원인이 되고 싶어하지 않습니다. 지금 DevOps 이니셔티브에 투자하면 혼란스러울 수 있습니다. 특히 모든 사람이 속도를 높여야 한다는 사실을 알고 있을 때 프로덕션 파이프라인의 속도가 느려진다면 더욱 그렇습니다. 자동화 및 오케스트레이션을 위한 생산을 활성화하는 것은 종종 일상 업무를 담당하는 시스템을 손상시키는 것을 의미하므로, 이를 필요로 하는 모든 이니셔티브는 바람직하지 않은 중단을 초래할 수 있습니다. 현실은 시스템을 프로비저닝하고, 확장하고, 관리하기 위해 구식의 수동적인 방법에 의존하는 것이 오늘은 아니더라도 내일은 진짜 혼란을 초래할 수 있다는 것입니다. 마찰 없는 생산 환경의 특징 중 하나는 용량과 서비스에 대한 요구에 맞춰서 대응할 수 있는 능력입니다. 디지털 혁신 노력으로 인해 증가하는 수요에 따라 IT가 무너지면서 이를 달성하는 것이 점점 더 어려워지고 있습니다. 위험이 없으면 보상도 없습니다. 지금 위험을 감수하면 애플리케이션 포트폴리오가 2배 이상 커졌을 때보다 위험이 덜할 가능성이 높습니다.
     
  3. 잠금 . IT 리더십에 대한 일반적인 두려움은 선택에 의해 "갇히는 것"에 대한 두려움입니다. 좋은 소식은 자동화와 오케스트레이션을 지원하는 대부분의 네트워크 장치와 시스템이 HTTP, REST, JSON과 같은 개방형 표준 프로토콜과 개념을 기반으로 한다는 것입니다. API와 템플릿을 최대한 활용하는 시스템을 설계하고 구축하는 데 시간을 투자하면 나중에 큰 성과를 거둘 수 있습니다. API를 통해 CLI에서 발행된 명령을 단계별로 재생성해야 하는 장치나 시스템과 통합하면 거의 확실히 잠금 상태가 될 것입니다. 이는 템플릿의 가장 큰 이점 중 하나로, 장치 및 시스템별 API에 대한 의존도를 줄이고 나중에 새 시스템이나 앱으로 쉽게 마이그레이션할 수 있는 몇 가지 명령에만 노출되도록 제한합니다.  인프라가 REST 기반 API를 지원하는지 확인하고, 가능하다면 템플릿을 사용하여 나중에 시스템 및 환경에서 쉽게 추출할 수 있도록 하세요.


물론 다른 우려 사항도 있지만, 주로 이 세 가지 주요 우려 사항은 기술 및 방법론 채택과 관련하여 데이터 센터 전체와 시간에 걸쳐 울려 퍼집니다. 시간이 걸리고, 방해가 될 수도 있고, 잠길 가능성이 매우 높습니다. 신중한 조사와 실행에 대한 신중한 접근 방식, 그리고 지금 투자하고 나중에 이익을 얻는 태도는 이런 우려를 완화하고 디지털 혁신을 가능하게 하고 가속화하는 견고하면서도 유연한 기반을 성공적으로 구축할 수 있는 더 나은 기회를 제공합니다.