컨테이너를 사용하는 개발자에게 인프라가 중요한 이유

오늘날 인프라 제공업체에서 가장 자주 듣는 질문 중 하나는 개발자 커뮤니티에 해당 인프라의 가치를 설명하는 방법입니다. 문제는 인프라의 이점 대부분이 생산에 적용된 후에 얻어진다는 것입니다. 이 중 어느 것도 개발자에게 직접적으로 가치를 제공하지 못합니다. 적어도 일상 생활에 영향을 줄 만큼 의미 있는 방식으로는 말이죠.

개발자라면 누구나 알고 있는 추가 개발의 이점이 있습니다. 2018년 애플리케이션 제공 현황 에서는 소수의 개발자가 참여했습니다. 하지만 그 비율은 그들이 배포하고자 하는 애플리케이션 서비스에 대한 주제에 대해 큰 의미를 갖습니다. 부하 분산, 캐싱, 가속과 같은 일부 애플리케이션 서비스는 인프라로서가 아니라 애플리케이션 자체의 일부로 배포되는 경우가 많습니다. TCP 최적화와 WAF는 거의 항상 인프라 서비스이며, 애플리케이션(모놀리스 또는 마이크로서비스)보다 앞선 데이터 경로에 구축됩니다.

이런 모든 응용 서비스에는 가치가 있습니다. 위험 감소, 성능 향상, 확장성. 하지만 이는 애플리케이션과 비즈니스 측면에서의 이점이며, 개발자에게는 애플리케이션을 프로덕션에 제공한 이후에 이점이 됩니다. 인프라가 사전에 제공되거나 개발 라이프사이클의 일부로 제공되는 경우의 이점을 찾는 것은 물론이고 구체적으로 설명하는 것도 어렵습니다.

하지만 컨테이너와 마이크로서비스를 계속해서 도입할수록 제공 전후 인프라의 가치가 더욱 분명해집니다.

대부분의 새로운 기술과 마찬가지로, 새로운 애플리케이션 아키텍처의 초기에는 인프라가 거의 제공되지 않습니다. 개발자들이 애플리케이션 아키텍처가 애플리케이션 서비스 인프라에 상당한 영향을 미친다는 사실을 알면 놀랄 수도 있습니다. 3계층으로 전환하면서 웹 기반 앱은 확장성(부하 분산)을 갖추게 되었습니다. 반응형 프레젠테이션 계층을 갖춘 Web 2.0을 도입하면서 프런트엔드 가속 인프라가 탄생했습니다. 모바일이 등장하고 모든 산업이 디지털화되면서 인프라가 WAF, DDoS, 봇 방어와 같은 보안 서비스에 반응하는 것을 보았습니다.

따라서 현재 우리가 보고 있는 일은 개발자들이 애플리케이션에 인프라 서비스 기능을 코딩하는 것입니다. 개발자들은 전통적으로 업스트림 서비스의 책임이었던 것을 코드로 옮기고 있습니다. 로드 밸런서에서 재시도. 플랫폼이나 프록시에서 mTLS. 합법적인 클라이언트에게만 통신을 제한하기 위한 액세스 제어.

컨테이너 프레임워크의 초기 특성과 빠른 도입률로 인해 개발자가 인프라 책임을 맡게 되었습니다.

하지만 항상 그래왔듯이, 이제는 바뀌고 있습니다. 이전 앱 아키텍처가 네트워크 인프라에서 반응을 이끌어냈던 것처럼 컨테이너와 마이크로서비스도 마찬가지입니다. 하지만 이번에는 새로운 상자 형태로 변화가 나타나지 않습니다. 지금은 개발자에게 필요한 애플리케이션 서비스를 컨테이너 환경 에 통합하려는 움직임이 일어나고 있습니다. 바로 여기서 서비스 메시가 등장하여 개발자에게 실질적이고 정량화된 가치를 직접 제공합니다.

Linux.com과의 인터뷰 에서 Aspen Mesh 의 수석 아키텍트인 Andrew Jenkins가 설명한 바와 같습니다.

사전 제공의 가치는 컨테이너 환경 내에서 기본적인 보안과 확장을 처리하는 데 필요한 반복적이지만 필요한 코드를 제거하고 범위를 줄이는 데 있습니다. 서비스 메시는 다양하고 멋진 기능을 갖추고 있지만, 그 이점은 주로 운영상의 이점, 즉 관찰 가능성, 책임성, 확장성에 있습니다. 개발자에게 가장 큰 가치는 코드를 없애는 것(따라서 기술 및 아키텍처 부채를 줄이는 것)입니다.

컨테이너 환경에 배포된 앱을 확장, 보호하고 관찰하기 위해 서비스 메시를 사용하면 인프라에서 처리해야 하는 코드 작성 부담이 덜어집니다. 하지만 최근까지는 개발자에게 위임되었습니다. 서비스 메시는 개발자의 책임을 덜어주고, 개발자가 비즈니스에 가치를 제공하는 서비스와 앱을 개발하는 데 사용할 수 있는 귀중한 시간을 돌려주는 한 가지 방법입니다.