우리 세 사람은 2009년 Microsoft Azure 클라우드 플랫폼이 시장에 처음 등장한 이후로 여기서 작업해왔다. 이 플랫폼을 사용한 공동 작업은 플랫폼을 만들고 플랫폼에서 애플리케이션을 만드는 것부터 Azure 개발 도구를 만들고 경험하는 것까지 꽤 광범위했다. 게다가 많은 고객과 파트너들이 Microsoft Azure에서 대규모 클라우드 기반 애플리케이션을 만들 수 있도록 지원했다. 지난 몇 년 동안 복원력과 확장성 있는 애플리케이션 설계부터 데브옵스 모범 사례, 고객과의 상호작용에서 Azure 플랫폼 기능과 Azure 도구, 기술 문서에 이르기까지 많은 교훈을 적용할 수 있었다.
하지만 몇 가지 질문과 문제가 계속해서 뒤따랐다. 예를 들자면 이런 질문이다. 개발 머신에서 돌아가는 것이 클라우드 환경에서도 돌아갈 것이라고 어떻게 보장할 수 있을까? 한 구성 요소에 대한 사소한 변경이 있는 경우 전체를 업데이트하지 않도록 애플리케이션 구조를 어떻게 짜야 할까? 다운타임 없이 가능한 빨리 업데이트를 배포하는 방법이 뭘까? 구성과 환경 변경은 어떻게 다뤄야 할까?
2013년에 이러한 도전을 다루며 아키텍처적 접근 방식으로 마이크로서비스를 사용하는 넷플릭스와 아마존, 다른 사업체에 관해 많은 업계 리더, 고객과 얘기하기 시작했다. 성공적인 아키텍처들(내부 및 외부 고객)과 하나씩 비교했고 그들이 이미 마이크로서비스 패턴의 많은 특성을 구현했다는 것을 알았다. 예를 들어 작업량을 기준으로 한 클라우드 서비스 애플리케이션 설계나 애플리케이션을 개별 컴포넌트/서비스의 수명을 갖는 다수의 서비스로 분해하는 것 등이다. 분명히 아키텍처는 이러한 방향으로 진화하고 있었고, '마이크로서비스'라는 용어가 대중화 됐을 때 많은 아키텍트와 개발자는 자신들이 이 방향으로 향하고 있음을 알았다.
도커(Docker)로 들어가 보자. 도커는 배포에 따른 부하와 하나의 서비스를 하나의 호스트에 배치하는 비용을 줄인다. 배포 부하가 줄어들면 마이크로서비스 아키텍처에서 늘어나는 공통 서비스의 배포를 관리하고 폴리글랏(polyglot) 환경에서 배포 메커니즘을 표준화하는 데 도움을 준다. 컨테이너와 함께 클라우드 환경에서 제공하는 프로그래밍 인프라는 마이크로서비스 아키텍처로 가는 길을 깔았다.
그러나 알맞은 아키텍처 접근 방식과 도구가 방정식의 절반이고, 개발/테스트 환경 구성과 데브옵스 플로우 자동화, 가상 머신들에서 도커 컨테이너를 지휘하고 계획하는 방법과 다른 서비스에서 마이크로서비스를 발견하는 방법, 해당 환경과 서비스를 모니터링하는 방법에 관한 개념적 사고가 나머지 절반을 이룬다.
우리는 최근 2년 동안 도커를 위한 Visual Studio 도구 세팅 엔지니어링 팀과 Azure 서비스 패브릭 컴퓨트(Service Fabric Compute) 엔지니어링 팀 양쪽에서 마이크로서비스와 도커 시나리오를 다루거나 다른 고객들과 작업했다.
어렵게 배운 교훈을 공유하고 Azure에서 도커를 사용해 마이크로서비스를 만드는 데 필요한 도구를 제공하고자 한다.
