애플리케이션 서비스에 대한 앱별 접근 방식이 중요한 이유
저는 남의 마음을 읽을 수는 없습니다(제 아이들은 동의하지 않겠지만 그건 중요하지 않습니다). 하지만 애플리케이션 제공 현황 설문조사에 대한 응답은 읽을 수 있습니다. 그리고 앱 개발자라고 스스로 밝히는 사람의 관점에서 이 글을 읽으면 매우 흥미로운 그림이 떠오르는 걸 봅니다.
개발자들은 속도를 중시합니다. 그리고 보안. 그리고 규모. 반드시 그 순서대로는 아니지만 그들은 세 가지 모두에 관심을 갖습니다. 그들은 관심을 가질 뿐만 아니라, 세 가지 모두를 달성하는 데 도움이 되는 애플리케이션 서비스의 가치를 인식합니다.
즉, 개발자는 모호한 '가속' 애플리케이션 서비스만 원하는 것이 아니라 TCP 최적화 및 캐싱을 제공하는 구체적인 서비스를 원합니다. 그들은 웹 애플리케이션 방화벽 과 부하 분산 기능이 필요하다고 말합니다.
문제는 이러한 애플리케이션 서비스의 대부분이 공유 인프라 모델로 제공된다는 것입니다. 각 애플리케이션은 자체적인 "가상 표현"을 갖지만 물리적으로는 공유 소프트웨어나 하드웨어에 상주합니다.
이는 실제로 문제를 일으킬 수 있으며 IT와 앱 개발 간에 갈등이 발생하는 원인이기도 합니다. 시스템의 이러한 공유적 특성으로 인해 변경 창과 검토 게시판, 토요일 밤 배포(피자로 우리를 달래며)가 생겨났습니다. 이러한 프로세스는 개발을 늦추고 배포를 모든 참여자에게 좌절스러운 경험으로 만듭니다.
우리는 더 이상 거대한 앱을 배포하지 않습니다. 우리가 아직 마이크로서비스를 열광적으로 구축하지 않고 앱을 수백 개의 작은 서비스로 분해하지 않았더라도, 더 빈번하게 배포 일정을 정하는 앱이 여전히 많이 있습니다. 1년 단위 프로젝트가 아닌 1주일 단위 스프린트로 개발되는 앱이며, 더 빠르고 더 자주 업데이트를 적용해야 합니다.
결국 그것이 (퍼블릭) 클라우드가 그토록 성공할 수 있었던 이유입니다. 이건 내 앱이고 내 인프라이기 때문에 업데이트를 푸시하기 전에 Bob이나 Alice, John이 올 때까지 기다릴 필요가 없습니다. 그것은 모두 내 것이기 때문에, 잘못되면 모두 내 책임입니다.
동일한 접근 방식이 사내에서도 가능하며, 더 바람직하다고 생각합니다. 필요한 것은 애플리케이션의 전달 체인을 구성하는 모든 부분과 부품이 클라우드가 바람직하게 만든 동일한 종류의 앱별 접근 방식을 지원하는 것입니다.
기본적으로 네트워크와 필요한 애플리케이션 서비스를 제공하기 위한 앱별 접근 방식은 애플리케이션에 전용 서브넷을 두는 것과 비슷합니다. 앱 제공 VLAN이라고 할 수 있죠. 모든 것은 전담 서비스를 갖춘 하나의 앱에 달려 있습니다.
그런 종류의 고립은 배포 일정에만 좋은 것이 아니라 다른 모든 사람에게도 좋습니다. 실패는 발생할 수 있으며, 실패가 발생하면 폭발 반경을 최대한 제한하고 싶을 것입니다. 앱별 아키텍처는 엄격하게 제한된 장애 영향을 의미하므로 "그냥 만약을 대비해" 대기 중인 모든 사람들이 전화를 받지 못해도 행복해집니다. 한 달에 한 번씩 출시 및 배포되는 앱과 충돌하지 않고 매주 출시하고 배포할 수 있습니다. 내 앱, 내 서비스, 내 배포 일정.
앱별 아키텍처를 사용하면 프로덕션 과정에서 발생하는 문제를 쉽게 해결할 수 있습니다. 그리고 종종 그렇게 하죠. 실제로 2017년 Atlassian 설문 조사 에 따르면 개발자의 50%가 코드를 출시한 후 프로덕션에서 문제가 발생했다고 보고했습니다. 다른 사람이 애플리케이션에 영향을 미칠 수 있는 변경을 했을 가능성은 없습니다. 귀중한 시간을 허비하여 어떤 시스템이 관련되어 있는지 파악하는 대신, 관련 시스템을 바로 파악할 수 있습니다.
앱별 아키텍처는 퍼블릭이든 프라이빗이든 클라우드에 더 잘 맞습니다. 이는 모델에서 가정한 사항입니다. 각 앱에는 확장성, 속도 향상, 보안을 위한 전용 애플리케이션 서비스 세트가 있습니다.
현실적으로 앱별 아키텍처는 불가피했습니다. 제가 이런 말을 한 것은 처음이 아닙니다 . 애플리케이션의 중요성은 무시할 수 없을 만큼 강하며, 애플리케이션을 안전하게 유지하는 데 필요한 애플리케이션별 보안이 점차 커지면서 조만간 앱별 접근 방식이 등장하게 되었습니다.
이는 좋은 일입니다. 개발자가 원하는 애플리케이션 서비스는 대개 애플리케이션에 특화되어 있기 때문입니다. 한 사람에게 효과가 있는 것이 반드시 다른 사람에게도 효과가 있는 것은 아니며, 오히려 부정적인 결과를 초래할 수도 있습니다. 앱별 아키텍처 접근 방식을 애플리케이션 제공에 적용하면 개발자가 앱을 확장하고 보안을 강화하고 속도를 높이는 데 필요한 것을 얻을 수 있을 뿐만 아니라 온프레미스든 오프프레미스든 클라우드에서 기대하는 셀프 서비스 모델을 보다 잘 지원할 수 있습니다.