가치 실현 시간 개선: 프로세스 및 병렬화

크리스마스에는 흔히 있는 한탄의 노래가 있습니다. 이 노래는 지붕 꼭대기와 소나무의 가시투성이 가지 아래에서 울려 퍼진다.

"한 개의 빛이 꺼지면, 다른 모든 빛도 꺼진다!"

이는 직렬 회로에 연결된 전구에 갇힌 사람의 외침입니다. 왜 이런 일이 일어나는지에 대한 장황한 설명은 하지 않겠지만, 단 하나의 전구가 타 버렸더라도 그것이 방해 요인이라는 것만은 말씀드리겠습니다.

이는 병렬 회로로 연결된 전구를 축복받은 사람들에게는 해당되지 않습니다. 전구 하나가 꺼져도 다른 전구들은 계속 밝게 타오를 수 있습니다.

이것은 시간과 가치와 응용을 어떻게 가질 수 있는가요? 모든 것. 결론적으로, 기존 IT는 직렬 회로로 생산을 진행하는 반면, 최신 앱 개발은 병렬 회로로 쉬지 않고 진행됩니다.

프로세스

최근 블로그에서 Pivotal Global Field의 CTO인 제임스 어콰트는 제품보다 프로세스에 적절하게 초점을 맞춘 지속적인 IT에 대한 중요한 그림을 제시했습니다. 그는 이를 생산으로의 길이라고 부른다.

생산 경로라는 개념은 실제로 프로세스에 대한 것이며, 기존 IT의 경우 병렬화에 대한 것입니다. 이 개념은 현대적 애플리케이션 개발과 아키텍처의 핵심입니다. 앱을 개별적이고 집중적인 구성 요소(때로는 마이크로서비스라고 함)로 분해하면 자연스럽게 병렬 개발이 이루어집니다. 이는 소규모 팀이 동시에 여러 구성 요소를 작업하기 때문입니다. 궁극적으로 이는 Agile을 애플리케이션의 속도를 높이고 가치 실현 시간을 단축하는 메커니즘으로 작동하게 하는 것입니다. 규모가 작은 팀은 아닙니다. 더 작은 앱은 아닙니다. 이러한 개념을 활용하여 애플리케이션을 개발하고 제공함으로써 병렬화가 달성됩니다.

생산 경로에도 동일한 접근 방식이 적용됩니다. 즉, 애플리케이션의 확장성과 보안을 구현하는 데 필요한 프로덕션 구성 요소(서비스)는 훨씬 더 큰 프로세스의 일부이며, 이 중 일부는 병렬로 개발 및 제공될 수 있습니다.

이를 방해하는 것은 전통적인 IT이다. 직렬 IT. 생산 풀로 확장된 폭포수 개발 방법론. 데이터는 네트워크를 통해 직렬로 흐르기 때문에 우리는 네트워크를 직렬 채널로 구축합니다. 라우터부터 방화벽, 로드 밸런싱, 앱 서버, 데이터베이스에 이르기까지. 데이터는 네트워크의 한쪽 끝에서 다른 쪽 끝으로 예측 가능한 경로를 따라 흐릅니다. 따라서 우리는 이러한 애플리케이션 서비스를 동일한 방식, 즉 자연스럽게 데이터 경로를 따르는 예측 가능하고 직렬화된 프로세스로 구현하고 제공합니다.

그건 더 이상 효과가 없을 거예요.

첫째, 이제 여러 개의 데이터 경로가 있기 때문입니다. NS와 EW를 통과하는 데이터 경로뿐만 아니라 다른 주요 방향으로 벗어나는 경로도 포함됩니다. 스크립트를 검색하려면 클라우드로 NE로 이동하세요. 스프라이트와 웹 글꼴을 검색하는 SW. WSE에서 지도를 가져와 앱에 삽입했습니다.

하지만 오늘날 생산 경로의 병렬화가 필요한 것은 데이터 경로를 분산시키는 것만이 아닙니다. 이는 효율성과 속도, 즉 최적화를 추구하는 것입니다.

병렬화

오늘날의 가치 기대에 부응하는 실행 속도를 높이기 위해서는 병행 개발이 필요합니다. 앱 개발뿐만 아니라 핵심 IT에도 그렇습니다. 오늘날 기업에서 사용하는 광범위한 애플리케이션 서비스를 살펴보면 병렬화가 배포 속도를 높이는 데 도움이 되는 여러 영역을 알 수 있습니다.

기존 IT가 고립되어 있다는 문제가 아닙니다. 결국, 마이크로서비스 아키텍처의 결과는 수십 또는 수백 개의 작은 사일로화된 팀이며, 각각은 매우 구체적인 애플리케이션 기능 세트에 집중합니다. 기존 IT는 이미 사일로 내에 또 다른 사일로입니다. 문제는 Agile 개발 관행이 자체적인 병렬 개발을 장려하는 반면, 기존 IT는 여전히 체계적이고 직렬화된 방식으로 프로덕션 프로세스를 관리하고 있다는 것입니다.

문제는 팀 간의 핸드오프이며, 프로덕션 경로에서 네트워크 트래픽을 미러링하는 방식에 있습니다. 이는 직렬적인 프로세스가 아니며, 가능한 경우 서비스 개발 및 제공을 병렬화해야 합니다.

즉, 조만간 협업을 장려하는 기능 간 팀 구조가 필요하다는 뜻입니다.

모든 부문에 걸쳐 보다 Agile한 관행을 도입하여 프로세스를 병렬화함으로써, 조직은 생산 과정에서 더 빠른 속도와 효율성을 달성할 수 있습니다.

프로세스는 제품입니다

제임스가 암시했듯이, 생산으로 가는 길은 실제로 하나의 과정입니다. 그리고 과정은 여러 단계로 구성됩니다. 검은띠를 딴 6시그마 프로세스 닌자라면 누구나 말하겠지만, 프로세스 속도를 높이는 것은 비효율성을 찾아 없애는 것입니다. 실제 운영 환경에서는 이러한 비효율성이 배포 프로세스에서 엄격하고 직렬화된 단계 사이의 대기 시간(핸드오프)으로 나타납니다.

도구가 도움이 될 수 있습니다. 하지만 궁극적으로 개선을 위해서는 프로세스를 면밀히 검토하고, 프로덕션 경로의 일부로 애플리케이션 서비스 제공을 병렬화할 수 있는 기회를 모색해야 합니다.

문화, 특히 협력 문화는 선택 사항이 아닙니다. 그것은 행동과 관행에 매우 실제적인 영향을 미칩니다. 팀 구조만으로도 파이프라인 자동화가 극적으로 변하며, 기존의 단일 기능 팀은 현대적이고 DevOps 중심의 팀보다 뒤처지게 됩니다. 더욱 협력적인 팀 구조를 추진하세요. 같은 맥락에서, 협력적인 팀은 주요 지표에 대해 일치된 의견을 가져야 합니다. 공유된 메트릭을 통해 NetOps와 보안 팀은 페널티 없이 지속적인 배포를 추진할 수 있습니다. 현재 NetOps의 약 4분의 3이 네트워크 가동 시간을 기준으로 측정됩니다. 배치 빈도는 그들에게 거의 영향을 미치지 않습니다. 그들은 네트워크 유지에 집중할 것입니다. 왜냐하면 그게 그들이 집중해야 할 일이기 때문입니다. 공유된 메트릭을 통해 NetOps는 비즈니스에 필요한 것, 즉 더 빠르고 빈번한 배포에 집중할 수 있습니다. 

마지막으로 공감이 필요합니다. 여러분은 모두 같은 팀이고 - 놀라실지도 모르지만 - 똑같은 것을 소중히 여깁니다. NetOps는 DevOps만큼 파이프라인 자동화에 높은 중요성을 둘 가능성이 높습니다. DevOps는 통합, 도구, 기술 세트와 관련된 장애물을 탐색하고 극복하는 측면에서 NetOps보다 10년 앞서 있다는 점을 기억하세요. 협업 팀은 배포부터 배포에 이르는 모든 도구(예: Jenkins 및 GitHub/GitLab)에 대한 표준화를 촉진함으로써 도움을 줄 수 있습니다.

생산으로 가는 길은 제품이 아니다. 그것은 과정이에요. 그리고 이는 가치 실현 시간을 개선하고 성공적인 애플리케이션 배포를 가능하게 하기 위해 가능한 한 협력적이고 병렬적으로 제공되어야 하는 프로세스입니다.