DevOps와 NetOps 간의 격차 해소

아직 눈치채지 못하셨다면, 우리는 "분열을 메우는 것..."과 같은 시리즈를 쓰고 있습니다.

이건 팀 간의 격차를 메우는 것에 관한 것인데, 처음에는 함정인 것 같았습니다.

저는 DevOps 팀과 NetOps 팀을 개인적인 차원에서 거의 대립시키는 기사를 너무 많이 봤습니다. 그것은 도움이 되지 않습니다. 그것은 사람이나 팀에 대한 것이 아니라 그들을 형성한 제약과 기대에 대한 것이기 때문입니다. 이러한 팀에 속한 사람들은 대부분 직장에서 똑같은 일, 즉 멋진 일을 즐깁니다. 우리 모두는 자랑스러워할 수 있는, 유용한, 멋진 것을 만들고 싶어합니다.

팀 간의 차이점과 우리의 근무일 형태를 결정하는 요소는 우리가 하는 일의 경계와 영향, 그리고 우리가 사용할 수 있는 도구입니다. DevOps 팀은 일반적으로 애플리케이션이나 서비스 모음을 해결합니다. NetOps 팀은 하나의 기업을 위한 솔루션을 제공하며, 클라우드 NetOps 팀의 경우 수백 개의 기업을 위한 솔루션을 제공합니다(네, 실제로 존재합니다). 대부분의 네트워크 팀은 적어도 한 발은 물리적 세계에 참여하고 있습니다. 왜냐하면 무언가가 실제로 광자와 전자를 한 장소에서 다른 장소로 밀어내야 하기 때문입니다. 대부분의 DevOps 팀은 가상 세계의 허황된 세계에서 일하며, 리소스를 거의 즉각적으로 생성하고 파괴할 수 있는 힘을 누립니다. 개발 및 DevOps 팀은 기본 아키텍처의 핵심에서 코드와 비즈니스 로직을 기꺼이(그리고 당연히도) 추상화하는데, 이는 누군가가 API 호출이 올바른 위치에 도착하고 올바른 위치에서 전송되도록 보장하고 있다는 암묵적인 신뢰 하에 수행됩니다. 모든 사람은 빠르게 움직이고 싶어하고, 모든 사람이 물건이 망가지지 않고, 망가져도 쉽게 진단하고 고칠 수 있기를 원합니다. 그들이 사는 우주는 내부에서 보면 조금 달라 보일 수도 있습니다.

문제는 이 두 현실의 경계에서 시작될 수 있습니다. 많은 조직에서 서로 다른 팀의 업무 관행과 SLA 요구 사항 사이에 격차가 있는 것은 분명합니다. 이러한 마찰은 새로운 것으로 여겨질 수 있지만, 이는 10년 이상 동안 관찰되어 온 상황입니다. F5 기술은 항상 애플리케이션 중심 팀과 인프라 중심 팀을 상호 연결해 왔기 때문입니다. 백엔드 서버 수나 애플리케이션 동작의 변경이든, 애플리케이션 아키텍처의 변경 사항은 보안 검사, 콘텐츠 라우팅 또는 부하 분산이 발생하는 애플리케이션 전송 계층에 항상 반영되어야 합니다. 이제 개발자들이 작업 흐름을 보다 반복적으로 구성함에 따라 이러한 변화가 점점 더 빨리 일어나고 있으며, 그에 따라 증상도 더욱 두드러지고 있습니다.

그래서 지금은 매우 흥미로운 시기입니다. 이처럼 격차를 메울 수 있는 기회는 전에 한 번도 없었습니다. F5에서는 매우 견고한 엔터프라이즈급 기술을 보다 민첩하고 자동화된 워크플로에 연결할 수 있는 도구를 점점 더 많이 개발해 왔습니다. 우리는 원하는 사람이라면 누구에게나 새로운 작업 방식에 대한 교육을 제공해 왔습니다. 그리고 우리는 회사 내부에서 일하는 방식을 바꾸어 왔습니다.

하지만 분열을 극복하는 가장 좋은 방법은 이해와 공유된 경험을 통해 구축하는 것입니다. 협력이라는 기반 없이는 다리를 지탱할 도구와 프로세스가 유지될 수 없습니다. NGINX와 더 많이 협력하면서 제가 가장 기대하는 바가 바로 이것입니다. 격차를 뛰어넘어 그들의 입장에서, 그리고 더 중요하게는 프로세스 격차의 고객 입장에서 어떤 모습인지 확인할 수 있는 기회입니다. 서로 협력하면 안전하고 빠르며 혁신적인 애플리케이션을 제공하는 모든 팀 간에 점점 더 나은 이해를 구축할 수 있도록 공동의 고객을 지원할 수 있습니다. 물론, 거기에는 기술이 들어갈 겁니다. 결국, 그것은 우리가 만드는 것이니까요. 하지만 이는 더 광범위한 사용 사례를 포괄하고 DevOps와 NetOps를 중심으로 한 보다 완전한 비전을 통해 우리가 가장 중점을 두는 그룹, 즉 고객과 사용자의 요구를 충족할 것입니다.