IT 리더는 DevOps에 참여하고 이를 수용해야 합니다.

IT 실무자들은 실무에 직접 참여하는 편입니다. 문화적 변화로서의 DevOps는 앱을 프로덕션에 배포하고 가용성, 보안, 성능을 유지하는 업무를 담당한 사람들에게는 실질적으로 실현 가능하지 않은 경우가 많습니다. 하지만 현실은 문화적 변화, 즉 집단 간 및 집단 내 고립의 붕괴가 일어나야 하며 , 늦기보다는 일찍 일어나야 한다는 것입니다. 

이는 특히 새로운 트렌드와 아키텍처가 네트워크에 미치는 영향과 관련하여 그렇습니다.

네트워크 중심 리더와 실무자 중 다수는 변화하는 앱 아키텍처 환경에 그다지 주의를 기울이지 않습니다. 예를 들어 API와 마이크로서비스로의 전환은 우리의 인프라에도 API가 있다는 사실 외에는 네트워킹 분야에서 거의 논의되지 않는 주제입니다. SDN(또는 SDDC) 때문입니다.

하지만 그들은 이러한 변화를 인식하고 이것이 네트워크와 까다로운 소비자 및 동료에게 해당 애플리케이션을 제공하는 데 어떤 영향을 미칠지(영향을 미칠지 여부가 아니라 미칠지) 알아야 합니다. 완전히 애플리케이션 아키텍처에 대한 결정인 것처럼 보이는 것도 네트워크 아키텍처뿐만 아니라 네트워크 성능과 요구 사항에 상당한 영향을 미칠 수 있습니다. 예를 들어, 멀티 테넌트 또는 단일 테넌트 마이크로서비스를 선택할지에 대한 결정은 보안부터 기본 라우팅 및 스위칭까지 네트워크 서비스에 상당한 영향을 미칩니다. 마이크로서비스와 함께 HTTP/2 또는 HTTP/1을 사용하는 것과 관련된 아키텍처 결정을 인식하지 못하면 네트워크에 심각한 문제가 발생하고 성능이 저하될 수 있습니다.

개발자들은 도메인 내부 및 외부에서 아키텍처가 미치는 영향에 대한 인식이 점점 높아지고 있습니다. 서비스 지연(두 서비스가 네트워크를 통해 통신하는 데 걸리는 시간)은 고도로 분산된 애플리케이션 아키텍처에서 잘 알려진 문제입니다. 개발자들이 알지 못하는 점은 네트워크(및 서비스 스택)가 이러한 환경의 성능(및 복원력)에 미치는 부정적인 영향을 완화하는 데 어떻게 도움이 될 수 있는가입니다. 

그것이 바로 네트워커들이 아는 것입니다.

문제는 110억 개의 마이크로서비스가 프로덕션에 투입되기 전까지는 네트워크 담당자가 관여하지 않는다는 것입니다. 그들은 상의하지 않았으며, 참여하는 시점에 제안을 한다는 것은 잠재적으로 서비스나 애플리케이션에서 상당한 재작업을 의미한다. 앱 내부가 아닌 네트워크에 확장성을 삽입하는 간단한 변경조차 악몽이 됩니다. 하지만 네트워크 확장성을 염두에 두고 서비스가 설계되었다면 원활하게 작동할 것입니다.

하지만 그렇지 않았고, 10명 중 9명의 임원은 앱을 더 빨리 출시해야 한다는 압박을 느꼈습니다 . 그렇게 많은 상호 연결되고, 관련되고, 상호 의존적인 서비스를 제공하기 위해 네트워크에 필요한 종류의 변경을 하려면 시간이 걸리기 때문에 그들은 더 큰 압박을 느끼고 있습니다.

IT에는 인프라, 네트워크, 스토리지, 보안이라는 4가지 작업이 있습니다. 그리고 4개의 사일로(혹은 중세적 은유를 선호한다면 타워)는 모두 서로 간의 교량을 구축해야 하며, 이를 통해 개발 주기 초기에 협업과 소통을 촉진해야 합니다. 아키텍처 선택에 대한 협업은 배포가 아닌 설계 중에 이루어져야 합니다 . 그리고 그러한 협업은 새로운 기술과 아키텍처가 고려되는 시점을 알 수 있는 각 조직에 대한 가시성을 갖춘 리더 에 의해 시작되어야 할 수도 있습니다.

DevOps는 단순히 자동화에 관한 것이 아닙니다. DevOps는 목표를 달성하기 위한 도구이자 기술입니다. 자동화는 앱을 배포하고 제공하는 데 필요한 서비스를 배포하는 담당자의 부담을 줄이는 데 큰 역할을 할 수 있으며, 이를 통해 4가지 운영 도메인 전반에 걸쳐 전문가를 확보할 수 있습니다. 조직 간의 보다 광범위한 협업(공유)에 참여할 수 있는 자유를 제공하여 앱 경제의 성장에 핵심이 되는 애플리케이션의 규모, 성능 및 보안을 개선합니다.

기업의 성공과 성장은 현장뿐 아니라 리더십 테이블에서의 IT 전반의 협업에 달려 있습니다.