기업들이 비즈니스 기능의 지속적인 개발, 제공 및 통합을 위해 DevOps를 도입함에 따라, 세심한 관리가 필수적입니다.
기업들은 정해진 기간 동안 코드를 개발하고 운영 시스템 관리 및 애플리케이션 관리를 결합하는 기존의 폭포식 및 계단식 소프트웨어 개발 방식에서 보다 애자일한 접근 방식으로 전환하고 있습니다.
지속적인 통합, 지속적인 개발 및 지속적인 제공을 통해 신속한 기능 프로비저닝에 대한 요구가 증가함에 따라 많은 기업들이 DevOps 프로세스를 도입하려고 합니다.
DevOps는 개발, 테스트 및 운영 팀을 통합하여 코드와 기능 애플리케이션의 세 영역 간 이동을 간소화하는 것을 목표로 합니다.
그러나 모든 것이 원활하게 실행되고 비즈니스에 최대한의 긍정적인 결과를 가져오면서 부정적인 영향을 최소화하려면, 적절한 피드백 루프를 갖춘 높은 수준의 관리가 필요합니다.
개발자 주도의 전환
기업들이 직면한 문제는 DevOps가 급속도로 성장하고 있으며, 이러한 성장이 상향식 관리가 아닌 하향식 관리 방식으로 이루어지고 있다는 점입니다.
많은 DevOps 도구가 오픈 소스 소프트웨어로 제공되므로, 조직 내 개인이 원하는 도구를 다운로드하여 사용하는 데 아무런 제약이 없습니다.
개발 또는 운영 부서의 많은 직원에게 이는 놓칠 수 없는 좋은 기회입니다. 개발자들은 IBM Rational Software Architect나 Microsoft Visual Studio와 같은 상용 시스템이든, Eclipse와 같은 오픈 소스 시스템이든, 기존 통합 개발 환경(IDE)에 통합할 수 있는 하위 시스템을 찾고 있었습니다.https://www.eclipse.org/downloads/)** 또는 Anjuta, 또는 Atlassian Jira Software나 CA PPM과 같은 소프트웨어 프로젝트 관리 소프트웨어.
이로 인해 [Jenkins와 같은 도구]( 사용이 증가했습니다.https://searchitoperations.techtarget.com/tip/Secure-Jenkins-for-fast-and-safe-app-delivery개발자와 운영 담당자 모두 Chef와 Puppet을 사용합니다. Jenkins는 소프트웨어 버전 관리를 자동화하는 일련의 프로세스를 제공하며, Perforce, CVS, Subversion, Git, Accurev와 같은 기존 버전 관리 도구를 지원하는 플러그인을 제공하고 지속적 배포를 위한 간소화된 프로세스를 지원합니다. Chef와 Puppet은 DevOps의 “운영” 측면에 더 초점을 맞춰 구성 관리 원칙을 사용하여 기능 패키지를 생성하고 이를 운영 환경에 자동으로 프로비저닝하는 방식으로 시작했습니다.
확장되는 옵션
이러한 도구들은 2005년(Puppet), 2009년(Chef), 그리고 2011년(Jenkins, Sun Microsystems가 2004년에 시작하고 현재 Oracle이 소유한 Hudson 프로젝트의 후속 작업)에 처음 출시된 이후로 기능이 크게 향상되었습니다.
이러한 도구들의 기능은 불과 몇 년 전과 비교해도 훨씬 더 많이 겹치게 되었고, 완벽한 DevOps 환경을 구축하기 위해 다른 개별 도구를 추가로 도입해야 할 필요성이 예전보다 줄어들었습니다.
팀워크와 완전한 피드백 루프에 대한 지원이 강화되면서, 개인 사용자를 위한 개별 도구로 시작했던 것들이 이제는 그룹 전체를 지원하는 도구로 발전했습니다. 심지어 분산된 사이트나 여러 회사에 걸쳐 협업하는 계약직 및 컨설턴트 그룹까지도 지원할 수 있게 되었습니다.
이 세 가지 거대 도구 외에도 Ansible, Salt와 같이 다양한 오픈 소스 라이선스 하에 동일한 분야에 적합한 도구들이 있으며, Docker와 Kubernetes 같은 컨테이너 소프트웨어 관리 시스템에 내장된 도구들도 있습니다. Ubuntu에 통합되고 기업에서 지원하는 환경을 원한다면 Canonical에서 JuJu를 통해 Kubernetes를 배포할 수도 있습니다.https://www.computerweekly.com/blog/Open-Source-Insider/AppScale-FastStart-for-Google-Compute-Engine-AWSKubernetes는 DevOps 환경에서 활용 가능한 컨테이너 오케스트레이션 분야의 새로운 강자로 빠르게 자리매김하고 있습니다. AWS, Google, Microsoft, IBM, Intel, Twitter 등을 회원사로 두고 있는 클라우드 네이티브 컴퓨팅 재단(CNCF)에서 Kubernetes를 지원하고 있습니다.
Cloud Foundry는 또 다른 오픈 소스 시스템으로, 앞서 언급한 대부분의 오픈 소스 도구처럼 상용 지원 시스템으로도 제공됩니다. Cloud Foundry는 DevOps에 적합한 자동화 기능을 제공하며, 상위 및 하위 시스템에 대한 높은 수준의 지원을 제공합니다. Cloud Foundry 역시 CNCF 회원사이지만, Kubernetes와 일부 기능이 겹치면서도 컨테이너 환경을 넘어 훨씬 더 광범위한 영역을 포괄합니다. Cloud Foundry 내의 KuBo(Kubernetes on BOSH)라는 별도 프로젝트는 이기종 애플리케이션 코드, 가상 머신(VM) 또는 컨테이너 환경에서 작업하는 사용자를 위해 통합 Cloud Foundry/Kubernetes 스택을 제공합니다.
너무 많은 도구
개별 개발자와 시스템 관리자가 각자 다른 방식으로 개발하여 IT 환경 전반에 걸쳐 다양한 도구가 혼용되는 상황은 조직에 큰 문제를 야기할 수 있습니다. 이러한 문제를 해결하는 방법은 크게 두 가지입니다.
첫째, 명확한 지침을 제시하는 것입니다. 사용할 도구 세트를 하나로 정하고 모든 개발자와 시스템 관리자가 동일한 도구 세트를 사용하도록 강제하는 것입니다. 하지만 안타깝게도 이 방법은 실패할 가능성이 매우 높습니다. 개발자와 시스템 관리자의 상황을 고려해 보세요. 그들의 책상 서랍을 열어보면 승인되지 않은 소프트웨어가 담긴 CD나 USB 드라이브가 얼마나 많이 있는지 알 수 있을 것입니다. 그들은 하나의 도구만 사용해야 한다는 당신의 의견에 동의하는 것처럼 보일지 모르지만, 당신이 더 이상 지켜보지 않을 때는 얼마든지 자기 방식대로 개발이나 관리하지 않을 가능성이 큽니다.
이러한 상황에서 조직은 모든 사람에게 지시를 내렸으니 당연히 그렇게 해야 한다는 착각에 빠지게 됩니다. 그러다 문제가 발생하면, 사후 분석을 통해 문제가 드러납니다. 바로 통합된 관리 체계 없이 기능들이 파편화되어 있다는 점입니다.
둘째, 현실적으로 접근해야 합니다. 이미 벌어진 일을 되돌릴 수는 없으며, 개별적으로 사용되는 여러 도구들을 기업 환경에 맞게 통합하는 방법을 찾는 것은 쉽지 않습니다.
많은 오픈 소스 도구들은 플러그인이나 오픈 소스 애플리케이션 프로그래밍 인터페이스(API)를 활용하여 다른 오픈 소스 도구와의 연동을 상당히 높은 수준으로 지원합니다.
더 높은 수준의 제어와 기업 수준의 지원이 필요한 경우에는, CloudBees처럼 Jenkins 및 관련 구성 요소를 지원하는 오픈 소스 소프트웨어 배포판을 구독하는 것이 기업에 필요한 “엔터프라이즈급” 기능을 제공할 수 있습니다.
오픈 시스템은 장기적인 지속 가능성을 제공합니다
더 나아가, 기존 도구를 지원하기 위해 높은 수준의 개방성을 제공하는 상용 시스템도 있습니다. 예를 들어 CA Automic은 DevOps 프로세스 간소화를 위한 훌륭한 자동화 솔루션을 제공하며, 다양한 기본 도구를 개방적인 방식으로 지원합니다.
이러한 시스템에서 다양한 기본 도구를 자유롭게 교체할 수 있다는 점은 핵심적인 장점입니다. 5년 전만 해도 **[Chef와 Puppet](https://searchitoperations.techtarget.com/tip/How-the-Puppet-architecture-manipulates-configurations쿠버네티스는 불과 3년 전에 출시되었는데, 앞으로 5년 후 시장은 어떻게 변할까요? 만약 포괄적인 통합 시스템이 특정 도구에 고정된 폐쇄형 시스템이라면, 뒤처질 수 있습니다. 반대로 개방형 시스템으로 플러그인/플러그인 기능을 지원한다면, 새로운 도구가 등장할 때마다 쉽게 도입할 수 있습니다.
데브옵스 분야에서 활동하는 기업은 많습니다. 예를 들어, HashiCorp는 Terraform과 Vagrant를 비롯한 다양한 도구를 제공하여 데브옵스 환경 운영을 간소화합니다. Perforce는 버전 관리라는 주력 분야에서 벗어나 광범위한 데브옵스 기능을 제공하는 Helix 포트폴리오를 출시했습니다.
기존 시스템 관리 구성 관리 소프트웨어의 진화하는 분야에서는 BMC의 BladeLogic 자동화 제품군이 있습니다. 클라우드 컴퓨팅과 컨테이너를 지원하도록 현대화된 BladeLogic Server Automation은 특히 Atrium Orchestrator, Control-M Automation, TrueSight 포트폴리오와 같은 다른 BMC 제품과 함께 사용할 경우, 데브옵스 기능을 제공할 수 있습니다.
HPE의 구성 가능한 인프라는 하드웨어와 소프트웨어의 격차를 해소하여 OneView를 통해 논리적 플랫폼을 쉽게 구성하고 물리적, 가상화 또는 컨테이너화된 소프트웨어를 프로비저닝할 수 있도록 지원합니다.
물론 클라우드 기반 DevOps 옵션도 있습니다. IBM은 BlueMix 플랫폼을 통해 다양한 기능을 제공합니다. AWS, Google, Microsoft는 자사 플랫폼에서 직접 툴링을 제공하며, 앞서 언급한 많은 툴들은 클라우드 플랫폼에서 셀프 서비스 모드로 구현할 수 있습니다.
DevOps는 비즈니스 요구 사항을 충족하는 주요 수단으로 자리 잡고 있습니다. 즉, 필요에 따라 신속하게 제공될 수 있는 새로운 기능의 지속적인 개발을 가능하게 합니다. 여기서 중요한 점은 “비즈니스 DevOps(BusDevOps)“라고 부르는 것이 더 적절하다는 것입니다. 비즈니스 요구 사항은 개발자가 아닌 비즈니스에 의해 결정되어야 합니다.
이러한 비즈니스 DevOps 환경을 최대한 활용하려면 엄격한 툴링이 필요하며, 이는 일방적인 규칙이나 지시를 통해서는 이루어지지 않을 가능성이 높습니다. 실용적인 접근 방식을 취하세요. 기존의 혼란에 질서를 부여할 수 있는 포괄적인 시스템을 제공하고, 개발자와 시스템 관리자가 자신에게 맞는 방식으로 작업할 수 있도록 지원해야 합니다.
