DevOps 실무자가 앱별 아키텍처에 관심을 가져야 하는 이유는 무엇입니까?
그 질문에는 당신이 내린 결론이 내포되어 있습니다.
지난 수십 년 동안 우리는 대부분의 프로덕션 파이프라인을 구성하는 애플리케이션 서비스를 공유 플랫폼에 배포해 왔습니다. 로드 밸런싱, 애플리케이션 성능 서비스, WAF, 페더레이션 ID와 같은 애플리케이션 서비스는 종종 애플리케이션 전송 컨트롤러(ADC) 형태로 공유 인프라에서 NetOps에 의해 제공됩니다.
하지만 시간과 수요, 그리고 마이크로서비스와 같은 새로운 애플리케이션 아키텍처의 등장으로 인해 해당 파이프라인에 변화가 필요하게 되었습니다 . 이러한 변화는 NetOps와 DevOps 모두에 좋은 일입니다. 인프라를 코드로 구축하는 것과 같은 배포 일정 및 운영 관행에 더 긴밀하게 부합하는 모델로 전환되기 때문입니다.
공유 인프라에 굳건히 자리 잡은 일부 애플리케이션 서비스가 있습니다. DNS(디에스엔) 볼륨형 DDoS 공격에 대한 방어. 네트워크 방화벽. 이러한 서비스는 본질적으로 기업 서비스입니다. 즉, 기업을 보호하고, 방어하고, 지원하기 위해 설계되었습니다. 만약 이 서비스가 실패한다면? 회사 전체에 생산성이나 수익이 발생하지 않았습니다.
그러나 다른 애플리케이션 서비스는 애플리케이션과 매우 밀접하게 관련되어 있습니다. 해당 애플리케이션의 구성, API 및 서비스는 종종 단일 애플리케이션을 지원하도록 특별히 구성됩니다. 단일 아키텍처가 아니라 단일 애플리케이션입니다.
이러한 서비스에 대한 책임은 점점 더 애플리케이션 운영(DevOps)과 애플리케이션을 제공하는 개발자의 참여로 옮겨가고 있습니다. 공유 모델이 여전히 필요한 전송 및 보안 애플리케이션 서비스를 제공하는 데 효과적일 수 있지만(종종 그렇게 됨) 여러 가지 이유로 대부분 앱별 모델이 바람직합니다.
첫째, 앱별 모델은 배포 일정 충돌을 깔끔하게 해결합니다 . 기업 조직은 지원하는 애플리케이션 서비스의 구성 및 배포와 관련하여 공유 인프라 충돌로 인해 제약을 받는 경우가 많습니다. 공유 인프라는 공유 리소스를 의미하며, 이로 인해 구성 충돌 가능성이 항상 높아집니다. 그러한 가능성을 없앰으로써 보다 빈번한 배포나 예정에 없던 배포에 대한 저항을 완화할 수 있습니다. 결국, 어떤 애플리케이션 서비스가 내 애플리케이션에만 전담되어 있고, 자체 리소스로 자체 플랫폼에서 실행된다면 충돌은 깔끔하게 해결됩니다. 내 앱, 내 위험.
두 번째로, 앱별 모델은 인프라를 코드로 구현하는 방법론을 포함하여 새로운 자동화 노력을 지원합니다. 리소스와 플랫폼을 단일 애플리케이션에 할당함으로써 구성에는 해당 애플리케이션만 포함됩니다. 불변성을 강제할 수 있으며, 엔트로피의 위험을 피할 수 있습니다. 사실 저는 ( 최근에 그랬듯이 ) 앱별 아키텍처 없이는 변경 불가능한 인프라를 제대로 구축할 수 없다고 주장하고 싶습니다. 이 접근 방식은 애플리케이션 인프라를 넘어 "네트워크"로 확장되는 지속적인 배포 파이프라인에 포함되는 것을 가능하게 합니다. 이 기능을 제공한다는 것은 구성 및 지속적인 관리의 책임을 NetOps에서 DevOps로 전환하는 것을 의미합니다. 좋은 소식은 더 큰 책임과 함께 더 큰 통제력이 수반된다는 것입니다. DevOps가 애플리케이션 서비스의 "소유자"가 되어 자체 조건과 일정에 따라 업그레이드, 패치 및 재배포할 수 있는 권한이 부여되기 때문입니다.
마지막으로, 앱별 모델은 훨씬 더 휴대성이 뛰어납니다. 공유 플랫폼에 얽매이지 않고 배포 아티팩트(구성 및 템플릿)에만 거의 전적으로 의존하지 않기 때문에 대부분의 프로덕션 파이프라인을 클라우드에서 클라우드로, 온프레미스에서 오프프레미스로 훨씬 더 적은 마찰과 노력으로 마이그레이션할 수 있습니다. 이러한 자유 덕분에 조직은 마이그레이션과 관련된 비용에 구애받지 않고도 해당 애플리케이션에 가장 적합한 클라우드와 위치를 선택할 수 있습니다.
DevOps는 온프레미스와 퍼블릭 클라우드 모두에서 애플리케이션 서비스에 대한 앱별 아키텍처 채택을 장려함으로써 큰 이점을 얻을 수 있습니다. NetOps가 다른 운영 도메인에 대한 더 큰 제어력과 가시성을 제공해야 하는 압박을 받고 있는 지금이 피자와 맥주를 마시며 NetOps 담당자와 차세대 애플리케이션 중심 앱별 아키텍처를 지원하는 방향으로 전환하는 것에 대해 논의하기에 좋은 시기입니다.